آیا پیش بینی در پروژه های نرم افزاری غیر ممکن است؟
در حالت کلی، خیر. تعدادی از پروژه های خاص منظوره مثل سیستم های نرم افزاری سفینه های فضایی وجود دارند که بارها و بارها برای همین منظور توسط یک تیم که برای همین کار آموزش دیده اند تولید می شوند. پروژه هایی از این قبیل مانند پروژه های عمران هم مدل دقیقی دارند و هم با طراحی با تحلیل ریاضی قابل اثبات است. در نتیجه این نوع پروژه ها در حد خوبی قابل پیش بینی هستند. ولی برای عموم نرم افزارهایی که تولید می شود، پیش بینی کار بسیار مشکلی است. این سختی دلایل زیادی دارد از جمله[۱]:
- تقریبا کل فرایند توسعه نرم افزار یک کار طراحی است در نتیجه به سختی می توان آن را برنامه ریزی و زمانبندی کرد.
- مواد اولیه ای که در ساخت استفاده می شود یعنی نرم افزارهای دیگر به سرعت در حال تغییر است.
- افراد در فرایند توسعه نرم افزار نقش پر رنگی دارند و افراد ذاتا پیش بینی پذیر نیستند.
- حتی اگر مشتری سیستم هم نیازهای خود را تغییر ندهد، بازار رقابت نیازهای خود را تحمیل می کند.در نتیجه استفاده از فرایندهای که بر اساس پیش بینی پذیری طراحی شده اند در پروژه هایی که قابلیت پیش بینی مناسبی ندارد(مانند بسیاری از پروژه های نرم افزاری) کار نادرستی است. البته این به معنای نفی برنامه ریزی و بروز هرج و مرج نیست. ولی باید به دنبال رهیافتهایی بود که پیش بینی ناپذیری نرم افزار را پذیرفته و برای آن راه حلی ارایه می دهند.
کنترل فرایندهای غیر قابل پیش بینی با فرایندهای مبتنی بر تکرار
ابتدا دو ایده قدیمی برای برخورد با سیستم های غیر قابل پیش بینی استفاده می شود را مطرح می کنیم.
در مسایل فیزیک وقتی می خواهند نرخ تغییرات را در یک نقطه محاسبه کنند در بازه بسیار کوچکی فرض می کنند که تغییری وجود ندارد. این فرض برای تمامی توابعی که در آن نقطه مشتق پذیر باشند درست است. حال در یک پروژه نرم افزاری با فرض اینکه تغییرات ناگهانی نداشته باشیم می توانیم از همین ایده استفاده کنیم.
ایده دیگر هم از سیستمهای خود کنترل شونده گرفته شده است که سیستم بر اساس بازخوردی که در مرحله قبل داشته است خود رفتار خود را بهبود می‌بخشد.
در نتیجه فرایندهایی پیشنهاد شد که زمان کل پروژه را به بازه های کوچکی تقیسم کرده و آن بازه ها را برنامه ریزی کنند. در انتهای هر بازه نیز با توجه به خروجی کار بازه بعدی را برنامه ریزی کنند.
نکته کلیدی در توسعه مبتنی بر تکرار این است که در انتهای هر تکرار، زیرمجموعه ای از قابلیت های محصول نهایی را به صورت نسخه ای قابل اجرا به عنوان خروجی می دهد. این نسخه ها همانند نسخه نهایی به صورت کامل تست می شوند. دلیل اصلی این کار این است که هیچ چیز غیر از یک نسخه قابل اجرا نمی تواند میزان پیشرفت پروژه را نشان دهد.
حال یک سوال مطرح است که مدت زمان هر تکرار چقدر باشد؟ XP پیشنهاد می دهد یک تا دو هفته باشد. SCRUM حدود یک ماه را پیشنهاد می دهد. در حالیکه Crystal حتی بیشتر از این زمان را مجاز می داند. به نظر می رسد این کاملا به طبیعت پروژه و افراد تیم بستگی دارد. اینکه ما در چه زمانی می توانیم نیازمندیهای خود را ثابت بدانیم و برای آن مدت برنامه و زمانبندی نسبتا دقیقی داشته باشیم. البته در [۱] توصیه شده است که هرچه می توانید این زمان را کوتاه در نظر بگیرد (تا جایی که به سربار فرایند به پیشرفت پروژه صدمه نمی زند).
افراد در متدولوژیهای چابک چه جایگاهی دارند؟
یکی از ویژگیهای متدولوژیهای قدیمی این است که قصد دارد فرایندی را تعریف کند که در آن افراد به صورت قطعات قابل تعویض و تغییر باشند. در نتیجه می توان افراد را مانند سایر منابع نظیر سخت افزارها در نظر گرفت. مثلا شما تعدادی تحلیلگر، طراح و چند پیاده ساز نیاز دارید. همانطور که دیده می شود نقش افراد بسیار مهم تر از خود افراد هستند. حال آیا واقعا افراد در فرایند توسعه نرم افزار قطعاتی قابل جابجایی هستند. یکی از ویژگی های متدولوژیهای چابک این است که این فرضیه را رد می کند.[۴].
نظریه تیلور مبنی بر جداسازی واحد برنامه ریزی که در بسیاری از علوم مهندسی کاربرد داشته است. اما این نظریه در صورتی درست است که کسانی که تعیین می کنند کارها چگونه انجام شود، بهتر از انجام دهنده ها این کار را بلد باشند. واضح است این مطلب درباره کدنویسانی که باهوش و باانگیزه باشند درست نیست.
مدیریت یک فرایند چابک چگونه است؟
در این بخش به چند نکته بسنده می کنیم. این نکات خلاصه مطالبی است که از[۱] گرفته شده است.
- در مدیریت فرایندهای چابک، افراد تیم باید فرایند را بپذیرند به جای اینکه فرایند دستوری باشد. یعنی باید قبول کنند که حرکت در قالب تعریف شده در فرایند به پیشرفت آنها و پیشرفت پروژه کمک می کند.
- برنامه نویسان باید بتوانند تمامی تصمیمات فنی را بگیرند. مثلا در XP تنها برنامه نویسان می توانند درباره کار خود تخمین زمانی بدهند.
- در فرایندهای چابک به جای مدیریت مبتنی بر اندازه گیری توسط مدیران به مدیریت تفویض اختیار تبدیل می شود. چون تا هنگامی که معیارهای اندازه گیری از بیرون انتخاب شوند حرکت برنامه نویسان به سمت بهینه کردن اندازه هاست تا اینکه برنامه بهتری تولید کنند. از دیگر دلایل این نحوه مدیریت این است که چون تکنولوژی به سرعت در حال تغییر است، بسیار محتمل است که یک برنامه نویس نکات فنی بیشتری نسبت به مدیر درباره حل مساله خود داشته باشد.
- فرایند باید خود اصلاح باشد. یعنی فرایند در طول زمان با بازخوردهایی که از تیم و پیشرفت کار می گیرد خود را تطبیق می دهد. پس این یک دید اشتباه است که یک فرایند را انتخاب کرده و سعی کنیم تا انتهای پروژه دقیقا به همان فرایند اولیه پایبند باشیم. این فرایند خود اصلاحی در مورد پروژه هایی که مانند آنها با یک تیم ثابت زیاد انجام شده بسیار ناچیز بوده ولی در مورد پروژه های جدید می تواند زیاد باشد، زیرا در طول زمان نیازمندیهای پروژه بیشتر شناسایی میشود.
منابع:
[1] Martin Fowler, The New Methodology, http://martinfowler.com/articles/newMethodology.html#AgileManifesto
[2] Steve McConnell, Development: Taming Wild Software Schedules, ISBN 1556159005
[3] Alistair Cockburn, Characterizing People as Non-Linear, First-Order Components in Software Development, 4th International Multi-Conference on Systems, Cybernetics and Informatics, Orlando, Florida, June, 2000.
[4] Jack W. Reeves, What is Software Design?, C++ Journal
