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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش سوم و آخر
اقدامات چابک(Agile Practices)
تیمی که حلقه بازخورد* با مشتریان و مدیرانش بیش از شش ماه باشد، چابک نیست. رویکردهای چابک برای اتخاذ تصمیمات بینابینی** و انطباق با اطلاعات جدید، تکرارهای کوتاهِ دو تا شش هفته‌ای را پیشنهاد می‌کنند .XP و Scrum دوره‌های مشخص‌تری -دو تا سه هفته در XP و سی روز در Scrum- دارند. در دیگر متدها مانند Crystal و ASD دوره‌های متنوع‌تری قابل تعریف است.

برنامه‌ریزی ویژگی و اولویت‌بندی پویا(Feature Planning and Dynamic Prioritization)
رویکردهای چابک، دوره‌های تکرار کوتاه‌مدت را با برنامه‌ریزی ویژگی و اولویت٬بندی پویا ترکیب می‌کنند. XP از کارتهای استوری (story)، ‏Scrum از واژه بک‌لاگ(backlog)،‏ ASD و FDD از ویژگی‌ (Feature) استفاده می‌کنند. نکته اصلی این است که رویکردهای چابک در وهله نخست ویژگی‌ها را به جای وظیفه‌ها(Task) برنامه‌ریزی می‌کنند، زیرا آن چه مشتری می‌فهمد، ویژگی است.
اولویت‌بندی پویا بدین معناست که مشتری در پایان هر تکرار می‌تواند ویژگی‌های دلخواه خود برای دوره بعدی را صرف‌نظر از ویژگی‌های برنامه‌ریزی‌شده قبلی و با افزودن ویژگی‌های جدید، دوباره اولویت‌بندی کند.
در Scrum اولویت‌ها فقط می‌توانند در پایان هر تکرار تغییر کنند و تغییر آنها در طول تکرار مجاز نیست. DSDM از قواعد MoSCoW ‏–Must have، Should have، Could have، Would have- برای اولویت‌بندی ویژگی‌ها استفاده می‌کند. روش اولویت XP، دوگزینه‌ای است: در این دوره هست یا نه؟ [مهم نیست در کدام یک از دوره‌های بعدی خواهد بود. فقط بودن در این دوره اهمیت دارد].

بازخورد و تغییر(Feedback and Change)
از آنجا که متدهای چابک برای محیط‌های پرتلاطم و پرتغییر کاربرد بیشتری دارند، اقدامات متنوعی را برای دریافت بازخورد دائمی از تصمیمات فنی، نیازمندی‌های مشتری و محدودیت‌های مدیریتی پیشنهاد می‌کنند.
XP برنامه‌نویسی دو نفره را برای دریافت بازخورد پیشنهاد کرده و DSDM نمونه‌سازی(پروتوتایپ) زود به زود را پررنگ کرده است. Crystal و ASD طرفدار بازنگری فرایند و تیم در پایان هر تکرار هستند. ASD و Scrum بازنگری پایان هر تکرار با گروه کارشناسی (گروه تمرکز ) مشتری را انجام می‌دهند.
اقدامات چابک به جای مقاومت در برابر تغییرات، تشویق به ایجاد آنها می‌کنند. در موقعیت‌های پرتلاطم کسب‌وکار، حد مجاز تغییرات در متدلوژِی باید متناسب با میزان تغییرات محیط باشد و نه مبتنی بر نگاه داخلی و میزان تغییرات قابل پذیرش در تیم. برای مثال تغییر اولویت‌بندی ویژگی‌ها و نیازمندی‌ها بدون نقض تغییرات، محدوده، زمان‌بندی و محدودیتهای کلان تعیین شده از سوی خریدار، بر اساس فضای تیم و شرکاء مشخص می‌شود.

تأکید بر کار گروهی
پیش هم بودن اعضای تیم [مشتریان، تیم توسعه و سایر ذینفعان] و شدت تعامل بین آنها از نشانه‌های متدهای چابک است. XP برنامه‌نویسی دو نفره را که سالها با نامهای متفاوتی وجود داشته، به کارگرفته است. Crystal، Scrum و ADS طرفدار اقدامات مبتنی بر مشارکت زیاد از جمله تیمهای پیش‌هم و بدون مرزبندی هستند و Lead Development نیز بر تعامل اعضای تیم تأکید دارد.
به‌کارگیری متدهای چابک نیازمند مشارکت زیاد مشتریان است. چنانچه مشتریان‌ اعم از نمایندگان واحدهای داخلی یا مدیران محصول واحد بازاریابی، برداشت درستی از مسیر محصول نداشته و بین الگو‌های ناشناخته سرگردان باشند، توسعه‌دهندگان چابک ناچارند از آنها پیروی کنند (و البته با تذکر و راهنمایی‌های موردی) و شکی نیست که پیامد مشتریان ضعیف، سیستم‌های ضعیف خواهد بود.

