আপনি কীভাবে গ্রহণযোগ্যতার মানদণ্ড ছাড়াই সফটওয়্যার বিকাশ করবেন?


70

আপনি কীভাবে সম্মতিসূচক মানদণ্ড ছাড়াই 4-5 বিকাশকারীদের একটি দলে সফটওয়্যার বিকাশ করবেন, পরীক্ষকরা কী পরীক্ষা করবেন এবং একাধিক (৩-৩) লোকেরা কীভাবে পণ্যের মালিক হিসাবে কাজ করবে তা জেনেও না।

আমাদের সমস্ত কিছু স্ক্রিন শট এবং কয়েকটি বুলেট পয়েন্ট সহ একটি স্কেচি 'স্পেক'।

আমাদের বলা হয়েছে যে এটি সহজ হবে তাই এই জিনিসগুলির প্রয়োজন হয় না।

আমি কীভাবে এগিয়ে যেতে পারি তার ক্ষতিতে আছি।

অতিরিক্ত তথ্য

আমাদের একটি কঠিন সময়সীমা দেওয়া হয়েছে।

গ্রাহক অভ্যন্তরীণ, তত্ত্বের সাথে আমাদের একটি পণ্যের মালিক রয়েছে তবে কমপক্ষে ৩ জন লোক সফ্টওয়্যারটি পরীক্ষা করে কোনও কাজের আইটেম ব্যর্থ করতে পারে কারণ এটি কাজ করে যে তারা কীভাবে ভাববে তা কাজ করে না এবং তারা কী প্রত্যাশা করে বা স্বচ্ছতার কিছুটা কম নেই এটি ব্যর্থ না হওয়া পর্যন্ত তারা আসলে কী জন্য পরীক্ষা করছে।

পণ্যের মালিক (গুলি) প্রশ্নের উত্তর দিতে বা প্রতিক্রিয়া জানাতে সহজেই উপলভ্য নয়। তাদের সাথে নিয়মিত কোনও নির্ধারিত সভা বা কল নেই এবং প্রতিক্রিয়াগুলি কয়েক দিন সময় নিতে পারে।

আমি বুঝতে পারি যে আমাদের একটি নিখুঁত বৈশিষ্ট্য থাকতে পারে না তবে আমি ভেবেছিলাম যে প্রতিটি স্প্রিন্টে আমরা আসলে যে জিনিসগুলিতে কাজ করছি তার গ্রহণযোগ্যতার মানদণ্ড থাকা 'স্বাভাবিক' হবে।


33
আমি বলব, আপনি চান তবে এটি বিকাশ করুন। যতক্ষণ আপনি কোনও মিটিংয়ে যেতে স্বাচ্ছন্দ্যবোধ করেন এবং আপনার পণ্য কীভাবে স্কেচী "স্পেক" এবং স্ক্রিনশটগুলির সাথে মেলে তা দেখানোর জন্য, আমি মনে করি আপনি ঠিক আছেন। অবশ্যই, আপনি সবসময়ই বিশদটির স্রষ্টাকে আরও বিশদে জানতে চাইতে পারেন ...
হতাশাগ্রস্থ

10
মূলত এটি স্বশাসিত বিকাশ বা "কাউবয় কোডিং"। বিকাশকারীরা বিশদটি পূরণ করে। বিকাশকারীদের সংখ্যাগরিষ্ঠ নিয়ন্ত্রণ রয়েছে। মূলত আপনার কখনও আনুষ্ঠানিক প্রয়োজনীয়তা থাকবে না। স্ট্যাকহোল্ডার (গুলি) এর জন্য ডেমো বিকাশ করুন, প্রতিক্রিয়া সংগ্রহ করুন, ধুয়ে ফেলুন এবং পুনরাবৃত্তি করুন।
জন রেয়নর

11
পণ্যের মালিক কী বোঝেন যে এটি ব্যয় এবং সময় সর্পিলকে উচ্চ এবং উচ্চতর নিশ্চিত করার জন্য একটি দুর্দান্ত উপায়? কম্পিউটারবিহীন বিজ্ঞানীরা, প্রায়শই ভাল লিখিত পরিষ্কার স্পেসিফিকেশনগুলির গুরুত্ব বুঝতে পারেন না। উদাহরণস্বরূপ, মার্কিন সরকার প্রায়শই একই জাতীয় সমস্যাগুলিতে চলে আসে, যখন তারা নতুন সামরিক হার্ডওয়্যারের জন্য প্রত্যাশা পরিবর্তন করে। সামরিক হার্ডওয়্যার প্রায়শই ওভারবজেট এবং সময়সূচী পিছনে থাকায় এটি বেশ কয়েকটি কারণ। joelonsoftware.com/2000/10/02/…
নিকালহ

35
"আমাদের বলা হয়েছে যে এটি সহজ হবে সুতরাং এই জিনিসগুলির প্রয়োজন নেই। ... আমাদের একটি কঠোর সময়সীমা দেওয়া হয়েছে। ... পণ্যের মালিক (গুলি) কোনও প্রশ্নের উত্তর দিতে বা প্রতিক্রিয়া জানাতে সহজেই উপলভ্য নয়। কোনও নিয়মিত তফসিলযুক্ত সভা বা তাদের সাথে কল এবং প্রতিক্রিয়া আসতে সময় নিতে পারে না। " আপনার আমার সহানুভূতি আছে এগুলির বৈশিষ্ট্য হ'ল "সফ্টওয়্যার রাইটিং কীভাবে কাজ করে তা ধারণা নেই" "
jpmc26

