مدل آبشاری(waterfall) و چابک(agile) در توسعه نرم افزار

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

اصلا متدی که میگیم چی هست ؟

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

چند تا مدل توسعه وجود داره ؟

مدل و فرایند تا دلتون بخواد داریم ( اصلا کی به کیه خودمون هم میتونیم یه متد بصورت کاملا دیمی خلق کنیم و با همون پیش بریم :) ولی یه سری از این متد ها و فرایند ها هستن که خیلی معروف هستن و تیم های زیادی باهاشون کار میکنن. مثل scrum, kanban, agile, scrumban, lean, XP, waterfall, PMBOK و ... .
اگه بخوایم همه این متد های توسعه رو بچپونیم تو مقاله فکر نکنم کسی حوصله کنه و تا ته اسکرول کنه :)
از این گذشته تو کشور خودمون ایران هم همه این متد ها مرسوم نیستن و معروف ترین ها همین متد های مرتبط با اجایل و مدل آبشاری هستن که قراره این موارد رو بررسی کنیم در ادامه.

آبشاری (WaterFall)

مدل آبشاری که بهش linear-sequential هم گفته میشه، میشه گفت قدیمی ترین و اولین مدل فرایندی معرفی شده هست. تو این مدل توسعه، همه چیز بصورت یک جریان خطی رو به پایین وجود داره (مثل یه آبشار). یعنی چی ؟
این مدل شامل چند فاز توسعه مختلف هست که هر کدوم تو یه بخشی از این مسیر به اصطلاح آبشار قرار دارن و فرایند طوری هست که هر فاز باید تموم بشه تا به فاز بعدی برسیم. هیچ ارتباطی هم بین این فاز ها وجود نداره این وسط.
به عکس زیر توجه کنید :

همونطور که تو عکس هم میبینید، ما از فاز بررسی نیازمندی ها باید شروع کنیم و به ترتیب بیایم و برسیم به آخر خط تا بتونیم محصول خودمون رو ارائه بدیم. دقت کنید که این مراحل یکبار ۰ تا ۱۰۰ برنامه ریزی میشن و تا رسیدن به محصول نهایی قابل بازبینی نیستن.برای مثال اگر شما برنامه نویس سایت باشد، باید کل طرح ui سایت رو که از فاز طراحی به دستتون رسیده کدنویسی کنید و تحویل فاز بعدی بدید.
حالا با توجه به این تعریف بریم ببینیم این مدل چه مزایا و چه معایبی داره :

مزایای مدل آبشاری

• ساده و قابل فهم: این مدل بیشتر بخاطر سادگی و عدم پیچیدگی که داره انقدر محبوب شده و هنوزم که هنوزه خیلی جاها ازش استفاده میکنن. منظور از سادگی اینه که ما هیچ مفهوم و اصطلاح و نقش سازمانی پیچیده ای نداریم و همه چیز مشخص و قابل فهم هست.
• سرعت بالا در پروژه های کوچک: این مدل اصلا خوراک پروژه های کوچیکی هست که نیازمندی های اون ها کم و قابل ارزیابیه( مثلا یه سایت معمولی لیندینگ طور ).
• عدم تداخل فاز ها: همونطور که بالاتر هم گفتم تو این مدل فاز ها هیچ تداخل و همجوشی با هم دیگه ندارن و هر فاز فقط در مرحله خودش انجام میگیره و.
• مشخص بودن بازه و ملزومات فاز ها: از اونجایی که فاز ها با همدیگه تداخلی ندارن و باعث بروز مشکل توی فاز های دیگه نمیشن، تقریبا میشه زمان دقیق شروع و پایان هر فاز رو تخمین زد و تعیین کرد که چه کار هایی باید داخلش انجام بشه ( با توجه به کار هایی که تو فاز قبلیش انجام شده ).
• مدیریت ساده: از اونجایی که این مدل قابل درک برای تمام اعضای تیم هست، مدیریت فاز ها و وظایف کار راحت تری هست.

معایب مدل آبشاری

