از اول تا آخر Agile

در این گیرودار که ما در مورد مباحث تخصصی Agile می نویسیم و کنفرانس بین المللی معرفی می کنیم و ده ها کار دیگر در این مابین (یهو) دوستی پیدا می شود و می پرسد (ببخشید : Agile چیه؟ یا من یه برنامه نویس تنهام چطور از Agile استفاده کنم و … ) و خلاصه کاسه و کوزه ما رو بهم میرزه.

اینگونه دوستان کم صبرو تحمل که بیشتر به طور اتفاقی با Agile در جایی برخورد کرده اند و یا اسمش را از یک جایی شنیده اند با هیجانی که ناشی از آشنایی با مقوله جدید هست می خواهند زود آن را از تئوری به عمل برسانند و به قولی از افردا در شرکت یا خانه Agile کار کنند. از اینرو و با توجه به صد ها سوالی که از بنده در این مورد پرسیده می شود تصمیم به ایجاد پست راهنمایی کردم تا در صورت مشاهده چنین دوستانی آنها را دعوت به مطالعه این پست بنمایانیم تا آنها مسیر خود را پیدا نمایند.

# Agile چیست ؟

• توسعه نرم افزار چابک
• فرق Agile با RUP یا دیگر روش های موجود در چیست؟

# Agile و مدیریت

• مدیریت در Agile
• Agile بهترین روش مدیریت منابع انسانی

# اسکرام چیست ؟

• اسکرام چیست؟
• بازنگری در اسکرام
• اسکرام ساده شده

# اسکرام و Agile

• ربط اسکرام با Agile

حرکت به سوی Agile

• کتاب اسکرام و اکس پی ساده شده
• چابک سازی سازمان و چراها
• Agile دارویی برای تمام امراض
• ابزارهای Agile
• مستند سازی در Agile
• Shu-Ha-Ri روشی برای Agile شدن
• تست محصول در Agile

اگر دوست گرامی که بعد از مطالعه این مطالب قید شده نتوانست به سوال خود پاسخ دهد بنده با کمال میل حاضر به پاسخ گویی به این دوست گرامی هستم در ضمن انجمن چابک ایران نیز پذیرای این دوستان چابک می باشد.

یاشیاسیز

توسعه نرم افزار Agile

Agile Software Development یا توسعه نرم افزار چابک چیست؟

Agile مجموعه ای از ارزش ها و اصول جهت توسعه نرم افزار های کارا توسط تیم های خود سازمانده می باشد. ارزش ها و اصول Agile در سال 2001 توسط 17 نفر از اساتید معتبر جهانی صنعت توسعه نرم افزار طی یک بیانیه با عنوان بیانیه توسعه چابک تنظیم و ارائه گردید. اساس و هدف این اصول و ارزش ها ارائه نرم افزار کارا و یا محصول کارآ به مشتری می باشد.

اما چه نیازی به روش Agile بود؟! به عبارتی چه شد که این 17 نفر (بعلاوه چند ده نفر دیگر که به صورت غیر مستقیم در این بیانیه تاثیر داشتند) در سال 2001 اقدام به انتشار چنین روشی کردند!؟

جواب کاملا واضح است: ضعف های موجود در روش های سنتی باعث شد که این دوستان روش Agile را معرفی نمایند.

روش های سنتی و یا موجود چه مشکلاتی داشتند؟

روش های موجود آن زمان (و فعلی این زمان ایران) که بیشتر به صورتی فاز به فاز عملیات اجرا می شد و نتیجه کار از قبل به صورت یک طراحی اولیه دقیق (Up-front Design) پیش بینی می شد یک سری ایراد اساسی و کلی داشت :

• صرف زمان زیاد و در واقع اتلاف زمان برای طراحی Up-front در فاز اولیه پروژه
• مشخص نبودن و واضح نبودن نیازمندی ها بدلیل ارتباطات کاغذی به جای ارتباطات چهره به چهره و کج روی های متعاقب
• بالا بودن هزینه تغییرات
• به طول انجامیدن پروژه و گذر از زمان تعیین شده در حد بسیار زیاد در بسیاری از پروژه ها
• عدم وجود زمان برای آزمایش محصول و متعاقبا محصولات پر از باگ و بدون کیفیت
• عدم شفافیت در پروسه توسعه و تولید : هیچ کس حتی مدیر پروژه نمی دانست که چقدر از محصول مورد نظر تکمیل شده است؟ چه اهدافی باقی مانده است؟ و … .

