فرادرستوسعه نرم افزار چابک (Agile Software Development) – علل پیدایش
«توسعه نرم افزار چابک» (Agile Software Development) رویکردی برای توسعه نرم‌افزار است که طبق آن الزامات و راه‌حل‌ها از طریق تلاش مشترک تیم‌های خود سازمانده و نیز مشتریان و کاربران نهایی محصول آن‌ها، حاصل می‌شود. رویکرد چابک تیم‌ها را قادر می‌سازد محصولات خود را با کیفیت بهتری تولید کنند و دائما در حال پیشرفت و بهبود باشند؛ همچنین این رویکرد موجب می‌شود که توسعه‌دهندگان خلاق‌تر باشند و با اولویت‌بندی بهینه کارها با سرعت پایدار، محصول نهایی نیز بهینه می‌شود. در دنیای امروز دیگر برای بسیاری سازمان‌ها این سوال مطرح نیست که چگونه «چابک» شویم، بلکه سوال اصلی آن‌ها این است که چگونه هرچه «سریع‌تر» چابک شویم. در این مجموعه نوشته‌ها با اصول کلیدی رویکرد چابک از دیدگاه توسعه‌دهندگان آشنا خواهیم شد و در مورد برخی از محبوب‌ترین روش‌های چابک در سازمان‌ها مانند «اسکرام» (Scrum) و «کانبان» (Kanban) صحبت خواهیم کرد. شگفت‌زده خواهید شد وقتی ببینید که رویکرد چابک تا چه میزان خلاقیت شما و کیفیت محصولاتتان را بهبود خواهد بخشید.
برای مطالعه این مطالب نیاز به پیش زمینه خاصی وجود ندارد و حتما لازم نیست که برنامه‌نویس باشید؛ تنها کافیست عضوی از هر کدام از تیم‌های درگیر فرایند توسعه محصول باشید تا این مطالب برای شما مفید و موثر باشد. بسیاری از مباحث روز این حوزه را به طور خلاصه پوشش خواهیم داد و مثال‌های عملی از پروژه‌های واقعی نیز خواهیم داشت؛ چند نرم‌افزار کاربردی هم در این زمینه معرفی خواهیم کرد.
بحران نرم‌افزار
افزایش محبوبیت متدولوژی چابک به دلیل همان چیزیست که این روزها عموما به عنوان «بحران نرم‌افزار» شناخته شده است. می‌دانیم که در فرایند توسعه نرم‌افزار، چالش اصلی ایجاد برنامه‌های کارآمد و مفید در بازه زمانی از پیش تعیین شده (Timeline) است. بحران از اینجا ناشی شد که برای مدیریت تیم‌های توسعه نرم‌افزاری هم همان شیوه‌هایی به کار برده می‌شد که قبلا در ساخت‌و‌ساز و پروژه‌های تولیدی دیگر به‌کار گرفته شده بود.
یک خط تولید ماشین را در نظر بگیرید؛ تمامی محصولات این خط تولید یکسان و مشابه هستند و یکی پس از دیگری مونتاژ می‌شوند. مهندسان طراح و مدیران در همان ابتدا چک لیست‌ها و اسنادی را تهیه می‌کنند که درآن به خوبی و وضوح در مورد ابزارها و فرایند انجام کار توضیح داده شده است و کارگران هم به سادگی همان خط مشی را دنبال می‌کنند. چنین سیستم مستندات جامعی باعث می‌شود که نقص‌ها و کاستی‌ها به سادگی قابل ردگیری و اصلاح باشند.
یا مورد دیگر مثلا ساخت‌و‌ساز یک خانه را در نظر بگیرید. با تنظیم قرارداد همه چیز نهایی و مشخص است و اگر شما در ادامه کار امکانات دیگری بخواهید به سفارشتان اضافه کنید، مستلزم هزینه اضافی است. عموما قراردادها جوری تنظیم می‌شوند که با کمترین تغییرات بعدی سازگار باشند و هر چه زمان بیشتری بگذرد، انجام تغییرات بعدی پر هزینه‌تر خواهد شد. در دنیای توسعه نرم‌افزار هم در ابتدا سعی کردند همان شیوه دنیای صنعت و ساخت و ساز را در پیش بگیرند؛ رویکرد اولیه توسعه نرم‌افزارها همان چیزی بود که امروزه به «مدل آبشاری» (Waterfall Model) معروف شده است.
مدل آبشاری توسعه نرم‌افزار
این مدل پنج فاز اصلی دارد:
- بررسی نیازمندی‌ها
- طراحی و تحلیل
- توسعه و پیاده‌سازی
- تست
- استقرار و نگهداری
هر فاز به طور مشخص و دقیق تعریف شده و خروجی آن ورودی فاز بعدی است. مثلا وقتی فاز طراحی و تحلیل به پایان می‌رسد یک سیستم کاملا طراحی شده داریم که دیگر آماده پیاده‌سازی است. بعد از پیاده‌سازی سیستم آماده مرحله تست است و همین طور الی آخر.
در ظاهر که همه چیز خوب به نظر می‌رسد. پس مشکل در کجا بود و چه چیزی باعث بروز «بحران نرم‌افزار» شد؟ باید بگوییم این شیوه دو مشکل اساسی دارد.
اولین ایراد این است که مشتری نمی‌تواند تا قبل از مرحله تست هیچ چیزی از محصول سفارش داده خود ببیند یا دریافت کند و تا اینجا معمولا دیگر دو سوم بازه زمانی تعیین شده برای کل پروژه از دست رفته است. در همین حین ممکن است با چنین کابوسی مواجه شوید: شرایط بازار تغییر کرده و محصولی که تا اینجا توسعه داده‌اید، دیگر ارزش چندانی ندارد؛ یا حتی مدیران سازمانی که به شما سفارش داده‌اند تغییر کنند، تصمیمات جدیدی بگیرند و نیاز باشد بخش زیادی از پروژه انجام شده مجددا تغییر کند و بدتر از همه این‌ها در حین فرایند توسعه و پیاده‌سازی به این نتیجه برسید که محصول نهایی فاز قبلی دارای ایراد اساسی در معماری و طراحی است.
همه این‌ها زنگ هشدار را به صدا در می‌آورد: بعد از هزینه مقدار زیادی پول و زمان و نیروی انسانی، این پروژه با شکست مواجه شده است. ایراد دوم اینجاست: در شیوه آبشاری رویکرد مدیریتی بالا به پائین جاری است. از اعضای تیم توسعه انتظار می‌رود که کاملا مطابق چک لیست‌ها و مستندات کنترلی روند پروژه عمل کنند و به طور کلی این شیوه فرایند را بر انسان‌ها ترجیح می‌دهد.
طبق گزارشی که در سال 1994 منتشر شد، تنها 16 درصد از پروژه‌هایی که بر طبق مدل آبشاری توسعه داده شده بودند، به موفقیت نهایی رسیدند و توانستند طبق بازه زمانی در نظر گرفته شده و بدون صرف هزینه و نیروی بیشتر پروژه را به اتمام برسانند. در 53 درصد از پروژه‌ها، با صرف بودجه و نیروی بیشتر و با شکست در برخی مراحل، سرانجام تیم‌ها توانستند بخشی از نیازهای مطرح شده اولیه را به اتمام برسانند، در حالی‌که از زمان تعیین شده اولیه هم مدت زیادی گذشته بود؛ 31 درصد از پروژه‌ها هم هیچ‌گاه به سرانجام نرسیدند.
در یک گزارش منتشر شده دیگر در سال 2000، 85 درصد از پروژه‌های نرم‌افزاری بررسی شده با شکست مواجه شده بودند. بعد از ارائه چنین گزارش‌هایی، دیگر تقریبا همه افراد فعال در صنعت نرم‌افزار به این باور رسیدند که به طور جدی به رویکرد مدیریتی جدیدی در تیم‌های توسعه نرم‌افزاری نیاز است؛ و سرانجام متدولوژی چابک معرفی شد. در نوشته‌های آینده با رویکرد توسعه نرم‌افزاری چابک بیشتر آشنا خواهیم شد.
برای مطالعه قسمت بعدی این مطلب روی لینک زیر کلیک کنید:
اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:
- مجموعه آموزش‌های مهندسی نرم افزار
- آموزش مدیریت Agile (چابک) پروژه ها با نرم افزار MSP
- مجموعه آموزش‌های برنامه‌‌نویسی
- همه‌چیز درمورد فرایندهای توسعه محصول جدید — بخش اول
^^