13
আপনি ব্যর্থতার জন্য সেট আপ করা হয়েছে। এটি সেই ধরণের জিনিস যা পরিচালনায় আরও বাড়ানো দরকার। আপনার যদি নির্দিষ্ট সময়সীমা না থাকে তবে আপনি সফল না হওয়া পর্যন্ত পুনরাবৃত্তি করতে পারবেন। যদি স্টেকহোল্ডাররা প্রতিক্রিয়ার জন্য উপলব্ধ ছিল, আপনি সময়সীমার দ্রুত আঘাত (সম্ভবত) শেষ করতে পারতেন hit মূলত যুক্তিসঙ্গতভাবে বিশদ বিবরণ থাকার জন্য ডিট্টো। তবে কিছু দিতে হবে । এটি সেই অংশ যেখানে আপনি আপনার মনিবকে আগুন থেকে আপনার @ pull টানতে খুব সুন্দরভাবে জিজ্ঞাসা করছেন।
জেরেদ স্মিথ

উত্তর:


130

একটি পুনরাবৃত্তি প্রক্রিয়া বিশদ বিবরণ ছাড়াই এটিকে সুন্দরভাবে অর্জন করবে।

কেবল একটি স্কেচি প্রোটোটাইপ তৈরি করুন, গ্রাহকের কাছ থেকে প্রতিক্রিয়া জিজ্ঞাসা করুন, প্রতিক্রিয়ার ভিত্তিতে পরিবর্তন করুন এবং অ্যাপ্লিকেশন শেষ না হওয়া পর্যন্ত এই প্রক্রিয়াটি পুনরাবৃত্তি করুন।

গ্রাহক এইভাবে এটি করার জন্য যথেষ্ট ধৈর্যশীল কিনা তা ভিন্ন প্রশ্ন। কিছু ক্লায়েন্ট এবং বিকাশকারীরা এই প্রক্রিয়াটি আসলে পছন্দ করে; যেহেতু গ্রাহক সর্বদা হাতছাড়া থাকে, তাই (শেষ পর্যন্ত) সে যা চায় ঠিক তা পাবে।

আপনি এইভাবে কোনও নির্দিষ্ট-ব্যয় বা নির্দিষ্ট সময়ের চুক্তিতে কাজ করছেন না এমনটি না বলেই যাওয়া উচিত।


114
একটি যুক্ত করা উচিত: "কেবলমাত্র প্রতি ঘন্টা আপনাকে অর্থ প্রদান করা হবে তা নিশ্চিত করুন", এবং "ক্লায়েন্টের অনুপস্থিত ধারণাগুলির বাইরে চলে গেলে কেবল অর্থ প্রদান করা হয় না"।
ডক ব্রাউন

22
গ্রাহক কী ভাবছেন তাও নথিভুক্ত করার বিষয়টি নিশ্চিত করুন, যাতে এটি কমপক্ষে কোথাও নোটগুলিতে বন্দী থাকে। এটি আনুষ্ঠানিক গ্রহণযোগ্যতার মানদণ্ড নাও হতে পারে তবে আপনি যখন পরবর্তী পদক্ষেপগুলি আসলে করার চেষ্টা করছেন তখন তা যথেষ্ট প্রাসঙ্গিক ..
এন্ডারল্যান্ড

4
@ ডক ব্রাউন: "গ্রাহক অভ্যন্তরীণ" যোগ করতে ওপি সম্পাদনা করেছেন - তাই এই মুহুর্তের মাধ্যমে প্রদান আশা করি কোনও সমস্যা নয়।
sleske

8
+1 অনেকগুলি অভ্যন্তরীণ প্রকল্পের জন্য এই প্রক্রিয়াটি অনুসরণ করেছে এবং এটি দেখতে পেয়েছে যে এটি সত্যিই ভালভাবে কাজ করে এবং সর্বোপরি সামগ্রিক সময়-সঞ্চয়কারী। একটি টিপ হল পুনরাবৃত্তিগুলি সংক্ষিপ্ত রাখা: এক বা দুই সপ্তাহ।
বব টাও

13
আমার অভিজ্ঞতা হ'ল এটি কার্যকরভাবে কাজ করে যখন আনুষ্ঠানিক গ্রহণযোগ্যতার মানদণ্ডের অভাবের কারণ হ'ল কেউ সত্যই নিশ্চিত হন না যে তারা আসলে কী চান। প্রোটোটাইপগুলি তাদের মতামত গঠনে সহায়তা করে এবং আপনি স্বীকার করেন যে আপনি একটি বড় অনিশ্চিত কাজ হাতে পেয়েছেন। তবে এটি মোটামুটি খারাপভাবে কাজ করে যখন কারণটি হ'ল স্টেকহোল্ডাররা কী চান তা নিয়ে ভাবনা / কথা বলার / লেখার সময় খুঁজে পাচ্ছেন না, বা যেখানে স্টেকহোল্ডাররা বিরোধী প্রয়োজনীয়তা রয়েছে যেগুলি রাজনৈতিক কারণে তারা স্পষ্টভাবে বলতে পারে বলে মনে করেন না। তারপরে একটি প্রোটোটাইপ কেবল রাস্তায় ক্যানটিকে লাথি মারে এবং কোনও স্টাথ স্টিক না পাওয়া পর্যন্ত কিছুই উন্নত হয় না।
স্টিভ জেসোপ

58