بزرگترین مشکل این پروسه ها ناکارآ بودن محصولات اشان بود.  اما چرا محصولات این پروسه ها ناکارآ تشریف داشتند؟

به این دلیل که عملکرد این پروسه ها بر اصل Anticipation یا پیش بینی استوار بود. در Anticipation یک سری موارد بر روی کاغذ و به عنوان قرار داد بسته جهت پیاده سازی تحویل تیم توسعه داده می شد و تیم توسعه موظف می شد در یک زمان مقرر و با یک منابع مشخص و ثابت این وظایف را پیاده سازی نماید. این اصل  همراه خود در بردارنده طراحی دقیق اولیه یا Big Design Up-Front بود (همان صحبت معروفی که شاید شنیده باشید :»ما اگر 1 سال وقت داشته باشیم 10 ماه آن را برای تحلیل و طراحی و  2 ماه آن را برای پیاده سازی صرف می کنیم).

Big Design Up-Front خوب است ولی در جایی که همه چیز ثابت باشد و نیازی به تغییر نداشته باشیم ولی آیا به راستی در جهان واقع و در اکثر پروژه هامان نیاز به تغییر نداریم؟!

زمانیکه در پروژه ای Up-Front Design می شود مسلما فاز تست آخرین فازی خواهد شد که بر روی محصول انجام می شود. ولی آیا این فاز تاثیر گذار می تواند باشد؟ محصولی که کامل ساخته شده است تزریق کیفیت به آن ساده نیست و در بعضی از موارد غیر ممکن خواهد بود. بهتر است به جای این , محصول با کیفیت ساخته شود و نه کیفیت به آن در آخر پروژه تزریق شود.

درکل اصل Anticipation که متد های آن زمان , بر آن استوار بودند رابطه ی خوبی با تغییر نداشتند زیرا آن ها عادت داشتند همه چیز را از قبل پیش بینی کنند و تغییر برای آنها بسیار هزینه بر بود. اما چرا تغییر برای آن پر هزینه بود؟ زیرا آنها تغییرات و کج روی های خود را خیلی دیر متوجه می شدند (اکثرا در آخر پروژه) و در محور زمان هر چقدر تغییر و یا مشکل دیر کشف شود رفع و یا ایجاد آن مشکل تر – پیچیده تر و پرهزینه تر خواهد بود. به همین دلیل آنها تغییر را رد می کردند.

رد کردن تغییر به منزله ناکارآمد کردن محصول و خروجی پروژه می باشد. هر تغییر و یا اصلاحی که در محصول نیاز می شود برای تکمیل و کارآمدتر کردن آن می باشد : به این دلیل که مشتری نیازمند تغییر است (زیرا تجارت او در حال تغییر است و یا اصلا او در شناخت نیازها اشتباه کرده است و یا هر چیز دیگری)  و اگر تغییر انجام نشود محصول به درد تجارت و کسب وکار مشتری نخواهد خورد و اگر تغییر نیز انجام شود هزینه آن بالا خواهد بود , که در این صورت هم پروژه به صرف نخواهد بود.

یکی دیگر از معایب اصلی Anticipation جلوگیری از به وجود آمدن  نوع آوری در محصول می باشد. یعنی عملا نوع آوری وجود نخواهد داشت.

مشکلات موجود در پروسه های موجود و خروجی های بی کیفیت و محصولات ناکارآ در آن زمان و بخصوص اتلاف و نارضایتی نیروی انسانی پروژه ها و ضررهای مالی کلان در حوزه IT این دوستان را بر آن داشت که روش جدیدی برای اصلاح پروسه توسعه نرم افزار معرفی نمایند که همه ما آن را با نام Agile یا چابک می شناسیم.

