পরিকল্পনার সভায় কোনও স্ক্রাম দল কীভাবে অবকাঠামোগত কাজের জন্য অ্যাকাউন্ট করে?

Question

পরিকল্পনা সভায় স্ক্র্যামের দল কীভাবে ডেভ / অবকাঠামোগত কাজের জন্য অ্যাকাউন্ট করে?

প্রথম নজরে, তারা ব্যবহারকারীর গল্পগুলির মতো মনে হয় না কারণ তারা শেষ ব্যবহারকারীর মান সরবরাহ করে না।

যাইহোক, একটি নির্দিষ্ট ব্যবহারকারীর কাহিনির সাথে তাদের কাজ হিসাবে সংযুক্তি কখনও কখনও তা বোঝায় না। উদাহরণস্বরূপ, বলুন কাজটি হ'ল: "বাঁশ সেটআপ করুন।" এই কার্যটি কোনও ব্যবহারকারীর গল্প সম্পূর্ণ করার প্রয়োজন নেই যেহেতু দলটি ম্যানুয়ালি তৈরি করতে এবং মোতায়েন করতে পারে। সুতরাং এটি একটি ব্যবহারকারীর গল্পের সাথে সংযুক্ত হওয়া অর্থহীন নয় কারণ ব্যবহারকারীর গল্পটি সম্পূর্ণ করার জন্য এই টাস্কটির প্রয়োজন নেই required

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

Answer 1

এগুলি আসলে ব্যবহারকারীর গল্প নয়। তারা স্টেকহোল্ডার গল্প। সফ্টওয়্যারটি প্রকৃতপক্ষে সরাসরি ব্যবহারকারীদের দ্বারা অর্থ প্রদান করা না হলে এটি তাদের উপকারের জন্য পুরোপুরি একটি গল্প তৈরি করা বিরল।

আমি আপনাকে কয়েকটি উদাহরণ দিচ্ছি:

• মূলশব্দযুক্ত নিবন্ধগুলি, যা বিজ্ঞাপনদাতাদের আরও কার্যকর বিজ্ঞাপন দেওয়ার অনুমতি দেয়
• ক্যাপচা, যেগুলি মডারেটরগুলিকে ম্যানুয়ালি স্প্যামের সাথে মোকাবিলা করতে বাধা দেওয়ার জন্য রয়েছে।

বেশিরভাগ প্রযুক্তিগত গল্পগুলি আসলে ব্যবসায়ের সুবিধা সরবরাহ করে তবে এটি ব্যবহারকারীদের জন্য খুব কমই। এগুলিকে আলাদাভাবে ফ্রেস করা সাহায্য করতে পারে। আমি সাধারণত ক্রিস ম্যাটসের বৈশিষ্ট্যযুক্ত ইনজেকশন টেম্পলেট ব্যবহার করি:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

এটি স্পষ্টভাবে উন্নয়ন দল সহ সকল ধরণের স্টেকহোল্ডারকে স্বীকৃতি দেয়। এখন আপনি আপনার প্রযুক্তিগত গল্পগুলিও ব্যবসায়ের সুবিধার্থে ডেকে বলতে পারেন:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

আমি এটিতে বেশ কয়েকটি ব্লগ পোস্ট লিখেছি: তারা ব্যবহারকারীর গল্প এবং বৈশিষ্ট্য ইঞ্জেকশন নয় এবং প্রযুক্তিগত গল্পগুলি পরিচালনা করছেন । আশা করি তারা সাহায্য করবে।

Comments

শব্দার্থবিজ্ঞান ... আইএমএইচও এটি চৈতন্য দর্শনের বিরুদ্ধে যায়; প্রয়োজনীয় বিচ্ছেদ যুক্ত করা যেখানে এটি অন্য কোনও তাত্পর্যপূর্ণ উজ্জ্বল অনুভূতিগুলির প্রকৃত মূল্য সরবরাহ করে না।

— অ্যারন ম্যাকআইভার

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

— লুনিভোর

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

— সোরোঁথার

