ضمن تشکر از دوست گرامی جناب آقای مهندس امیرجلیلیفرد، ترجمه مقاله 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
گزیده:
«امید غریزهای است که تنها ذهن استدلالی و معقول بشر میتواند آن را از بین ببرد.»
گراهام گرین
وقتی خاطره زیر به قلم مهندس علی عبداللهی را خواندم، خیلی تحت تأثیر قرار گرفتم:
“بعد از بیدارباش نماز صبح، همه بچهها کلههایمان را از پنجره بیرون برده بودیم و برف را تماشا میکردیم و خیلی شادی میکردیم چرا که مطمئن بودیم توی این برف سنگین خیلی از دبیران ما نخواهند توانست از فومن و یا رشت بیایند و این در دنیای دانش آموزی یعنی یک روز خوب و به یاد ماندنی.
جاده فومن – گشت را خوب ورانداز میکردیم که آیا هیچ موجود زندهیی در حال عبور و مرور است یا نه. هر علامتی دال بر باز بودن راه، ناامیدکننده بود.
خدا را شکر، هیچ ماشینی نه میآمد و نه میرفت.
کمی دورتر یک نفر با زحمت خودش را به سمت گشت میرساند.
پیش گفتار
در راستای تولید محتوای فارسی برای موضوعات مورد علاقه و باارزش، مطالب برگزیده پس از ترجمه توسط چند تن از عزیزان، از طریق وبلاگ در اختیار خوانندگان قرار خواهد گرفت. با وجود همه کمبودها، امیدوارم که این کار اثرگذار و مفید باشد.
مقاله نخست توسط دوست گرامی جناب آقای مهندس امیر جلیلیفرد ترجمه شده است.
مقدمه
مقاله Agile Software Development: The Business of Innovation نوشته Jim Highsmith و Alistair Cockburn دو تن از امضاءکنندگان بیانیه چابک(Agile Manifest) است. این مقاله در سپتامبر سال 2001 یعنی حدود هفت ماه پس از امضای بیانیه در مجله IEEE Computer چاپ شده است.
این مقاله شامل بخشهای زیر است:
+ مسأله
+ پاسخ متدهای چابک
++ اصول بنیادی
+ بیانیه نرمافزار چابک
+ قواعد زاینده
+ اقدامات چابک
++ برنامهریزی ویژگی و اولویتبندی پویا
++ بازخورد و تغیییر
++ تأکید بر کارتیمی
توسعه نرم افزار چابک: کسب و کار نوآوری
ظهور و سقوط اقتصاد اینترنتی مبتنی بر شرکتهای داتکام نباید ما را از این واقعیت غافل کند که محیط کسبوکار با سرعت فوقالعاده و فزایندهای به تغییر ادامه میدهد. برای پیشرفت در این محیط پرتلاطم، ناچاریم با انتظارات کسبوکار شامل نوآوری بیوقفه و ایجاد فرهنگ نوین کاری روبرو شویم.
رویکردهای چابک از جمله XP ،Crystal، Lean Development، Scrum و ASD از دریچهای به تغییر مینگرند که نشانگر آشفتگی محیط کسبوکار و تکنولوژی کنونی است.
مسئله
به تازگی در تحقیقی که Michael Mah در QSM Associates بر روی بیش از 200 پروژه توسعه نرم افزار
انجام داده، گزارش داده است محققان قادر به یافتن تقریباً نیمی از طرحهای[1] اولیه پروژهها برای مقایسه با یکدیگر نشدند. چرا ؟ زیرا هدف اصلی، اجرای پروژه مطابق با طرح اولیه نبوده و به جای آن، راضی نگهداشتن مشتری -در هنگام تحویل پروژه و نه در آغاز آن– اولویت پیدا کرده است.
همچنین در اغلب پروژههای بازبینیشده مشاهده کردیم که تغییرات مهم در نیازمندیها، محدوده و تکنولوژی -که خارج از کنترل تیم توسعه هستند- رخ دادهاند.
پذیرش اعتبار نظریه “ضرایب متغیر هزینه Barry Boehm”مبنی بر اینکه هزینه تغییرات در طول چرخه حیات پروژه ثابت نبوده و افزایش مییابد، بدین معناست که پرسش اصلی، چگونگی مدیریت تغییرات ناخواسته در پروژه است و نه چگونگی جلوگیری از بروز آنها.
روشهای رایج فرض میکنند فقط با تلاش بیشتر میتوان مجموعه کاملی از نیازمندیها را در اسرع وقت شناسایی و پیشبینی کرد و از این رو هزینهها را با جلوگیری از ایجاد تغییرات کاهش داد. امروزه نپذیرفتن و انجام ندادن سریع تغییرات به معنی بی توجهی به شرایط و موفقیت کسبوکار است.
روشهای رایج مدیریت فرایندها نیز با اندازهگیریهای مستمر، شناسایی خطاها و بهبود فرایند میکوشند تا تغییرات را در جایی خارج از فرایندها مدیریت کنند. این روشها فرض میکنند خطاها عامل تغییرات هستند. هر چند برخی خطاها ناشی از مشکلات فرایندها هستند اما واقعیت این است که عامل ایجاد تغییرات اساسی، تغییرات محیطیاند. از آنجایی که قادر به حذف تغییرات محیطی نیستیم، کاهش هزینه انجام آنها، تنها استراتژی بادوام و درازمدت است. به عبارت دیگر، استراتژی جدید به جای حذف دوباره کاری(بازکاری)، سعی در کاهش هزینه آن دارد.
در هر صورت، نه تنها در پذیرش تغییرات، بلکه در انجام آنها نیز باید به فکر حفظ کیفیت باشیم. انتظارات در طول سالها افزایش یافته است. بازار متقاضی و منتظر نرمافزارهای نوآورانه با کیفیت عالی برای رفع نیازهایش است و البته آنها را خیلی زود میخواهد.
گزیده:
لازم نيست آدم از كوهي بالا رود تا بفهمد بلند است. پائولو كوئيلو
مرجع: اس.جی.
