فرآیند خلق نرم افزار  به طور کلی یا به واسطه یک ایده جدید آغاز می گردد یا برای حل یک مشکل؛ در طی این مسیر می بایست یک متدولوژی یا چارچوب به کار گرفته شود تا ضامن کیفیت محصول نهایی باشد. همه ما عمدتا با متدولوژی های سنتی مثل آبشاری (Waterfall) آشنایی داریم و شاید چند وقتی هم باشد با متدولوژی نسبتا جدیدتری نظیر چابک (Agile) یا چارچوبی نظیر اسکرام (Scrum) آشنا شده باشیم و اندر مزایای آنها سخنان بسیار شنیده باشیم و سودای آن را در سر بپرورانیم که هم اینک به سمت چابک شدن کوچ کنیم، اما نکته مهمی که باید مد نظر داشته باشیم این است که پروژه های قابل اجرا با این متدولوژی باید دارای ویژگی هایی باشند و استفاده از اسکرام برای هر پروژه ای ممکن است نه تنها ما را چابک نکرده بلکه با تاثیر منفی نتایجی کاملا خلاف انتظار ما داشته باشند.

و اگر ابتدا یک طرح کلی از کار تهیه کرده و در هر بازه جزئیات را بیافزاییم، در حقیقت نمونه ای از خاصیت تکرارپذیری  (Iterative) است.

نهایتا با ترکیب این دو، ما به ویژگی اصلی چابک دست یافته ایم.

گمان کنم با ذکر این مثال، ویژگی‌های متدولوژی چابک ملموس تر شد؛ حال باید به کاربرد این متدولوژی دقت کنیم!

بله، متدولوژی چابک را هرجایی نمی توانید به کار ببرید، همانگونه که دیدید در این روش ما یک طرح دقیق و با قابلیت اطمینان بالا از محصول مورد نظرمان در اختیار نداریم، پیش بینی (Anticipation) بسیار پایین است و کاملا واضح است که برای پروژه های بزرگ که نیاز به اطمینان بالا و نقشه راه دقیق دارند استفاده از این روش خطای بزرگی است!
در حقیقت برای پروژه های کوچک و متوسط که پیچیده هستند و پایداری در آنها پایین است، متدولوژی چابک بهترین راه حل می باشد.

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

عمدتا افراد هنگامی که دچار تاخیر شده اند و یا با مشکلات دست و پنجه نرم می کنند به فکر تغییر می افتادند و  تنها تحول پیش روی خود را هم خیزش به سمت متدولوژی چابک می بینند اما کافی است که یک دقیقه تامل کنند و واقعیت را نظاره گر باشندکه آنها  با یک فیل سر و کار دارند نه یک ببر یا موش!

بخشی از مشکلات موجود، ممکن است به خاطر عدم درک افراد تیم از مساله اصلی باشد! گاها آنقدر روی حواشی تمرکز می‌کنیم که نمی توانیم مسائل را به صورت کلی ببینیم.

در خیزش به سمت چابک شدن (برای فعالیت های بزرگ) دو چالش را باید مدنظر قرار دهید:

• توانایی تعریف دقیق مساله (مشکل) پیش رو را داریم؟
• اینکه آیا روی مساله درستی تمرکز کرده ایم؟

توجه داشته باشید کسب و کارها براساس ایده یا نیازمندیهای حل نشده شکل می گیرند و راه حل ها می تواند فنی و غیر فنی و یا ترکیبی باشد؛ اما نکته اصلی این است که از همان آغاز اجزا باید به خوبی برای همدیگر شناخته شده باشند، به تعریف ساده تر دامنه کاری هریک از اجزا مشخص باشد و در عین حال هر کدام نسبت به فعالیت های دیگر قسمت ها آشنایی نسبی داشته باشند.

بطور مثال همان فیل یاد شده را در نظر بگیرید، اگر پروژه بزرگ ما همان فیل باشد و تیم ما چون افرادی که با چشمان بسته هر کدام سعی در یافتن مفهوم اصلی داشته باشند، چند برداشت متفاوت و بعضا نادرست خواهیم داشت؟

حال بیایید به یک نمونه واقعی از استفاده متدولوژی چابک برای یک پروژه اشاره کنیم:

برای یک پروژه با زمان ثابت و فشرده و بودجه محدود  و یک تیم با پیش زمینه ذهنی سنتی (آبشاری) استفاده از متدولوژی چابک بسیار موثر بود، به نحوی که اعضای تیم که در ابتدا بسیار مردد بودند در نهایت از تحویل پروژه در نصف زمان مقرر بسیار خرسند گشتند.  خیز ش به سمت چابک صورت گرفت، متاسفانه در پروژه بعدی نتیجه مسرت بخش نبود!
آموزش تدارکات این محصول در حدود 3 ماه زمان میبرد در صورتی که کارکرد منطقی نرم افزار در حدود 3 تا 5 ماه بود.

در حقیقت بعضی از پروژه ها نیازمند یک مدیر پروژه توانمند و نقشه راه (Road Map) دقیق هستند و وجود چندین مدیرتولید متوسط و عدم پیش بینی دقیق نتایج عکس خواهد داشت.

اگر قصد بهینه سازی داریم می بایست به طور کلی زنجیره ارزش را بررسی کنیم و  نگاه سطحی و یک جانبه نگری ما را از مسیر اصلی دور می‌کند.

پینوشت:
* عمیقا معتقدم که اسکرام چارچوب هست و نه متدولوژی، به همین علت هم لفظ چارچوب را، برای تاکید، پیش از آن آوردم.
* ممکن به لفظ چار‌چوب ایراد گرفته و بگویید که چهارچوب صحیح است! اما باید خاطر نشان کنم که چهارچوب به معنای Frame و چارچوب به معنی Framework است.

برداشتی آزاد از + تصاویر ابتدایی از + و تصویر انتهایی از +

دوشنبه 7 اردیبهشت 94