আপনি যা বলছেন তা যদি সত্য হয় এবং অনুমান করা আপনার পক্ষে এমনকি শুরু করার পক্ষে যথেষ্ট ভাল নয় তবে (এবং আপনি এই মূল্যায়নে সৎ হচ্ছেন), আমি এই প্রতিবেদনটি সুপারিশ করছি:

  1. আপনাকে দেওয়া হয়েছে এমন স্কেচগুলি এবং "স্কেচি" অনুমানটি পড়ুন।
  2. আপনার নিজস্ব অনুমানটি এমন একটি স্তরে লিখুন যা কোড করার জন্য আপনার পক্ষে যথেষ্ট । আপনাকে এক টন অনুমান করতে হতে পারে।
  3. পর্যালোচনার জন্য গ্রাহককে আপনার স্পেক প্রদর্শন করুন। তারা যে অংশগুলি পছন্দ করেছে তা নোট করুন এবং যে অংশটি তারা মনে করেন যে আপনি এটি ভুল করেছেন on
  4. আপনি এবং গ্রাহক একত্রে না হওয়া পর্যন্ত 2 এবং 3 পদক্ষেপ পুনরাবৃত্তি করুন।
  5. আপনার এখন পর্যাপ্ত পরিমাণ রয়েছে।

যদি আপনার গ্রাহক "যখন এটি সহজ হবে" বলেছিলেন তখন তারা যদি ঠিক থাকে তবে এই অনুশীলনটি একটি কেকের টুকরো হওয়া উচিত।

যদি আপনার গ্রাহকটি ভুল ছিল এবং প্রকৃতপক্ষে প্রয়োজনীয়তাগুলির মধ্যে সমস্ত ধরণের গোটাছা এবং শূন্যতা রয়েছে তবে আপনার খসড়া স্পেসিফিকেশনটি সমস্যাটি দ্রুত চিত্রিত করবে এবং তাদের সাথে যোগাযোগ করবে যে তারা ভুল ছিল (আপনার কোনও আঙুল বা তর্ক করার দরকার নেই) কারণ এটি হবে ঠিক তাদের সামনে এবং সুস্পষ্ট হতে। এছাড়াও, আপনার স্পষ্ট those অস্পষ্টতাগুলি সমাধান করার জন্য একটি দুর্দান্ত আলোচনার সরঞ্জাম হিসাবে পরিবেশন করবে এবং আপনি তাদের প্রতিক্রিয়া দিয়ে এটি সংশোধন করার সাথে সাথে মূল সিদ্ধান্তগুলির রেকর্ড হিসাবে কাজ করবেন।


27
কখনও কখনও আপনি "স্পেক" (পরিবর্তে গ্রাহকদের ক্ষেত্রে) পরিবর্তে আপনার অনুমানটিকে "কাজের সময়সূচী" (যা তাদের নন-প্রোগ্রামার মস্তিস্কের কোনও প্রকল্পের জন্য বন্ধুত্বপূর্ণ এবং দরকারী জিনিস হিসাবে গ্রহণ করে) বলে গ্রাহককে প্রতারনা করতে পারেন which এর মতো যারা বিকাশের প্রক্রিয়াতে নিযুক্ত হওয়ার সমস্ত মৌলিক নীতিগুলির বিরোধী, তাদের অ-প্রোগ্রামার মস্তিষ্করা পেডেন্টিক পেপারওয়ার্কের এক ক্লান্তিকর অংশ হিসাবে ভাবেন যা প্রোগ্রামাররা তাদের কোনও অকারণে করতে দেয়)।
স্টিভ জেসোপ

দ্বিতীয় পয়েন্টে, আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি কেবল বিকাশকারীর জন্য প্রযুক্তিগত স্পেসটি লিখুন। অন্যথায়, বিকাশকারী তার কাজ শুরু করতে অক্ষম হবে। এইভাবে, আপনি যে ব্যবসায়ের বিকাশ হতে চলেছে তার সমান্তরালে ব্যবসায় দলের সাথে সহযোগিতা করতে পারেন। এইভাবে বিকাশ এবং ব্যবসায়িক দল উভয় প্রয়োজনীয়তার সাথে একে অপরের সাথে সিঙ্ক হয়ে যায়।
করণ

3
your draft specification will quickly illustrate the problem and communicate to them that they were wrong (....) since it will be right in front of them and obvious- আমি উল্লেখ করতে চাই যে ক্লায়েন্টরা যারা বুঝতে পারেন যে এই সমস্ত স্পষ্টভাবে হ'ল সেই ক্লায়েন্ট যাদের সাথে আপনার কখনই সমস্যাটি শুরু হবে না। বা এটি আরও
দৃc়তার সাথে বলতে

1
কিছু ভাবেন যাঁরা কখনও "এটি পাবেন না", তবে আমার অভিজ্ঞতায় এটি আপনার প্রয়োজনীয় স্তরের বিশদর উদাহরণ প্রদর্শন করতে এবং প্রয়োজনীয়তাগুলি করার সময় আপনি যে ধরণের "ভুল" সিদ্ধান্ত নিতে পারেন তা তাদের প্রদর্শন করতে সহায়তা করে the দ্ব্যর্থক।
জন উ

18

পণ্য মালিক আপনাকে একটি প্রোটোটাইপ দিয়েছেন; তাকে আরও ভাল করে ফিরিয়ে দিন (যতক্ষণ না আপনার কাজ শেষ হয়)

দেখে মনে হচ্ছে আপনাকে প্রকল্পটি শুরু করার জন্য একটি কাগজ প্রোটোটাইপ সরবরাহ করা হয়েছে। এটি কোনও ভয়ানক সূচনা নয়। আমি আপনাকে একই ভাষাতে ব্যবসায়ের মালিকের সাথে যোগাযোগ করার পরামর্শ দিচ্ছি , প্রগতিশীল সক্ষম প্রোটোটাইপ সরবরাহ করে by

আপনার প্রোটোটাইপগুলি কাগজ দিয়ে শুরু হওয়া উচিত, ডিজিটাল মকআপগুলিতে সরানো উচিত এবং তারপরে "বাস্তব" প্রযুক্তি দিয়ে তৈরি করা উচিত।

ট্রি হাউস এর জন্য একটি দুর্দান্ত গাইড রয়েছে, যা শেষ হয়:

