بازبینی اسپرینت خود را شروع کنید

جلسه بازبینی اسپرینت در اسکرام به نزدیک شدن ذینفعان پروژه و تیم اسکرام و ایجاد هماهنگی های لازم بسیار کمک می کند و حتما در این جلسات از افرادی که به نحوی در پروژه نقشی دارند دعوت کنید که بازخورد خود را ارائه دهند.
یکی از مسائل اصلی این جلسه بحث Inspect و Adaptation اجایل می باشد که علاوه بر مشاهده کارهای انجام شده در اسپرینت به بهبود مابقی مسیر تیم اسکرام کمک خواهد کرد.
همانطور که در مقالات قبل هم به آن اشاره کردیم داشتن جلسات طولانی کارایی و بازخورد تیم شما را کاهش می دهد و برای همین پیشنهاد می شود که برای جلسات یک هفته ای اسپرینت نهایتا یک ساعت زمان صرف کنید.⏲
در نرم افزار مدیریت پروژه اسکرام ما بردهای هوشمند برای راحتی کار جلسات بازبینی پیاده سازی شده است

در ادامه جلسه Sprint Review را مورد ارزیابی عملیاتی قرار میدهیم:

جلسه عملیاتی بازبینی اسپرینت در اسکرام

فرض بفرمائید که در جلسه برنامه ریزی اسپرینت که در مقاله بررسی تجربی جلسه برنامه ریزی اسپرینت آن را کامل تشریح کردیم قرار شد قابلیت های زیر را در طول اسپرینت انجام دهید:

• پیاده سازی لاگین وب سایت
• پیاده سازی ورود از طریق جیمیل
• پیاده سازی قابلیت یادآوری رمز عبور

در ابتدای جلسه برای شفاف شدن قابلیت های انجام شده، مالک محصول👴 موارد برنامه ریزی شده در اسپرینت جاری را برای ذینفعان و افرادی که در جلسه وجود دارند تشریح می کند(دقت داشته باشید ما اینجا مثال های نرم افزاری ارائه کردیم ولی به یاد داشته باشید که اسکرام صرفا برای محیط های توسعه نرم افزار نمی باشد و در تمامی محیط هایی که مدیریت های پیچیده دارند قابل استفاده می باشد) و تیم توسعه قابلیت های انجام شده در طول اسپرینت را برای اعضای حاضر در جلسه نمایش می دهند و افراد دعوت شده به جلسه بازخورد خود را اعلام کرده و برای بهبود عملکرد قابلیت ها با اعضای تیم اسکرام گفتگو می کنند.
به یاد داشته باشید که مالک محصول قبل از شروع جلسه با ذینفعان هماهنگی های مورد نظر برای شرکت در جلسه را انجام می دهد.
جلسه بازبینی اسپرینت در جهت کمک به برنامه ریزی اسپرینت های آینده بسیار کاربردی می باشد و خروجی این جلسه به بازبینی Product Backlog بسیار کمک می کند و ممکن است قابلیت های جدیدی را برای اسپرینت های آینده تولید کند یا نحوه ی عملکرد قابلیت های آینده پروژه را تحت تاثیر قرار دهد.
قطعا به خاطر دارید که در متدهای قدیمی مدیریت پروژه ها، از لحظه ای که پروژه شروع شده تا لحظه ای که بازخورد ذینفعان گرفته می شود معمولا مدت زمان زیادی سپری می شود و عملا افراد تیم و ذینفعان بعد از این مدت طولانی از یکدیگر بازخورد می گرفتند و مشکل از جایی شروع می شود که درک هر کدام از پروژه ممکن است متفاوت باشد😩 و عملا بعد از مدت زمان زیادی تازه از این مشکل باخبر شده و کار از کار گذشته است...

از انجام اشتباهات زیر در جلسات بازبینی اسپرینت خودداری کنید

•  آماده کردن ارائه برای پروژه یا گزارش وضعیت در جلسه review کاربرد ندارد و خود محصول را ارائه دهید
• عدم توجه به بازخوردهای ذینفعان پروژه در جهت بهبود Product Backlog
• شفاف نشدن وضعیت قابلیت های انجام شده
• فراهم نکردن شرایط تعامل و همکاری بین تیم اسکرام و ذینفعان پروژه

وظیفه ی هر کدام از نقش های اسکرام در جلسه Sprint Review

1- مالک محصول👴: نقش شفاف کردن قابلیت های انجام شده برای ذینفعان پروژه را برعهده دارد.
2- اسکرام مستر👲: در جهت افزایش کارایی جلسات و برقراری اصول اسکرام تلاش می کند.
3- توسعه دهندگان👱: ارائه سیستم تکمیل شده و بررسی اینکه اسپرینت به چه صورتی پیش رفت و با چه مشکلاتی  در طول اسپرینت مواجه شدند و چگونه راه حل مشکلات را پیدا کردند.
همچنین به سوالاتی که توسط اعضای جلسه در مورد Increment مطرح می شود پاسخ می دهند.