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

به گزارش ایتنا، این فرد که منیش ستی نام دارد، با انتشار یک آگهی استخدام، گفته به فردی نیاز دارد که کنار دستش بنشیند و هر وقت وارد فیس‌بوک شد، یک سیلی نثار او کند! بر این اساس، تنها وظیفه و کار این فرد فقط سیلی زدن خواهد بود. آقای ستی گفته به ازای این کار، هشت دلار در ساعت حقوق می‌دهد! این برنامه‌نویس بی‌اراده گفته وقتی می‌بیند در هفته ۱۹ ساعت را به شبکه‌های اجتماعی اختصاص می‌دهد و زمان کاری‌اش را تلف می‌کند، خجالت می‌کشد. مشخص نیست آیا کسی حاضر است برای چنین کاری استخدام شود یا خیر و آیا اصولا این شیوه می‌تواند آقای ستی را از وبگردی بی‌هدف نجات دهد یا او باید روش‌های دیگری را امتحان کند.»

مرجع: دنیای اقتصاد

گزیده:
«نتیجه ارادهٔ ضعیف حرف است و نتیجهٔ اراده قوی، عمل.» گوستاو لوبن

متن زیر بخش اول ترجمه مقاله Embracing Change with Extreme Programming نوشته Kent Beck است در IEEE Software در سال 1999 منتشر شده است.
این مقاله توسط دوست گرامی جناب آقای مهندس مهدی نگاهی ترجمه شده است.

————————————————————————————————-

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

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

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

چرخه‌های بلندمدت توسعه خوب نبودند چرا که نتوانستند خود را با تغییرات سازگار کنند. این موضوع شاید بدین معناست که آن چه نیاز داشتیم ایجاد چرخه‌های کوتاه‌تر بود. بنابراین همان طور که شکل 2 نیز نشان می‌دهد مدل آبشاری عامل ایجاد تکرارها^۱ بوده است.

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

جامعه دانشگاهی مهندسین نرم‌افزار که هزینه زیاد تغییر نرم‌افزار را به عنوان یک چالش معرفی کرده است، تکنولوژی‌هایی نظیر پایگاه داده‌ رابطه‌ای، برنامه‌نویسی ماژولار^۲ و مخفی‌سازی اطلاعات را ایجاد کرده‌ است. چه می‌شد اگر این تلاش‌های دشوار نتیجه می‌داد؟ چه می‌شد که ما در کاهش هزینه‌ تغییرات مداوم، خوب عمل می‌کردیم؟ چه می‌شد که مجبور نبودیم برای تسویه‌حساب با ساطور به جان مدل آبشاری بیفتیم؟ چه می‌شد اگر می‌توانستیم مدل آبشاری را در مخلوط‌کن بریزیم [و با هر چیز دیگری مخلوط کنیم]؟

تصویر 1: تکامل مدل آبشاری (a) و چرخه طولانی آن (تحلیل، طراحی، پیاده‌سازی و آزمایش) به مدل کوتاه‌تر با چرخه‌های تکرارشونده به عنوان مثال مدل حلزونی^۳(b) و از آنجا به XP (c) با ترکیب فعالیت‌ها و انجام مقدار کمی از آنها در هر بار ولی مدوام در طول فرایند توسعه نرم افزار

اقدامات^۴ XP
در زیر توضیح مختصری در مورد اقدامات مهم XP آورده شده است.
1- بازی برنامه‌ریزی(Planning Game)
مشتریان محدوده و زمان‌بندی انتشار^۵ را بر اساس برآورد برنامه‌نویسان تعیین می‌کنند و برنامه‌نویسان فقط کارکردهای درخواست‌شده در استوری^۶‌ها را در تکرار جاری پیاده‌سازی می‌کنند.

2- انتشارهای کوچک(Small Releases)
سیستم طی چند ماه –کوتاه‌ترین زمان ممکن- و قبل از حل کل مسأله برای استفاده آماده و راه‌اندازی می‌شود. انتشارهای جدید به کرات در بازه‌های روزانه تا ماهانه ساخته و منتشر می‌شوند.

3- استعاره (Metaphor)
چارچوب سیستم با استفاده از استعاره یا مجموعه‌ای از استعاره‌ها که بین مشتری و برنامه‌نویسان به اشتراک گذاشته شده، تعریف می‌شود.