• عدم وجود demo های متعدد برای مشتری: یکی از بزرگترین ایراداتی که این مدل داره اینه که تا وقتی به فاز آخر نرسیم، عملا هیچ پیش نمایشی از محصول برای ارائه به مشتری نداریم.
• سختی در تغییر نیازمندی ها: اگر مشتری یا هرکس دیگه ای آخر کار یا حتی حین کار خواستار تغییری باشه، اعمال این تغییرات خیلی سخته چون باید برگردیم به فاز اول و دوباره شروع به بررسی کنیم. این کار بصورت غیرمستقیم باعث بروز مشکلاتی که تمامی فاز های بعدی میشه و نیازه که اوناهم تغییر داشته باشن.
• دیباگ کردن طاقت فرسا: فرض کنیم ما تمام فاز هارو تموم کردیم و نسخه نهایی رو هم پابلیش کردیم و پولمونو هم گرفتیم و رفتیم باهاش بستنی بخوریم. تو همین حین مشتری زنگ میزنه و میگه فلان جای سایتم فلان مشکل رو داره؛ بی زحمت درستش کنید.اینجاست که بستنیه میپره تو گلوتون:) چرا ؟
  چون دیباگ کردن تو مدل آبشاری به این معنیه که برای اصلاح یه باگ کوچولو باید بریم دوباره از فاز های بالایی شروع به تغییر دادن بکنیم و پله پله بیایم پایین تا برسیم به فاز آخر و نسخه جدیدی رو ارائه بدیم.
• ناکارآمدی در پروژه های بزرگ و ریسک بالا: همونطور که گفتم تو این مدل هیچ چیز قطعی نیست( حتی بعد از رسیدن به نسخه نهایی، چون ممکنه تغییراتی اعمال بشه ). در نتیجه اصلا توصیه نمیشه برای پروژه هایی که نیازمندی های پیچیده ای دارن و طولانی مدت هستن از این مدل استفاده کنید.

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

چابک (Agile)

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

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

اصول اجایل

• ارتباط نزدیک و سازنده تمامی افراد و برنامه نویس های تیم باهمدیگه.
• تعامل موثر و مرتب با مشتری طی فرایند توسعه برای درک بهتر نیازمندی های پروژه و درخواست های مشتری.
• ارائه نسخه های متعدد حین توسعه پروژه به مشتری برای درک بهتر درخواست ها و نیازمندی ها.
• پاسخ به تغییرات و پذیرش اونها طی فرایند توسعه.

متد های اجایلی

همون طور که گفتیم اجایل فقط یه طرز تفکر هست و نه متدولوژی. اما متد هایی وجود دارن که با همین طرز تفکر زاده شدن و یه جورایی زیرمجموعه ای از اجایل هستن.
از معروف ترین متد ها، میشه Scrum رو اسم برد که احتمالا اسمش رو زیاد شنیدید.
این متد ها معمولا اصول و ارزش های مشترکی دارن اما یه سری تفاوت هایی هم ممکنه داشته باشن با هم.

- متد scrum

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

قراره نقش ها و اصطلاحات و فرایند های این متد رو با هم دیگه بررسی کنیم.(یک سری از اصطلاحات، تو متد های دیگه هم وجود داره که همینجا کاملا میپردازیم بهشون)
یه نگاهی به این عکس بندازید :

اصطلاحات:

• داستان کاربر(user story): تعاریف و توصیف‌هایی شفاف از ویژگی‌های مورد انتظار مشتری هست که ممکنه هم توسط مشتری و هم توسط مدیران پروژه نوشته بشه.
  برای مثال "امکان سفارش آنلان غذا" یک استوری برای یک پروژه فروشگاهی هست.
• بک لاگ محصول(product back log): بک لاگ رو میتونیم انباری از داستان ها و کار های در انتظار انجام تصور کنیم که برای تهیه لیست کار های روزمره، به این انبار سر میزنیم و موارد مورد نیاز رو با خودمون برمیداریم و میبریم(اصطلاحا pull میکنیم) و اگر کاری قابل انجام نبود دوباره برمیگردونیمش به انبار(یا push میکنیم).

