Sprint Retrospective چیست؟ ۲۰ سوال برای رترو بهتر

تیمی که رترو را جدی نمی‌گیرد، محکوم است که اشتباه‌هایش را هر اسپرینت تکرار کند. جلسهٔ رترو اسپرینت، تنها فرصت تیم است تا نه دربارهٔ «چه ساختیم»، بلکه دربارهٔ «چطور ساختیم» صحبت کند. اما واقعیت این است که خیلی از رتروها بی‌نتیجه می‌مانند؛ یا به جلسهٔ سرزنش تبدیل می‌شوند، یا سؤال درستی پرسیده نمی‌شود، یا اقدام‌هایش هیچ‌وقت پیگیری نمی‌شوند.

در این مقاله می‌بینید Sprint Retrospective چیست، چه فرقی با Sprint Review دارد، چطور برگزار می‌شود، ۲۰ سؤال کاربردی برای یک رتروی مؤثر و فرمول رسیدن از بحث به اقدام واقعی را یاد می‌گیرید.

Sprint Retrospective چیست؟ (پاسخ سریع)

Sprint Retrospective جلسه‌ای در پایان هر اسپرینت است که در آن تیم به فرایند کار خودش نگاه می‌کند — چه چیزی خوب پیش رفت، چه چیزی بد، و چه چیزی را باید در اسپرینت بعد بهبود داد — و در نهایت یک یا دو اقدام مشخص برای بهبود انتخاب می‌کند.

فرق Sprint Retrospective و Sprint Review چیست؟

این دو جلسه اغلب قاطی می‌شوند، اما موضوعشان کاملاً متفاوت است:

مثال عددی: در مرور اسپرینت، تیم نشان می‌دهد که از ۱۶ امتیاز برنامه‌ریزی‌شده، ۱۴ امتیاز را تحویل داده است (دربارهٔ محصول). در رترو، همان تیم بررسی می‌کند که چرا ۲ امتیاز ناتمام ماند — مثلاً تست‌ها دیر شروع شدند (دربارهٔ فرایند). مرور می‌گوید «کجا هستیم»؛ رترو می‌گوید «چطور بهتر برسیم».

چرا رترو مهم است؟

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

سه سؤال پایهٔ رترو

1. چه چیزی خوب بود؟ (باید ادامه یابد)
2. چه چیزی خوب نبود؟ (باید اصلاح شود)
3. چه چیزی را می‌خواهیم بهبود دهیم؟ (اقدام بعدی)

این سه سؤال، چارچوب ساده و همیشگی رتروست و همهٔ فرمت‌های پیشرفته‌تر فقط همین‌ها را باز می‌کنند. اگر در تیم تازه‌کار هستید، از همین سه سؤال شروع کنید؛ پیچیدگی فرمت را برای وقتی نگه دارید که این چارچوب ساده دیگر جواب ندهد.

رترو چقدر زمان می‌گیرد؟

مدت رترو با طول اسپرینت متناسب است. یک قاعدهٔ سرانگشتی رایج:

نکته مهم: رترو هم مثل بقیهٔ جلسات اسکرام Timebox است. زمان مشخص بگذارید و به آن پایبند بمانید؛ رترویی که بدون سقف زمانی کش بیاید، معمولاً از بحث مفید به حاشیه می‌رود.

۲۰ سوال برای رتروی بهتر

دربارهٔ فرایند:

1. کدام بخش از کارمان بیشترین اصطکاک را داشت؟
2. کجاها منتظر هم ماندیم؟
3. تخمین‌هایمان چقدر به واقعیت نزدیک بود؟
4. کدام مرحلهٔ کار گلوگاه بود؟

دربارهٔ همکاری:

1. ارتباط بین اعضا کجا خوب بود و کجا نه؟
2. آیا همه حرف‌شان را زدند یا بعضی ساکت ماندند؟
3. چه چیزی همکاری را سخت می‌کرد؟
4. کجاها کمک به یکدیگر می‌توانست سرعت را بیشتر کند؟

دربارهٔ کیفیت:

1. دوباره‌کاری چقدر داشتیم و از کجا آمد؟
2. کیفیت تحویل‌هایمان این اسپرینت چطور بود؟
3. چه باگ‌هایی قابل پیشگیری بودند؟

دربارهٔ تیم و انگیزه:

1. چه چیزی انگیزه‌مان را بالا برد؟
2. چه چیزی تمرکزمان را گرفت؟
3. بیشترین انرژی کجا هدر رفت؟

برای آینده:

1. اگر این اسپرینت را دوباره انجام می‌دادیم، چه چیزی را عوض می‌کردیم؟
2. چه عادت کوچکی را باید بسازیم؟
3. چه عادت بدی را باید کنار بگذاریم؟
4. بزرگ‌ترین فرصت بهبود ما چیست؟
5. چه چیزی را در اسپرینت بعد امتحان کنیم؟
6. اگر فقط یک اقدام را انتخاب کنیم، آن چیست؟

