جلسات بازبینی (Sprint Review)

مقدمه ای بر بازبینی اسپرینت/Sprint Review
Sprint Review یک جلسه کاری است که در آن تیم اسکرام کار تکمیل شده خود را به ذینفعان ارائه می دهد و از آنها بازخورد و راهنمایی می خواهد. تیم اسکرام و ذینفعان با هم در مورد پیشرفت انجام شده به سمت هدف محصول، هرگونه تغییر در حال ظهور در فضای تجاری یا فنی بحث می کنند و در مورد کارهای بعدی با یکدیگر همکاری می کنند.
بررسی اسپرینت در یک نگاه
محدوده زمانی | شرکت کنندگان | انطباق/سازگاری | بررسی/بازرسی | رویداد |
4 hours for a 1 month Sprint | Scrum Team, Stakeholders | Product Backlog | Increment, Sprint, Product Backlog, Progress toward Product Goal | Sprint Review |
برگزاری Sprint Review
Sprint Review یک جلسه کاری و مشارکتی برای تیم اسکرام و ذینفعان برای بررسی پیشرفت و تطبیق برنامههای آینده است. اشتباه رایجی که تیمها در انجام بررسی اسپرینت مرتکب میشوند این است که مالک محصول کار انجام شده در طول اسپرینت را به مخاطبان ذینفعان ارائه میدهد. این یکی از قدرتمندترین ابزارهای اسکرام را حذف می کند: بازخورد مکرر ذینفعان.
در عوض، کل تیم اسکرام باید به بررسی Sprint به عنوان راهی برای همکاری با ذینفعان در مورد ارزشی که ایجاد کردهاند و اینکه چگونه باید برنامههای آتی خود را به گونهای تطبیق دهند که ارزش بیشتری ایجاد کند، نگاه کنند.
مهم است که برای Review از قبل برنامه ریزی کنید. مثلا:
- تیم باید تصمیم بگیرد که چه چیزی مورد بررسی و بحث قرار می گیرد. به یاد داشته باشید: تنها کارهایی که با تعریف Done مطابقت داشته باشند می توانند در طی Sprint Review بررسی شوند.
- بر اساس آنچه در Review مورد بحث قرار می گیرد، شخصی در تیم، اغلب مالک محصول، مطمئن می شود که ذینفعان درستی به Sprint Review دعوت شده اند.
- این تمرین خوبی است که تیم اسکرام چیز مهم بعدی را که میخواهد یاد بگیرد را شناسایی کند و برای دریافت بازخورد در مورد آن برنامهریزی کند.
- برای هر موردی که در طول Review مورد بحث قرار می گیرد، بهترین کار این است که به یکی از اعضای تیم وظیفه هدایت بحث داده شود. اغلب، شخصی که بحث را هدایت می کند، توسعه دهنده (یا توسعه دهندگان) است که روی آن مورد کار کرده است. معمولاً این ایده بدی است که مالک محصول بحث را در مورد همه موضوعات رهبری کند.
- هر کسی میتواند تسهیلکننده Sprint Review باشد. آنها می توانند عضوی از تیم اسکرام، یکی از ذینفعان یا فردی باشد که اصلاً در پروژه دخالت ندارد. اغلب، مالک محصول Sprint Review را تسهیل می کند زیرا آنها نمایندگان ذینفعان تیم اسکرام در طول اسپرینت هستند و اغلب در صحبت کردن به زبان مشتری بهترین هستند.
روش های مختلفی برای انجام Sprint Review وجود دارد و هیچ فرمت تجویز شده ای وجود ندارد. با این حال، مهم است که هدف از انجام Review محقق شود.
تیم اسکرام و ذینفعان باید:
- نتیجه اسپرینت را بررسی کنند.
- در مورد پیشرفت به سمت Product Goal بحث کنند.
- هر گونه تغییر در محیط، مانند تغییرات در بازار، رفتار مشتری و بازخورد مشتری را مورد بحث قرار دهند.
- در مورد کارهای بعدی همکاری کنند. در نظر بگیرید که ارزشمندترین کار بعدی چیست و Product Backlog را به روز کنند.
Sprint Review را موثرتر برگزار کنید
هدف، تایم باکس و شرکت کنندگان در Sprint Review به خوبی مشخص شده است. با این حال، ما گاهی اوقات میبینیم که تیمهای اسکرام در ضد الگوهایی قرار میگیرند که ارزش کار آنها را کاهش میدهد.
ضد الگوهای رایج عبارتند از:
- Sprint Review یک جلسه اعلام وضعیت، نمایش دمو یا ارائه یک طرفه است – در عوض، باید فرصتی برای مالک محصول و ذینفعان باشد تا جهت آینده محصول را شکل دهند.
- محصول نشان داده شده با تعریف Done مطابقت ندارد یا با Increment قبلی ادغام نشده است – گاهی اوقات آنچه ارائه می شود با استانداردهای کیفیت تیم مطابقت ندارد و تنها بخشی از محصول نشان داده می شود. در هر صورت، ذینفعان هنگام ارائه بازخورد در مضیقه قرار می گیرند.
- تیم لیستی از PBI های تکمیل شده را بدون نشان دادن نتایج PBI به ذینفعان یا بحث در مورد کار ارائه می دهد.
- نتیجه اسپرینت فقط در یک ارائه نشان داده می شود. خود محصول/Increment نشان داده نمی شود.
- Sprint Review به این دلیل انجام می شود که مالک محصول کار تکمیل شده توسط توسعه دهندگان را بپذیرد – این یک افسانه است که یک Sprint Review موفق زمانی است که مالک محصول کار را تایید می کند. مالک محصول باید در طول اسپرینت با تیم کار کند و هیچ چیز نباید در Sprint Review غافلگیر کننده باشد.
- توسعهدهندگان شرکت نمیکنند – با غیبت در Sprint Review، توسعهدهندگان فرصت دریافت بازخورد مستقیم ذینفعان را از دست میدهند و زمینههای مربوط به تصمیمگیریهای مربوط به تغییرات در Product Backlog و کارهای بعدی را از دست خواهند داد.
- هیچ کاربر یا مشتری واقعی در میان ذینفعان حاضر وجود ندارد – اغلب همکاران و مدیریت به عنوان نماینده ای برای مشتریان محصول عمل می کنند. یافتن مشتریانی که برای بررسی یک محصول در حال توسعه مناسب هستند، همیشه کار آسانی نیست، اما زمانی که اتفاق بیفتد، ارزشمند است.
نکاتی برای داشتن Sprint Review قوی
شکستن ضدالگوهای ذکر شده در بالا به ایجاد Sprint Review قوی و موثر کمک می کند. نکات زیر را در نظر بگیرید:
- اطمینان حاصل کنید که ذینفعان درستی به Sprint Review دعوت شده اند و آنها هدف از Sprint Review و نقش خود را در آن درک می کنند.
- همکاری مستقیم بین ذینفعان و اعضای تیم را تقویت کنید.
- رویداد را تسهیل کنید تا ذینفعان بتوانند با محصول ارتباط برقرار کنند.
- اطمینان حاصل کنید که زبان مورد استفاده برای همه شرکت کنندگان قابل درک است. توسعه دهندگان باید در برابر وسوسه استفاده بیش از حد اصطلاحات فنی مقاومت کنند.
- در مورد آنچه انجام شد و انجام نشد شفاف باشید – تیم خلاصه ای از کارهای انجام شده در Sprint و کارهای انجام نشده و بازگرداندن آنها به Product Backlog ارائه می دهد. برای شفافیت در این موضوع، تعریف Done را قابل مشاهده نگه دارید.
- در مورد نحوه انجام Sprint بحث کنید – توسعه دهندگان هر مشکلی را که در طول Sprint داشتند و اقدامات انجام شده برای غلبه بر آنها را به اشتراک می گذارند. فرصتی برای بحث در مورد موانعی که توسط تیم اسکرام قابل حل نیست را در نظر بگیرید. با درگیر کردن ذینفعان، تیم می تواند از این رویداد برای توسعه مشارکت نزدیک با ذینفعان استفاده کند.
- بازخورد جمع آوری کنید – توسعه دهندگان به ذینفعان نشان می دهند که چه کاری انجام شده است تا بازخوردی در مورد ارزش آنچه تکمیل شده جمع آوری کنند. این بازخورد به توسعهدهندگان و مالک محصول کمک میکند تا ارزیابی کنند که آیا مفروضاتی که انجام دادهاند درست یا غلط بودهاند.
- بررسی وضعیت فعلی Product Backlog – مالک محصول وضعیت فعلی Backlog را از جمله موارد Product Backlog که در Sprint تکمیل نشده اند را ارائه می دهد. بر اساس بازخوردهای دریافتی از ذینفعان، فرصت های جدید ممکن است شناسایی شوند و مورد بحث قرار گیرند و به طور بالقوه به کارهای Backlog اضافه شوند.
- تصمیم بگیرید که بعداً چه کاری انجام دهید – تیم اسکرام و ذینفعان بر اساس آموخته ها و نتایج حاصل از اسپرینت بر روی کار بالقوه برای اسپرینت بعدی همکاری می کنند. فرصت ها، ریسک ها، مسائل و شرایط بازار جدید مورد بحث قرار می گیرد.
- Product Backlog را بر اساس بحث های انجام شده در Sprint Review تطبیق دهید.
- چشم انداز محصول، محرک های ارزش کلیدی، هدف محصول و هدف اسپرینت را مرور کنید.
- از ذینفعان بخواهید که به Sprint Review امتیاز دهند تا بدانید در کجا میتوان پیشرفتها را انجام داد.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.