مقدمه ای بر برنامه ریزی اسپرینت / Sprint Planning

هر اسپرینت با برنامه‌ریزی اسپرینت شروع می‌شود، جایی که تیم اسکرام تعیین می‌کند که برای انجام چه کاری در طول اسپرینت برنامه‌ریزی کند.

در طول جلسه، تیم اسکرام بر روی موارد زیر تمرکز می کند:

• ارزشی که می توان در طول Sprint ایجاد کرد.
• انتخاب آیتم های Product Backlog در طول اسپرینت.
• برنامه ریزی کار مورد نیاز برای رسیدن به هدف اسپرینت.
• برنامه ریزی برای ایجاد یک Increment که مطابق با تعریف Done باشد.

تیم اسکرام با ایجاد یک Sprint Backlog که شامل هدف اسپرینت، PBI های انتخابی محصول و طرح توسعه دهندگان برای ارائه کار است، مسیر را شفاف می کند.

برنامه ریزی اسپرینت در یک نگاه

برگزاری Sprint Planning

در طول این رویداد به سه موضوع پرداخته می شود:

• چرا این اسپرینت ارزشمند است؟
• در طول این اسپرینت چه کاری می توان انجام داد؟
• این کار چگونه انجام خواهد شد؟

برنامه ریزی اسپرینت یک رویداد برای کل تیم اسکرام است. در صورتی که تیم احساس کند توصیه های افراد خارج از تیم می تواند مفید باشد می تواند از افراد خارج از تیم اسکرام نیز دعوت کند. افراد درون تیم در طول این رویداد مسئولیت های خاصی دارند:

مالک محصول

• اطمینان حاصل می کند که شرکت کنندگان در رویداد، اطلاعات کافی در مورد مهم ترین PBI ها از جمله نحوه پشتیبانی آنها از Product Goal را دارند.
• به تیم طرحی در مورد آنچه که آنها می توانند توسعه دهند که برای ذینفعان ارزشمند باشد ارائه می دهد. تیم باید بتواند کار را در طول دوره اسپرینت کامل کند. PO نباید در چگونگی خلق ارزش و کار توسعه دهندگان دخالتی بکند.

کل تیم اسکرام

• با همکاری همه اعضا، تیم یک Sprint Goal ایجاد می‌کند که نشان می‌دهد چرا این اسپرینت برای ذینفعان، از جمله مشتریان و کاربران، ارزش ایجاد می‌کند.
• این Sprint Goal به موضوع شماره یک می‌پردازد: «چرا این اسپرینت ارزشمند است؟»

توسعه دهندگان

• موارد موجود در Product Backlog را برای انجام در Sprint فعلی انتخاب کنید. این موضوع به موضوع شماره دو می پردازد: “در طول این اسپرینت چه کاری می توان انجام داد؟”
• هنگامی که توسعه دهندگان PBI را برای Sprint انتخاب می کنند، آنها مواردی را در نظر می گیرند:
  • Product Backlog و Product Goal
  • ارزیابی تیم از ظرفیتش ، بر اساس عملکرد گذشته آنها در اسپرینت های قبلی
  • تعریف Done
  • Increment فعلی
  • هر پیشنهادی برای بهبود فرآیند که در طول بازنگری اسپرینت تیم عنوان شده است.
• یک طرح برای چگونگی انجام PBI ایجاد کنید. این به موضوع شماره سه می‌پردازد: «این کار چگونه انجام می‌شود؟»

اسکرام مستر

• در طول جلسه مسئولیت های خاصی برای کمک به تیم برای انجام درست رویداد دارد. به عنوان مثال، اسکرام مستر، اگر ببیند PBI به اندازه کافی تحلیل نشده است یا تیم موانع بالقوه را نادیده می گیرد و یا Sprint Goal از Product Goal پشتیبانی نمی کند یا حتی تیم مقدار غیرقابل دستیابی از کارها را انتخاب کرده است، تیم را راهنمایی می کند.
• اغلب اسکرام مستر به عنوان تسهیل کننده این رویداد عمل می کند، اگرچه تسهیل این جلسه می تواند توسط هر کسی در جلسه انجام شود.