نکتهٔ استفاده: این ۲۰ سؤال را یک‌جا نپرسید. در هر رترو ۴ تا ۶ سؤال متناسب با حال تیم انتخاب کنید. سؤال بیستم — «اگر فقط یک اقدام را انتخاب کنیم» — باید تقریباً همیشه آخرین سؤال باشد.

چطور رترو را مؤثر برگزار کنیم؟

1. محیط امن بسازید: رترو جای سرزنش نیست؛ جای یادگیری است. اگر کسی بترسد، حرف واقعی زده نمی‌شود.
2. به گذشتهٔ نزدیک بچسبید: فقط همین اسپرینت را بررسی کنید، نه شکایت‌های قدیمی.
3. داده بیاورید: نمودارها و آمار اسپرینت (Velocity، دوباره‌کاری، باگ‌ها) را مبنای بحث کنید، نه فقط حس و حال.
4. به اقدام برسید: رترو باید با یک تا دو اقدام مشخص با مالک و مهلت تمام شود، نه فهرست آرزوها.
5. از رتروی قبل شروع کنید: اول اقدام‌های رتروی قبل را مرور کنید: اجرا شدند؟ اثر داشتند؟

یک مثال واقعی از رتروی مؤثر

تیم متوجه می‌شود در رترو، همه از «وقفه‌های زیاد در روز» ناراضی‌اند. به‌جای گفتن «باید بهتر شویم»، یک اقدام مشخص انتخاب می‌کنند: «هر روز ۲ ساعت بدون جلسه و چت» و یک نفر را مالک پیگیری‌اش می‌کنند. در رتروی بعدی، همین یک اقدام را بررسی می‌کنند: کار کرد یا نه؟

مثال عددی از اثر اقدام: تیم تصمیم می‌گیرد از اسپرینت بعد، تست را از روز اول شروع کند. نتیجهٔ قابل‌سنجش: دوباره‌کاری ناشی از باگ، از ۳ روز در اسپرینت قبل به کمتر از ۱ روز می‌رسد و Velocity از ۱۶ به ۱۹ امتیاز می‌رود. این عددها نشان می‌دهند اقدامِ درست، اثر واقعی دارد.

اشتباهات رایج

1. رترو بدون اقدام: بحث خوب اما بدون خروجی عملی، بی‌فایده است.
2. تبدیل به جلسهٔ سرزنش: تمرکز روی «چه کسی»، نه «چه چیزی».
3. اقدام‌های زیاد و مبهم: ۱۰ اقدام بزرگ معمولاً هیچ‌کدام اجرا نمی‌شود.
4. پیگیری نکردن: اقدام رتروی قبلی در رتروی بعدی بررسی نمی‌شود.
5. شرکت‌نکردن مدیر محصول یا ردهٔ بالاتر به‌عنوان ناظر: حضور مدیری که تیم از او حساب می‌برد، امنیت روانی را از بین می‌برد.

مزایا و محدودیت‌های رترو

مزایا:

• بهبود فرایند را به یک عادت دوره‌ای تبدیل می‌کند.
• مشکلات کوچک را پیش از تبدیل‌شدن به بحران شناسایی می‌کند.
• اعتماد و امنیت روانی تیم را در بلندمدت تقویت می‌کند.

محدودیت‌ها و Trade-off:

• رتروی خوب، زمان می‌برد و اگر جلسه‌ها زیاد باشند، فشار جلسات بالا می‌رود.
• اگر اقدام‌ها ثبت و پیگیری نشوند، رترو صرفاً یک هزینهٔ زمانی بی‌نتیجه است.
• برای تیم‌های تازه‌کار که هنوز اعتماد ساخته نشده، رترو ممکن است سطحی برگزار شود؛ این تیم‌ها باید اول روی امنیت روانی کار کنند.

نکات کاربردی

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

دوایتفای و رترو

رترو وقتی اثر دارد که اقدام‌هایش ثبت و پیگیری شوند و داده‌ی واقعی اسپرینت در دسترس باشد. در دوایتفای می‌توانید صورت‌جلسهٔ رترو را در مستندات پروژه نگه دارید، اقدام‌های بهبود را به‌عنوان تسک با مسئول و مهلت بسازید، وضعیتشان را روی برد کانبان دنبال کنید و در رتروی بعدی با گزارش‌های کاری و دادهٔ Velocity آن‌ها را مرور کنید. به این ترتیب بهبود مستمر، از یک جلسهٔ حرف‌زدن به یک چرخهٔ واقعی و قابل‌ردیابی تبدیل می‌شود.

جمع‌بندی

Sprint Retrospective موتور بهبود تیم است. با سه سؤال پایه شروع کنید، محیط امن بسازید، داده بیاورید و حتماً به یک یا دو اقدام مشخص با مالک و مهلت برسید. و مهم‌تر از همه، اقدام‌ها را در ابزار مدیریت کار ثبت کنید و در رتروی بعدی پیگیری‌شان کنید — رتروی بدون پیگیری، فقط یک جلسهٔ حرف‌زدن است.

اگر موضوع Sprint Retrospective برایتان مفید بود، پیشنهاد می‌کنیم مدیریت پروژه های نرم افزاری و اپلیکیشن برنامه ریزی روزانه را هم بخوانید.