@ সোরোঁথার তখন কোথায় শেষ হবে? "হতাশার মাত্রা হ্রাস করার জন্য, একটি উন্নয়ন দল হিসাবে আমরা আমাদের নিজস্ব নিয়ম তৈরি করতে চাই" এটি প্রকৃতির বিজ্ঞপ্তি circ এটি একটি কারণ যা আপনি ব্যবহারকারীর উপর দৃষ্টি নিবদ্ধ রেখেছিলেন এবং তা হ'ল এটি। কার্যগুলি পিও থেকে গোপন করা উচিত; যেহেতু পিওকে সেই বিবরণগুলির সাথে নিজেকে উদ্বেগ করা উচিত নয়।

— অ্যারন ম্যাকআইভার

ওহ, এবং কেবল যদি এটি পরিষ্কার ছিল না - আমি স্ক্রাম সম্পর্কে আমার চেয়ে কাজের কাজ করা সম্পর্কে বেশি যত্নশীল। বা পাতলা। বা বিডিডি। আমি আরও বিশ্বাস করি যে সফটওয়্যারটির সর্বাধিক দরকারী কাজটি ঝুঁকি শেখার এবং পরিচালনার সাথে সম্পর্কিত। পদ্ধতি যখন দরকারী কাজ করার পথে আসে তখন আমি দরকারী কাজের দিকে ঝুঁকছি।

— লুনিভোর

Answer 2

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

Comments

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

— উইলিয়াম পিয়েট্রি

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

— লুনিভোর

@ লুনিভোর - পার্থক্য হ'ল কেউ আপনাকে শেখার জন্য অর্থ প্রদান করে না। আপনি শেখার সাথে যা করেন তার জন্য তারা আপনাকে অর্থ প্রদান করে। টিমগুলি তাদের সরঞ্জাম এবং তাদের জ্ঞান উন্নত করতে সর্বদা কিছুটা সময় নেয়। তবে এটিকে বেগ হিসাবে গণনা দলকে যে ধরণের কাজ করতে চলেছে তা নিয়ে বিভ্রান্ত করে।

— উইলিয়াম পিত্রি

এটি কেবল সরঞ্জাম এবং জ্ঞানের বিষয়ে নয়। অ্যাশলে জনসন থেকে চিন্তাভাবনা পরীক্ষা: আপনি শেষ প্রকল্পটি সম্পর্কে চিন্তা করুন। একই লোক, একই প্রয়োজনীয়তা, একই প্রযুক্তি, তবে আপনি যা শিখেছেন তা শিখিয়ে নিয়ে আবার এটি করতে কত সময় লাগবে তা চিন্তা করুন। প্রধানমন্ত্রীর কাছ থেকে উদ্ধৃতিগুলি প্রায় 25% থেকে 33% এ চলে - বাকিটি আমরা সফ্টওয়্যার প্রকল্পগুলিতে কতটা শিখি। ইচ্ছাকৃত আবিষ্কার সম্পর্কে ড্যান নর্থের পোস্টটি পড়ুন: dannorth.net/2010/08/30/introducing-deliberate-discovery

— লুনিভোর

Answer 3

ধীরে ধীরে তাদের করুন

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

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

Comments

+1: প্রথমবার স্পাইক সমাধান করুন, তারপরে এটি দ্বিতীয় বারের থেকে আরও ভাল এবং নির্ভরযোগ্য হতে হবে ref

— এস .লট

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

— ক্রিস্টো

এবং আপনার নিয়মিত প্রতিবিম্বের জন্য এবং যেকোনোভাবে প্রক্রিয়াটির উন্নতি করার জন্য সময় করা উচিত।

— মাইকেল

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

— মাইকেল

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

— উইলিয়াম পাইত্রি

Answer 4

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

আপনার উদাহরণ গ্রহণ; ম্যানুয়ালি বিল্ডিং এবং মোতায়েনের অর্থ এটি চলমান প্রচেষ্টা এবং এর কোনও সমাপ্তির রূপ নেই। এটি অনির্দিষ্টকালের জন্য বিদ্যমান।

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

