مترجم: سهراب آروین
نرمافزارسازی «چابک» (Agile) چتری است که چندین متدولوژی تکراری (Iterative) و افزایشی (Incremental) تولید نرمافزار را زیر سایه خود جای میدهد: Extreme Programming (XP)، Scrum، Crystal، Dynamic System Development Model (DSDM)، Lean Development و Feature Driven Development (FDD).
متدولوژیهای چابک، بر خلاف متدولوژیهای سنتی، تلاش تمام دستاندرکاران پروژه را (از مدیر پروژه و مشتری گرفته تا برنامهنویس و تستکننده) بر تولید و ارایه «نرمافزار بهدردخور و تستشده» متمرکز میکند. در متدولوژی چابک تمام امور تولید نرمافزار (برنامهریزی، تحلیل و طراحی، برنامهنویسی، یکپارچهسازی و تست) در «تکرار»های کوتاه و متناوبی گنجانده میشود، به طوری که هر تکرار بتواند بیشترین خدمت را به تکرار بعدی ارایه کند. با وجود تمام مزایای رویکرد چابک، توجه اندک این سبک به مستندسازی رسمی، افسانههای نادرستی را در مورد آن رواج داده است.
متدولوژی نرمافزارسازی چابک در چند سال اخیر راه خود را به جریان تولید نرمافزار گشوده است. همگام با شتاب گرفتن چرخه کسبوکار و افزایش فشار رقابت، بیشتر شرکتهای تولیدکننده نرمافزار برای سرعت بخشیدن به زمان عرضه محصول، تطابق با نیازهای متغیر کسبوکارها، همسو کردن اهداف فناوری و کسبوکار و ایجاد مزیت رقابتی، به متدولوژیهای چابک روی آوردهاند.
هر چرخش مهم در این صنعت همراه با ترس، شک و بیاطمینانی است و قوت گرفتن نرمافزارسازی چابک نیز از این قاعده مستثنا نیست؛ چرا که تفاوتی اساسی در برنامهریزی، ساخت و تحویل نرمافزار ایجاد کرده است. با این حال، هرچه زمان پیشتر میرود و پروژههای بیشتری با این روش موفقیت کسب میکنند، جامعه نرمافزارسازان برای آشنایی با این رویکرد فرصت و جرات بیشتری مییابند. از سوی دیگر، در همین راستا، ماهیت رویکرد چابک نیز دچار ابهام بیشتری میشود. بر اساس تجربهای که از صدها پروژهای که طبق این رویکرد در شرکتهای فورچون 100 (Fortune) اجرا شده کسب کردهام، میتوانم به دقت بگویم که «چابک» چه هست و چه نیست. بنابراین این جا قصد دارم به پنج افسانه نادرستی را بیان کنم بپردازم که حول و حوش این گونه متدولوژیها شکل گرفته است.
افسانه 1 - متدولوژی چابک بیانضباط است
برخی رویکرد چابک را نوعی هک کردن و برخی دیگر آن را «اول کد کن، بعد درستش کن» میدانند. هر کسی که در یک پروژه چابک شرکت کرده باشد میداند که یکپارچگی مستمر، برنامهنویسی آزمونگرا، بازساخت (Refactoring) و حتی جفتبرنامهنویسیِ (Pair Programming) جنجالی، هیچ کدام به معنی بیانضباطی در ساخت نرمافزار نیست. ؛ بلکه درست برعکس، معادل ساخت و عرضه نرمافزاری تستشده و مورد پذیرش صنعت نرمافزار در چرخههای کوتاه کاری است که دست بر قضا به انضباط بالایی نیز نیاز دارد.
بسیاری از رویههای تعریف شده در متدولوژیهای چابک برای موفقیت پروژه نه تنها به انضباطی انفرادی، بلکه به تعهدی جمعی بستگی تام دارد. نفعرسانی تیمها به سازمان و دریافت ارزش از آنها نه در چرخههای سالانه، بلکه طی ماه یا هفته انجام میشود. نکته جالب این که بسیاری از شیوههایی که در چابک مورد استفاده قرار میگیرد، چند دهه قدمت دارند. مساله این است که تنها چند سالی است که تمام این شیوهها به صورت مجموعه اصولی واحد و هماهنگ گردآوری شده است. با شکلگیری متدولوژیهای چابک انضباط تیمی در اعضای اجرایی و مدیریتی افزایش یافته است و حتی میتوان گفت که هرچه تیم چابکتر باشد، نیاز بیشتری به انضباط دارد.
افسانه 2 - تیم چابک برنامهریزی نمیکند
این سوتفاهم به طور عمده از درک نادرست روش برنامهریزی تکراری چابک نشات میگیرد. تیمهای چابک نیز به اندازه سایر تیمها زمان صرف برنامهریزی میکنند. تفاوت در این است که در روش چابک، نه تنها در ابتدای آن بلکه در سراسر طول پروژه گسترده شده است. در اصل، شیوه تکراری و افزایشی چابک شامل برنامهریزی پروژه نیز میشود.
اگر به برنامهریزیهای تفصیلی و وظیفهمحور پروژههای سنتی نگاهی دقیقتر بیاندازیم، متوجه میشویم که این نوع برنامهها خیلی زود از واقعیتهای فنی و کاری فاصله میگیرند و هر چه از ابتدای پروژه میگذرد، انرژی بیشتری برای همگرایی آنها لازم میشود. در صورتی که شیوه چابک این تغییر سریع را میپذیرد و برنامهریزی مستمر را جایگزین برنامهریزی تفصیلی اولیه به صورت انتشار فصلی، تکرار ماهانه و یا هفتگی میکند.
افسانه 3 - نرمافزارسازی چابک قابل پیشبینی نیست
از دیدگاه برنامهریزی، روشهای چابک برای سنجش و پیشبینی، رویکردی کاملا متفاوت با روشهای سنتی ترویج میکنند. رویکرد سنتی برنامهریزیِ تفصیلی، گمانهزن و مبتنی بر وظایف را به کار میگیرد و بر اساس آن میزان پیشرفت، انحراف از برنامه و پیشبینی دقیق نتایج را محاسبه میکند. اما برنامهای که بدین طریق تهیه میشود تنها «حسی از پیشبینیپذیری» ایجاد میکند. به هر حال طی چند دهه تولید نرمافزار، ناکارآمدی چنین پیشبینیهایی مشخص شده است.
در عوض، رویکرد چابک برنامهریزی سطح بالا و ویژگیمحوری را به کار میگیرد که با ماهیت ذاتا پیچیده پروژههای تولید نرمافزار سازگار است. در این نوع برنامهریزی جزییات با پیشرفت پروژه و مشخص شدن مشخصات تفصیلی آن به مرور اضافه شده و منجر به بازبرنامهریزی مداوم و تکراری میشود. تکمیل برنامهریزی با استفاده از اطلاعات تاریخی پروژه باعث بهبود مستمر آن میشود. با جایگزین شدن حقایق مبتنی بر گمانهزنی با واقعیتهای تاریخی پروژه، اعضای تیم میتوانند پیشبینی دقیقتری از آن چه باید در طول پروژه تولید و ارایه شود داشته باشند. تیمهای چابک به جای نمودارهای گانت (Gantt) و پرت (PERT) از نمودارهای سادهتری مانند «نمودار سرعت» (Velocity) و «نمودار خاکستر شدن تمامسوختن» (Burndown) بهره میبرند.
چنان چه در شکل روبهرو نیز (که نمونهای است از نرمافزاری مدیریت پروژه چابک شرکت VersionOne) پیدا است، اندازهگیری «نمودار سرعت» بر نقاط روایت و روزها یا ساعتهای ایدهآل استوار است و حجم ویژگیهایی را نشان میدهد که تیم میتواند در هر تکرار عرضه کند. «سرعت» یک تیم در طول زمان تثبیت و به پیشبینیپذیری مناسبی منجر میشود. از سوی دیگر، نمودار «تمامسوختن خاکستر شدن» در همین شکل، حجم کار باقیمانده نسبت به روزهای باقیمانده از هر تکرار و از کل پروژه و هر تکرار را نشان میدهد. در صورتی که شیب این دو عامل نزدیک به هم نباشد، تمام اعضای پروژه از این عقبماندگی مطلع میشود. بدین ترتیب، تیم نه تنها میتواند عکسالعمل متناسب نشان دهد، بلکه میتواند حجم کار تکرار بعدی را هم به میزان لازم تعدیل خواهد کردکند.
تیمهای چابک، به جای برنامهریزی سالانه برای باقیمانده پروژه، به طور مستمر برنامهریزی، تخمین و اولویتبندی میکنند. از این راه، اعضای تیم قدرت برنامهریزیشان بهبود مییابد و مضاف بر آن اطمینان بیشتری نیز از قابلیتهای خود در تامین اهداف ذینفعان پیدا میکنند، که خود در نهایت منجر به ایجاد اعتماد بیشتری در کل سازمان تولید نرمافزار میشود.
افسانه 4 - نرمافزارسازی چابک اندازهپذیر نیست
به عنوان یک اصل کلی، تولید نرمافزار ذاتا دارای محدودیت اندازهپذیری (Scalability) است و شواهد بسیاری حاکی از آن است که این امر خاص متدولوژی تولید نیست. هر چه پروژه بزرگتر باشد، احتمال شکستش هم بیشتر است و هر چه تعداد افراد دخیل در آن بیشتر باشد، پیچیدگی و مخاطره عدم ارتباط صحیح درست نیز بزرگتر است. رویکرد چابک با پذیرش این حقایق، پروژههای کوچکتر، تکرارهای کوتاهتر و تیمهای کوچکتری را پیشنهاد میکند. بارها و بارها ثابت شده است که بهرهوری تیمهای کوچک به مراتب از تیمهای بزرگ بیشتر است.
البته این بدین معنی نیست که سازمانها نباید به حل مشکلات بزرگ بپردازند. بلکه رویکرد چابک ادعا میکند که برای حل مسایل مشابه راهحلهای متفاوتی وجود دارد. گرایش رویکرد چابک این است که باید پروژههای بزرگ را به چندین مساله کوچکترِ هماهنگشده تقسیم کرد، به طوری که بتوان با تیمهای کوچک و زمانهای کوتاهتر انجامشان داد تقسیم کرد. حاصل کار هر تیم در انتهای هر تکرار یکپارچه میشود، تا از سازگاری فنی و کارکردیشان اطمینان حاصل شود.
طی یک دهه گذشته پروژههای چابک بسیاری که صدها نفر در قالب چندین تیم مرتبط و مستقر در نقاط جغرافیایی دور از هم را گرد هم آورده و با موفقیت انجام شدهاند، کفایت و توانایی این رویکرد را به اثبات رساندهاند. در واقع اگر سازمانی نیاز به حل یک مساله بسیار بزرگ و پیچیده نرمافزاری داشته باشد، دلایل متعددی مبین آن است که با روی آوردن به یک روش چابک میتواند مخاطرات را سریعتر آشکار کند، ارزش تجاری آن را زودتر نشان دهد و به سرعت رویکردی منضبط نسبت به تولید و تست نرمافزار اتخاذ کند.
افسانه 5 - نرمافزارسازی چابک هم یک مد زودگذر است
تحلیلگر کسبوکار یک پروژه چابک هم درست مانند یک مدیر پروژه چابک بیشتر روی مهارتهای تسهیل و هماهنگی افراد تکیه میکند. نقش یک تحلیلگر کسبوکار چابک تسهیل گفتگوی بین سفارشدهنده محصول و تیم فنی است. تحلیلگر کسبوکار، دانش سیستمی بسیاری را برای استخراج مشخصات محصول از درخواستهای سفارشدهنده آن به کار میگیرد و نقش مترجم این مشخصات به زبان فنی مورد نیاز تیم تولید نرمافزار را به عهده دارد. این مشخصه در کنار دیگر مزایای رویکرد چابک آن را به شیوهای عملی و نه صرفا یک مد زودگذر تبدیل کرده است.
مدهای زودگذر عموما با هیاهوی بسیار در مورد چیزهایی با ارزش ذاتی اندک همراه هستند. این در حالی است که رویکرد چابک طی کمتر از ده سال به اصلیترین روش تولید نرمافزار در بسیاری از شرکتهای تولیدکننده نرمافزار تبدیل شده است و بسیاری، ( از هر دو طیف خیالپروران و عملگرایانِ این صنعت) نیز آن را پذیرفته و ارتقا دادند. گرچه تا پنج یا شش سال پیش این رویکرد بیشتر در تیمهای کوچک و هممکان پذیرفته شده بود، اما اکنون رویکرد چابک در بسیاری از شرکتها و سازمانهای بزرگ و توزیعشده فناوری اطلاعات نیز به همان گستردگی به کار گرفته میشود.
پژوهشی از موسسه فوررستر (Forrester) نشان میدهد که موج دوم پذیرش رویکرد چابک در شرکتها و سازمانهای بزرگ در راه است. طبق نتایج این پژوهش، در حال حاضر 14 درصد شرکتهای تولیدکننده نرمافزار در اروپا و آمریکای شمالی این روش را به کار میگیرند و حدود 19 درصد نیز در حال پیادهسازی آن یا برنامهریزی برای پذیرش آن هستند. این شرکتها دریافتهاند که با استفاده از این روش تولید میتوانند فاصله زمانی تولید تا عرضه به بازار (Ttime-to-Mmarket) را کاهش دهند، کیفیت را بهبود بخشند و روابطشان را با ذینفعان بازار مستحکمتر کنند.
مطابق با تحقیق دیگری که توسط شرکت VersionOne از مشتریان خود صورت گرفته است و تا حدود زیادی با تحقیق موسسه فوررستر همسویی دارد، سه دلیل عمده انتقال از رویکرد سنتی تولید نرمافزار به رویکرد چابک عبارت است از: 1) سرعت بخشیدن به عرضه نرمافزار؛ 2) همسو کردن نیازهای کسبوکار و بازار با نیازهای فناوری اطلاعات؛ و 3) بهبود شفافیت فرآیند تولید نرمافزار. این عوامل نمیتوانند مربوط به یک مد زودگذر باشند، بلکه معیارهایی بر اساس نیازهای واقعی کسبوکار هستند.
خلاصه
در نهایت، این سازمان متولی فناوری اطلاعات است که باید رویکرد چابک را ارزیابی کند و به این نتیجه برسد که آیا باید آن را به کار گیرد یا خیر. حتی اگر تیمی به این نتیجه برسد که رویکرد چابک در محیط عملیاتیاش کاربردی ندارد، باید بر اساس حقایق به این نتیجه برسد، نه بر پایه افسانههایی که در این مقاله به آنها پرداختیم. در این راه، بر هر متخصصی لازم فرض است که منافع، مخاطرات و بدهبستانهای ناظر بر رویکرد چابک را خود بسنجد.
در مواجهه با هر شیوه جدیدی، همیشه ترسی از ناشناختهها وجود دارد. خوشبختانه در این راه پیشروان صنعت نرمافزار خطشکن بودهاند و در یک دهه اخیر مشکلات بسیاری را حل کردهاند و موانع بسیاری را از سر راه برداشتهاند. این پیشاهنگان در تمام فعالیتهای چابکشان، از نرمافزارسازی آزمونگرا و یکپارچهسازی پیوسته گرفته تا برنامهریزی انتشار و گزارشدهیهای روزانه، انضباط کاملی را اعمال کردهاند. تیمهای چابکی که چنین انضباطی را رعایت نکردهاند، تنها پوستهای از رویکرد چابک را روی کارهایشان کشیدهاند.
برای کارشناسانی که سالها در صنعت نرمافزار بودهاند، رویکرد چابک چیزی نیست مگر بستهبندی فرآیندها و شیوههای مهندسی و مدیریت پروژههای نرمافزاریای که چندین دهه مورد استفاده بودهاند. مزیت تکاملیِ کلیدی این رویکرد در عرضه فرآیندها و شیوههایی است که به گونهای طراحی شدهاند که هم با محیط بهشدت متغیر پروژههای نرمافزاری امروز تطابق پیدا کرده کنند و هم بر آن تاثیر مثبت بگذارند.
بهکارگیری روزافزون رویکرد چابک در شرکتها و سازمانهای بزرگ فناوری اطلاعات، این نکته را محرز میکند که این شیوه تنها به کار تیمهای کوچک و مستقر در مکانی واحد نمیآید، بلکه ابزار مناسبی برای پروژههای بزرگ نرمافزاری نیز هست و در کل باعث شفافیت، بهرهوری، ایجاد ارزش و کیفیت بیشتر و در کل، موجب کاهش کلی مخاطرات ناظر بر این پروژهها است. چیزی که این روزها از تیمهایی که به رویکرد چابک روی آوردهاند میشنویم این است که بازگشت به روشهای قدیمی تولید نرمافزار، حتی در تصورشان هم نمیگنجد!
| < قبلی | بعدی > |
|---|