نقطه عکس حالت Anticipation حالت Adaptation می باشد که Agile بر آن استوار می باشد.

در Adaptation به جای یک طراحی دقیق و برای سازگاری بیشتر محصول با نیاز های واقعی مشتری از Real-Time Planning و Emergent Design استفاده می شود. یعنی به حد کافی در زمان های مناسب نیازمندی هایی از طریق ارتباط چهره به چهره دائم و فیدبک مشتری دریافت می شود که فقط آنها بر اساس عکس بزرگ محصول برنامه ریزی و طراحی می شوند و نه بیشتر.

Iterative و Incremental بودن روش Agile فرصت مغتنمی برای ایجاد یک بستر Adaptation به وجود آورده است. بدین صورت که محصول به صورت Incremental ساخته می شود و در Iterative های معلوم و کوتاه در اختیار مشتری قرار داده می شود  در هر تکرار و یا چرخش فیدبک های مشتری به عنوان نیازمندی های جدید وارد پروسه توسعه می شوند که بدلیل فیدبک های دائم و زود هزینه تغییرات بسیار پایین خواهد آمد.

علاوه بر این در Agile بدلیل Incremental بودن , پروسه آزمایش  و یا Test به صورت یکپارچه با توسعه بخش ها انجام می شود که این نوید دهنده یک محصول با کیفیت در هر Release خواهد بود. به عبارت ساده تر به جای تزریق کیفیت ,  بخش ها را با کیفیت می سازیم که این هم هزینه نگه داری هر بخش را کاهش می دهد و هم محصول نهایی با کیفیت می شود و هم تغییرات قابل اجرا خواهند بود. در حالی که در روش Anticipation پروسه Test در فاز آخر انجام می شد.

به طور کلی برای ویژگی یک متد بر پایه Adaptation می توان موارد زیر را بر شمرد :

• Real-Time Planning
• Emergent Design
• Integrated Testing
• Collaborative Discussions
• Just-in-Time & Just-Enough Requirements

به طور خلاصه در Agile هدف این است که محصولی کارآمد تحویل مشتری داده شود و محصول کارآمد محصولی است که با نیاز های مشتری سازگار باشد.  برای همین اصول و ارزشهایی برای دست یابی به این مهم در بیانیه توسعه چابک آمده است.

ارزش های توسعه نرم افزار چابک

افراد و تعاملات بالاتر از فرآیندها و ابزارها
نرم افزار کارا بالاتر از مستند سازی جامع
همکاری مشتری بالاتر از قرارداد کار
جوابگویی به تغییرات بالاتر از پیروی یک طرح

با وجود اینکه در موارد سمت چپ ارزش هایی وجود دارد ولی
موارد سمت راست ارزش بیشتری برای ما دارند

ارزش افراد و تعاملات به معنی ایجاد یک محیط فعالانه و همکارانه بین اعضای تیم می باشد. ارزش همکاری مشتری به معنی دست یابی به فیدبک های مشتری و ایجاد نوع آوری می باشد. ارزش جوابگویی به تغییرات هم نیز در جهت دست یابی به ارزش والای نرم افزار کارآ می باشد.

به عبارت ساده تر ما تیمی داریم که تعاملات خوبی بین اعضای آن در جریان است و این تیم با گرفتن فیدبک های مشتری به صورت متوالی و سازگار کردن محصول با نیازهای مشتری در حال توسعه نرم افزار کارآ می باشد.

همه این مواردی که ذکر شد ارزش هایی می باشند که انتظار می رود یک سازمان چابک برای خود داشته باشد. ولی اینها وحی منزل نیستند و سازمان ها می توانند ارزش های خود را برای چابک سازی خود داشته باشند.

در کنار ارزش های سازمان چابک 12 اصل چابک نیز وجود دارد که سازمان های چابک برای دست یابی به ارزش های چابک می توانند پیرو آن اصول باشند:

اصول بیانیه چابک
ما از این اصول پیروی می کنیم :

بالاترین اولویت ما رضایت مشتری از طریق
تحویل به موقع و مداوم نرم افزار ارزشمند می باشد

