باورهای نادرست در مورد اجایل

اجایل یعنی سریع و ارزون !!!"ما باید اجایل باشیم چون با اجایل میتونیم یک کار معین رو خیلی سریعتر و ارزون تر انجام بدیم"همه بچه باحالها، این روزا اجایل کار می‌کنند.حالا که ما هم یک پروژه بزرگ داریم به جای روش آبشاری که طولانی و پرهزینه است چطوره اجایل کار کنیم سریع و ارزون! درسته؟ دیگه چی بهتر از این ?فکر میکردم بعد از گذشت این همه سال دیگه واقعا چنین جملاتی نشنوم.اول اینکه اجایل اصلا انجام پروژهای بزرگ و سنگین به این صورت رو قبول نداره. اجایل ما رو به حرکت از تفکر پروژه محور به تفکر محصول محور و از انجام کارهای حجیم و از قبل برنامه ریزی و زمان بندی شده به سمت انجام کارهای در اندازه هر چه کوچکتر تشویق میکنه. اصول توسعه اجایل بر توسعه افزایشی (incremental) و تکراری (iterative) بنا شده.اشتباه نشه، این به این معنی نیست که یک پروژه بزرگ با دامنه از پیش تعریف شده رو به تعداد زیادی مرحله بشکنیم که این مورد متاسفانه خیلی هم رایجه، بعضی وقتا حتی با دامنه نامشخص و ناواضحه!!! اگر اجایل رو اینجوری درک کنیم به خودمون و اجایل ظلم کردیم.اجایل میگه فقط با یک قدم کوچیک شروع کنیم بعد از اون یک قدم کوچیک دیگه رو تعریف و برنامه ریزی کنیم و تویه هر قدم یاد ‌بگیریم و دامنه رو متناسب یافته ها تغییر بدیم و به قدم بعد بریم و همینطور رو به جلو حرکت کنیم.اجایل در واقع درکوتاه مدت حتی میتونه کمی کندتر باشه و این اصلا اشکالی نداره. اولویت اصلی اجایل توسعه نرم افزار باکیفیت و با ساختار فنی درسته برای همین در اجایل کلی زمان صرف بازنگری کدها، ساختارها و نیازمندیهای کسب و کار میشه و این هزینه رو با کمال میل می‌پذیره و این در واقع به این معناست که اجایل در تحویل ویژگیهای مورد نیاز حتی تا حدودی کند عمل میکنه و این درست در مقابل جمله "سریع و ارزونه" چون نرم‌افزار سریع و ارزون معادل نرم‌افزرای کم کیفیت و پر از اشکال و خطاست.کیفیت ضعیف و خطاها و مشکلات نامشخص معمولا حاصل اجرای پروژه‌های با دامنه بزرگ و بعضا نامشخص در بهترین حالت با مدل آبشاریه (باور کنید بعضی وقتا مدل فواره‌ای هم هست ?) و جای تعجب نیست که این نوع پروژه ها تبدیل به یک معضل بزرگ برای سازمان و نفرات درگیر در اون پروژه بشن که از تحویلهای دیر و کم کیفیت با صرف هزینه های گزاف رنج میبرن و ما می مونیم با یک تیم خسته که دیگه انگیزه ای برای انجام کار خوب نداره.اگر چه اجایل حتی ممکنه برای ساخت هر ویژگی مجزا به نظر کند تر برسه ولی مزایای بسیار بیشتری در برابر مدل آبشاری ارائه میکنه که یکیشون ارائه زودهنگامه. شما ترجیح میدید یک پروژه شش ماه طول بکشه و هشت ویژگی رو در انتها ارائه کنه و یا هشت ماه طول بکشه و هر ماه یک ويژگی با کیفیت ارائه کنه تازه اولین محصول تنها یکماه بعد از شروع پروژه ارائه بشه؟ممکنه زمان اجرای کار طولانی تر بشه ولی با ارائه زود هنگام ارزشها، یادگیری زودتر، دریافت نیازمندیهای واقعی زودتر مشتری و در نهایت کاهش ریسک کل پروژه ارمغانیه که اجایل برای ما خواهد داشت.به اعتقاد بعضیا اجایل یک طرز تفکره (Mindset) که البته درست هم هست ولی این تازه اول ماجراست.اینکه ما طرز تفکر اجایل داشته باشیم پایه و بستری آماده میکنه برای درک عصاره اصلی اجایل یعنی حرکت.بله! اجایل یک حرکت و جریان رو به جلوست. Agile is a movementاجایل یک روش و دیدگاه جدیده که بتونیم با همدیگه کار کنیم، تبادل نظر کنیم، همدیگه رو تشویق و حمایت کنیم و در کنار هم این جریان رو به جلو حرکت بدیم.شاید یک جمله بهتر در مورد اجایل به جای "سریع و ارزون" جمله "کوچک و زود" باشه من فکر میکنم این جمله بهتر فلسفه وجودی اجایل و مزایای اجایل رو نشون میده. تمرکز اجایل بر مشتریانه نه ذینفعانشاید این ایده اشتباه که اجایل سریعتر و ارزون تر از روشهای دیگه است از این طرز تفکر سنتی مدیریت پروژه که "هر چه که ذینفعان پروژه می‌خواهند باید انجام دهیم" نشات میگیره که البته در نگاه اول خیلی هم منطقی به نظر میرسه و متاسفانه هنوز هم اساس قضاوت نحوه‌ی کار مدیر پروژه ها در بسیاری از سازمانها و موسساته.مبانی تفکر اجایل البته سعی میکنه که از زوایه دید مشتریان واقعی به قضیه نگاه کنه و سوالهای از این قبیل رو مطرح میکنه:نرم‌افزارواقعا"چه کاری برای مشتری باید انجام بده؟ و چه ارزش افزوده ای میتونه برای مشتریان فراهم کنه؟چطوری میتونیم بعضی قابلیتها (و نه همه‌ی قابلیتهای ممکن) رو سریع به مشتریان تحویل بدیم؟چطوری میتونیم به سرعت از ویژگیها و قابلیتهای که تاکنون ارائه کردیم برای اصلاح و یا ادامه کار یاد بگیریم.و چطوری میتونیم قابلیتهای خودمون رو برای ارائه ارزشهای بیشتر به مشتری توسعه بدیم.البته اینجا تمرکز اجایل بر سرعته! اما توجه کردید؟ زبان و نوع بیان اجایل متفاوته.اصول بیانیه اجایل از واژه سریع استفاده نمی‌کنه بجاش واژه های زودهنگام و پرتکرار بکار میبره.Our highest priority is to satisfy the customer through early andcontinuous delivery of valuable softwareDeliver working software frequently, from a couple of weeks to a couple of months,with a preference to the shorter timescaleبنابراین اجایل بجای ارائه یک پروژه بزرگ در یک زمان کم به معنای سریع و تعجیل برعکس از ارائه زودهنگام و مکرر وِیژگیها و تغییرات خیلی کوچک در بازه های زمانی کوتاه حمایت میکنه.اجایل از مثلث آهنی متفاوتی استفاده میکنهمثلث آهنی ستنی مدیریت پروژه همانطوری که همه میدونیم از محدوده Scope ، زمان Time و هزینه Cost تشکیل شده به این صورت که هزینه معمولا تابعی از زمانه ( معمولا به افراد بر اساس زمانی که صرف می‌کنند پرداختی داریم) و زمان هم تابعی از محدوده‌ست.بنابراین در یک روش مدیریت پروژه ضعیف کلی زمان صرف کنترل محدوده پروژه میشه و همیشه دنبال روشهای هستند که زمان و هزینه پروژه رو کاهش بدن!!!ولی کنترل این مثلث آهنی برای هر مدیر پروژه‌ای میتونه یک کابوس واقعی رقم بزنه، چرا که واقعا در مورد نرم‌افزار از ابتدا نمی‌توان تخمین زد که نیازهای واقعی مشتریان چیه، چرا که در خیلی موارد خود مشتریان هم از قبل نمی‌‌دونن واقعا چی میخوان و هر چه محدوده‌ی پروژه‌ بزرگتر باشه این مشکل هم حادتره. هر چه که ما در پروژه‌‌های نرم‌افزاری جلوتر می‌ریم از نکات و تغییرات و نیازهای جدیدی که توسط مشتریان مطرح میشن متعجب میشیم. بنابراین فرض بر ثابت نگه داشتن محدوده یک روش بسیار غلط در کنترل مثلث آهنیه و البته وجود این مثلث و کنترلش در تولید نرم‌افزار کلا از پایه اشتباه.اجایل از یک مثلث دیگه برای کنترل تولید محصول استفاده میکنه. مثلث اجایل از سه راس ارزش Value، کیفیت Quality و محدودیتهاConstrains تشکیل شده (توصیه میکنم اگه تونستید یک نگاهی به کتاب Agile Project Management جیم های‌اسمیت بندازین) و محدودیتها به مثلث اول یعنی مثلث آهنی STC اشاره میکنه. پس محدودیتهای کل پروژه تنها یکی از فاکتورهایه که باید بهش توجه کنیم و البته در اجایل محدودیتها اغلب به اندازه دو راس دیگه یعنی ارزش و کیفیت اهمیت ندارن.اگه به نظرتون این مسئله خیلی ملموس نیست فرض کنید در حین پروژه مشتری درخواستی رو مطرح میکنه که قبلا نبوده ولی الان ارزش زیادی براش داره و حتی حاضره پول زیادی بابتش بده ولی پیاده سازی این مورد باعث میشه از محدوده و زمان از قبل تعیین شده خارج بشیم. بنظرتون نباید این مورد انجام بشه؟!!! پس خلق ارزش بر محدودیتها اولویت داره و یا فرض کنید در حین پیاده سازی پروژه به باگ و مشکلاتی بخوریم که از قبل پیش بینی نشده و اصلاح اونها باعث بشه از سقف محدودیتها خارج بشیم. آیا نباید مشکلات نرم‌افزار برطرف بشه؟ بالاخره در این حالت یا باید با تاخیر پروژه انجام بشه و از محدوده‌ی زمان خارج بشیم و یا تعدادی ویژگی رو که باید پیاده می‌شدند رو حذف کنیم (کم کردن محدوده) ولی بدیهیه که روی کیفیت نمی‌تونیم معامله کنیم.بنابراین تمرکز اجایل بر خلق ارزش و کیفیته و این دو، از اولویت بسیار بیشتری از محدودیتها برخوردارن درصورتیکه در روشهای سنتی با کنترل هزینه و زمان سعی در راضی کردن ذینفعان پروژه دارن نه مشتریان واقعی و نرم‌افزای که مشتری واقعی ازش راضی نباشه محکوم به شکسته.