• اسپرینت (sprint): به بازه های زمانی شخص که برای توسعه بخش های کوچک و شکسته شده در نظر گرفته میشن، اسپرینت گفته میشه. اسپرینت ها در متد اسکرام، بسته به عواملی ممکنه ۲ هفته الی ۴ هفته طول بکشن.
  تو این بازه ها هر کدوم از اعضای تیم مسئول انجام کاری هست که بهشون محول شده.
• بکلاگ اسپرینت (Sprint Backlog): به لیست کارهایی که در طول یک اسپرینت باید انجام داده بشه گفته میشه. این لیست از لیست بک لاگ محصول بیرون کشیده میشه.
• وظیفه(task): به هر کدوم از آیتم های موجود در بک لاگ اسپرینت که باید توسط تیم انجام بشن task گفته میشه.
• بُرد(Board): در تمام مراحل کار باید یک بُرد فیزیکی یا دیجیتالی داشته باشیم که اعضای تیم بتونن از وظایف خودشون و بقیه اعضای تیم مطلع باشن و روند کاری و وضعیت فعالیت های خودشون رو بصورت تصویری پیگیری کنن. ورودی های این بُرد همون بک لاگ اسپرینت هست و بعد از شروع اسپرنت همه روزه به روز رسانی میشه.
  این بُرد ها شامل ستون های مختلفی هستن که ممکنه متغیر باشن تو هر متد یا تیمی و حتی اسامی مختلفی داشته باشن. اما در ساده ترین حالت حداقل سه ستون زیر رو شامل میشن :
  منتظر انجام یا todo ،در حال انجام یا in progress، انجام شده یا done.

تسک های موجود در بُرد ممکنه بسته به اولویت، ستون یا موضوعی که دارن رنگ های مختلفی داشته باشن تا بهتر دسته بندی بشن. همچنین ممکنه یک سری point بر حسب درجه سختیشون داشته باشن.

اگر بخوام تصویر بالا رو توضیح بدم :
-لیست to do از بک لاگ به بُرد تزریق میشه.
-هر شخصی تسک خودش رو از ستون to do وارد ستون in progress یا develop میکنه و شروع به کار میکنه.
-بعد از اتمام کار، کد میتونه وارد ستونی به اسم in review بشه که تو این مرحله شخص دیگه ای مسئول مرور کردن این کد ها میشه.
-ستون بعدی ستون تست هست که تو این قسمت تستر شروع به تست کردن کار های انجام شده میکنه.
در نهایت اگر همه چیز اوکی بود، تسک مورد نظر ادغام میشه و میره تو ستون done.

• جلسات برنامه ریزی(planning): جلساتی که قبل از شروع هر اسپرینت برگزار میشن و همه افراد تیم به کمک استاد اسکرام، با توجه به اولویت بندی های موجود و زمان و توان انجام، شروع به بیرون کشیدن لیستی از بک لاگ میکنن تا به اسپرینت تزریقش کنن.
• جلسات سرپایی(Stand up Meeting): همه روزه و معمولا قبل از شروع به کار، جلساتی به مدت ۱۵ دقیقه بین اعضای تیم برگزار میشه که درمورد کار های روز قبل، مشکلات پیش اومده و برنامه کارهای روز جاری صحبت میشه( این جلسات معمولا بصورت ایستاده برگزار میشه ).
• جلسه گذشته نگر(retro): بعد از اتمام هر اسپرینت، جلسه ای برگزار میشه که تو اون تمامی اعضای تیم درمورد تجربیات، آموخته ها، مشکلات و کمبود هایی که تو اسپرینت به اتمام رسیده داشتن صحبت میکنن.
• جلسه نسخه نمایشی(demo): این جلسه بسته به پیشنهاد ذینفع یا ذینفعان پروژه و یا درخواست مشتری، هر یک یا چند اسپرینت یک بار برای مشاهده demo یا پیش نمایش از نتیجه اسپرینت های به اتمام رسیده برگزار میشه.

نقش ها:

