اگر قسمت اول دلایل شکست اسکرام در ایران را نخوانده‌اید حتماً به شما پیشنهاد می‌کنم از آنجا شروع کنید. دوباره هم تأکید می‌کنم این مقاله قرار نیست اصول اجایل-اسکرام را بازتعریف کند بلکه فقط به مواردی که کمتر به آنها توجه شده خواهد پرداخت.
در قسمقبلی مقاله به یکی از دلایل شکست اجایل-اسکرام با موضوع استراتژی یا چرایی استفاده از آن پرداختیم. در این قسمت از مقاله نیز به موضوع عدم قطعیت می‌پردازیم که بخش مهمی از روح اجایل و اسکرام است البته حتماً از نگاهی که تابه‌حال به آن کمتر نگاه کرده‌ایم.
در تعاریف کلاسیک و عمومی اجایل عدم قطعیت را این‌گونه شرح می‌دهند: ازآنجایی‌که معمولاً تعریف اولیه از موضوع با نتیجه دلخواه متفاوت است پس ما در فضای عدم قطعیت به سر می‌بریم. عمومی‌ترین مثال این است که مشتری خودش به‌درستی نمی‌داند چه می‌خواهد! یا چیزی در ذهن دارد را به‌درستی بیان نمی‌کند یا به‌درستی به تیم تولید و توسعه منتقل نمی‌شود و معمولاً نتیجه با چیزی که مشتری یا ذی‌نفعان انتظار دارد متفاوت است پس ما با وجود این عدم قطعیت باید شیوه‌ای را اتخاذ کنیم که این مشکل را برطرف کرده یا به حداقل برسانیم. این راهکار هم چیزی نیست جز اجایل!
اساساً اشتباه نگفته‌ایم که اجایل زاده مشکل عدم قطعیت در پروژه‌ها بوده است. هرچقدر پروژه‌های بشر پیچیده‌تر و بزرگ‌تر شد و در مسیر انجام پروژه و کسب نتیجه با مشکل روبرو شد با مسئله عدم قطعیت به‌عنوان ریشه مشکلات برخورد کرد. مدیران پروژه و سازمان‌های مدیریتی به دنبال راه حلی برای حل این مشکل گشتند که شامل مدل چابک یا همان اجایل بود.
در این مدل که بر مبنای روش تکمیل شونده (Incremental) و یا تکرارشونده (Iterative) و البته نه محدود به اینها شکل گرفت تمرکز در مفهوم سطح بالا به درک درست نیاز مشتری، چرخه بازخورد (Feedback) و تبدیل آن به محصول نهایی بود.
احتمالاً از اکثر اسکرام مسترها بپرسید می‌گویند ما در چرخه‌های اسپرینت (Sprint) خروجی ممکن را در اختیار مشتری یا مالک محصول قرار می‌دهیم تا چرخه بازخورد و اصلاح را در دوره‌های بعدی اجرا کنیم و این را راه‌حل عدم قطعیت می‌دانیم. اما… مشکل همین جاست! برخی از این مسائل باید قبل از شروع اسپرینت حل شود! عجیب است؟ پس به مثالی که در ادامه می‌زنم توجه کنید.
فکر کنید در ضلع غربی زمینی می‌خواهیم دیوار بکشیم. خشت‌های دیوار در ضلع شرقی دپو شده است. اسپرینتی برنامه‌ریزی می‌کنیم که در طول یک هفته آجرها و مصالح را به محل ساخت دیوار منتقل کنیم (از ضلع شرقی به غربی) تا در اسپرینت بعدی شروع به ساختن دیوار کنیم و پروسه ساخت دیوار منتظر متریال نماند. می‌نشینیم و برنامه‌ریزی اسپرینت را انجام می‌دهیم. یک فرقون برای جابه‌جایی راحت‌تر مصالح تدارک می‌بینیم و این کار را به ۲ نفر می‌سپاریم.
در جلسه روزانه (Daily Meeting) فردا میاییم و وضعیت را بررسی می‌کنیم نفرات به ما می‌گویند در وسط زمین موانعی مانند جوب آب و تپه‌ای وجود دارد که اگر بخواهند آن را دور بزنند کار در پایان اسپرینت تمام نمی‌شد. ما به فکر چاره می‌افتیم که ماشینی برای حل این مشکل تدارک ببینیم اما متأسفانه در برنامه‌ریزی همین اسپرینت برای ماشین‌های کارگاه کار دیگری را تعیین کرده‌ایم و نیروی انسانی ما در اسپرینت بعدی منتظر آماده بودن آجر و مصالح است و اگر نرسد همه چیز به هم می‌خورد.
اگر مدیر خوش‌شانسی باشیم راه حلی (Workaround) مانند اجاره ماشینی از خارج از کارگاه برای این مشکل پیدا می‌کنیم و اگر خوش‌شانس نباشیم تمام برنامه‌ریزی‌های منظم و دقیقی که انجام داده‌ایم تحت‌تأثیر این موضوع پیش‌بینی‌نشده که خودش نوعی از عدم قطعیت است دست خوش تغییر می‌شود و زمان را از دست می‌دهیم.
اگر با خودمان صادق باشیم عدم قطعیت بالا تقریباً ربطی با چرخه بازخورد ندارد. عملاً عدم پیش‌بینی و نظاره (Observation) درست باعث این مشکل شده است. در پروژه‌های پیچیده این مشکلات با عنوان موانع فنی (Technical Obstacles) پیش میایند که حاصل همان طرح‌ریزی سطحی و یا عدم نظاره درست است.
حتماً شما هم مثل من این افسانه را شنیده‌اید که فرنگی‌ها برای انجام کاری یک سال مطالعه و برنامه‌ریزی می‌کنند و در چند هفته یا ماه اجرا! چقدر این افسانه حقیقت داشته باشد یا نه ولی راه‌حل همین است. بخصوص وقتی پروژه‌های از جنس تحقیق و توسعه باشند یعنی باید قبل از اجرا راهکاری کشف، آزمایش و اگر مؤثر بود وارد چرخه توسعه بشود نه اینکه وسط پروژه برنامه‌نویس به شما بگوید این راهی که فکر می‌کردیم جواب بده، جواب نمی‌دهد!
طرح‌ریزی عمیق نیازمند افرادی مسلط به دامنه (Domain Expert)کار است. می‌بایست قبل از ورود به هر چرخه اسپرینت توسعه، تحقیق و آزمایش لازم را انجام داده باشند. شاید درست به نظر برسد که باید در اسپرینت‌های قبل اسپرینتی برای تحقیق و آزمایش برگزار و نتایج آن به اسپرینت بعدی موکول شود. اما راستش را بخواهید به نظرم اسکرام فضای مناسبی (کافی) برای تحقیق و آزمایش ندارد چه‌بسا موضوع تحقیق و آزمایش حتی پیچیده‌تر از فضای عدم قطعیت است و در فضای نادانسته زیست می‌کند. تا جایی که اداره تحقیقات انستیتو تکنولوژی ماساچوست (MIT) کتابی با نام "مدیریت بر مدیریت‌ناپذیر – مدیریت سازمان‌های تحقیقاتی" نوشته آر. کی. جین و اچ. سی. تریاندیس در این زمینه منتشر کرده است. مدیریت بر مدیریت‌ناپذیر! (کتاب دیگری نیز با همین نام منتشر شده "مدیریت بر مدیریت‌ناپذیر - قوانین، ابزارها و بینش برای مدیریت افراد و تیم‌های نرم‌افزار اثر میکی مانتل و ران لیچتیکه خواندن آن هم خالی‌ازلطف نیست!)
هرچند بر این باورم تحقیق و آزمایش به‌خودی‌خود موضوع پیچیده است (به‌مراتب پیچیده‌تر از پیداکردن پستی‌وبلندی‌های زمینی که در مثال گفتیم) اما شما و تیمتان درخور پیچیدگی و اهمیت پروژه‌تان باید به راه‌حل این موضوع فکر کنید. افرادی مسلط به دامنه این مسئولیت را قبول و بالاخره به روشی متناسب با تیم و ابعاد پروژه در قالب اسپرینت‌های قبلی یا هر شیوه دیگری به نتیجه برسانند.
برای اطمینان از حدود 10 اسکرام مستر پرسیدم هدف از اسپرینت چیست؟ اکثر قریب به‌اتفاق گفتند که نتایج ملموس را بتوان در اختیار مشتری قرار داد. اتفاقاً منابع اسکرام هم همی را بیان می‌کنند اما به نظرم این کفایت نمی‌کند! اسپرینت در چرخه اجایل-اسکرام نقش بزرگی را بازی می‌کند و آن‌قدر مؤلفه‌هایی دارد که فقط همین دلیل کفایت نمی‌کند و اساساً به نظر من شما می‌توانستی خارج از چرخه اجایل حتی در برنامه‌ریزی و مدیریت پروژه آبشاری به نحوی برنامه‌ریزی انجام دهید که نتیجه هرکدام از خروجی‌ها را ببری به مشتری نشان بدهی و فیدبک بگیری پس قطعاً اجایل-اسکرام هدف مهم‌تری را از اسپرینت انتظار دارد و از آن مهم‌تر معتقدم هیچ آدم عاقلی نمی‌ایستد در پایان اسپرینت حتی اگرچند روز باشد صبر کند تا متوجه شود اشتباه می‌کند! پس من تعریف جدیدی از اسپرینت را برای خودم به وجود آوردم. (ادعایی ندارم این تعریف از آن من باشد چرا که آن‌قدر به نظرم بدیهی است حتماً کسانی قبل از من به آن فکر کرده‌اند):
من معتقدم اسپرینت تنها بخشی از پروژه است که ما در آن باید آگاهی کامل داشته باشیم و فضای بزرگ عدم قطعیت پروژه را به فضای قطعیت در بازه‌های کوچک تبدیل کنیم. حالا اگر اشتباه هم کردیم در دوره‌های بعدی از آن درس‌آموخته در آغاز اسپرینت جدید استفاده کنیم.
این قطعیت می‌تواند شامل موارد ذیل باشد (صدالبته نه محدوده به اینها):
· بدانیم مشتری از خروجی کوچک اسپرینت چه انتظاری دارد
· پیاده‌سازی این خروجی چه پیچیدگی و موانع فنی دارد
· ریسک‌های محتمل و راهکارهای مربوط به ریسک‌ها از قبل مشخص باشد.
علاوه بر هر حالتی از عدم قطعیت که در اجایل-اسکرام به آن می‌پردازیم توجه به موانع فنی به همان مقدار مهم است. بارها دیده‌ام که اتفاقاً هم مشتری می‌داند چه می‌خواهد هم به‌درستی بیان کرده است و هم به‌درستی منتقل شده است ولی موانع فنی از جنس مفروضات غلط یا پیچیدگی پیش‌بینی‌نشده موجب تأخیر در تحویل نتایج و آزار تیم و ذی‌نفعان می‌شود.
موضوع مهم توجه به این موانع پیش از شروع هر چرخه توسعه با استفاده از هر روشی متناسب با ابعاد، پیچیدگی و یا اهمیت پروژه شما است. هیچ راهکار قطعی هم برای آن وجود ندارد اما عدم توجه به آن حتماً موجب اشکالات بزرگ‌تری خواهد شد.