ফ্রেমওয়ার্কের সাথে প্রোটোটাইপিংয়ের দুর্দান্ত জিনিসটি হ'ল প্রোটোটাইপটি প্রায়শই আসল সাইট হয়ে যায় কারণ কাঠামো এবং স্টাইলিং ইতিমধ্যে স্থানে রয়েছে। যদি একই ফ্রেমওয়ার্ক ব্যবহার করা হয় তবে স্ক্র্যাচ থেকে সাইটটি পুনরায় তৈরি করার দরকার নেই।

আপনি কোনও আনুষ্ঠানিক স্পেসিফিকেশনও সরবরাহ করতে পারেন, বিশেষত যদি আপনি কোনও খারাপ ফলাফলের জন্য দোষী হওয়ার বিষয়ে উদ্বিগ্ন থাকেন। তবে আপনি সম্ভবত প্রোটোটাইপগুলি থেকে আরও প্রতিক্রিয়া পাবেন।

আপনার সময়সীমা পূরণ

নোট করুন যে আপনার পরবর্তী প্রচেষ্টাগুলি সর্বোপরি ধ্রুপদী "প্রোটোটাইপস" হবে না, কারণ সেগুলি নিষ্পত্তিযোগ্য হবে না (বা তাদের অংশগুলি হবে না)। শেষ, সর্বাধিক সক্ষম, পুনরাবৃত্তি আপনার সময়সীমা আপনার বিতরণযোগ্য হয়ে ওঠার আগে শেষ করে।

আপনার সময়সীমাটি আপনার কাছে সর্বাধিক সংজ্ঞায়িত প্রয়োজনীয়তা। সম্পূর্ণ এবং সুসংগত কিছু আছে যা আপনি সময়মতো বিতরণ করতে পারেন।

আপনার পরীক্ষকদের সাথে সহযোগিতা করুন

যদি এই শিথিল প্রক্রিয়াটি আপনার সংস্থার জন্য একটি নতুন জিনিস হয় তবে আপনার পরীক্ষকরা আপনার চেয়ে সম্ভবত আরও বেশি ক্ষতির মুখোমুখি হবেন এবং আপনাকে গাইডেন্সের জন্য খুঁজছেন । প্রক্রিয়া শুরুতে আপনি তাদের কিছু সময় পেয়েছেন। তাদের মনিবকে জানতে দিন যে আপনি আনুষ্ঠানিক গ্রহণযোগ্যতার মানদণ্ড না পেয়ে তাদের অর্থবহ পরীক্ষা দিতে সহায়তা করার চেষ্টা করছেন।

পরীক্ষকগণের কাছে তাদের সরবরাহের প্রয়োজনীয় কোনও দৃ have়তা আছে কিনা তা খুঁজে নিন যেমন পরীক্ষার প্রুফ-ডকুমেন্টেশন, যা আপনি "ফিরে যেতে" পারেন।

পরীক্ষার প্রথম নকশা চেষ্টা করুন

যেহেতু আপনার কোনও আনুষ্ঠানিক প্রয়োজনীয়তা নেই, তাই পরীক্ষার কেসগুলি বিকশিত হওয়ার জন্য কিছু কাঠামো সরবরাহ করবে।

নিজেকে টেস্ট ফার্স্ট ডিজাইন এবং / অথবা পরীক্ষা চালিত বিকাশের সাথে একটি উত্তীর্ণের পরিচয় দিন এবং প্রয়োজনীয় হিসাবে প্রক্রিয়াটি সম্পর্কে আপনার পরীক্ষকগণকে গাইডেন্স দিন। এর মতো দ্রুত প্রকল্পের জন্য, আপনাকে প্রক্রিয়াটিতে বিশেষজ্ঞ হওয়ার দরকার নেই। তবে একটি প্রমাণিত পদ্ধতি ব্যবহার আপনার এবং আপনার পরীক্ষকদের ভাল প্রতিফলিত করবে।

বিশেষত ইউআইয়ের জন্য মানকে আঁকুন

চেহারা এবং অনুভূতি সম্পর্কে আপনার কোনও প্রয়োজনীয়তা নেই তবে আপনার একটি সময়সীমা রয়েছে। পেশাদার দেখা শিল্পকর্ম তৈরি করতে আপনার যে কাজটি করা দরকার তা হ্রাস করতে অন্য কারও ডিজাইনের কাজটি ব্যবহার করুন।

আপনার সাইটের জন্য একটি মানক UI চয়ন করুন এবং নির্দেশ না দেওয়া পর্যন্ত এটিকে কাস্টমাইজ করবেন না। আপনি কোন প্লাটফর্মটির জন্য বিকাশ করছেন তা আমি জানি না তবে বুটস্ট্র্যাপ বা গুগল মেটেরিয়াল ডিজাইন দুটি উদাহরণ।

যোগাযোগ করুন, তবে পেস্টার করবেন না

আমি পণ্য মালিককে একদিন একটি ইমেল প্রেরণের পরামর্শ দেব। এটি জরুরি হলে কেবল তার চেয়ে বেশি প্রেরণ করুন।

আপনার যদি প্রশ্ন থাকে, আপনি যদি নির্দেশনা না পান তবে কীভাবে আপনি এগিয়ে যাবেন তা বর্ণনা করুন। উদাহরণ স্বরূপ:

এই অ্যাপ্লিকেশনটির ব্যবহারকারীদের কি মোবাইল ডিভাইসগুলি দিয়ে এটি অ্যাক্সেস করা দরকার? এই মুহূর্তে আমরা ধরে নিচ্ছি যে এটি কেবল একটি ডেস্কটপ / ল্যাপটপ সিস্টেম হবে।

আতঙ্কিত হবেন না

