مترجم: مهندس امیر جلیلی‌فرد
فهرست
+ مسأله
+ پاسخ متدهای چابک
++ اصول بنیادی
+ بیانیه نرم‌افزار چابک
+ قواعد زاینده
+ اقدامات چابک
++ برنامه‌ریزی ویژگی و اولویت‌بندی پویا
++ بازخورد و تغیییر
++ تأکید بر کارتیمی
توسعه نرم افزار چابک: کسب و کار نوآوری – بخش دوم
پاسخ متدهای چابک
متدهای چابک پاسخی به این انتظار بازار هستند. استراتژی متدهای چابک، کاهش هزینه تغییرات در طول پروژه است. برای مثال XP از تیم توسعه نرم‌افزار می‌خواهد:
— اولین تحویل[۱] را طی چند هفته با هدف کسب موفقیت زودهنگام و بازخورد سریع آماده کنید.
— راه‌حلهای ساده ابداع کنید. در نتیجه، نیاز به تغییرات، کمتر و اعمال آنها نیز ساده‌تر خواهد بود.
— کیفیت طراحی را مدام بهبود دهید و پیاده‌سازی story بعدی را کم‌هزینه‌تر از فعلی کنید.
— برای شناسایی زودتر و کم‌هزینه‌تر عیبها، مدام آزمایش[۲] کنید.
کیفیت طراحی در توسعه نرم‌افزار چابک اهمیت داشته و بر آن تاکید می‌شود. گاهی متدهای چابک با کدنویسی موردی(ad hoc) یا کدنویسی گاوچرانی(cowboy) اشتباه گرفته می‌شوند. دلیل این اشتباه این است که طراحی در این متدها نه به صورت یک‌باره و پیش‌هنگام[۳] -خیلی زودتر از زمان پیاده‌سازی-، بلکه به تدریج و در بخشهای کوچک انجام می‌شود.
هر یک از متدهای چابک، کیفیت را به شیوه خاص خود مدیریت می‌کند. برای نمونه، DSDM گروهی از نمونه‌های اولیه(پروتوتایپ) را برای ورود و حمله به حوزه‌های ناپایدار و ناشناخته مانند تکنولوژی‌های نوین،قواعد کسب‌وکار جدید و طراحی رابط کاربر استفاده می‌کند. Scrum از جلسات روزانه ۱۵ دقیقه‌ای و بازنگری‌های جامع در پایان تکرارهای ۳۰ روزه استفاده می‌کند.
اصول بنیادی
متدهای چابک بر دو مفهوم تاکید دارند:
— درستی بی‌چون و چرای کدی که کار می‌کند
— اثربخشی[۳] افرادی که با حسن نیت با یکدیگر کار می‌کنند
کدی که کار می‌کند به توسعه‌دهندگان و حامیان مالی[۴] نشان می‌دهد چه چیزی واقعاً در پیش رویشان قرار دارد. (به جای اینکه داشتن چیزی در آینده به آنها قول داده شده باشد). کدی که کار می‌کند می‌تواند ارسال، اصلاح یا دور انداخته شود. اما هرچه که باشد، واقعی و ملموس است.
استفاده موثر از افراد منجر به افرایش سرعت، قدرت مانور و صرفه‌جویی در هزینه‌ها می‌شود. افراد می‌توانند ایده‌ها را رو در رو سریع‌تر به یکدیگر منتقل کنند تا با نوشتن و خواندن مستندات. چند طراح در کنار هم، طرح بهتری ارائه می‌دهند تا اینکه جداگانه روی طرح کار کنند. زمانی که توسعه‌دهندگان با مشتریان و حامیان مالی گفت‌وگو کنند، قادر به رفع مشکلات دشوار، تعدیل اولویت‌ها و بررسی راه‌های جایگزین به شیوه‌ای خواهند بود که بدون همکاری آنها امکان‌پذیر نیست.
بیانیه نرم افزار چابک
برای رسمیت بخشیدن به ایده‌ها، ما – Highsmith و Cockburn- در فوریه ۲۰۰۱ با ۱۵ نفر دیگر که نمایندگان XP، Scrum، DSDM، ASD، Crystal، Feature Driven Development، Pragmatic Programming و سایرینی که بر ضرورت تعریف متدهای جایگزینی برای توسعه نرم‌افزار توافق نظر داشتند با هدف امضای بیانیه توسعه نرم‌افزار چابک گرد هم آمدیم. ما نوشتیم:
“ما در حال کشف راه‌های بهتری برای توسعه نرم‌افزار با انجام آن و کمک به دیگران برای انجام آن هستیم. برای این کار ما آمده‌ایم تا ارزشمند بدانیم:
— افراد و تعامل بین آنها را بیش از فرایندها و ابزارها
— نرم‌افزاری که کار می‌کند را بیش از مستندات جامع
— مشارکت مشتری را بیش از مذاکره قرارداد
— پاسخگویی به تغییر را بیش از اجرای یک طرح
این بدین معناست که هر چند اقلام سمت چپ ارزشمند هستند، ما اقلام سمت راست را باارزشتر می‌دانیم.”
فرایندها، ابزارها، مستندسازی‌ها، قراردادها و طرحها مفیدند، اما در شرابط فشار و اضطرار، از انجام بعضی کارها صرف‌نظر می‌کنیم. لذا ضروری است مشخص کنیم که چه کارهایی الزامی و چه کارهایی قابل چشم‌پوشی‌اند.
تکیه بر تعامل افراد، اشتراک‌گذاری اطلاعات و تغییر سریع فرایند را در صورت لزوم، آسان می‌کند. مبنا قرار گرفتن نرم‌افزاری که کار می‌کند امکان اندازه‌گیری سرعت واقعی تولید خروجی‌ها و دریافت بازخوردهای زودهنگام را فراهم می‌کند. حداقل‌سازی مستندسازی نیز با تعامل زیاد بین افراد جبران می‌شود.
مشارکت مشتری بدین معنی است که همه بازیکنان -حامی مالی، مشتری، کاربر و توسعه‌دهنده- در یک تیم هستند. ترکیب تجربیات و مهارت‌های متفاوت آنها در کنار حسن‌نیتشان، گروه را قادر به تغییر سریع مسیر پروژه و به دنبال آن، تولید نتایج قابل قبول‌تر و طراحی ارزان‌تر می‌کند. وجود قرارداد یا منشور پروژه‌ها ضروری است، اما وجود آنها بدون مشارکت مشتریان ناکافی است.
تهیه طرح پروژه، اعضای تیم را به سمت اندیشیدن به مسیر پروژه و احتمالات آن سوق می‌دهد. معمولاً پس از چند روز، پروژه از مسیر برنامه‌ریزی شده خارج و طرح بی‌اعتبار می‌گردد. بنابراین به جای تمرکز روی طرح منسوخ شده، رو در رو شدن با واقعیات تغییرپذیر اهمیت پیدا می‌کند.
قواعد زاینده(Generative Rules)
یکی از جنبه‌های توسعه چابک که اغلب فراموش شده یا از نظر دور مانده، این است که:
سازمانها، سیستم‌های انطباق‌پذیرِ پیچیده هستند. سیستم انطباق‌پذیر پیچیده، سیستمی است که در آن اجزای مستقل و غیرمتمرکز از طریق روشهای خودسازماندهی و تحت مجموعه‌ای از قواعد ساده و زاینده، نتایج نو، ابداعی و فوری ایجاد می‌کنند.
برای مثال، هدف از معرفی ۱۲ اقدام(Practice) در XP این نبوده که قواعدی جامع و فراگیر تعریف شود که در هرموقعیت و شرایطی به کار گرفته شوند. بلکه هدف این است که وقتی تیمی این اقدامات را انجام می‌دهد، آنها قواعد زاینده‌ای باشند که با هماهنگی و هارمونی عمل می‌کنند.
بسیاری از متدولوژی‌ها، قواعد جامع و فراگیر دارند یعنی کارهایی که احتمالاً می‌توانید در هر موقعیتی[۶]انجام دهید. متدهای چابک قواعد زاینده را پیشنهاد می‌کنند -مجموعه‌ای کمینه از کارهایی که باید در هر موقعیتی انجام شوند تا با استفاده از آنها، اقدامات مناسب موقعیتهای جدید و خاص خلق شود. تیم‌هایی که پیروی قواعد جامع و فراگیر هستند، به فرد دیگری وابسته‌اند تا پیشاپیش اقدامات را برای موقعیتهای جدید تعیین کند. روشن است که این شیوه خیلی زود شکست می‌خورد. اما تیمی که پیروی قواعد زاینده است، به محض بروز مسائل، به افراد و خلاقیت آنها برای یافتن راه‌حل‌ها وابسته است. خلاقیت تنها راه مدیریت مشکلات پیچیده توسعه نرم‌افزار و موقعیتهای گوناگون آن است و نه انبوه قواعد مکتوب.
[۱]Delivery
[۲] Test
[۳] Effectiveness
[۴] Sponser
[۵] Up-front
[۶] Situation
گزیده:
«امید غریزه‌ای است که تنها ذهن استدلالی و معقول بشر می‌تواند آن را از بین ببرد.»
گراهام گرین
دیدگاهتان را بنویسید