• صاحب محصول(product owner): به عنوان ذی نفع پروژه و نماینده مشتری، مسئولیت جمع آوری و اولویت بندی بک لاگ ها و تعیین نقشه راه رو داره. همچنین دائما با مشتری در ارتباط هست و feedback هایی رو دریافت و منتقل میکنه.
• استاد اسکرام(scrum master): شخصی هست که مسئولیت برنامه ریزی اسپرینت و تزریق لیست کار ها،
  نظارت بر پیشبرد و اتمام به موقع کار ها، اطلاع از کار اعضا و متمرکز کردن اون ها رو به عهده داره.
• تیم توسعه(develop team): تیمی متشکل از افرادی با تخصص های مختلف که مسئول به تحقق رساندن اهداف اسپرینت هستن. تعداد این اعضا متغیر هست اما معمولا بیشتر از ۱۰ نفر نیستن.
  هیچ کدوم از این اعضا نسبت به دیگری برتری و رتبه ندارن و همیشه در تعامل سازنده با همدیگه هستن.

بررسی فرایند کاری :

حالا که کاملا با این اصطلاحات آشنا شدید، میخوام اتفاقات یک اسپرینت رو بصورت خلاصه وار با استناد به عکس بالایی توضیح بدم :
-اولین اتفاقی که باید بیفته، جلسه planning هست تا بک لاگ اسپرینت مشخص بشه.
-بعد از اون board آماده میشه و تسک ها شروع به پیشروی میکنن و این کار تا انتهای اسپرینت ادامه داره.
-هر روز صبح توی جلسات روزانه یا سرپایی درمورد کار های روز گذشته و برنامه روز جاری صحبت میشه.
-بعد از اتمام اسپرینت، تو جلسه retro درباره تجربیات اسپرینت تموم شده صحبت میشه.
-در صورت نیاز جلسه demo هم با حضور مدیران یا مشتری برگزار میشه و نتایج کار به نمایش گذاشته میشه.
بعد از همه این کار ها، دوباره این حلقه از اول تکرار میشه و روز از نو و روزی از نو :)

حالا که با متد اسکرام آشنا شدیم بریم یه نگاه کوچیکی به دوتا از متد های دیگه‌ی اجایلی داشته باشیم.

- متد XP

متدولوژی XP که مخخف عبارت Extreme Programming یا برنامه نویسی مفرط هست.

البته گیف بالا شوخیه:) این متد به معنی زیاد کار کردن نیست و با همون طرز تفکر اجایلی و مختص توسعه نرم افزار طراحی شده.
این متد از practice های مختلفی که در تصویر بالا هم مشاهده میکنید تشکیل شده که بر نحوه انجام کار ها تاکید دارن. هر حلقه رنگی نشون دهنده گروهی از این practice ها هست که بصورت دوار انجام میگیرن.
به چند تا از این practice ها در ادامه اشاره میکنم.
تمرکز اصلی متد روی کاهش هزینه های توسعه و افزایش کیفیت محصول، به کمک feedback های دریافتی از طریق practice ها در هر بخشی از کار و پاسخ گویی سریع به نیازمندی های درحال تغییر هست.

اگر نقشه راه محصول رو مثل یک جاده پر پیچ و خم در نظر بگیریم، متد XP مثل راننده ماشینی هست که دائما چشم هاش به جاده هست و با هر پیچی سریعا واکنش نشون میده و سریعا فرمون رو میچرخونه.
همچنین تو این متد باید تصور کنید زمان نامحدودی در اختیار دارید و دائما در حال refactor کردن کدها، تست نویسی و ارتباط با مشتری و اعضای تیم باشید(مهم کیفیته).

عکس زیر به خوبی فرایند کاری و ترتیب مراحل رو تو این متد نشون میده :

تفاوت متد اسکرام و XP :

• برخلاف اسکرام، اسپرینت ها تو این متد بین ۱ تا ۲ هفته تنظیم میشن.
• برخلاف اسکرام، تو این متد برنامه نویسی بصورت جفت یا pair انجام میشه.یعنی برنامه نویس ها، طراح ها و حتی تستر ها بصورت جفت و دوتایی با هم کار میکنن.(این یکی از مهم ترین practice هاست).
  یه نفر مسئول کد نویسی یا طراحی هست که بهش navigator گفته میشه و نفر دوم مسئول کنترل و ایده پردازی برای نفر کناری هست که بهش observer گفته میشه( البته چند وقت یکبار جای این دوتا با هم عوض میشه ).
  همچنین این دو نفر مسئول integration testing هم هستن که به معنی تست کردن کار های انجام شده بعد از اتمام کار هست و یکی دیگه از practice ها محسوب میشه.