আমি "প্রয়োজনীয়তা" শব্দটি জানতাম না এমন লোকদের জন্য প্রচুর প্রকল্পে জড়িত ছিলাম Most বেশিরভাগ সফল হয়েছিল। হ্যান্ডস অফ পণ্য মালিকরা আপনাকে দুর্দান্ত সমাধানগুলি তৈরি করতে অক্ষাংশ দেয়।

দ্রষ্টব্য, এই প্রকল্পগুলির কিছু প্রকল্পের মালিকদের খুশি করা অসম্ভব ছিল এবং তাদের অক্ষমতার অজুহাত দেখিয়ে "আমি খুব ব্যস্ত ..." এর আড়ালে লুকিয়ে রেখেছিলাম। তবে বেশিরভাগই শেষ ফলাফলের সাথে "আনন্দিত" ছিলেন।


উল্লেখ করা হয়নি এমন একটি বিষয় হ'ল হার্ড ডেডলাইন: এটি গুরুত্বপূর্ণ হবে যে সেই তারিখে কিছু বিতরণ করা হয়েছে এবং এটি কাজ করে (গতিগুলির মধ্য দিয়ে যায়), এমনকি যদি ঘণ্টা, শিসফেল এবং দ্রুত গতির দাগগুলি অনুপস্থিত থাকে। এই সীমাবদ্ধতার জায়গায় রেখে, @ টিম যে সমস্ত পয়েন্টগুলি তৈরি করে সেগুলি ঠিক ঠিক হওয়া উচিত
ফিলিপ ওকলি

ফিলিপ ওকলি, প্রতিক্রিয়াটির জন্য ধন্যবাদ আমি পুনরাবৃত্তিমূলক প্রোটোটাইপিং প্রক্রিয়া সম্পর্কে একটি পয়েন্ট যুক্ত করেছি যাতে একটি মিসড সময়সীমা রোধ করতে ক্রমবর্ধমানভাবে গ্রহণযোগ্য "বিতরণযোগ্য" উত্পাদন করা উচিত। যদি এটি সাহায্য করে তবে আমাকে জানান।
টিম গ্রান্ট

এটি একটি উন্নতি। এমনকি আরও জরুরি হয়ে উঠতে এমনকি 'সভা' থেকে 'সভা' তে পরিবর্তন করুন। তারপরে সম্ভবত এই বিবৃতিটি যুক্ত করুন যে তারা যদি অন্য জিনিসগুলি ছাড়াই একটি তারিখ দেয় তবে তা মূল প্রয়োজনীয়তা হয়ে যায়, যাতে নিম্নলিখিত 'নোট' এর প্রসঙ্গ থাকে। (প্রায়শই গ্রাহকরা কেবল সময় এবং ব্যয় নিয়েই উদ্বিগ্ন থাকেন, বাকিটি প্রসাধনী এবং ফ্যাশন, যেমনটি আমি নিশ্চিত যে আপনি জানেন ;-)
ফিলিপ ওকলি

10

একটি প্রকল্প হ'ল নিশ্চিততা অর্জন না হওয়া পর্যন্ত অনিশ্চয়তা হ্রাস করার কাজ :

  • শুরুতে সবসময় কিছুটা অনিশ্চয়তা থাকে। কখনও কখনও এটি প্রয়োজনীয়তাগুলির মধ্যে একটি সামান্য অস্পষ্টতা। কখনও কখনও, এটি খুব কৌতুকপূর্ণ। আপনাকে কাজের অংশ হিসাবে কাজ করতে হবে।
  • কৌশলটি পুনরায় এই অনিশ্চয়তা (বিশ্লেষণ, নকশা ও বাস্তবায়নের সংমিশ্রণ) হ্রাস করা, ব্যবহারকারীর গল্পগুলিকে পরিমার্জন করা এবং আপনার সিস্টেমটি প্রয়োগ করা।
  • পরীক্ষার কেস / পরিস্থিতি এবং গ্রহণযোগ্যতার মানদণ্ডগুলি একইভাবে পরিষ্কার করতে হবে। তারা গুণমান এবং নির্ভুলতা সম্পর্কে অনিশ্চয়তা হ্রাস করতে অবদান রাখবে (অন্যান্য মধ্যে)।
  • শেষে, পর্যাপ্ত নিশ্চয়তা পৌঁছে যায়: গ্রাহক একটি পরীক্ষিত পণ্য পান যা তার প্রয়োজনের সাথে খাপ খায় এবং এটি ব্যবহার করা যায়।

এটি প্রগতিশীল সম্প্রসারণের মূলনীতি: প্রয়োজনীয়তা, মানদণ্ড এবং ফলাফল ধাপে ধাপে বিশদভাবে বর্ণিত হবে, যেমন গ্রাহক তার নিজস্ব প্রত্যাশা এবং প্রয়োজনীয়তাগুলি বিকাশ প্রক্রিয়াতে জড়িত হওয়ার মাধ্যমে করবেন।

এটা কি কোন সমস্যা?

স্কেচিয়ার প্রাথমিক প্রয়োজনীয়তাগুলি, অনিশ্চয়তা তত বেশি এবং কার্য সম্পাদন করার জন্য প্রয়োজনীয় সময় তত বেশি। সুতরাং অতিরিক্ত কাজটি কে করবে এবং কে ব্যয় করবে তার বিষয়টি ঠিক।

এই দুটি প্রশ্নের উত্তর চুক্তিতে থাকা উচিত। বা একটি আলোচনার বিষয় হতে পারে। এবং গ্রাহককে অবশ্যই অতিরিক্ত জড়িততা গ্রহণ করতে হবে (মূল যুক্তি হবে "আবর্জনা ফেলা, ময়লা ফেলা", যদিও আমি আপনাকে আরও কূটনৈতিক উপায়ে উপস্থাপনের জন্য দৃ strongly়ভাবে পরামর্শ দিচ্ছি ;-))


