حسین اصلانیسلام امیدوارم خوب و سرحال باشید؛ در مقاله اول اجایل دوای درد تیم ها برای شما از نیاز هایی که باعث شد اجایل متولد بشه گفتم، این که چه اتفاقی افتاد که آن 17 نفر (بعلاوه چند ده نفر دیگر که به صورت غیر مستقیم در این بیانیه تاثیر داشتند) در سال 2001 اقدام به انتشار چنین روشی کردند! در ایم مقاله سعی می کنم به شما را با توسعه نرم افزار به روش اجایل به زبان بازاری آشنا کنم! پس با من همراه باشید!
مشکل بزرگی که در صنعت نرم افزار وجود دارد این است که خروجی پروژه ها مثلا بعد از دو سال هزینه بدرد نخور می شود، یعنی تیم دو سال بر روی پروژه کار میکرد و نهایتا مشتری میگفت این آنچیزی نیست که من می خواستم و … . اما بعد از ظهور اجایل ما مجبوریم مشتری را در طی روند تولید محصول دخیل نماییم به طور مداوم بازخوردهای او را بگیریم ، خلاقیت ایجاد نماییم و به طور کلی محصول را خوشمزه کنیم و نهایتا شاهد بیگ بنگ نباشیم.
روش های موجود آن زمان (و فعلی این زمان ایران) که بیشتر به صورتی فاز به فاز عملیات اجرا می شد و نتیجه کار از قبل به صورت یک طراحی اولیه دقیق (Up-front Design) پیش بینی می شد یک سری ایراد اساسی و کلی داشت که همه مدیران پروژه به خوبی با آن آشنا هستند :
- صرف زمان زیاد و در واقع اتلاف زمان برای طراحی Up-front در فاز اولیه پروژه
- مشخص نبودن و واضح نبودن نیازمندی ها بدلیل ارتباطات کاغذی به جای ارتباطات چهره به چهره و اشتباهات بعدش ...
- بالا بودن هزینه تغییرات
- به طول انجامیدن پروژه و گذر از زمان تعیین شده در حد بسیار زیاد در بسیاری از پروژه ها
- عدم وجود زمان برای آزمایش محصول و متعاقبا محصولات پر از باگ و با کیفیت خیلی پایین
- عدم شفافیت در پروسه توسعه و تولید : هیچ کس حتی مدیر پروژه نمی دانست
که چقدر از محصول مورد نظر تکمیل شده است؟ چه اهدافی باقی مانده است؟کجاییم؟ و چه شده ؟ چه می شود و … . ( البته مدیران پروژه خوب می توانند این مسئله را توجیح کنند اللخصوص در جلسه با مافوق خودشان)
بزرگترین مشکل این پروسه ها ناکارآ بودن محصولات اشان بود. اما چرا محصولات این پروسه ها ناکارآ تشریف داشتند؟
برای این که عملکرد این پروسه ها بر اصل پیش بینی یا Anticipation یااستوار بود. در پیش بینی یک سری موارد بر روی کاغذ و به عنوان قرار داد بسته جهت پیاده سازی تحویل تیم توسعه داده می شد و تیم توسعه موظف می شد در یک زمان مقرر و با یک منابع مشخص و ثابت این وظایف را پیاده سازی کند. این اصل همراه خود در بردارنده طراحی دقیق اولیه یا Big Design Up-Front بود (همان صحبت معروفی که شاید شنیده باشید :”ما اگر 1 سال وقت داشته باشیم 10 ماه آن را برای تحلیل و طراحی و 2 ماه آن را برای پیاده سازی صرف می کنیم).
Big Design Up-Front خوب است ولی در جایی که همه چیز ثابت باشد و نیازی به تغییر نداشته باشیم ولی آیا به راستی در جهان واقع و در اکثر پروژه هامان نیاز به تغییر نداریم؟!
کاملا معلومه که وقتی در پروژه ایی Up-Front Design می شود فاز تست آخرین فای است که بر روی محصول انجام می شود. ولی آیا این فاز تاثیر گذار می تواند باشد؟ محصولی که کامل ساخته شده است تزریق کیفیت به آن ساده نیست و در بعضی از موارد غیر ممکن است. بهتر است به جای این , محصول با کیفیت ساخته شود و نه کیفیت به آن در آخر پروژه تزریق شود.
درکل اصل پیش بینی که متد های آن زمان , بر آن استوار بودند رابطه ی خوبی با تغییر نداشتند و ندارند و نخواهند داشت، زیرا آن ها عادت داشتند همه چیز را از قبل پیش بینی کنند و تغییر برای آنها بسیار هزینه بر بود. اما چرا تغییر برای آن پر هزینه بود؟ زیرا آنها تغییرات و کج روی های خود را خیلی دیر متوجه می شدند (اکثرا در آخر پروژه) و در محور زمان هر چقدر تغییر و یا مشکل دیر کشف شود رفع و یا ایجاد آن مشکل تر – پیچیده تر و پرهزینه تر خواهد بود. به همین دلیل آنها تغییر را رد می کردند.
رد کردن تغییر به منزله ناکارآمد کردن محصول و خروجی پروژه می باشد. هر تغییر و یا اصلاحی که در محصول نیاز می شود برای تکمیل و کارآمدتر کردن آن می باشد : به این دلیل که مشتری نیازمند تغییر است (زیرا تجارت او در حال تغییر است و یا اصلا او در شناخت نیازها اشتباه کرده است و یا هر چیز دیگری) و اگر تغییر انجام نشود محصول به درد تجارت و کسب وکار مشتری نخواهد خورد و اگر تغییر نیز انجام شود هزینه آن بالا خواهد بود , که در این صورت هم پروژه به صرف نخواهد بود.
یکی دیگر از معایب اصلی پیش بینی جلوگیری از به وجود آمدن نوع آوری در محصول می باشد. یعنی عملا نوع آوری وجود نخواهد داشت.(و من به شدت با این مسئله مشکل دارم)
مشکلات موجود در پروسه های موجود و خروجی های بی کیفیت و محصولات ناکارآ در آن زمان و بخصوص اتلاف و نارضایتی نیروی انسانی پروژه ها و ضررهای مالی کلان در حوزه IT این دوستان را بر آن داشت که روش جدیدی برای اصلاح پروسه توسعه نرم افزار معرفی نمایند که همه ما آن را با نام Agile یا چابک می شناسیم.
نقطه عکس حالت Anticipation حالت Adaptation می باشد که Agile بر آن استوار می باشد.
در Adaptation به جای یک طراحی دقیق و برای سازگاری بیشتر محصول با نیاز های واقعی مشتری از Real-Time Planning و Emergent Design استفاده می شود. یعنی به حد کافی در زمان های مناسب نیازمندی هایی از طریق ارتباط چهره به چهره دائم و فیدبک مشتری دریافت می شود که فقط آنها بر اساس عکس بزرگ محصول برنامه ریزی و طراحی می شوند و نه بیشتر.
ایده آل و افزایشی بودن روش اجایل فرصت مغتنمی (غنیمت شمرده شده ایی) برای ایجاد یک بستر قابل توافق به وجود آورده است. بدین صورت
که محصول به صورت افزایش پله به پله یا افزایشی ساخته می شود و در ایده آل های معلوم و
کوتاه در اختیار مشتری قرار داده می شود در هر تکرار و یا چرخش فیدبک های
مشتری به عنوان نیازمندی های جدید وارد پروسه توسعه می شوند که بدلیل فیدبک
های دائم و زود هزینه تغییرات بسیار پایین خواهد آمد و کیفیت سر به فلک می کشد!
از این خوبی اجایل که بگذریم، به خاطر پله به پله بودم پروسه آزمایش و تست به صورت یک پارچه با توسعه بخش ها، این نوید داده می شود که در هر Release یک محصول با کیفیت وجود خواهد داشت.به عبارت ساده تر به جای تزریق کیفیت , بخش ها را با کیفیت می سازیم که این هم هزینه نگه داری هر بخش را کاهش می دهد و هم محصول نهایی با کیفیت می شود و هم تغییرات قابل اجرا خواهند بود. در حالی که در روش پیش بینی پروسه Test در فاز آخر انجام می شد.
به طور خلاصه در Agile هدف این است که محصولی کارآمد تحویل مشتری داده شود و محصول کارآمد محصولی است که با نیاز های مشتری سازگار باشد. برای همین اصول و ارزشهایی برای دست یابی به این مهم در بیانیه توسعه چابک آمده است.
مجید علوی
۱۰ مرداد ۹۶، ۱۱:۳۹درود فراوان یعنی دیگه زمانبندی را پیشبینی نکنیم؟خب چیکار کنیم پس؟
حسین اصلانی
۱۰ مرداد ۹۶، ۱۱:۴۵سلام لطفا با شکیبایی مطالب را دنبال کنید, به زودی اموزش بازی های زمانبندی پروژه را منتشر می کنیم