سخن آخر:
در سال ۱۹۹۵، Goldman،Nagel و Preiss نویسندگان کتاب Agile Competitors and Virtual Organizations تعریف زیر را برای چابکی پیشنهاد کرده‌اند:
چابکی عبارت است از پویایی، توجه به شرایط، پذیرش بی‌باکانه تغییرات و ترقی‌گرایی. چابکی درباره بهبود بهره‌وری، کاهش هزینه‌ها یا کوچک‌سازی کسب‌وکار برای گذر از طوفانهای ترسناک بازارهای رقابتی نیست. چابکی درباره موفقیت و پیروزی است: درباره موفقیت در عرصه‌‌های رقابتی نوظهور و پیروزی در کسب سود، سهم بازار و مشتریان در اوج طوفانهای بازارهای رقابتی است –هم‌اکنون این موارد، بسیاری از شرکتها را به هراس انداخته.
هر چند این کتاب درباره تولید نوشته شده، اما تعریف چابکی برای محیط توسعه نرم‎‌افزار کنونی، کاملاً صادق است.
خلاصه این که چابکی درباره ایجاد و پاسخگویی به تغییرات است. آنچه که درباره متدهای چابک تازگی دارد، اقدامات به‌کارگرفته شده در آنها نیست، بلکه به رسمیت شناختن افراد به عنوان حرکت‌دهندگان اصلی پروژه به سوی موفقیت به همراه تأکید فراوان بر اثربخشی و قدرت مانور است. این امر منجر به مجموعه‌ای از ارزشها و اصولی می‌شود که جهان‌بینی چابک را تشکیل می‌دهند.
توسعه نرم‌افزار چابک بیانگر دو عامل فشار بر کسب‌وکار و تکنولوژِی کنونی است: نیاز به «رویکردهای پویا همراه با نوآوری» و تمایل به «ایجاد محل‌کاری» که در کاریکاتورهای Dilbert *** وجود نداشته باشد.

—————————-
*پسخورد یا بازخورد، اندازه‌گیری متغیرهای خروجی و استفاده از آنها در اعمال ورودی به سیستم است. اعمال ورودی، عملیات سیستم، اندازه‌گیری خروجی و استفاده از آن در اعمال مجدد ورودی سیستم، حلقه‌ای را شکل می‌دهد که آن را حلقه پسخورد/بازخورد گویند.

** trade-off به معنای سبک‌وسنگین کردن و هم چنین معاوضه آمده است به عنوان مثال «انتخاب بین کوه رفتن یا خرید کردن در صبح روز جمعه این هفته».

*** www.Dilbert.com

گزیده:
عادت دستان ما را هوشمندتر و هوش ما را بی‌دست‌وپاتر می‌سازد.

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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش دوم
پاسخ متدهای چابک
متدهای چابک پاسخی به این انتظار بازار هستند. استراتژی متدهای چابک، کاهش هزینه تغییرات در طول پروژه است. برای مثال 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

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

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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش دوم
پاسخ متدهای چابک
متدهای چابک پاسخی به این انتظار بازار هستند. استراتژی متدهای چابک، کاهش هزینه تغییرات در طول پروژه است. برای مثال 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

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

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

مقدمه
مقاله Agile Software Development: The Business of Innovation نوشته Jim Highsmith و Alistair Cockburn دو تن از امضاءکنندگان بیانیه چابک(Agile Manifest) است. این مقاله در سپتامبر سال ۲۰۰۱ یعنی حدود هفت ماه پس از امضای بیانیه در مجله IEEE Computer چاپ شده است.

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

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

رویکردهای چابک از جمله XP‏ ،Crystal،‏ Lean Development،‏ Scrum و‏ ASD از دریچه­ای به تغییر می­نگرند که نشانگر آشفتگی محیط کسب­وکار و تکنولوژی کنونی است.

مسئله
به تازگی در تحقیقی که Michael Mah در QSM Associates بر روی بیش از ۲۰۰ پروژه توسعه نرم افزار
انجام داده، گزارش داده است محققان قادر به یافتن تقریباً نیمی از طرحهای^[۱] اولیه پروژه­ها برای مقایسه با یکدیگر نشدند. چرا ؟ زیرا هدف اصلی، اجرای پروژه مطابق با طرح اولیه نبوده و به جای آن، راضی نگه­داشتن مشتری -در هنگام تحویل پروژه و نه در آغاز آن– اولویت پیدا کرده است.

