راهنمای مطالب

• اسپرینت
  • مقدمه ای بر اسپرینت
    • مؤثرتر کردن اسپرینت
• برنامه ریزی اسپرینت
  • مقدمه ای بر برنامه ریزی اسپرینت
  • برگزاری رویداد برنامه‌ریزی اسپرینت
• بهبود اثربخشی رویداد برنامه ریزی اسپرینت
• اسکرام روزانه
  • مقدمه ای بر اسکرام روزانه
  • برگزاری رویداد اسکرام روزانه
  • موثرتر کردن رویداد اسکرام روزانه
• بازبینی اسپرینت
  • مقدمه ای بر بازبینی اسپرینت
  • برگزاری رویداد بازبینی اسپرینت
  • موثرتر کردن رویداد بازبینی اسپرینت
• بازنگری اسپرینت
  • مقدمه ای بر بازنگری اسپرینت
  • برگزاری رویداد بازنگری اسپرینت
  • موثرتر کردن رویداد باز اسپرینت

الگوهای نادرست  (Antipatterns)

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

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

• عدم حضور مالک محصول: اگر مالک محصول یا نماینده او در جلسات برنامه‌ریزی اسپرینت شرکت نکنند، توسعه‌دهندگان باید وارد عمل شده و بر اساس درک و برداشت خود وظایف مالک محصول را انجام دهند. متاسفانه بعید است که آنها تمام اطلاعاتی که مالک محصول درباره آیتم‌های بک‌لاگ محصول و میزان ارزشمندی و اولویت آنها دارد را در اختیار داشته باشند. این وضعیت بار زیادی بر دوش توسعه‌دهندگان و ذینفعان می‌گذارد و ممکن است به تولید محصول نادرست منجر شود.
• انتخاب آیتم‌های بک‌لاگ و هدف اسپرینت توسط مالک محصول بدون بحث درباره ارزش کارها: توسعه‌دهندگان ممکن است در طول انجام آیتم‌های بک‌لاگ تصمیمات بیشماری بگیرند و بدون درک ارزش آیتم‌ها، ممکن است آنها تصمیمات نادرستی بگیرند.
• تنها تیم رهبری یا تیم “اصلی” تخمین‌ها را ارائه می‌دهند: اسکرام باور دارد که تیم به صورت مشترک قوی‌تر است و تخمین‌های قوی نظرات، دانش و تخصص همه اعضای تیم را در نظر می‌گیرد.
• انتخاب بیش از حد کارها یا انتخاب کارها توسط مالک محصول برای اسپرینت: توسعه‌دهندگانی که کارهای اسپرینت را تعیین نمی‌کنند، مسئولیت‌های خود را انجام نمی‌دهند.

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

• عدم پالایش کافی بک‌لاگ محصول: بدون پالایش کافی، توسعه‌دهندگان فرضیاتی مانند ارزش هر PBI، نیازهای ذینفعان و معیارهای پذیرش را ایجاد می‌کنند که موفقیت اسپرینت را به خطر می‌اندازد.
• نیازمندی‌های مبهم: اگر PBIها اطلاعات کافی برای توسعه‌دهندگان برای درک آنچه درخواست شده است را نداشته باشند، نتیجه کار آن‌ها احتمالاً نیازهای ذینفعان را برآورده نخواهد کر و وقت همه را تلف خواهد کرد..
• وجود کار ناتمام در پایان اسپرینت: تخمین بیش از حد حجم کارهایی که می توان در طول اسپرینت انجام داد، نشانه‌ای است از اینکه PBI ها به درستی تعریف نشده‌اند، تیم ارزیابی ضعیفی از ظرفیت خود دارد و یا اینکه تعریف انجام شده (DoD) برای وضعیت فعلی محصول بسیار محدود کننده است.
• تقسیم و تخمین کارها در طی جلسه: تیم‌های قوی اسکرام بک‌لاگ خود را به طور منظم پالایش کرده و تخمین می‌زنند.
• طولانی بودن جلسه برنامه‌ریزی اسپرینت:  هرچه تیم از طریق جلسات پالایش با بک‌لاگ آشناتر باشد، جلسات برنامه‌ریزی اسپرینت موثرتر خواهند بود. جلسات طولانی برنامه ریزی اسپرینت،  معمولاً بخوبی برنامه‌ریزی یا تسهیل نشده اند.

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