1
আমি প্রথম বাক্যটি পছন্দ করি। এটির বুকেএন্ডটি হ'ল গ্রাহক: 1) তারা কী চান তা নিশ্চিত হতে পারে না, 2) তারা যাওয়ার সাথে সাথে তাদের মন পরিবর্তন করে, 3) অ্যাক্সেসযোগ্য কিছু চায়। তবে এটি যদি আসলে একটি সাধারণ প্রকল্প হয় তবে এটির সাফল্যের ভাল সম্ভাবনা রয়েছে।

1
এই এক সোনার।
ব্রুনো গার্ডিয়া

8

" কোনও নিয়মিত তফসিল সভা নেই "। ঠিক আছে, তাহলে আপনি কেন নিয়মিত সভাগুলির সময় নির্ধারণ করে শুরু করবেন না ? আপনার একাধিক পণ্যের মালিকদের একা গ্যারান্টি দেয় যে আপনার প্রকল্পটি সহজ হবে না, কারণ এই লোকগুলির প্রত্যেকের বিবাদমান প্রয়োজনীয়তা থাকবে যা উপস্থিত সমস্ত স্টেকহোল্ডারদের সাথে ব্যক্তিগতভাবে আলোচনা করা উচিত।

অতিরিক্তভাবে, আমি সত্যিই, সত্যিই, আপনাকে একটি বিস্তারিত সিদ্ধান্ত লগ রাখার প্রস্তাব দিই । সিদ্ধান্ত নেওয়ার সময় উপস্থিত থাকা ব্যক্তিদের একটি তারিখ এবং তালিকা সহ খুব ন্যূনতমতম সময়ে আপনি যে কোনও সিদ্ধান্ত নিয়েছেন তা লিখে রাখুন। আরও ভাল আপনি যদি লিখতে পারেন তবে কেন কিছু ঠিক করার সিদ্ধান্ত নেওয়া হয়েছিল। এটি আপনার পিসিতে কোনও ফাইল, আপনার ইন্ট্রানেট উইকের কোনও পৃষ্ঠা, বা আপনার ডেস্কের একটি নোটবুক কিনা তা বিবেচ্য নয়। লগটি আপনাকে এবং প্রকল্পকে সুরক্ষা দেয়: যখন পরীক্ষক কোনও আইটেম "ব্যর্থ" হন, আপনি চিহ্নিত করতে পারেন যে এই লোকগুলির সাথে এইভাবে সিদ্ধান্ত নেওয়া হয়েছিল, এবং এটি আপনার সমস্যা নয় তবে তাদের এবং পরীক্ষকদের মধ্যে। এটির ফলে যদি চশমাগুলি পরিবর্তিত হয় তবে জরিমানা, তবে এই মুহুর্তে তারা তাদের মনে যে কোনও সময়সীমা মেটানোর আশা করতে পারে না - বা তাদের অবশ্যই সুযোগটি অন্য কোথাও কাটাতে হবে।


8

স্পষ্ট প্রয়োজনীয়তা ছাড়া একটি প্রকল্প, আলগা নেতৃত্ব, সম্পন্ন (DoD) কোন সংজ্ঞা, কোন এক নিশ্চিত করুন যে আপনি তথ্য আপনি একটি সময়োপযোগী ফ্যাশন আপনার কাজ এবং পূরণের প্রয়োজন আছে উপার্জন কাছে জবাবদিহি করতে ইচ্ছুক তাদের নির্দিষ্ট সময়সীমা প্রোজেক্টের জন্য একটি রেসিপি ব্যর্থতা.

আইট্রেটিভ বিকাশ একটি খারাপ পরামর্শ নয়, তবে এর জন্য পণ্যের মালিক এবং বিকাশকারীদের মধ্যে ঘনিষ্ঠ সহযোগিতা প্রয়োজন। এই হুকের উপর কাউকে বলার চেষ্টা করুন, "আমরা জানি যে আমাদের কাছে প্রশ্ন রয়েছে Who প্রকল্পের সরবরাহ দেরি না হওয়ার কারণে যারা উত্তর পেয়েছেন তা নিশ্চিত করার জন্য নিয়মিত কে উপলব্ধ থাকতে পারেন?" অগ্রগতি পর্যালোচনা করতে এবং প্রতিবন্ধকতাগুলি সরিয়ে নিতে কারও সাথে নিয়মিত সময় নির্ধারণ করুন। যদি তারা না দেখায়, বা প্রত্যাখ্যান করে না, তবে ভদ্র লিখিত চিঠিপত্র এবং দস্তাবেজ বিলম্ব বা প্রতিক্রিয়াবিহীন অনুসরণ করুন। যদি পণ্য মালিকরা উপলব্ধ নাও হন, তাদের হতে পারে এমন একটি প্রতিনিধি সরবরাহ করতে বলুন।

এছাড়াও, পুনরাবৃত্তিমূলক বিকাশের আরেকটি বৈশিষ্ট্য হ'ল প্রয়োজনীয়তাগুলিতে পরিবর্তন সময়রেখার পরিবর্তনের প্রয়োজন। আপনি সময়সীমাটি বিকাশ করতে না পারলে আপনি একটি সময়সীমাটি পূরণের প্রতিশ্রুতি দিতে পারবেন না এবং আপনি কী করার দরকার তা সম্পর্কে ভাল ধারণা না থাকলে আপনি একটি সময়রেখা বিকাশ করতে পারবেন না। কৌতুকপূর্ণভাবে কোনও অনুমানের জন্য জিজ্ঞাসা করার পরিবর্তে, বর্তমান অনুমানটি পর্যালোচনা করুন, আপনার বা টিমের কীভাবে কাজ করা উচিত তা সম্পর্কিত কোনও প্রশ্ন নথি করুন, পণ্য মালিকদের সাথে এটি আলোচনা করার জন্য সময় নির্ধারণ করুন, এবং উত্তরগুলি নথিবদ্ধ করুন। আপনি হয়ে গেলে, আপনার সিদ্ধান্তগুলির ভিত্তিতে আপনার স্পেসিফিকেশনগুলি থাকে, যা আপনি তখন পণ্য মালিকদের সাথে (লিখিতভাবে) সম্মতি জানাতে পারেন। একটি স্পপের উদ্দেশ্য হ'ল অস্পষ্টতা অপসারণ এবং একটি ডিওডি তৈরি করা, যা একটি প্রশ্নোত্তর পর্বটি ঠিক কী সরবরাহ করতে পারে। যদি কোনও অনুমানের বিরোধিতা থাকে তবে এটিকে একটি অনুমান বলবেন না।

