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

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

اصل شماره یک بیانیه: بالاترین اولویت ما، کسب رضایت مشتری با تحویل زود هنگام و مداوم نرم افزار با ارزش است.

 اصل شماره دو بیانیه: حتی در پایان توسعه به تغییرات خوش آمد می گوییم. متدهای چابک تغییرات را برای مزیت های رقابتی مشتری مهار می کنند.

به طور کلی، تاثیر این موضوع بر روی صنعت چشمگیر و اساسی است. همان گونه که در کتاب «Scaling Software Agility» بیان شده است:

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

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

اسکرام

اسکرام یک روش مدیریت پروژه چابک است که به طور گسترده مورد استفاده قرار می گیرد. تجربه های اصلی اسکرام شامل موارد ذیل هستند:

• کار در اسپرینت هایی که تکرارهای زمان ثابت 30 روزه یا کمتر هستند انجام می گردد. 
• کار در اسپرینت ثابت است. وقتی محدوده اسپرینت تثبیت شد، هیچ کارکرد دیگری نمی تواند اضافه شود. کارکرد جدید فقط توسط تیم توسعه می تواند اضافه گردد. 
• کارها برای اینکه انجام شوند در بک لاگ محصول قرار می گیرند. بک اگ محصول شامل نیازمندی های جدید، نقص ها و فعالیت های زیرساختی و طراحی هستند. 
• «استاد اسکرام» مربی توانمندسازی تیم های خودسازمانده و خودپاسخگو است. این تیم ها مسئولیت تحویل نتایج موفقیت آمیز در هر اسپرینت را بر عهده دارند. 
• «مالک محصول» نقش وکیل مشتری را بازی می کند. 
• جلسه اسکرام روزانه یک روش با اهمیت برای برقراری ارتباط است.  
• اسپرینت ها باید زمان ثابت باشند. اسپرینت ها، جلسه های ایستاده و جلسه های بازنگری انتشار در زمان های تعیین شده کامل می شوند.

 سبک وزن بودن اسکرام باعث شده است که به طور گسترده توسط سازمان های توسعه نرم افزار مورد استفاده قرار بگیرد.

ایکس پی

ایکس پی یکی از روش های توسعه نرم افزار چابک است که به طور گسترده در بسیاری از کتاب ها توصیف شده است. تجربه های اصلی ایکس پی شامل موارد ذیل هستند:

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

ایکس پی در محدوده، تجویزی می باشد و معمولا در تیم های کمتر از ده توسعه دهنده اعمال می گردد. به طوری که، مشتری باید در کنار تیم مقیم باشد و یا به راحتی در دسترس تیم قرار بگیرد. به علاوه،P در XP مخفف کلمه «programming» می باشد، و بر خلاف روش های دیگر، ایکس پی تجربه های شدیدی برای کدنویسی که خروجی با کیفیت بسیار بالایی را تولید می نماید، در نظر می گیرد.

جنگ روش ها

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

(بررسی روش های چابکی که به طور گسترده اتخاذ شده اند. چهارمین گزارش سالانه بررسی توسعه چابک در سال 2009. با همکاری شرکت VersionOne)

بیانیه چابک

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

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

 اشخاص و تعاملات برتر از فرایندها و ابزارها 

 مشارکت مشتری برتر از قرارداد کار

نرم افزار قابل استفاده برتر از مستندات جامع

 پاسخ به تغییرات برتر از دنبال کردن یک برنامه

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

فرایندهای تطبیقی(چابک)

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

در حقیقت تعدادی از این روش ها، شامل روش توسعه سیستم های پویا(DSDM)، توسعه ویژگی محور(FDD)، توسعه نرم افزار تطبیقی، اسکرام، ایکس پی، فرایند یکپارچه باز(Open Up)، فرایند یکپارچه رشنال چابک(Agile RUP)، کانبان، ناب، روش های کریستال و ... هستند.

اصول روش های چابک

پشت بیانیه چابک مجموعه ای از اصول مهم وجود دارد که به عنوان چارچوبی مشترک برای تمام روش های چابک به خدمت گرفته می شوند:

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

فرایندهای تکراری و تدریجی

در چند دهه گذشته، شکست مدل آبشاری در کنار وجود فشارهای «زمان تا بازار » و گسترش ابزارها و تکنولوژی های توسعه نرم افزار باعث شد تا به مدل های مبتکرانه و مبتنی بر اکتشاف نیاز پیدا کنیم. به گونه ای که این موضوع ما را به فرایندهای تکراری دهه 1980 و 1990 هدات کرد. همان طوری که شکل ذیل نشان می دهد این روش ها شامل موارد ذیل هستند:

• توسعه سریع یافته ها توسط کشف تجربی(حلزونی)
• ساخت سریع مدل ها، نمونه های اولیه و سیستم ابتدایی با استفاده از ابزارهای بسیار سریع(توسعه سریع برنامه کاربردی) 
• توسعه تکراری و تدریجی سیستم های بسیار بزرگ و بسیار پیچیده(فرایند یکپارچه رشنال)

(فرایندهای تکراری Spiral-RAD-RUP)

نیازمندی ها در فرایند های تکراری

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

مدل حلزونی

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

(مدل حلزونی)