مترجم: مهندس امیر جلیلی‌فرد
 فهرست
+ مسأله
+ پاسخ متدهای چابک
++ اصول بنیادی
+ بیانیه نرم‌افزار چابک
+ قواعد زاینده
+ اقدامات چابک
++ برنامه‌ریزی ویژگی و اولویت‌بندی پویا
++ بازخورد و تغیییر
++ تأکید بر کارتیمی

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش دوم
پاسخ متدهای چابک
متدهای چابک پاسخی به این انتظار بازار هستند. استراتژی متدهای چابک، کاهش هزینه تغییرات در طول پروژه است. برای مثال XP از تیم توسعه نرم­‌افزار می­‌خواهد:
-- اولین تحویل^[1] را طی چند هفته با هدف کسب موفقیت زودهنگام  و بازخورد سریع  آماده کنید.
-- راه­‌حل­های ساده  ابداع کنید. در نتیجه، نیاز به تغییرات، کمتر و  اعمال آنها نیز ساده­‌تر خواهد بود.
-- کیفیت طراحی را مدام بهبود دهید و پیاده­‌سازی story بعدی را کم­‌هزینه­‌تر از فعلی کنید.
-- برای شناسایی زودتر و کم­‌هزینه­‌تر عیبها، مدام آزمایش^[2] کنید.

کیفیت طراحی در توسعه نرم­‌افزار چابک اهمیت داشته و بر آن تاکید می‌شود. گاهی متدهای چابک با کدنویسی موردی(ad hoc) یا کدنویسی گاوچرانی(cowboy) اشتباه گرفته می­‌شوند.  دلیل این اشتباه این است که طراحی در این متدها نه به صورت یک‌باره و پیش‌هنگام^[3] -خیلی زودتر از زمان پیاده‌سازی-، بلکه به تدریج و در بخشهای کوچک انجام می‌شود. 

هر یک از متدهای چابک، کیفیت را به شیوه خاص خود مدیریت می­‌کند. برای نمونه، DSDM گروهی از نمونه­‌های اولیه(پروتوتایپ) را برای ورود و حمله به حوزه­‌های ناپایدار و ناشناخته مانند تکنولوژی­‌های نوین،­قواعد کسب­‌وکار جدید و طراحی رابط کاربر استفاده می­‌کند. Scrum از جلسات روزانه 15 دقیقه­‌ای و بازنگری­‌های جامع در پایان تکرارهای 30 روزه استفاده می­‌کند. 

اصول بنیادی
متدهای چابک بر دو مفهوم تاکید دارند:
-- درستی بی‌چون و چرای کدی که کار می­‌کند
-- اثربخشی^[3] افرادی که با حسن نیت با یکدیگر کار می­‌کنند

کدی که کار می­‌کند به توسعه­‌دهندگان و حامیان مالی^[4] نشان می­‌دهد  چه چیزی واقعاً در پیش رویشان قرار دارد. (به جای اینکه داشتن چیزی در آینده به آنها قول داده شده باشد). کدی که کار می­‌کند می­‌تواند ارسال، اصلاح  یا دور انداخته شود. اما هرچه که باشد، واقعی  و ملموس است.

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

 بیانیه نرم افزار چابک
  برای رسمیت بخشیدن به ایده­‌ها، ما – Highsmith و Cockburn- در فوریه 2001 با 15 نفر دیگر که نمایندگان XP، Scrum، DSDM، ASD، Crystal، Feature Driven Development، Pragmatic Programming و  سایرینی که بر ضرورت تعریف متدهای جایگزینی برای توسعه نرم‌افزار توافق نظر داشتند با هدف امضای بیانیه توسعه نرم‌افزار چابک گرد هم آمدیم. ما نوشتیم:

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

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

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

مشارکت مشتری بدین معنی است که همه بازیکنان -حامی مالی، مشتری، کاربر و توسعه­‌دهنده- در یک تیم هستند. ترکیب تجربیات و مهارت‌های متفاوت آنها در کنار حسن­‌نیتشان، گروه را قادر به تغییر سریع مسیر پروژه و به دنبال آن، تولید نتایج قابل قبول‌تر و طراحی ارزان­‌تر می­‌کند. وجود قرارداد یا منشور پروژه­‌ها ضروری است، اما وجود آنها بدون مشارکت مشتریان ناکافی است.

تهیه طرح پروژه، اعضای تیم را به سمت اندیشیدن به مسیر پروژه و احتمالات آن سوق می­‌دهد. معمولاً پس از چند روز، پروژه از مسیر برنامه­‌ریزی شده خارج و طرح بی­‌اعتبار می­‌گردد. بنابراین به جای تمرکز روی طرح منسوخ شده، رو در رو شدن با واقعیات تغییرپذیر  اهمیت پیدا می­‌کند.

 
قواعد زاینده(Generative Rules)
یکی از جنبه­‌های توسعه چابک که اغلب فراموش شده یا از نظر دور مانده، این است که:
سازمان­ها، سیستم­‌های انطباق­‌پذیرِ پیچیده هستند. سیستم انطباق­‌پذیر پیچیده، سیستمی است که در آن اجزای مستقل و غیرمتمرکز از طریق روشهای خودسازماندهی و تحت مجموعه­‌ای از قواعد ساده و زاینده، نتایج نو، ابداعی و فوری ایجاد می­‌کنند.

برای مثال، هدف از معرفی 12 اقدام(Practice) در XP این نبوده که قواعدی جامع و فراگیر تعریف شود که در هرموقعیت و شرایطی به کار گرفته شوند. بلکه هدف این است که وقتی تیمی این اقدامات را انجام می‌دهد، آنها قواعد زاینده­‌ای باشند که با هماهنگی و هارمونی عمل ‌می‌کنند.

بسیاری از متدولوژی­‌ها، قواعد جامع و فراگیر دارند یعنی کارهایی که احتمالاً  می‌توانید در هر موقعیتی^[6]انجام دهید. متدهای چابک قواعد زاینده را پیشنهاد می­‌کنند -مجموعه­‌ای کمینه­ از کارهایی که باید در هر موقعیتی انجام ­شوند تا با استفاده از آنها، اقدامات مناسب موقعیت‌های جدید و خاص خلق شود. تیم­‌هایی که پیروی قواعد جامع و فراگیر هستند، به فرد دیگری وابسته­‌اند تا پیشاپیش اقدامات را برای موقعیتهای جدید تعیین کند. روشن است که این شیوه خیلی زود شکست می­‌خورد. اما تیمی که پیروی قواعد زاینده است، به محض بروز مسائل، به افراد و خلاقیت آنها برای یافتن راه‌حل‌ها وابسته است. خلاقیت تنها راه مدیریت مشکلات پیچیده توسعه نرم­‌افزار و موقعیت­‌های گوناگون آن است و نه انبوه قواعد مکتوب.

گزیده:
«امید غریزه‌ای است که تنها ذهن استدلالی و معقول بشر می‌تواند آن را از بین ببرد.»
گراهام گرین