কাউকে বিশ্বাস করবেন না যখন তারা আপনাকে বলবে এটি সহজ হবে । কখনও কখনও এটি সত্যিই যেমন শোনাচ্ছে হিসাবে সহজ, এবং আমি এই বিশ্বাস করতে পারে যদি (এবং শুধুমাত্র যদি ) আমি পণ্য মালিকদের ভাল সম্পূর্ণরূপে বিশ্বাস করতে যে প্রয়োজনীয়তা সত্যিই হিসাবে সহজ তারা যা বলে তারা হয় যথেষ্ট জানি, এবং চশমা আমি হয়েছে প্রদত্ত স্ব-ব্যাখ্যামূলক (যদি তা না হয় তবে আমি একটি প্রশ্নোত্তর সেশনটি শিডিউল করি এবং এটি নথি করি)। আমি অনেক পরিস্থিতিতে পড়েছি যেখানে অপারেশন দৃষ্টিকোণ থেকে সহজ অবিশ্বাস্যরকম কঠিনবিকাশের দিক থেকে, বা আপনি মনে করেন আপনি সম্পূর্ণ হয়ে গেছেন এবং হতাশার শব্দগুলি আপনি শুনতে পান ("ওহ, যাইহোক, আমরা ভুলে গিয়েছিলাম ...") " উদাহরণ ... "আপনাকে যা করতে হবে তা হ'ল ডকুমেন্ট রিপোজিটরির বাইরে এই পিডিএফ ফাইলগুলি পড়তে হবে", যা গ্রহণের পরীক্ষার সময় রূপান্তরিত হয়, "ওহ, আমরা ভুলে গিয়েছিলাম যে এগুলির কয়েকটি পুরোপুরি বেমানান উপায়ে পড়া হয়েছিল, এবং কারও কারওর পক্ষে ভুল পৃষ্ঠার আকার নির্ধারিত রয়েছে, এবং কারও কারও কাছে এই তিনটি পৃষ্ঠা সংযুক্ত করা দরকার এবং আমাদের একইগুলি প্রদর্শন করার জন্য এটি দরকার That এটি ঠিক করা ঠিক আছে, তাই না? "।

মুল বক্তব্যটি হ'ল এটি সত্যিই সহজ হতে পারে এবং একটি দ্রুত বৈঠকই তা নিশ্চিত করতে পারে, আপনাকে সমস্ত অনুমানের নথিভুক্ত করতে এবং সেগুলি সঠিক এবং সঠিক কিনা তা নিশ্চিত করতে পারে। আপনি তাদের কার্যকারী কোডটি লিখতে হবে যেগুলি তাদের প্রত্যাশা পূরণ করতে হবে এমন প্রতিবন্ধকতাগুলি সরিয়ে দেওয়ার জন্য আমি উঠে দাঁড়ানোর পরামর্শ দিচ্ছি, কারণ আপনি পায়ের আঙ্গুলের উপর ভর দিয়েই থাকুন না কেন, কেউ সম্ভবত শেষ পর্যন্ত অসন্তুষ্ট হবে। যদি আপনি প্রশ্নের উত্তর পেতে অবিচল থাকেন এবং কাউকে বিরক্ত করছেন, আপনি যখন প্রয়োজনীয় সময়ে প্রয়োজনীয় পণ্যগুলি যথাসময়ে বিতরণ করবেন তখন তারা এগুলি ভুলে যাবে। আপনি যদি স্পষ্টতা পেতে ব্যর্থ হন এবং বিতরণ না করেন তবে কেউই মনে রাখবেন না যে তারা আপনাকে সেগুলি বাগ না করার জন্য বলেছিল।


3

একটি অনুমান ছাড়া, আপনার দলবদ্ধ কাজ আছে। চটফটে যান।

পিও এবং মাংসের সাথে বসে কিছু / ছোট ছোট গল্প / আইস বের করুন। "আমরা কেবল এই স্ক্রিনটি সরবরাহ করতে চলেছি, কেবল এই বোতামটি 'বিং!' দিয়ে চলেছে" "। কিছু এসি সেট আপ করুন। গল্পটি পৌঁছে দিন। গল্পটি প্রদর্শন করুন। বোতামগুলি লাল হতে হবে Turn একটি বাগ বা একটি নতুন গল্প উত্থাপন। যে বোতামগুলি ঠাঁই হয়ে যায় তা বিতরণ করুন। ইত্যাদি।

সহযোগীভাবে ঘন ঘন প্রদর্শিত হয় যে ছোট উল্লম্ব টুকরোগুলি নির্দিষ্ট এবং বিতরণ।

যদি গ্রাহক আপনার সাথে এইভাবে কাজ করে না, তবে উপায় খুঁজে নিন।


-1