پذیرائی از نیازهای در حال تغییر , حتی آن هایی
که در اواخر توسعه پدید آور می شوند. فرآیند های چابک
تغییرات را جهت رقابت بر سر مشتری مهار و کنترل می نمایند

تحویل نرم افزار کارکننده غالبا از چند هفته تا چند ماه
یک بار انجام می شود که زمانبندی کوتاه تر ترجیح داده می شود

ذینفعان تجاری و توسعه دهندگان باید هر روزه در
طول پروژه با هم کار کنند

پروژه ها را بر روی افراد با انگیزه بنا کنید. محیط لازم را
به آنها بدهید و از نیازهای آن ها پشتیبانی نمایید وبه
آنها اعتماد نمایید تا کارها را انجام بدهند

کارآمدترین و موثرترین روش برای انتقال و رساندن
اطلاعات به تیم توسعه , گفتگوی چهره به چهره و رودرو می باشد

نرم افزار کارکننده اصلی ترین معیار پیشرفت می باشد

فرآیند های چابک توسعه پایدار را ترویج می دهند.
حامیان مالی , توسعه دهندگان و کاربران باید قادر به
حفظ سرعت پیشرفت ثابتی براى يک مدت نامحدود باشند

توجه مداوم به برتری فنی و طراحی خوب باعث
افزایش چابکی می شود

اصل سادگی ضروری می باشد

بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های
خود سازمانده پدید آور می شود

در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید
و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نماید

جمع این ارزش ها و اصول در یک سازمان باعث چابک شدن آن سازمان می شود. البته به این نکته توجه نمایید که سازمان چابک کار نمی کند بلکه چابک می شود.

اما چگونه می توان چابک شد ؟

برای چابک شدن باید در پروسه توسعه و یا حتی سطوح کلان سازمان مانند مدیریت منابع انسانی پروژه و یا هر سطحی ارزش های و اصول چابک رعایت شوند و در نظر گرفته شوند. به عبارتی باید همه سازمان چابک شود و نه فقط بخش یا واحد توسعه نرم افزار. به همین دلیل حرکت سازمان به سمت Agile را تغییر یا Change گفته نمی شود و از اصطلاح Transformation یا تحول استفاده می شود. یعنی باید سازمان در راه چابک شدن متحول شود.

برای اینکه بتوان به سطحی از چابکی دست یافت می توان از Practice های Agile مانند Scrum , XP , Crystal و یا … بهره جست . در همین رابطه پیشنهاد می کنم این مطلب را مطالعه کنید: ربط اسکرام با Agile.

نتیجه گیری

Agile یک تفکر ناب در زمینه توسعه نرم افزار می باشد که خروجی و هدف آن ارائه نرم افزار کارآ می باشد. در Agile هزینه توسعه بدلیل Lean بودن و تحلیل و طراحی سازگار  پایین خواهد بود. در Agile بدلیل Iteration عمل کردن و ارتباط چهره به چهره دائم با مشتری و آزمایش یکپارچه شاهده محصول با کیفیت و کارآ خواهیم بود. در Agile به دلیل خود سازمانده بودن تیم ها شاهد نفرات و تیم های خوشحال و راضی خواهیم بود. و سازمان نیز بدلیل چابک بودن دارای سود بالایی خواهد بود.

یاشیاسیز

اسکرام فقط Scrum نیست

زمانیکه به اولین تجربه خودم در مورد اسکرام فکر می کنم ,  حسابی خنده ام می گیره . اسکرامی که من برای اولین بار یاد گرفتم و آن را درشرکت بر روی یک پروژه پیاده سازی کردم ,  اصلا اسکرام نبود . اسکرام ما کلا به یک Task Board من در آوردی ختم می شد . از جمله اشتباهاتی که در مورد اسکرام داشتم , می توانم به موراد زیر اشاره کنم :