• برعکس متد اسکرام، تو این متد اعضای تیم میتونن اسپرینت و بک لاگ اون رو در صورت نیاز تغییر بدن.
• تو متد اسکرام، تسک هایی که برای بک لاگ اسپرینت از بک لاگ محصول pull میشن رو خود اعضای تیم با نظارت اسکرام مستر مشخص میکنن؛ اما تو این متد این تسک ها رو مشتری با اولویت بندی که داره مشخص میکنه و تیم موظف هست که طبق همون بک لاگ پیش بره و به اهداف برسه.
• از ویژگی های این متد که خیلی بهش توجه میشه و جزو core practice های اون محسوب میشه، نوشتن تست ها و اجرای اونها قبل و بعد از برنامه نویسی و آزمایش کل سیستم هر چند روز یکبار هست( درکل کیفیت کد ها خیلی مهمه تو این متد و مدام باید مرور و تست بشن و یجورای منظور از "مفرط" همینه ).

- متد kanban

این متدولوژی از اجایل هم بر پایه همون تفکرات و البته فلسفه ی سیستم Just-In-Time شرکت تویوتا بنا شده. کانبان متدی هست که با روش های سخت گیرانه ای که داره باعث مدیریت بهتر گردش کار بین اعضای تیم میشه و کمک میکنه تا لیست کار های روزانه‌ی مشخص و شفافی، بدون multitasking داشته باشیم.
همه این ها در کنار هم باعث افزایش بازدهی میشن و از این منظر بسیار مناسب تیم هایی هست که منابع محدودی دارن.
نحوه کار و فرایند توسعه تو این متد بسیار نزدیک به متد اسکرام هست و وجوه مشترک خیلی زیادی دارن. اما تفاوت هایی هم دارن که اونها رو از هم جدا میکنه.

تفاوت متد اسکرام و کانبان :

• بجای scrum master که تو اسکرام داشتیم، تو این متد agile coach یا مربی اجایل رو داریم که تقریبا همون نقش رهبر و استاد رو داره.
• سیستم pull از بک لاگ در این متد تفاوت هایی داره. تو متد اسکرام تسک های داخل برد یکجا وارد میشدن و همه شروع به کار و به عهده کردن تسک ها میکردن( اصلا خود لغت اسکرام اشاره به نوعی بازی فوتبال داره که تو اون همه یهو مثل گیف زیر حمله میکنن به توپ:) ).

اما تو متد کانبان ورودی ها محدود هست و همه چیز بستگی به ظرفیت و توانایی تیم داره. برای مثال اگر تیم ما ۴ نفره باشه نهایتا باید ۵ تسک وارد برد بشه(مثلا).
تو این متد وقتی یکی از تسک ها به مرحله done برسه از برد خارج میشه و به ستون قبلی خودش سیگنالی میده که موقع تزریق تسک جدید رسیده. اون ستون هم به ستون قبلی خودش سیگنال میده و اینطوری تسک جدیدی از بک لاگ تزریق میشه در لحظه.

• تو این متد محدودیت ویژه ای برای WIP یا کار های در حال انجام داریم. هر شخص نمیتونه بیشتر از یک محدوده ای تسک(معمولا ۲ تا) در حال انجام داشته باشه.

جمع بندی

یکم طولانی شد. اما شاید بتونه فقط مفاهیم خیلی پایه از این مواردی که بررسی شدن رو بهتون یاد بده. مواردی که برای یه برنامه نویس یا طراح یا تستر که میخواد تو یه تیم اجایلی کار کنه کافیه؛ اما برای کسی که میخواد یه scrum master بشه نه.

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

اگر خوشتون اومد لایک یادتون نره... اگر هم ایرادی(چه گرامری چه علمی) تو مقاله دیدید خوشحال میشم درجریانم بزارید تا اصلاحش کنم.