আপনি যেমন রূপরেখার কথা বলেছেন ঠিক তেমন প্রকল্পগুলি করার জন্য আমি বেশ কয়েকটি কাজ করেছি। আপনি কী ডিজাইনের সিদ্ধান্ত নিচ্ছেন এবং কেন সেগুলি আপনাকে নিতে হবে তা পিও যতক্ষণ না জানে, আপনার ভাল হওয়া উচিত। অন্যদিকে, তারা যদি নকশা সংক্রান্ত সিদ্ধান্তগুলি বুঝতে না পারে, তবে আপনাকে কমপক্ষে একটি লিখিত ব্যবহারকারী গ্রহণযোগ্যতা পরীক্ষার নথির জন্য এগুলি চাপতে হবে।


-2

আপনি কোড লেখা শুরু করার আগে আপনার একটি বিশদ, যাচাইযোগ্য স্পেকের প্রয়োজন। এটি একটি সত্য, এবং এটি কাছাকাছি পাওয়া যায় না।

অন্য কেউ যদি সেই অনুমানটি লিখতে রাজি না হয় তবে বিকাশকারীদের এটি লিখতে হবে। সুতরাং আপনি একটি অসম্পূর্ণ বৈশিষ্ট্য পেতে। আপনি এটিকে একটি সম্পূর্ণ বৈশিষ্ট্যে পরিণত করেন (যার অর্থ "অন্য কেউ আমাকে না বললে" এটিই আমি বাস্তবায়ন করতে যাচ্ছি ")। আপনি সেই অনুচ্ছেদটি স্টেকহোল্ডারদের হাতে তুলে দিন এবং তাদের চেকটি পরিবর্তন করার সুযোগ দিন। কেবলমাত্র বৈশিষ্টটিকে সংশোধন করার একটি সুযোগ - উদাহরণটিকে "আমার পক্ষে এটি পছন্দ হয় না" উদাহরণ দিয়ে সরিয়ে না ফেলে। এই মুহুর্তে, এটি আপনার অনুমান, বা তারা কোনও আলাদা অনুমান সরবরাহ করতে পারে তবে চশমাটি সরাবে না।

আপনার সহকর্মীদের কাছ থেকে দ্রুত পর্যালোচনা পাওয়া ভাল ধারণা হতে পারে যারা এই অনুমানটির উন্নতি করতে পারে। তবে যাইহোক, আপনার কাছে একটি অনুমান আছে, আপনি সেই অনুযায়ী কোডটি লিখেন, পরীক্ষকরা সেই অনুযায়ী পরীক্ষা করেন। এবং আপনি আপনার কাজটি করেছেন: আপনি একটি ধারণা রেখেছিলেন এবং এটি প্রয়োগ করেছেন। যদি অনুমানটি গ্রাহক যা চান তা না হয় তবে এটি সরাসরি পণ্য মালিক বা গ্রাহকের যে কোনও ভাল অনুমান লিখতে বিরক্ত করা যায় না তার দায়বদ্ধতা।


6
"কোড লেখা শুরু করার আগে আপনার একটি বিশদ, যাচাইযোগ্য স্পেকের প্রয়োজন That's এটি একটি সত্য এবং এর আশেপাশে কোনও লাভ নেই" "আমার সহকর্মীরা এবং আমি অনেক প্রকল্পে এটি করেছি এবং আমাদের অনেক সাফল্য এবং খুব কম ব্যর্থতা হয়েছিল। আপনার দাবি নিখুঁত নয়।
whatsisname

1
@ ওয়াটসিসনাম সম্মত হয়েছে। আমিও এইভাবে কোড লিখেছি। এটি তখন ঘটে যখন কার্যটির কোনও অনুসন্ধানের দিক থাকে। এখন বিন্যাস ছাড়াই কোডিংয়ের ত্রুটি রয়েছে, তবে কখনও কখনও আপনি কোনও লক্ষ্য অর্জন করতে পারবেন না বলার চেয়ে এগুলি আরও গ্রহণযোগ্য হয়।
আম্মোনে কর্ট

1
@ ওয়াটসিসনাম, শব্দবন্ধটি উন্নত করা যেতে পারে তবে মূল সত্যটি হ'ল আপনি কোন অনুরোধটি কী তা না বুঝে তা পূরণ করতে পারবেন না যদি আমি কেবল "জাভাতে আমাকে একটি প্রোগ্রাম লিখুন" বলি, আপনার পক্ষে সেই প্রোগ্রামটি লেখা অসম্ভব । প্রোগ্রামটি কী করা উচিত তার নিজের ধারণাটি তৈরি করতে পারেন - অন্য কথায়, নিজের লক্ষ্য উদ্ভাবন করুন এবং তারপরে এটি পূরণ করুন — তবে এমন লক্ষ্য অর্জন করা একটি খাঁটি অসম্ভবতা যা আপনাকে সহ কারও দ্বারা কখনও বলা হয়নি । এটি বড় বা ছোট কোনও অনুরোধের জন্য প্রযোজ্য ; আপনার প্রয়োজন , উত্পাদন এবং / বা উপস্থাপনের আগে প্রয়োজনীয়তা এবং চাওয়াগুলি অবশ্যই বুঝতে হবে ।
ওয়াইল্ডকার্ড

এটি বলেছিল ... একটি অনুরোধটি বোঝার এবং পূরণ করার জন্য যে স্তরের বিশদটির প্রয়োজনীয়তার প্রয়োজন তা তীব্রভাবে বিবেচনা করা যেতে পারে। এটি অনুমানের অধীনেও হতে পারে । এর একমাত্র সমাধান যোগাযোগ।
ওয়াইল্ডকার্ড

@ উইল্ডকার্ড: হ্যাঁ আমি মনে করি শব্দবন্ধটি অনেক বেশি অনুমোদিত হতে পারে। আপনি যা বলতে চাইছেন তা জেনোর প্যারাডক্সের কথা মনে করিয়ে দিলেও কম জোর করে।
কিয়াস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.