Fail سریع خوب است
یکی از مزایای سوییچ کردن به روش چابک، رویارویی سریع با شکست است (منظور از شکست احتمال دارد به جایی برسید که کل پروژه تعطیل شود) برای روشن شدن مطلب , در مورد نحوه کار پروژه های waterfall فکر کنید. نیازهای کسب‌کار به ویژگی نرم افزار تبدیل می شود. تیم توسعه این ویژگی ها را بررسی و شروع به طراحی و ساخت نرم افزار می کند. چند ماه بعد گروه توسعه با جلال و شکوه و طی مراسم شیرینی خورانی نرم افزار را به مشتری نشان می دهند .
تاریخ نشان داده است که معمولا این شادی به طول نخواهد انجامید به دلیل اینکه بعضی از بخش ها آن طوری نیست که مشتری درخواست کرده بود و یا اصلا آن طور بود که مشتری درخواست کرده بود ولی مشتری هم اشتباه کرده بود و نیاز مشتری برآورده نشده است. نرم افزار و یا بخشی از نرم افزار با شکست روبرو شده است . شما دو راه حل دارید : ۱- بازنویسی , که هزینه زیادی دارد ۲- بی‌خیال شدن پروژه و قبول ضرر و زیان.
همانطور که در قسمت آموزش اسکرام عرض کرده بودم , در این متدلوژی نرم افزار به بخش هایی تقسیم می شود که نتیجه هر بخش به صورت جداگانه به حالت Demo به مشتری ارایه می شود و مشتری مشکلات هربخش را کشف و به تیم توسعه اطلاع می دهد . معمولا هر ۳ هفته یک بار که اسپرینت تمام می شود به مشتری دموی نرم افزار داده می شود , و این که مشکلات ۳ هفته را رفع کردن راحتر و کم هزینه تر از رفع مشکلات نرم افزاری ۶ ماهه می باشد .
از مشتری و یا اصلاحا صاحب محصول (Product Owner) نترسید, هر Sprint که تمام شد , به او اجازه دهید تا نرم افزار را استفاده نماید و مشکلات را به شما بازتاب دهد و اینگونه است که Agile شکل می گیرد .