• پیش‌بینی‌های نادرست: توسعه‌دهندگان باید پیش‌بینی کنند چه کاری در یک اسپرینت قابل انجام است و تیم‌های اسکرام باید پیش‌بینی کنند چه زمانی بخشی از محصول آماده استفاده خواهد بود. تیم‌هایی که برنامه‌ریزی اسپرینت ضعیفی دارند، معمولاً قادر به ایجاد پیش‌بینی‌های قابل اعتماد نیستند.
• نداشتن  تعهد مشترک یا هدف اسپرینت نامشخص: هدف اسپرینت باید تیم را حول یک نتیجه مشخص متمرکز کند. اگر تیم به نتیجه یکسان متعهد نباشد، احتمالاً هدف اسپرینت به خوبی تعریف نشده است.
• تمرکز بیشتر بر روی سرعت تا ارزش:  سرعت (Velocity ) واحد اندازه‌گیری میزان تولید است، نه ارزش. هدف اسپرینت ایجاد ارزش است، نه صرفا انجام دادن حجم بالایی از کارها.
• کامل نبودن تست‌ها در پایان اسپرینت: اگر تست‌ها طبق تعریف کامل بودن (DoD) در پایان اسپرینت کامل نشوند، کار انجام شده (Done) نیست. تیم یا تعریف کامل بودن را نادیده می‌گیرد یا  حجم کاری که می تواند انجام دهد را دست بالا می گیرد..
• تیم‌ها کار بر روی PBI های انتخابی را تا زمانی که همه کارهای اسپرینت تعریف نشده‌اند، شروع نمی‌کنند: اگر هنوز ناشناخته‌هایی در طول یا بعد از جلسه وجود داشته باشد، تیم با چیزهایی که می‌داند شروع می‌کند و ناشناخته‌ها را در طول اسپرینت تعریف می‌کند.

نکات برای برنامه‌ریزی اسپرینت‌های قوی:

شکستن ضد الگوهای ذکر شده در بالا به ایجاد رویدادهای برنامه ریزی اسپرینت قوی و موثر کمک می کند. نکات زیر را در نظر بگیرید:

• پرسیدن سوالات توسط توسعه دهندگان تا زمانی که مشخص شود هر PBI چگونه ارزش ایجاد می‌کند یا برای مشتری مفید است.
• پرسیدن سوالات توسعه‌دهندگان تا زمانی که درک خوبی از نحوه اجرای PBIها داشته باشند.
• همکاری تیم‌های اسکرام در حل مسائل به صورت مشترک.
• تیم‌های اسکرام از متریک‌ها به‌عنوان ملاک انتخاب میزان کار برای اسپرینت استفاده می‌کنند.
• درک تیم‌های اسکرام از همه کارهای لازم برای ایجاد یک افزونه که با تعریف انجام شده (DoD) مطابقت داشته باشد و استفاده از این درک برای کمک به ظرفیت تیم.
• ایجاد استراتژی‌هایی که به چندین عضو تیم اجازه می‌دهد روی یک PBI متمرکز شوند.
• تمرکز تیم‌های اسکرام بر استراتژی‌هایی که اصل “به اندازه کافی” لین (lean) را دنبال می‌کنند.
• افزودن موارد بهبود به اسپرینت که در جلسه بازنگری اسپرینت قبلی کشف شده‌اند.

متن اصلی این نوشته در سایت Scrum.org را اینجا بخوانید.