আপনি অবশ্যই অ্যাপ্লিকেশনটি প্রতিটি স্প্রিন্টটি তৈরি এবং স্থাপন করতে পারেন তবে তা দিনের বেলা হয়ে যাওয়া কাজগুলির অংশ হয়ে যায় যা আনুষ্ঠানিকভাবে ব্যাকলগের মাধ্যমে ট্র্যাক করা হয় না এবং তারপরে এটি সমস্ত কিছুই হয়ে যায়।

Comments

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

— ইগোর পপভ 20

প্রকৃতপক্ষে এই অবকাঠামোগত কাজটি সম্পন্ন সংজ্ঞাটির অংশ হওয়া উচিত।

— ইগর পপভ

Answer 5

ব্যবহারকারীর গল্পগুলি ব্যবহারকারীর দৃষ্টিকোণ থেকে একটি বিজনেস মানকে সংজ্ঞায়িত করে। যে কারণে অবকাঠামোগত কাজগুলি সাধারণত একটি "বর্জ্য" হিসাবে বিবেচিত হয়। এর অর্থ এই নয় যে তাদের প্রয়োজন নেই। এর অর্থ হল যে আরও অবকাঠামোগত কাজগুলি করা কম ব্যবসায়ের মূল্য সরবরাহ করবে। যে কারণে অবকাঠামোগত কাজগুলি ব্যবহারকারীর স্টরি হিসাবে বিবেচনা করা উচিত নয় এবং কোনও ব্যবহারকারীর গল্পের সাথে সংযুক্ত হওয়া উচিত নয়।

পরিকল্পনার বৈঠকে টিমকে অবশ্যই পরবর্তী স্প্রিন্টে অবকাঠামোগত কাজগুলি একেবারে প্রয়োজনীয় হবে তা বিবেচনা করতে হবে। প্রতিশ্রুতিবদ্ধ হবে এই অবকাঠামোগত কাজগুলি মাথায় রেখে। এটি দলের গতিবেগকে প্রভাবিত করবে যা সঠিক ফলাফল কারণ বেগটি পরিমাপ করে যে টিম কতটা ব্যবসায়িক মূল্য সরবরাহ করতে পারে।

Answer 6

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

Comments

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

— উইলিয়াম পিট্রি

কিন্তু ব্যবসায়ের মূল্য কী? এটি একটি বিস্তৃত শব্দ, এবং যে কোনও কিছু যা ব্যবসাকে শীঘ্রই আরও ভাল / ইত্যাদি সফ্টওয়্যার প্রকাশ করতে দেয় সেই ব্যবসায়ের মূল্য রয়েছে to

— অ্যান্ডি উইসেন্ডেঞ্জার

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

— উইলিয়াম পাইত্রি

Answer 7

আমি যা দেখেছি তার থেকে অনেকগুলি অবকাঠামোকে প্রদত্ত হিসাবে বিবেচনা করা হয়। এর মধ্যে অন্তর্ভুক্ত রয়েছে:

• সংশোধন নিয়ন্ত্রণ ব্যবস্থা;
• স্বয়ংক্রিয় বিল্ড সিস্টেম;
• আইডিই এবং অন্যান্য বিকাশকারী সরঞ্জামসমূহ;
• উন্নয়ন সার্ভার;
• মোতায়েন প্রক্রিয়া; এবং
• প্রকল্প প্রক্রিয়া এবং মান।

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

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

Comments

+1: এটি যদি না হয় তবে চটপটে সত্যই শক্ত। স্থিতিশীল, প্রমাণিত অবকাঠামো এবং প্ল্যাটফর্মটি তত্পরতার জন্য এক ধরণের প্রাক-প্রয়োজনীয়।

— এস .লট

Answer 8

নিম্নোক্ত বিবেচনা কর:

• স্ক্রাম টিম একটি বিদ্যমান পণ্য স্যুটে প্রধান বৈশিষ্ট্য যুক্ত করে।

