انجمن انفورماتیک ایران انجمن انفورماتیک ایران انجمن انفورماتیک ایران
گزارش کامپیوتر شماره 234, ویژه مرداد و شهریور ماه 96 منتشر شد. چهارشنبه  ٠١/٠٩/١٣٩٦ ساعت ٢٠:١٠
 

 گاهی نیاز است که چابک تر باشید
بازخوانی اجرای موفق یک پروژه به شیوه­ چابک

پویا شهبازیان
مشاور تولید نرم‌افزار در شرکت آسا
پست الکترونیکی: pooya.shahbazian@yahoo.com


 

پایبندی به یک شیوۀ مشخص برای انجام کار به منظور قابل تکرار کردن موفقیت­ها راهی منطقی و معقول است. اما محصور ماندن در چارچوب­ فرآیندها و ترس از شکستن و زیرپا گذاشتن آن ممکن است فرآیند را به ابزار شکست پروژه تبدیل کند و در کم‌عارضه‌ترین حالت، پروژه را به بهترین هدف ممکن آن نرساند. این حالت زمانی رخ می­دهد که فرآیند را تنها به دلیل فرآیند بودن آن اجرا کنیم.
همچنین به مرور زمان در­می­یابید که تمام عوامل موفقیت در پروژه در فرآیند مورد استفاده پوشش داده نشده است. لذا نیاز است تا در چنین مواقعی پیش نیازهای لازم برای به بار نشستن عملکرد در چارچوب فرآیندی مشخص را پیشاپیش آماده کرده باشید و حتی در حین اجرای پروژه بنا به نیاز و شرایط، رویکرد و تجربه­ای را از سایر فرآیندها به عاریت بگیرید.
من به همراه یک تیم این چارچوب فکری را در پروژه­ای به کار گرفتیم، تجربه­ای که یکی از بهترین تجربه­های کار ما شد. در انجام این پروژه از روشگان اسکرام استفاده شد، اما در میانه پروژه مجبور به زیرپا گذاشتن برخی از تجربه­های این چارچوب شدیم. از طرفی اجرای خود این فرآیند با تکیه بر پیش نیازهایی که مدت‌ها پیش از آن شکل گرفته بودند منجر به موفقیت پروژه شد. در ادامه به بازخوانی این پروژه و بررسی نقاط شکست فرآیند و پیش نیازهای منجر به موفقیت خواهیم پرداخت.
داستان پروژه
هدف از پروژه تهیه سیستمی بود برای کمک به استقرار یک سیستم سازمانی بزرگتر. تیمی که کاربر اصلی سیستم بود نیز دید واضحی از سیستمی که باید تولید می­شد نداشت. از دید مشتری قرار بود تنها عملیات جمع آوری داده با سیستم انجام شود و نه چیزی بیشتر.
در آغاز کار تصمیم­ گرفتیم که:
1-   هر هفته یک نسخه از سیستم را انتشار دهیم و هر هفته تنها در باره­ با اولویت­ترین نیازهای هفته­ پیش‌رو صحبت کنیم و آن‌ها را انجام دهیم.
3-   به منظور تعدیل فشار کار، تنها به اندازه­ ظرفیت تیم یعنی چیزی نزدیک به چند ده نفر ساعت در هفته کار برای انجام برداریم.
4-   وجود آزمایش­های خودکار را مبنای پذیرش کارهای انجام شده قرار دهیم. لذا سیستم باید آزمایش­های خودکار می­داشت وبرای اجرای منظم آزمایش‌ها باید Build خودکار در پروژه استفاده می­شد.
هفته اول
جلسه­ای با حضور اعضای تیم و نماینده مشتری (مالک محصول در اسکرام) برگزار شد، چشم اندازی کلان از سیستم توصیف شد و  توافق شد که بخش جمع­آوری اطلاعات سیستم به همراه بخش امنیت آن پیاده­سازی شود.
با کمک مالک محصول، چگونگی ثبت اطلاعات در سیستم با جزئیات، مورد بررسی قرار گرفت. کارهای لازم فنی مانند طراحی بانک اطلاعاتی و زیرساخت و ... برای انجام ویژگی درخواست شده مشخص شد. طی یک هفته­ کارهایی برای آماده سازی زیرساخت و طراحی معماری مناسب انجام شد، در عین حال بخشی از سیستم که حداقل لازم برای ورود و ثبت اطلاعات را فراهم می­کرد به انجام رسید. در پایان هفته جلسه­ای برگزار شد، محصول ارائه شد و به تیم استفاده کننده تحویل شد. تیم استقرار ثبت اطلاعات پایه سیستم را شروع کرد و ثبت بخش­های اصلی از اطلاعاتی که باید در سطح سازمان جمع آوری می­شد آغاز شد.
هفته دوم
با عملیاتی شدن بخش­هایی از سیستم، مالک محصول مفهوم جدیدی با عنوان تایید اطلاعات جمع آوری شده توسط سیستم را مطرح کرد که تا پیش از این صحبتی از آن نشده بود. اولویت این قابلیت جدید به دلیل نیاز به بررسی مجدد اطلاعات جمع­آوری شده برای افزایش دقت آن‌ها، بسیار بالا اعلام شد. مانند قبل کارهای فنی لازم مشخص شدند، کار جدید به علاوۀ چند اشکالی که در سیستم مطرح شده بودند در برنامۀ اجرا قرار گرفتند. کارها مانند هفته قبل پیش رفت، جلسه تحویل برگذار شد و نسخه­ای از سیستم در اختیار مشتری قرار گرفت که آن را جایگزین نسخه قبلی کرد و کار ثبت اطلاعات را این­بار با افزودن فرآیند تایید اطلاعات وارد شده، ادامه داد.
هفته سوم
در جلسه­ای که برای تعریف کارها و اهداف جدید برگزار شد، مشتری­ معتقد بود می­توان از ابزار در حال تولید برای هدفی جدید تحت عنوان «مدیریت پروژه و برنامه­ریزی» استفاده کرد. از این رو مفهومی با عنوان برنامه­ریزی و کنترل پروژه به اهداف سیستم افزوده شد و کارهای لازم برای انجام کنترل و برنامه­ریزی به ریز مشخص شدند. حجم کارها بسیار بالاتر از ظرفیت تیم بود. از این رو مشتری مجبور به انتخاب کارهای با اولویت­تر بود، کارها انتخاب و فرآیند تبدیل آن‌ها به وظیفه انجام شد.
در میان هفته، مشتری درخواست جلسه­ای فوری داشت، طبق شرایطی که در محل استقرار پیش آمده بود نمی­شد در ادامه کار از معماری همیشه برخطی که بنا بر شرایط اولیه کارفرما برای سیستم در نظر گرفته شده بود استفاده کرد و عملاً سیستم با شکست مواجه شده بود و غیر قابل استفاده بود. اولویت‌ها تغییر کرد، سیستم باید به وضعیتی در می­آمد که از کار کردن برون‌خط نیز پشتیبانی می­کرد و قابلیت همگامی با بانک اطلاعاتی اصلی در زمانی که برخط می­شد را پیدا می­کرد. با توجه به زمان باقی مانده از هفته­ای که در آن بودیم. کارهای در دست انجام متوقف و میزان کاری را که می­شد در چند روز باقی مانده از هفته انجام داد، به انتخاب مشتری و جبر شرایط انتخاب کردیم. در انتهای هفته بخشی از کار پشتیبانی برون‌خط انجام شده بود. در این هفته نسخه قابل استفاده­ای وجود نداشت چرا که نتوانسته بودیم مجموعه ویژگی­هایی را که برای عملیاتی شدن لازم بود کامل کنیم.
در این هفته بنا بر شرایط کسب­و­کار، یکی از تجربه­های اسکرام مبنی بر عدم پذیرش کار جدید در میانه اسپرینت و عدم شکستن دوره زمان ثابت اسپرینت را کنار گذاشتیم چرا که تمام پروژه در خطر شکست بود. دو راه حل داشتیم، یکی این‌که کل اسپرینت را تعطیل می­کردیم و از همان روز اسپرینت جدیدی را با طول یک هفته­، مشابه با سایر اسپرینت‌ها برنامه­ریزی کنیم یا تنها زمان باقی مانده چند روزه از اسپرینت را برنامه­ریزی می­کردیم. برای حفظ آهنگ کار در تیم، راه­حل دوم را انتخاب کردیم.
هفته چهارم
اولویت با اتمام کارهای مربوط به پشتیبانی از قابلیت کار کردن برون‌خط سیستم بود تا بتوانیم هرچه سریعتر نسخه قابل استفاده­ای را به کاربران ارائه کنیم. این هفته تمام کارهای مربوط به آن برداشته شد پس از پایان هفته، نسخه آماده شد. در پایان هفته نسخه­ای که قابلیت پشتیبانی از رفتار برون‌خط را نیز داشته باشد تحویل دادیم. برنامه به مسیر قبلی برگشت و کار بر روی انجام بخش­های برنامه­ریزی و کنترل متمرکز شد. کارهایی که از زمان رها کردن این بخش باقی مانده بود را با برداشتن کارهای جدید به نحوی که زمان تیم را پر کند برداشتیم.
 اتفاق جدید بیماری یکی از اعضای تیم و عدم حضور 4 روزۀ او بود.