Sprint Planning را موثرتر برگزار کنید.

ضدالگو ها

هدف، تایم باکس و شرکت کنندگان برنامه ریزی اسپرینت به خوبی مشخص شده اند.  با این حال، ما گاهی اوقات می‌بینیم که تیم‌های اسکرام در ضد الگوهایی قرار می‌گیرند که ارزش کار آن‌ها را کاهش می‌دهد.

شرکت کنندگانی که مسئولیت های خود را به درستی انجام نمی دهند:

• مالک محصول در دسترس نیست – اگر مالک محصول یا نماینده او در برنامه ریزی اسپرینت شرکت نکند، توسعه دهندگان باید وارد عمل شوند و بر اساس درک خود، تمام مسئولیت های مالک محصول را انجام دهند. متأسفانه، بعید به نظر می‌رسد که آن‌ها تمام اطلاعاتی را که یک مالک محصول دارد در اختیار داشته باشند که به آن‌ها اجازه می‌دهد تعیین کنند چه چیزی باعث می‌شود این Sprint و هر آیتم Product Backlog نسبت به سایر موارد موجود در Backlog ارزشمندتر باشد. این وضعیت بار نامناسبی را بر دوش توسعه دهندگان و ذینفعان وارد می کند و ممکن است منجر به توسعه محصول اشتباه شود.
• بدون اینکه صحبتی در مورد ارزش کار انجام شود، PBIها و Sprint Goal توسط مالک محصول انتخاب می‌شوند – در زمان پیاده سازی یک PBI، توسعه‌دهندگان ممکن است تصمیمات بی‌شماری بگیرند. بدون درک ارزش چیزی که خلق می کنند، احتمالاً تصمیمات بدی خواهند گرفت.
• فقط فرد یا افراد خاصی در تیم تخمین می زنند. اسکرام معتقد است که تیم وقتی قوی تر عمل میکند که با هم کار کند. همچنین برای داشتن برآوردهای درست باید همه دیدگاه ها، دانش و تخصص اعضای تیم را در نظر گرفت.
• کشیدن کارهای زیاد به اسپرینت و یا مالک محصول به توسعه دهندگان بگوید که چه کاری را به Sprint بکشند – توسعه دهندگانی که تعیین نمی کنند چه کاری را می توان در طول Sprint انجام داد، مسئولیت های خود را انجام نمی دهند.

Backlog یا شرکت کنندگان برای رویداد آماده نیستند:

• عدم Product Backlog Refinement – بدون Refine کافی، توسعه دهندگان فرض های نادرستی مانند: ارزش هر PBI; ذینفعان چه چیزی را می خواهند و چرا آن را می خواهند. معیارهای پذیرش برای PBI؛ و توانایی آنها برای کار روی هر PBI را در یک اسپرینت را در نظر می گیرند. این مفروضات غلط موفقیت اسپرینت را به خطر می اندازد.
• نیازمندی های مبهم – اگر PBI ها اطلاعات کافی در مورد نیازمندی ها برای توسعه دهندگان نداشته باشند، این احتمال وجود دارد که نتیجه کار آنها نیازهای ذینفعان را برآورده نکند و وقت همه را تلف کند.
• Undone ماندن کار در پایان یک اسپرینت – تخمین بیش از حد کارهایی که می‌توان در طول اسپرینت تکمیل کرد، نشانه آن است که PBIها به اندازه کافی تحلیل نشده‌اند، تیم ارزیابی ضعیفی از ظرفیت خود دارد یا تعریف Done برای تیم بسیار محدودکننده است.
• در این جلسه کار شکسته شده و تخمین زده می شود – یک تیم قوی اسکرام به طور منظم PBI ها را بررسی و تحلیل می کند که شامل تخمین و تجزیه کار است.
• برنامه ریزی اسپرینت بیش از حد طول می کشد – هر چه تیم با Backlog  آشناتر باشد، از طریق جلسات منظم Refine و تعریف DoR ، جلسات برنامه ریزی اسپرینت کارآمدتر و موثرتر خواهد شد. جلسات برنامه ریزی اسپرینتی که طولانی می شوند، اغلب به خوبی برنامه ریزی یا تسهیل نمی شوند.