4- طراحی ساده(Simple Design)
در هر لحظه، طراحی همه آزمونها را پشت سر می‌گذارد، هر آن چه که برنامه‌نویسان نیاز دارند، در اختیارشان قرار می‌دهد و کد تکراری در آن وجود ندارد و حاوی کمترین تعداد کلاس و متد است. خلاصه این قاعده این است: “هر چیزی را یک بار و فقط یک بار بیان کنید.”

5- آزمایش‌ها(Tests)
برنامه‌نویسان لحظه به لحظه آزمونهای واحد^۷ می‌نویسند که باید تجمیع و به درستی اجرا شوند. در هر تکرار، مشتریان آزمونهای کارکردی^۸ را برای استوری‌ها می‌نویسند که اجرای آنها نیز ضروری است. اجرای آزمونها در پایان تکرار منجر به شناسایی ایرادهای محصول می‌شود. در چنین شرایطی نیاز به تصمیم‌گیری سازمانی است تا از بین تحویل محصول با ایرادهای شناسایی‌شده یا قبول دیرکرد انتشار محصول پس از رفع ایرادها، یکی انتخاب شود.

6- بازسازی(Refactoring)
طراحی سیستم با تغییر طراحی موجود که همه آزمونها را پشت‌سر گذاشته، تکامل می‌یابد.

7- برنامه‌نویسی دو نفره(Pair Programming)
همه کد برنامه به صورت دو نفره با یک نمایشگر، صفحه کلید و موشواره -یک دستگاه- نوشته می‌شود.

8- یکپارچه‌سازی مداوم(Continuous Integration)
کد جدید حداکثر بعد از چند ساعت با سیستم موجود یکپارچه می‌شود. پس از آن، سیستم دوباره ساخته^۹ و همه آزمونها اجرا می‌شود، در صورت نامؤفق بودن آزمایش، کد جدید رد می‌شود.

9- مالکیت جمعی(Collective Ownership)
در صورت امکان بهبود، هر برنامه‌نویس موظف است هر کدی را در هر جایی از سیستم و در هر زمانی اصلاح کرده و بهبود بخشد.

10- مشتری مقیم(On-Site Customer)
مشتری به صورت تمام وقت در کنار تیم تولید است.

11- کارهفتگی 40 ساعته(40-hour Weeks)
هیچ کس نمی‌تواند دو هفته متوالی اضافه‌کاری داشته باشد. حتی اضافه‌کاری غیرمتوالی بیش از حد، نشانه وجود مشکلی عمیق است که نیاز به شناسایی و رسیدگی دارد.

12- محیط کار باز(Open Workspace)
اعضای تیم در یک سالن بزرگ کار می‌کنند که دور تا دور آن دارای پارتیشن‌های کوچک است. برنامه‌نویسی دونفره بر روی کامیپوترهایی انجام می‌شود که در وسط سالن قرار دارند.

13- فقط قواعد(Just Rules)
به عنوان بخشی از تیم XP متعهد به اجرای قواعد هستید. اما به یاد داشته باشید که اینها فقط یک سری قاعده‌اند. اعضای تیم می‌توانند قواعد را در هر زمانی تغییر دهند به شرطی که بر سر روش ارزیابی تغییرات ناشی از آنها توافق داشته باشند.

[۱] Iterations
[۲] Modular Programming
[۳] Spiral Model
[۴] Practices
[۵] Release
[۶] Story
[۷] Unit test
[۸] Functional tests
[۹] Build

گزیده:

Testing is not the point. The point is about responsibility. Kent Beck

ضمن تشکر از دوست گرامی جناب آقای مهندس امیرجلیلی‌فرد، ترجمه مقاله Agile Software Development: The Business of Innovation را می‌توانید از اینجا دریافت فرمایید.