تعطیلاتی در پیش بود که طبق برنامه ریزی سایر اعضای تیم می­توانستند با گذاشتن وقت بیشتر نبود یک نیرو را برای چند روز جبران کنند. باید در این مدت با استفاده از اینترنت به کارساز مشتری که برنامۀ مبدأ کنترل بر روی آن نصب بود متصل می­شدیم و کار را پیش می‌بردیم. روز دوم از تعطیلات 4 روزه که تیم حساب بزرگی روی آن باز کرده بود اتفاق بدی افتاد. زیرساخت و کارسازهای مشتری دچار مشکل شد و دسترسی به کارساز برنامۀ مبدأ کنترل قطع شد و کار تا پایان تعطیلات به اجبار متوقف شد.
هفته پنجم
تیم نسخه‌ای برای ارائه نداشت، کارفرما به این نتیجه رسیده بود که باید برای تسریع در انجام کارهایی که سیستم برای آن ساخته می­شد برخی از امکانات را که در سیستم اصلی وجود داشت به نرم افزار برنامه­ریزی و جمع­آوری اطلاعات منتقل کند. با جلسات و مذاکراتی که انجام شد راه‌حلی غیر از توسعۀ این بخش­ها در سیستم برای برآورده کردن نیاز انتخاب شد. تیم از یک تغییر سهمگین دیگر نجات پیدا کرده بود.
مدت زمانی که تیم در این هفته برای پروژه گذاشت بیش از مدت زمان توافق شده برای هر هفته بود. با اضافه کاری چیزی نزدیک به یک و نیم برابر ظرفیت تیم، کار انجام شد. کارهای عقب افتاده علاوه بر کارهای اصلی سیستم طی این هفته انجام شدند.
هفته ششم
به دلیل پیچیدگی، بخشی از کارها از هفته پیش باقی مانده بود، کاربران چند اشکال جدید مطرح کرده بودند و قابلیتی جدید به سیستم اصلی افزوده شده بود که ما نیز باید به خاطر آن تغییراتی در سیستم­مان اعمال می­کردیم. تیم هم پیشنهادی برای مفیدتر شدن برنامه­ دردست تولید داشت. انجام ویژگی پیشنهادی، تکمیل کارها و تغییر به دلیل قابلیت جدید سیستم مادر در دستور کار این هفته قرار گرفت. در پایان هفته سیستم با قابلیت‌های توافق شده به تیم بهره‌بردار تحویل شد.
 مالک محصول با بررسی امکانات محصول تا این جای کار به این نتیجه رسید که محصول به اندازه کافی جوابگوی نیازهای کسب­وکار است و ادامه پروژه بیش از این ارزش افزوده­ای برای کسب­و­کار نخواهد داشت. پروژه خاتمه یافته اعلام شد.