هدف جلسه محقق نمی شود:

• پیش‌بینی‌های اشتباه – از توسعه‌دهندگان خواسته می‌شود پیش‌بینی کنند که چه کارهایی را می‌توان در یک Sprint انجام داد و اغلب از تیم‌های اسکرام خواسته می‌شود پیش‌بینی کنند که چه زمانی بخشی از محصول برای استفاده در دسترس خواهد بود. تیم‌های اسکرام که برنامه‌ریزی اسپرینت را ضعیف انجام می‌دهند، معمولاً قادر به ایجاد پیش‌بینی قابل اعتماد نیستند.
• بدون تعهد مشترک یا Sprint Goal نامشخص – اهداف اسپرینت برای تمرکز تیم بر روی یک نتیجه منحصر به فرد طراحی شده اند. اگر تیم به همان نتیجه متعهد نباشد، احتمالاً هدف اسپرینت به خوبی تعریف نشده است.
• تیم بیشتر در مورد Velocity صحبت می کند تا Value – معیار Velocity مقداری برای میزان تولید “فیچر” بدون توجه به ارزش آن است. هدف Sprint ایجاد ارزش است، نه اجرای حجم بالایی از کارها.
• تست ها تا پایان اسپرینت کامل نمی شوند – اگر تستی که در تعریف DoD مشخص شده است در پایان اسپرینت کامل نشود، کار Done نشده است. تیم یا DoD خود را نادیده می گیرد یا کارهایی را که می توانند انجام دهند را دست بالا برآورد می کنند.
• تا زمانی که تمام کارها برای Sprint مشخص نشده باشد، تیم‌ کار روی PBI انتخاب شده را شروع نمی‌کنند. اشکالی ندارد اگر در طول/پس از این رویداد هنوز مجهولاتی وجود داشته باشد، تیم با آنچه می داند شروع می کند و مجهولات بیشتر را در طول اسپرینت بررسی و شفاف می کند.

نکاتی برای داشتن Sprint Planning قوی

• شکستن ضد الگوهای ذکر شده در بالا به ایجاد جلسات برنامه ریزی اسپرینت قوی و موثر کمک می کند. نکات زیر را در نظر بگیرید:
• توسعه دهندگان تا زمانی که مشخص شود هر PBI چگونه ارزش ایجاد می کند یا برای مشتری مفید است، سؤال می پرسند.
• توسعه دهندگان تا زمانی که درک خوبی از نحوه پیاده سازی PBI داشته باشند، سؤال می پرسند.
• تیم های اسکرام برای حل مشکلات با هم همکاری می کنند.
• تیم های اسکرام با توجه به Acceptance Criteria، میزان کار انتخاب شده برای اسپرینت را در نظر میگیرند.
• تیم های اسکرام تمام کارهای مورد نیاز برای ایجاد یک Increment را که به تعریف Done آن ها پایبند باشد را درک می کنند و با استفاده از این درک ظرفیت خود را محاسبه می کنند.
• تیم‌های اسکرام استراتژی‌هایی را طراحی می‌کنند که چندین عضو تیم را قادر می‌سازد تا روی یک PBI تمرکز کنند.
• تیم‌های اسکرام بر استراتژی‌هایی تمرکز می‌کنند که اصل ناب (Lean) «فقط کافی» را به تیم می آورد.
• تیم‌های اسکرام آیتم‌های بهبودی را به Sprint اضافه می‌کنند که در Sprint Retrospective قبلی کشف شده اند.

مترجم: امیر دوراندیش

منبع: https://www.scrum.org/learning-series/sprint-planning