جستجو برای:
سبد خرید 0
  • مسترکلاس WPD
  • دوره های آموزشی
    • اسکرام مستر
    • مالک محصول
    • دولوپر
    • مدیران
    • مشترک برای همه نقش ها
    • سازمانی و تیمی
  • آکادمی
  • باشگاه پیشرفت
  • مدرسان
  • تماس با ما
  • سبد خرید

ورود

رمز عبور را فراموش کرده اید؟

هنوز عضو نشده اید؟ عضویت در سایت
  • پشتیبانی: 09386596030
  • info@scrumschool.ir
  • تدریس در مدرسه اسکرام
  • لیست علاقه‌مندی‌ها
مدرسه اسکرام
  • مسترکلاس WPDداغ
  • دوره های آموزشی
    • اسکرام مستر
    • مالک محصول
    • دولوپر
    • مدیران
    • مشترک برای همه نقش ها
    • سازمانی و تیمی
  • آکادمی
  • باشگاه پیشرفت
  • مدرسان
  • تماس با ما
  • سبد خرید
ورود / عضویت

وبلاگ

مدرسه اسکراممقالاتبدون دسته بندیجلسات بازبینی (Sprint Review)

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

12 تیر 1402
ارسال شده توسط امیر دوراندیش
بدون دسته بندی

مقدمه ای بر بازبینی اسپرینت/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 امتیاز دهند تا بدانید در کجا می‌توان پیشرفت‌ها را انجام داد.
بعدی جلسات دیلی اسکرام (Daily)
قبلی جلسات گذشته نگر (Sprint Retrospective)

دیدگاهتان را بنویسید لغو پاسخ

برای نوشتن دیدگاه باید وارد بشوید.

جستجو برای:
  • محبوب
  • جدید
  • دیدگاه ها
پشتیبانی

توجه
مدرسه اسکرام هیچ گونه وابستگی به موسسه Scrum.org ندارد و ادعا هم نمی کند که محتواهایی که تولید و ارائه می کند و کلاسهایی که برگزار می نماید، مورد تایید موسسه مذکور است. با اینحال مدرسه اسکرام بطور کامل دنباله رو موسسه Scrum.org است و تمام تلاش خود را بکار میگیرد تا محتواهایی که تولید می کند منطبق بر سطوح کیفیت این موسسه باشد.
در ضمن تمامی کلمات مخفف ، عبارتها و سرنامهایی که در ادامه آمده جزء داراییهای فکری و حقوق معنوی موسسه Scrum.org می باشد و مدرسه اسکرام صرفا از آنها به عنوان مرجع و برای ارجاع استفاده می کند و در مورد مالکیت آنها هیچگونه ادعایی ندارد.

Awareness
We are not affiliated with Scrum.org and do not claim that our contents and classes are endorsed and confirmed by Scrum.org. Furthermore, we are not a representative of Scrum.org.
NOTE: All following words, acronyms, and phrases are trademarks belonging to Scrum.org:
PSM I, PSM II, PSM III, PSPO I, PSPO II, PSPO III, PSD I, SPS, PAL I, PSK I, PSU I, Professional Scrum Master, Professional Scrum Product Owner, Professional Scrum Developer, Scaled Professional Scrum, Professional Agile Leadership, Professional Scrum with Kanban, Professional Scrum with User Experience.

خبرنامه

چیزی را از دست ندهید! ثبت نام کنید و از رویدادها، تخفیف ها و دوره های جدید ما مطلع باشید.

    Scrum School 2025 © | کلیۀ حقوق برای مدرسه اسکرام محفوظ است و استفاده از مطالب در جاهای دیگر صرفا با ذکر منبع و لینک به سایت مدرسه اسکرام بلامانع است.
    اشتراک گذاری در شبکه های اجتماعی
    ارسال به ایمیل
    https://scrumschool.ir/?p=11154
    مرورگر شما از HTML5 پشتیبانی نمی کند.