گزیده:
فیلم‌سازان باید به این نیز بیندیشند که فیلم‌هایشان را در روز رستاخیز با حضور خودشان نمایش خواهند داد. چارلی چاپلین

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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش سوم و آخر
اقدامات چابک(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 نیز بر تعامل اعضای تیم تأکید دارد.
به‌کارگیری متدهای چابک نیازمند مشارکت زیاد مشتریان است. چنانچه مشتریان‌ اعم از نمایندگان واحدهای داخلی یا مدیران محصول واحد بازاریابی، برداشت درستی از مسیر محصول نداشته و بین الگو‌های ناشناخته سرگردان باشند، توسعه‌دهندگان چابک ناچارند از آنها پیروی کنند (و البته با تذکر و راهنمایی‌های موردی) و شکی نیست که پیامد مشتریان ضعیف، سیستم‌های ضعیف خواهد بود.

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

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

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

*** www.Dilbert.com

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

داشتم فیلمی تماشا می‌کردم. زنی مبتلا به بیماری سرطان دستگاه تنفسی، می‌خواست مدارکی را امضاء کند تا به پزشکان اجازه دهد که به زندگی وی پایان دهند.
تنها پرسش بیمار این بود: بعد از تزریق دارو، چقدر طول می‌کشد تا …؟
یکی از پزشکان تلاش می‌کرد تا وی را منصرف کند. راههایی پیشنهاد می‌کرد که همه آنها با درد و رنج همراه بودند و فقط چند صباحی وی را قادر به ادامه زندگی می‌کردند.
بیمار می‌گفت: حتی اگر همین حالا درمانی برای این بیماری پیدا شود، دیگر به من کمکی نخواهد کرد.
بیمار به ناگاه رو به پزشک گفت: تو چرا این قدر از این که من بمیرم می‌ترسی؟ چرا نمی‌خواهی من بمیرم؟ مرگ برای من ترسناک نیست! چرا به من امید می‌دهی؟
و ادامه داد: گاهی امید از مرگ ترسناک‌تر است، وقتی که دست‌نیافتنی باشد!

از لحظه شنیدن این گفت‌وگو (دیالوگ)، بخشی از ذهنم درگیر پردازش و فهم آن شده است و هنوز هم مشغول است.
حالا فهمیده‌ام که چرا ….

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

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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش دوم
پاسخ متدهای چابک
متدهای چابک پاسخی به این انتظار بازار هستند. استراتژی متدهای چابک، کاهش هزینه تغییرات در طول پروژه است. برای مثال 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]انجام دهید. متدهای چابک قواعد زاینده را پیشنهاد می­‌کنند -مجموعه­‌ای کمینه­ از کارهایی که باید در هر موقعیتی انجام ­شوند تا با استفاده از آنها، اقدامات مناسب موقعیت‌های جدید و خاص خلق شود. تیم­‌هایی که پیروی قواعد جامع و فراگیر هستند، به فرد دیگری وابسته­‌اند تا پیشاپیش اقدامات را برای موقعیتهای جدید تعیین کند. روشن است که این شیوه خیلی زود شکست می­‌خورد. اما تیمی که پیروی قواعد زاینده است، به محض بروز مسائل، به افراد و خلاقیت آنها برای یافتن راه‌حل‌ها وابسته است. خلاقیت تنها راه مدیریت مشکلات پیچیده توسعه نرم­‌افزار و موقعیت­‌های گوناگون آن است و نه انبوه قواعد مکتوب.

[1]Delivery
[2] Test
[3] Effectiveness
[4] Sponser
[5] Up-front
[6] Situation

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

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

توسعه نرم افزار چابک: کسب و کار نوآوری – بخش دوم
پاسخ متدهای چابک
متدهای چابک پاسخی به این انتظار بازار هستند. استراتژی متدهای چابک، کاهش هزینه تغییرات در طول پروژه است. برای مثال 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]انجام دهید. متدهای چابک قواعد زاینده را پیشنهاد می­‌کنند -مجموعه­‌ای کمینه­ از کارهایی که باید در هر موقعیتی انجام ­شوند تا با استفاده از آنها، اقدامات مناسب موقعیت‌های جدید و خاص خلق شود. تیم­‌هایی که پیروی قواعد جامع و فراگیر هستند، به فرد دیگری وابسته­‌اند تا پیشاپیش اقدامات را برای موقعیتهای جدید تعیین کند. روشن است که این شیوه خیلی زود شکست می­‌خورد. اما تیمی که پیروی قواعد زاینده است، به محض بروز مسائل، به افراد و خلاقیت آنها برای یافتن راه‌حل‌ها وابسته است. خلاقیت تنها راه مدیریت مشکلات پیچیده توسعه نرم­‌افزار و موقعیت­‌های گوناگون آن است و نه انبوه قواعد مکتوب.

[1]Delivery
[2] Test
[3] Effectiveness
[4] Sponser
[5] Up-front
[6] Situation

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