هم‌چنین در اغلب پروژه­های بازبینی­‌شده مشاهده کردیم که تغییرات مهم در نیازمندی­ها، محدوده و تکنولوژی -که خارج از کنترل تیم توسعه هستند- رخ داده­اند.

پذیرش اعتبار نظریه “ضرایب متغیر هزینه­ Barry Boehm”مبنی بر اینکه هزینه تغییرات در طول چرخه حیات پروژه ثابت نبوده و افزایش می­یابد، بدین معناست که پرسش اصلی، چگونگی مدیریت تغییرات ناخواسته در پروژه است و نه چگونگی جلوگیری از بروز آنها.

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

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

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

[۱] Plan

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

این موضوع، عنوان مقاله‏ای از مارتین فاولر به سال ۲۰۰۴ است. مشغول بررسی مطلبی بودم که آن را مجدداً خواندم. در اصل این مقاله همان طور که خود فاولر ذکر کرده، به بررسی نقدی که به روس اکس-پی وارد شده پرداخته است. هر چند که این بررسی بسیار آموزنده و مفید است، اما بخش اول آن که بررسی دو روش طراحی برنامه‏ریزی شده و طراحی تکاملی می‏پردازد، نکات ظریفی را بیان داشته که هر روز با آن مواجه هستیم و حتی هر یک از ما برای دوری از آن، روشهایی نیز به تجربه برای خود تبیین کرده‏ایم. به لحاظ اهمیت این نکات، بخش اول مقاله را به همان صورت در زیر آورده و آدرس مقاله را نیز در ادامه ذکر کرده‏ام.

Planned and Evolutionary Design

For this paper I’m going to describe two styles how design is done in software development. Perhaps the most common is evolutionary design. Essentially evolutionary design means that the design of the system grows as the system is implemented. Design is part of the programming processes and as the program evolves the design changes.

In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the “code and fix” nightmare, where the bugs become exponentially more expensive to fix as the project goes on.

Planned Design is a counter to this, and contains a notion born from other branches of engineering. If you want to build a doghouse, you can just get some wood together and get a rough shape. However if you want to build a skyscraper, you can’t work that way – it’ll just collapse before you even get half way up. So you begin with engineering drawings, done in an engineering office like the one my wife works at in downtown Boston. As she does the design she figures out all the issues, partly by mathematical analysis, but mostly by using building codes. Building codes are rules about how you design structures based on experience of what works (and some underlying math). Once the design is done, then her engineering company can hand the design off to another company that builds it.

Planned design in software should work the same way. Designers think out the big issues in advance. They don’t need to write code because they aren’t building the software, they are designing it. So they can use a design technique like the UML that gets away from some of the details of programming and allows the designers to work at a more abstract level. Once the design is done they can hand it off to a separate group (or even a separate company) to build. Since the designers are thinking on a larger scale, they can avoid the series of tactical decisions that lead to software entropy. The programmers can follow the direction of the design and, providing they follow the design, have a well built system

Now the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it’s impossible to think through all the issues that you need to deal with when you are programming. So it’s inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn’t gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There’s usually a quicker fix and time pressure. Hence entropy (again).

Furthermore there’s often a cultural problem. Designers are made designers due to skill and experience, but they are so busy working on designs they don’t get much time to code any more. However the tools and materials of software development change at a rapid rate. When you no longer code not just can you miss out on changes that occur with this technological flux, you also lose the respect of those who do code.

This tension between builders and designers happens in building too, but it’s more intense in software. It’s intense because there is a key difference. In building there is a clearer division in skills between those who design and those who build, but in software that’s less the case. Any programmer working in high design environments needs to be very skilled. Skilled enough to question the designer’s designs, especially when the designer is less knowledgeable about the day to day realities of the development platform.

Now these issues could be fixed. Maybe we can deal with the human tension. Maybe we can get designers skillful enough to deal with most issues and have a process disciplined enough to change the drawings. There’s still another problem: changing requirements. Changing requirements are the number one big issue that causes headaches in software projects that I run into.

One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won’t help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard.

Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can’t be prevented, however careful your requirements engineering process.

So all this makes planned design sound impossible. Certainly they are big challenges. But I’m not inclined to claim that planned design is worse than evolutionary design as it is most commonly practiced in a “code and fix” manner. Indeed I prefer planned design to “code and fix”. However I’m aware of the problems of planned design and am seeking a new direction.

آدرس مقاله:

http://martinfowler.com/articles/designDead.html

گزیده:

She said that she usually cried at least once each day not because she was sad but because the world was so beautiful and life was so short.
Brian Andreas – Reference: Booch Blog