پروژه توانسته بود که نیازهای مشتری و کاربران را به اندازه­ای کافی و بدون تولید ویژگی‌های کم یا زیاد جواب دهد. تیم توسعه و مشتری هر دو راضی بودند. کارفرما در زمان تسویه حساب مالی، مبلغی بیش از توافقات انجام شده را به عنوان پاداش به تیم پرداخت کرد تا از همراهی و خلاقیت تیم و پایبندی­ به تعهدهایش قدردانی کرده باشد.

مروری بر دلایل موفقیت پروژه و اتخاذ رویکردهای منجر به تصمیم­گیری­های خاص
در ابتدای این نوشتار به پیش‌نیازهای اجرای موفق فرآیند اشاره شد. در ادامه به تشریح این موارد پردخته خواهد شد:
شکل حقوقی همکاری و قرارداد
مهم­ترین پیش‌نیاز لازم که بستر اجرای موفق فرآیند و موفقیت پروژه را فراهم کرد، زمینه حقوقی و شکل قرارداد بین تیم پیمانکار و کارفرما بود. محور این قرارداد انجام پروژه با دامنه­ی مشخص نبود بلکه مبنای قرارداد خرید خدمت تیم پیمانکار - فارغ از دامنه مسئله­ای که باید حل می­شد - بود. چنین شکل قراردادی نیز خود نیازمند سرمایه­ای بزرگتر بود که بدون آن عقد چنین قراردادی عملاً ناممکن بود. «اعتماد کارفرما به پیمانکار» این اعتماد به واسطه رابطه­های کاری پیشین و اثبات صداقت پیمانکار شکل گرفته بود. این شکل باعث شده بود پیمانکار و کارفرما از نقش سنتی خود خارج شوند و هردو بر انجام بهترین کاری که به اندازه کافی خوب باشد تمرکز کنند. بر اساس تجربه همه ما در قراردادهای مرسوم مسئله‌ای با دامنه مشخص تعریف می­گردد و طی آن پیمانکار سعی بر آن دارد تا با کمترین کار تعهد خود را انجام دهد و نسبت به هر تغییری مقاومت می­کند. در نقطه مقابل نیز کارفرما سعی دارد بیشترین کار ممکن را در چارچوب قرارداد از پیمانکار تحویل بگیرد.
تغییر شکل قرارداد باعث شده بود کارفرما و پیمانکار در کنار یکدیگر قرار گیرند نه در مقابل هم. نمونه­ای از این همسویی پیشنهاد ایجاد ویژگی­ای بود که حاصل خلاقیت تیم توسعه برای کارآمدتر کردن سیستم در حال تهیه بود، ایده­ای که حجم کار توسعه را بیشتر می­کرد اما منجر به افزایش خوش­کاری سیستم و ایجاد ارزش افزوده برای کاربران می­شد.
این شکل از تعامل و قرارداد مشخصاً در هیچ جای چارچوب اسکرام (همان فرآیندی که برای اجرای پروژه انتخاب شده بود) نیامده است اما بدون وجود چنین فضایی اجرای پروژه و انعطاف در مقاطع سخت آن ناممکن بود.

