فهرست مطالب
جلسهٔ تحویل نسخه است و همه می‌دانند نسخه آماده نیست. مدیر محصول می‌پرسد «از کِی معلوم بود؟» و جواب صادقانه معمولاً این است: «از دو هفته پیش، ولی کسی جایی ثبتش نکرده بود.» توسعه دو روز دیر تمام شد، UAT به خاطر آماده نبودن محیط تست سه روز دیر شروع شد، و انتشار منتظر پنجرهٔ تغییر ماند. هیچ‌کدام از این‌ها به‌تنهایی فاجعه نبود؛ فاجعه این بود که همه با هم، روز تحویل کشف شدند.
این نوشته دربارهٔ یک عادت ساده است که این مشکل را تا حد زیادی حل می‌کند: برای هر نسخه، به‌جای یک تاریخ تحویل، چند نقطهٔ عطف تعریف کنید و برای هر کدام دو تاریخ نگه دارید: برنامه‌ای و واقعی.
مشکل «یک تاریخ تحویل»
بیشتر تیم‌ها برای نسخه فقط یک تاریخ دارند: همانی که اول گفته شد. این تاریخ دو ایراد دارد. اول اینکه بازخورد نمی‌دهد؛ تا روز تحویل نمی‌شود فهمید در مسیر هستیم یا نه. دوم اینکه وقتی تغییر می‌کند، معمولاً بی‌صدا تغییر می‌کند. کسی تاریخ کارت را عوض می‌کند و تاریخ قبلی از بین می‌رود؛ دیگر نمی‌شود دید برنامه چه بود و چقدر جابه‌جا شد.
نتیجه این است که تیم هیچ‌وقت از تأخیرهایش یاد نمی‌گیرد. اگر نمی‌دانید تأخیر نسخهٔ قبل در توسعه بود یا در UAT یا در انتظار انتشار، برنامهٔ نسخهٔ بعد را هم با همان خوش‌بینی می‌چینید.
چهار نقطهٔ عطف، هر کدام دو تاریخ
برای تیم‌های نرم‌افزاری که نسخه را از توسعه به تست کاربر و بعد به محیط عملیاتی می‌برند، چهار نقطهٔ عطف تقریباً همیشه کافی است:
- شروع توسعه: روزی که کار نسخه واقعاً شروع شد، نه روزی که جلسهٔ برنامه‌ریزی برگزار شد.
- پایان توسعه: کد کامل است و برای تست تحویل شده.
- ورود به UAT: نسخه روی محیط تست کاربر است و کاربران کلیدی می‌توانند آن را ببینند.
- لایو شدن: نسخه روی محیط عملیاتی منتشر شد.
برای هر کدام، تاریخ برنامه‌ای یک بار در شروع اسپرینت ثبت می‌شود و دیگر دست نمی‌خورد. تاریخ واقعی روزی ثبت می‌شود که آن اتفاق افتاد. یک نمونه:
| نقطهٔ عطف | برنامه‌ای | واقعی | اختلاف |
|---|---|---|---|
| شروع توسعه | ۱ مهر | ۱ مهر | — |
| پایان توسعه | ۸ مهر | ۱۰ مهر | ۲ روز تأخیر |
| ورود به UAT | ۱۲ مهر | — | ۳ روز مانده |
| لایو شدن | ۱۶ مهر | — | — |
از همین جدول کوچک، روز ۱۰ مهر معلوم است که دو روز از حاشیه خورده شده و فقط دو روز تا UAT مانده. این همان لحظه‌ای است که باید دربارهٔ آن حرف زد: آیا UAT را کوتاه‌تر کنیم، دامنه را کم کنیم، یا تاریخ لایو را با اطلاع همه جابه‌جا کنیم؟ هر سه تصمیم معقول‌اند؛ تصمیم نامعقول این است که تا ۱۶ مهر صبر کنیم.
یک نکتهٔ کوچک ولی مهم: تأخیر هر نقطه را نسبت به تاریخ برنامه‌ای خودش بشمارید، نه نسبت به نقطهٔ قبلی. اگر پایان توسعه دو روز دیر شد ولی ورود به UAT سر وقت انجام شد، یعنی تیم با فشردن کار جبران کرده و این هم اطلاعات مفیدی است. برعکس، اگر توسعه سر وقت تمام شد و UAT چهار روز دیر شروع شد، مشکل در تحویل به تست است، نه در برنامه‌نویسی، و راه‌حلش هم چیز دیگری است.
UAT مرحله‌ای است که بیشتر از همه گم می‌شود
در خیلی از تیم‌ها، به‌خصوص وقتی مشتری یا واحد کسب‌وکار باید نسخه را تأیید کند، بیشترین تأخیر نه در توسعه که بین پایان توسعه و تأیید نهایی است. محیط تست آماده نیست، کاربر کلیدی مرخصی است، یا باگ‌هایی پیدا می‌شود که برگشت به توسعه لازم دارند. وقتی ورود به UAT یک نقطهٔ عطف جدا با تاریخ خودش باشد، این تأخیر دیگر زیر عنوان کلی «نسخه دیر شد» پنهان نمی‌ماند.
باگ‌هایی که در UAT و بعد از لایو پیدا می‌شوند هم باید جایی ثبت شوند که به نسخه گره بخورند. برای اینکه کاربران خودشان مشکل را با اسکرین‌شات گزارش کنند، گزارش باگ از زبان کاربر با اسکرین‌شات را ببینید، و برای اینکه هر خطا از کشف تا رفع کجا می‌رود، چرخهٔ عمر خطا در نرم‌افزار را.
کانبان و اسپرینت روی یک تابلو
لازم نیست بین کانبان و اسپرینت یکی را انتخاب کنید. الگویی که برای خیلی از تیم‌های کوچک و متوسط جواب می‌دهد این است که ستون‌های تابلو جریان کار باشند (کارهای آماده، در حال انجام، در بررسی) و نسخهٔ بعدی یک ستون جدا باشد که کارت‌های آن نسخه در آن جمع می‌شوند و سربرگش چهار نقطهٔ عطف را نشان می‌دهد. با این ترتیب، هر کسی که به تابلو نگاه می‌کند در یک نگاه هم وضعیت کارها را می‌بیند و هم وضعیت نسخه را.
چند عادت کوچک که این کار را جدی نگه می‌دارد:
- تاریخ برنامه‌ای را پس از شروع اسپرینت عوض نکنید؛ اگر برنامه تغییر کرد، در توضیح نسخه بنویسید چرا.
- تاریخ واقعی را همان روز ثبت کنید، نه در جلسهٔ پایان اسپرینت از روی حافظه.
- در جلسهٔ روزانه، اول اختلاف‌ها را ببینید؛ کارت‌هایی که از سررسیدشان گذشته‌اند هم.
- در پایان هر نسخه، اختلاف چهار نقطه را کنار هم بگذارید و ببینید تأخیر معمولاً کجا رخ می‌دهد.
تیم فارسی‌زبان، تقویم شمسی
تیم‌های ایرانی معمولاً با ابزارهایی کار می‌کنند که برای زبان و تقویم دیگری ساخته شده‌اند. نتیجه‌اش آشناست: تاریخ‌ها میلادی ثبت می‌شوند و در ذهن به شمسی تبدیل می‌شوند، متن فارسی در کارت‌ها به هم می‌ریزد، و هر کسی که می‌خواهد بفهمد «۸ مهر» در ابزار کدام روز است، یک تقویم کناری باز می‌کند. این‌ها چیزهای کوچکی‌اند، ولی هر اصطکاک کوچک احتمال اینکه کسی تاریخ واقعی را همان روز ثبت کند را کمتر می‌کند. ابزاری که راست‌چین است و تاریخ را همان‌طور نشان می‌دهد که تیم حرف می‌زند، مستقیم روی کیفیت داده اثر دارد.
آمدن از ترلو بدون از دست دادن تاریخچه
بیشتر تیم‌ها با ترلو یا ابزاری شبیه آن شروع کرده‌اند و چیزی که مانع جابه‌جایی می‌شود، تاریخچه است: کارت‌ها، نظرها و پیوست‌هایی که سال‌ها جمع شده‌اند. پیش از انتقال، چند کار را انجام دهید: بردهای مرده را بایگانی کنید، برچسب‌ها را یکدست کنید، و تصمیم بگیرید کدام ستون‌ها در ساختار جدید به نسخه تبدیل می‌شوند. انتقال را اول با یک برد کوچک امتحان کنید و یک هفته هر دو را موازی نگه دارید.
BoardMug برای همین کار ساخته شده
بوردماگ تابلوی کانبان فارسی و راست‌چین برای تیم‌های نرم‌افزاری است. هر ستون می‌تواند یک اسپرینت باشد با نام نسخه و تاریخ برنامه‌ای و واقعی برای همین چهار نقطهٔ عطف (شروع توسعه، پایان توسعه، ورود به UAT و لایو شدن) با تقویم شمسی. سربرگ اسپرینت وضعیت، شمارش معکوس تا نقطهٔ عطف بعدی و روزهای تأخیر را نشان می‌دهد و کارت‌های گذشته از سررسید علامت می‌خورند. تغییرات بی‌درنگ برای همهٔ اعضای برد دیده می‌شود، هر برد گفت‌وگوی خودش را دارد، و بردهای ترلو با ستون‌ها، کارت‌ها، برچسب‌ها، نظرها و پیوست‌ها از داخل خود برنامه منتقل می‌شوند. هم روی سرور ما اجرا می‌شود و هم با نصب اختصاصی روی Windows Server و IIS با SQL Server خودتان.
صریح بگوییم: گانت، وابستگی بین کارها و تایم‌شیت ندارد و اپ موبایل جدا هم ندارد؛ عمداً ساده مانده است. اگر پروژه‌تان با مسیر بحرانی برنامه‌ریزی می‌شود، ابزار دیگری لازم دارید. جزئیات در boardmug.ir.
جمع‌بندی
یک تاریخ تحویل، تأخیر را تا روز آخر پنهان می‌کند. چهار نقطهٔ عطف با تاریخ برنامه‌ای ثابت و تاریخ واقعی که همان روز ثبت می‌شود، تأخیر را وقتی نشان می‌دهد که هنوز می‌شود درباره‌اش تصمیم گرفت، و در پایان هر نسخه به تیم می‌گوید کجا معمولاً عقب می‌افتد. برای آشنایی با بقیهٔ ابزارهای خانوادهٔ ماگ، به صفحهٔ اصلی سر بزنید.