• Top-Down Management :  همانطور که می دانید یکی از اصول اصلی در Agile و اسکرام Self-Organize بودن نیروی کار(برنامه نویس) می باشد که ما به هیچ وجه چنین اجازه ای به نیروی کار نمی دادیم و شیوه Command-And-Control را با بدترین حالت ممکن به کار می بستیم .
• طرح ریزی تیمی : به دلیل وجود مدیریت بالابه پایین ,  این مورد هم که امکان نداشت انجام شود . یعنی بنده همه چیز رو طرح ریزی می کردم و به تیم تزریق می کردم که در محیط های چابک بدینگونه عمل نمی شود .
• تکرارهای کوتاه مدت : در اسکرام که حداکثر طول اسپرینت 4 هفته هست , ما اسپرینت 3 ماهه داشتیم .
• بازبینی عملکرد : بازبینی عملکرد تیم پس از هر اسپرینت طی جلسه retrospective تقریبا امری است ضروری که ما ,  سال به سال چنین کاری رو انجام نمی دادیم .
• همکاری با مشتری : همکاری ما خوب بود ولی مشکل ما  این بود : ما باید یک نفر را به عنوان Product Owner داشتیم در حالی که ما 400 نفر Product Owner داشتیم . خاله مدیر شرکت هم نظر می داد .
• ارائه نرم افزار کارا : یکی از ارزش های اصلی Agile ارائه نرم افزار ارزشمند برای مشتری است به صورتی که نیازهای کسب و کار مشتری را برآورده کند ولی ما فقط در فکر سود و منفعت بیشتر برای شرکت بودیم و کاری نداشتیم که مشتری استفاده می کند یا نه .
• با انگیزگی تیم : برای توسعه نرم افزار خوب در محیط Agile حتما نیاز به نیروی کار با انگیزه بود ولی در محیط ما چیزی که وجود نداشت انگیزه بود . اعتصاب های گوناگون ,  تاخیر در پرداخت حقوق , تورم ,  سهمیه شده بنزین و … از عوامل کاهنده انگیزه نیروی کار بود .
• تست نرم افزار : یکی از کارهایی که هیچ وقت انجام نشد ,  نوشتن تست برای بخش های مختلف برنامه بود .
• تولید کدهای خوب : بدلیل عدم وجود Automate Tests و تغییرات زیاد در طول پروسه توسعه نرم افزار ,  ما در نهایت دارای یک سری کد کثیف بودیم .
• جوابگویی به تغییرات : یکی از مشکلات اساسی ما همین مورد بود . یا ما جواب نمی دادیم و اگر هم جواب می دادیم در دام Scope Creep می افتادیم . کدهای کثیف تولید می شد , برنامه قابلیت پشتیبانی را از دست می داد .
• و …

اگر اهل فن باشید حتما خواهید دانست که مشکل ما در دو سطح متفاوت قابل بحث می باشد . اول سطح اسکرام دوم سطح Agile . اولا مشکل ما این بود که اسکرام را کاملا بلد نبودیم ( در آن زمان منابع زیادی برای یادگیری وجود نداشت (چه انگلیسی و چه فارسی ) ) . ثانیا ربط اسکرام با Agile را درک نکرده بودیم . بی تعارف عرض کنم که ما اسکرام را یاد گرفته بودیم بدون اینکه بدانیم Agile چیست و  از آن استفاده می کردیم؟؟!

برای همین است که یکی از دغدغه های من در این وبلاگ و یا آموزش این است که Scrum فقط Scrum نیست . اگر Scrum در خدمت Agile نباشد معنی نخواهد داشت و پیشنهاد من این است که برگردیم به متد قبلی که قبلا کار میکردیم . پس در آموزش خود  سعی کنید که از Agile به سمت اسکرام حرکت کنید .

البته یادگیری اسکرام چیزی نیست ,  شاید در عرض 2 ساعت بتوانید کل اسکرام را یاد بگیرید . ولی درک و یادگیری Agile  ومهمتر از همه ,  پیاده سازی تفکر Agile کاری است بس مشکل که با خواندن 1 عدد کتاب یا چند مقاله  امکان پذیر نخواهد بود. پس اسکرام فقط اسکرام نیست و برای استفاده از آن باید Agile را هم درک کرده باشید .

یاشیاسیز