• ইঞ্জিনিয়ারিং সেরা পদ্ধতির উপর ভিত্তি করে বর্তমান থাকার জন্য বিকাশ প্রযুক্তি / সরঞ্জাম / ইউটিলিটিগুলি আপগ্রেড করার প্রয়োজন রয়েছে।

• এই কাজের সাথে একটি রিলিজ লোড করা সামঞ্জস্য করে তোলে যাতে রিলিজের সময় স্প্রিন্টের সমস্যাগুলি সমাধান করা যায়।

• যেহেতু ব্যবসায় এই আইটেমগুলি থেকে অপ্রত্যক্ষ মান অর্জন করে আমি প্রস্তাব দিচ্ছি যে স্বচ্ছতার স্বার্থে এগুলি হ'ল পণ্য ব্যাকলগ আইটেম (পিবিআই)।

• দলটি এই আইটেমগুলিকে আকার দেয় এবং তারা যে কোনও পিবিআইয়ের মতো আচরণ করে।

আমার জন্য এই সমস্যাটি এটাই উত্থিত হয় যে আমি অন্যান্য ব্যবসায়িক কেন্দ্রিক পিবিআইয়ের নীচে কাজগুলি কীভাবে এই কাজটি আড়াল করতে পারি তা বুঝতে চেষ্টা করতে সময় নষ্ট করতে চাই না।

আমি চাই না এই ধরণের অবকাঠামোগত কাজের দ্বারা পিবিআই সাইজিং স্কাইং হোক। আমি কী করা হচ্ছে তা দেখতে চাই এবং আমি কী দিতে চাই তা বুঝতে চাই।

আমি আরও মনে করি যে মানসম্পন্ন সমাধান সরবরাহের জন্য প্রয়োজনীয় অবকাঠামোগত বিনিয়োগের মাধ্যমে দলটি ব্যবসায় যে প্রতিশ্রুতি নিয়েছে তা বোঝার মূল্য রয়েছে।

Answer 9

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

Comments

এক্সপি এটি সুপারিশ করে না। কিছু লোক তা করেন তবে এটি অবশ্যই বেক, এট আল দ্বারা সংজ্ঞায়িত হিসাবে এক্সট্রিম প্রোগ্রামিংয়ের অংশ নয়। ব্যক্তিগতভাবে, আমি মনে করি Iteration জিরো একটি খারাপ ধারণা।

— উইলিয়াম পিয়েট্রি

আরেকটি সমস্যা, আপনি সর্বদা 0 থেকে শুরু করেন না, আপনি বুঝতে পারেন আপনার এখনই দরকার হয় বা পরবর্তী স্প্রিন্টে something

— অ্যান্ডি উইসেন্ডেঞ্জার

@William: দেখুন "পরিকল্পনা এক্সট্রিম প্রোগ্রামিং" কেন্ট অঙ্গুলিনির্দেশ, অধ্যায় 15, পৃষ্ঠা 66 দ্বারা

— স্টিভেন উ লো

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

— উইলিয়াম পাইত্রি

@ উইলিয়াম: আহা, আমি দেখছি আপনি কী পাচ্ছেন? আমি সমস্ত সফ্টওয়্যার অবকাঠামো বলতে চাইছি না , কেবলমাত্র আপনি উল্লিখিত স্টাফ

— স্টিভেন এ। লো 5

Answer 10

আমাদের দলে আমরা নিম্নলিখিতটি করি:

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

দ্বিতীয় ধাপটি সবচেয়ে গুরুত্বপূর্ণ। একটি চতুর অনুশীলনের মতো, স্ক্রমে আপনি নিজের কাজগুলি সম্পাদনের জন্য যথাসম্ভব চেষ্টা করার চেষ্টা করেন। অপ্রয়োজনীয় কাজ করার জন্য আপনার জীবন অপচয় না করার উপায় হিসাবে এটি গ্রহণ করুন: আমার অভিজ্ঞতা দেখায় যে 50% "শীতল-শান্ত" জিনিসগুলি শেষ অবধি পরিত্যক্ত এবং অবিস্মরণীয় end