هنگام کار در یک محیط چابک، مرتباً در مورد «DOD» و «DOR» می شنوید. در موارد متعددی متوجه شدم که این مفاهیم گاهی انتزاعی یا اشتباه درک می‌شوند. در برخی موارد، آنها در جای خود قرار می گیرند، اما در نهایت کم استفاده می شوند یا استفاده نمی شوند، مانند قطعنامه های خوبی که در ابتدای سال می گیریم اما هرگز انجام نمی دهیم. آنقدر نشانه‌ها که باعث شد بخواهم چند خط روی کاغذ بیاورم تا هرکس بتواند انعکاس خودش را تغذیه کند.
در این مقاله ابتدا به ملاقات DOD می رویم: این مفهوم چیست؟ چگونه آن را بسازیم؟ باید آپدیت بشه؟ سپس ما خواهر کوچک آن، DOR معروف را کشف خواهیم کرد. خواهیم دید که مشترکاتی بین این دو وجود دارد.
DOD: تعریف انجام شده
مفهوم “کار انجام شده”: از زندگی روزمره … تا فناوری اطلاعات.
همانطور که متوجه خواهید شد، تعریف Done با نام اختصاری “DOD” نیز شناخته می شود. به معنای واقعی کلمه، این تعریف چیزی است که به پایان رسیده است … “تعریف انجام شده”.
وقتی این را گفتیم، طرح این سؤال مشروع است: کار تمام شده چیست؟ اغلب متوجه شده ام که هرکسی می تواند تعریف خود را داشته باشد.
برای شروع، بیایید مثالی از زندگی روزمره بیاوریم: شخصی که پل نام دارد از فرزندانش می خواهد لباس های خود را تا کرده و در کمد خود بگذارند. چند ساعت بعد، پل متوجه می شود که فقط جوراب ها به صورت جفت دسته بندی شده و به درستی ذخیره می شوند. بقیه لباس ها بر اساس رنگ دسته بندی شده و روی تخت انباشته می شوند. این چیزی نیست که پل تصور می کرد… برای بچه ها سطح کیفیت تاشو و ذخیره سازی کافی بود اما برای پل نه. از طریق این مثال متوجه می شویم که ممکن است برای همه ترجیح داده شود که تعریف یکسانی از “کار انجام شده” داشته باشند تا از غافلگیری ناخوشایند جلوگیری شود.
برای بازگشت به دنیای IT، زمانی که باید در مراحل مختلف متوالی کار کنیم، می‌تواند مهم باشد که در مورد کار تمام شده به توافق برسیم. هدف این است که بدانیم چه زمانی می توانیم کار خود را به مرحله دیگری “هل” کنیم تا شخص ثالث بتواند آن را بازیابی کند. برای نشان دادن این پاراگراف، بیایید مثال زیر را در نظر بگیریم: چگونه مالک محصول می تواند تصور کند که توسعه ایالات متحده به پایان رسیده است؟ او چگونه می تواند تشخیص دهد که این ایالات متحده می تواند در محدوده نسخه آزمایشی بعدی قرار گیرد؟ در این مورد، DOD می تواند ابزار جالبی باشد. به خواندن ادامه دهید متوجه خواهید شد که چرا…
DOD: از چه چیزی تشکیل شده است؟
به روشی ساده، DOD را می توان به عنوان فهرستی از معیارها توصیف کرد که به آنچه باید انجام شود تا کار به عنوان تمام شده در نظر گرفته شود، اشاره دارد.
با بازگشت به مثال خود، در اینجا چند معیار وجود دارد که می تواند به PO کمک کند تا تعیین کند آیا ایالات متحده می تواند “نمایش داده شود” یا خیر:
- تست های واحد انجام شده: آنها 70٪ کد را پوشش می دهند.
- کد معتبر: کد محصول برای ایالات متحده توسط 2 همتا بررسی شده است.
- اسناد به روز شده: اسناد مرتبط با ایالات متحده نوشته یا به روز شده است.
- پیگیری به روز: JIRA یا برد دیگری به روز شده است
- دمو آماده: “دمو” با داده های مورد استفاده و موارد مختلف برای نشان دادن آماده شده است.
لطفا توجه داشته باشید، هیچ چیز در سنگ تنظیم نشده است! بسته به پروژه و زمینه شرکت ممکن است چندین معیار دیگر وجود داشته باشد!
توجه داشته باشید که همه ایالات متحده در یک سرعت مشخص دارای DOD یکسان هستند. معیارهای وزارت دفاع باید به عنوان یک دعوت به تأمل در نظر گرفته شود. آیا نوشتن اسناد برای همه ایالات متحده در عقب ماندگی منطقی است؟ آیا برای هر ایالات متحده مرتبط است؟ آیا ارزش می آورد؟ شما باید این سوال را از خود بپرسید و اگر مستندات مربوط به یک ایالات متحده مرتبط و خوب نیست، نباید این کار را انجام داد که مانع از نشان دادن ایالات متحده نمی شود …
به عبارت دیگر، DOD نباید یک ترمز باشد، گاهی اوقات باید بدانیم چگونه “کمی طناب را رها کنیم” تا جلوی تحولات را نگیریم.
چه زمانی و چگونه آن را بسازیم؟
در مورد موقتی هیچ قانون دقیقی وجود ندارد. به طور کلی، DOD قبل از اولین برنامه ریزی اسپرینت تعیین می شود. برخی از تیم ها آن را در طول پروژه تعریف می کنند زیرا قبلاً به آن فکر نکرده اند یا انجام آن را ضروری ندانسته اند. راه های مختلفی برای ایجاد یک DOD وجود دارد که به دو مورد اشاره می کنیم.
اول، تیم می تواند از وزارت دفاع تیم های دیگر الهام بگیرد. بیایید تیمی را تصور کنیم که زمینه شرکت را کشف می کند یا اولین گام های خود را در یک محیط چابک برمی دارد. در این مورد، می توان آن را بر اساس یک DOD که قبلاً تولید و استفاده شده است، ایجاد کرد و به آن اجازه می دهد برای جلوگیری از سندرم وایت شیت، مبنای اولیه ای برای کار و مبادله داشته باشد. البته نباید کورکورانه DOD “همسایه” خود را به عهده بگیرید، اما از خود بپرسید که چه معیارهایی را می توان برای پروژه من مورد استفاده قرار داد؟ همچنین می تواند یک REX جالب باشد.
مسیر دیگری که باید از آن استفاده کرد، تجربه Scrum Master است. در این مورد Scrum می تواند لیستی از معیارها را برای روشنگری و راهنمایی تیم پیشنهاد کند. سپس بازیگران مختلف معیارهایی را انتخاب می کنند که برای آنها مهم به نظر می رسد و در یک زمان معین با پروژه تطبیق داده می شود.
هر روشی که باشد، شامل یک جلسه تیمی است تا اعضا بتوانند با هم اولین DOD را تعریف کنند.
آیا DOD می تواند تکامل یابد؟
فقط یک پاسخ: بله! DOD می تواند تکامل یابد، هیچ چیز آن را مجبور به ثابت ماندن در طول زمان نمی کند! تیم می تواند معیارهایی را اضافه یا حذف کند. اغلب، DOD در طول پروژه تکامل می یابد. به عنوان مثال، اگر بازیگران با مشکلی مواجه شدند و دوست داشتند که دیگر تکرار نشود، می توانند یک معیار در DOD اضافه کنند. به تدریج، DOD آموخته های تیم را منعکس می کند.
به شدت از تکامل آن در میانه دوی سرعت خودداری می شود. اگر تیم یک معیار تاثیرگذار اضافه کند، این می تواند باعث “انفجار” شمارنده ها و اختلال در روند توسعه شود. با این حال، اگر برای مطلوبیت محصول، معیار جدیدی باید کاملاً ادغام شود بدون اینکه هدف و تاریخ پایان اسپرینت مختل شود، باید وضعیت را مطالعه کرد.
DOR : تعریف آماده
مفهوم “آماده کار”
تعریف آماده، که با نام اختصاری DOR شناخته می شود، لیستی از عناصری است که یک داستان کاربر باید جمع آوری کند تا نامزد توسعه باشد. اینها معیارهایی هستند که به داستان کاربر اجازه می دهند از بک لاگ محصول به بک لاگ اسپرینت حرکت کند. این یک قرارداد بین PO و توسعه دهندگان در نظر گرفته می شود.
DOR می تواند یک “ضمانت” برای جلوگیری از برنامه ریزی سرعتی باشد که طول می کشد و می تواند بر انگیزه تیم تأثیر بگذارد. اگر ایالات متحده از DOR پیروی کند، توسعه دهندگان باید همه عناصر را برای ارزیابی سریع و دقیق آن در دسترس داشته باشند. سپس می‌توانیم از سؤالات متعدد در برنامه‌ریزی اسپرینت اجتناب کنیم و خطر دست کم گرفتن ایالات متحده را به حداقل می‌رسانیم.
ایجاد، به روز رسانی و ترکیب: نقاط مشترک با DOD!
مانند بسیاری از تصمیماتی که تیم های چابک می گیرند، DOR باید از طریق بحث آزاد مانند DOD توسعه یابد. در اینجا دیگر هیچ دستور العمل معجزه‌ای وجود ندارد… تیم می‌تواند به تجربیات سایر تیم‌ها یا متخصصان چابک تکیه کند تا البته اولین سکوی پرتاب را داشته باشد که با پروژه خود سازگار باشد!
مانند DOD، DOR در زمان منجمد نمی شود. به موازات پیشرفت تیم از نظر اعتماد به نفس و بلوغ تکامل می یابد. DOR لازم نیست در پایان هر دوی سرعت تغییر کند. با این حال، تیم باید هر از چندگاهی زمان لازم را صرف کند تا مطمئن شود که دومی همچنان با بلوغ تیم و زمینه پروژه مطابقت دارد.
مانند “خواهر کوچکش”، DOR نیز از معیارهایی تشکیل شده است که تیم برای تعیین اینکه آیا ایالات متحده آماده توسعه است یا خیر، بر آنها تکیه می کند. در زیر چند نمونه از معیارها آورده شده است:
- ایالات متحده توسط PO به تیم معرفی شد. او به چالش کشیده شد و همه اعضای تیم آن را پذیرفتند و درک کردند
- نیاز مشخص شده است: قوانین مدیریت بیان شده و نمونه هایی آنها را نشان می دهد
- مدل ها برای مشخص کردن نیاز موجود هستند
- این تیم ایالات متحده را در وظایف فنی رد کرد
البته این لیست کامل نیست!
DOR: تمرین خوب یا بد؟
حتی اگر DOR یک عمل خوب در نظر گرفته شود، دوباره DOR نباید مانعی برای چابکی باشد. گاهی اوقات همه چیز در طرح اسپرینت آماده نیست. ایالات متحده تعبیه شده در سرعت می تواند مدل HMI خود را به دلایل مختلف (فقدان زمان طراح، انطباق لحظه آخری و غیره) در طول سرعت تولید شده ببیند. البته این عمل باید در حاشیه انجام شود اما می توان از آن استفاده کرد.
در نتیجه
ما فقط چند کلمه در مورد این دو مفهوم که اغلب در چابکی با آن مواجه می شویم، گفتیم. همانطور که در نمودار زیر نشان داده شده است، DOD و DOR در بالادست و پایین دست اسپرینت دخالت می کنند. شما متوجه خواهید شد که DOD و DOR دوقلو هستند حتی اگر اهداف متفاوتی داشته باشند. هیچ اجباری برای استفاده از آنها وجود ندارد، اما آنها می توانند کمک بزرگی به خصوص برای تیم هایی باشند که در چابکی تازه کار هستند. اگر هنوز این مفاهیم را اجرا نکرده اید، از شما دعوت می کنم که آنها را امتحان کنید زیرا در کل وقتی آنها را می چشید، آنها را تطبیق می دهید!