درک شرایط کسب و کار توسط تیم و تصمیم گیری برای موفقیت
تجربه زمان ثابت بودن اسپرینت در فرآیند مرجع مورد استفاده در مقطعی که کل کسب­وکار به علت تغییر شرایط محیط اجرا دیگر قابل استفاده نبود، حتی پایبندی به آن و عدم انعطاف تیم توسعه به بهانه پایبندی به فرآیند و تجربه­های آن ممکن بود به شکست کل پروژه بینجامد یا در بهترین حالت موفقیت را به تاخیر بیندازد. تصمیم به توقف یک اسپرینت و تغییر مسیر توسعه و در عین حال شکل انجام آن برای حفط قابلیت اندازه­گیری سرعت تیم، تصمیمی همسو با کسب­وکار با کمترین تاثیر منفی بر جریان خلق ارزش برای مشتری بود، تصمیمی که تیم آن را با شجاعت گرفت.

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

تسلط اعضای تیم به مبانی نظری و فناوری
اعضای تیم پیمانکار مجموعه­ای از افراد مجرب بودند که بر فناوری مورد استفاده و مبانی نظری به خوبی تسلط داشتند. همین امر باعث شده بود تا تیم بتواند ساده­ترین و درعین حال کارآمدترین تصمیمات را در حوزه تحلیل و طراحی بگیرد. و راه حل درستی را برای مسایل پیدا کند. بدون تسلط اعضای تیم توسعه به فناوری، انعطاف تیم نسبت به تغییراتی که ریشه در دامنه کسب­وکار داشت می­توانست به ریزش بهمن‌گونه پروژه بینجامد.

استفاده از تجربه‌هایی از سایر فرایندها
همانطور که می‌دانید چارچوب اسکرام به تجربه­های فنی نمی­پردازد، لذا برای تضمین کیفیت کارهای انجام شده و باقی ماندن کیفیت بخش‌های پیشین در زمان اعمال تغییرات، تیم توسعه به تجربه­های فنی که در فرانید XP وجود داشت روی آورده بود. استفاده از تجربه­هایی مانند آزمون و توسعه مبتنی بر آن و تکیه بر تجربه طراحی ساده و تجربه­ یکپارچه‌سازی مستمر منجر به آن شده بود که تیم توسعه با خیالی آسوده نسبت به اعمال تغییرات اقدام کند، زیرا همیشه ناظری ماشینی برای کنترل تغییرات وجود داشت و از سویی سادگی طراحی و اعمال پیچیدگی متناسب با شرایط باعث شده بود تغییرات به ساده­ترین و کم حاشیه ترین شکل ممکن اعمال می­شد.

جمع بندی

این تجربه و تجربه‌های بعد از آن نشان داد که پایبندی محض به فرایند برای موفقیت پروژه کافی نیست. در فرایندهای چابک باید به ارزش‌ها و اصول چابک پایبند بود و اگر در مقطعی نیاز بود تجربه­های فرآیند را نیز باید کنار گذاشت. پیش از اجرای فرایند، فراهم کردن زمینه­هایی که باید در بستر آن فرایند را اجرا کرد، بسیار مهم است. دست یافتن به شکلی منعطف از قراداد، وجود تیمی دیرپا و هماهنگ که به فناوری­ها و مبانی نظری مسلط هستند از پیش‌نیازهای اصلی اجرای موفق فرایند هستند. کمک گرفتن از تجربه­های سایر فرایندها برای پوشش نقاط ریسک پروژه می‌تواند منجر به تسهیل اجرای فرایند ودسترسی به نتایح مطلوب شود. به بیانی ساده‌تر گاهی نیاز است چابک‌تر از آنچه باشید که فرایند مورد استفاده‌تان ممکن می­سازد.