پروژه‌هایی وجود دارند که بسیار ساده و قابل پیش‌بینی هستند و می‌توان از ابزارهای عقلانی برنامه‌ریزی و تصمیم‌گیری در آنها استفاده کرد. پروژه‌های دیگری که پیچیده‌تر یا غیرقابل پیش‌بینی هستند، نیاز به رویکردی متفاوت دارند که بیشتر بر خودسازمان‌دهی و نوآوری تکیه دارد.
اکثر پروژه‌های توسعه نرم‌افزار به دلیل همگرایی سه عامل انسان‌ها، نیازمندی‌ها و فناوری، پیچیده و غیرقابل پیش‌بینی تلقی می‌شوند. رویکردهای مختلف استفاده شده برای ارائه و مدیریت پروژه‌ها می‌تواند در چارچوب مدل‌های کنترل فرآیند و پیچیدگی پروژه بهتر درک شود.
فرآیند تعریف‌شده — رویکرد سنتی محور برنامه‌ریزی
سنتی، با شروع یک پروژه، یک بسته نیازمندی‌ها ایجاد می‌شود و سپس “تأیید” می‌شود. مدیر پروژه فرض می‌کند که این تأیید منجر به یک مجموعه ثابت از نیازمندی‌ها می‌شود و اکنون می‌توان برنامه‌ریزی را آغاز کرد. مدیر پروژه تخمین می‌زند که تکمیل نیازمندی‌ها چقدر طول می‌کشد و برنامه پروژه را ایجاد می‌کند. برنامه پیش‌بینی می‌کند که پروژه تا یک تاریخ معین به پایان برسد و این تاریخ به مشتری اطلاع داده می‌شود.
عیب اساسی این رویکرد این است که برنامه، که همه چیز را هدایت می‌کند، بر این فرض استوار است که نیازمندی‌ها ثابت هستند و تغییر نمی‌کنند. تجربه نشان داده است که این هرگز صادق نیست؛ نیازمندی‌ها هرگز ثابت نیستند — همیشه تغییر می‌کنند. هنگامی که نیازمندی‌ها تغییر می‌کنند، برنامه تحت تأثیر قرار می‌گیرد؛ و بنابراین، تاریخ تکمیل نیز باید تغییر کند. به نظر می‌رسد در بسیاری از موارد این امر غیرممکن است و تیم باید تا تاریخی که تعهد داده‌اند، تحویل دهد. این زمانی است که بحران بزرگی رخ می‌دهد و پروژه شروع به خارج شدن از کنترل می‌کند.
فرآیند تجربی — رویکرد ارزش‌محور اجایل
رویکرد ارزش‌محور اجایل بر اساس تجربه‌گرایی است که تمام ذهنیت را تغییر می‌دهد. از ابتدا فرض می‌کند که هر نیازمندی‌ای که از قبل وجود دارد، ثابت نیست و تغییر خواهد کرد.
ذهنیت اجایل همچنین فرض می‌کند که باید تا یک تاریخ معین تحویل دهید. این رویکرد زمان و منابع را ثابت می‌کند و نیازمندی‌ها را نامشخص می‌گذارد. به نظر ما، این رویکرد بیشتر شبیه واقعیت ایجاد نرم‌افزار است. اکنون تمام مفهوم ارزش‌محور کاملاً منطقی است. هنگامی که مقدار مشخصی از زمان دارید که در آن مطمئن نیستید آیا می‌توانید تمام نیازمندی‌ها را تحویل دهید (چون تغییر خواهند کرد و بنابراین زمان لازم برای تکمیل آنها نیز تغییر خواهد کرد)، واکنش طبیعی این است که نیازمندی‌ها را اولویت‌بندی کنید و ابتدا آنهایی را که بیشترین ارزش را برای مشتری ایجاد می‌کنند، تکمیل کنید.
شما ممکن است بپرسید، “نیازمندی‌هایی که تا تاریخ تحویل تکمیل نشده‌اند چطور؟” این دلیل استفاده از رویکرد ارزش‌محور است. شما این واقعیت را که تمام نیازمندی‌ها تا تاریخ تحویل تکمیل نخواهند شد، تأیید می‌کنید. سؤال مهم این است که آیا ویژگی‌های کافی را برای پشتیبانی از یک سیستمی که برای مشتری ارزشمند است، تحویل داده‌اید.
نرخ شکست پروژه‌های نرم‌افزاری
گزارش CHAOS سال 2015 اخیراً توسط گروه استندیش منتشر شده است. گزارش‌های CHAOS از سال 1994 هر ساله منتشر می‌شوند و یک نگاه کلی به وضعیت صنعت توسعه نرم‌افزار هستند. این سال گزارش 50،000 پروژه در سراسر جهان را بررسی کرده است، از ارتقاء‌های کوچک تا پیاده‌سازی‌های بازسازی سیستم‌های عظیم. این سال گزارش شامل تعریف تقویت‌شده‌ای از موفقیت است که بر چند عامل اضافی که در نظرسنجی‌های قبلی پوشش داده شده بود، تمرکز دارد.
نتایج نشان می‌دهد که هنوز کار زیادی برای دستیابی به نتایج موفق از پروژه‌های توسعه نرم‌افزار باقی مانده است. جدول زیر نتایج پروژه‌ها را در طی پنج سال گذشته با استفاده از تعریف جدید عوامل موفقیت (به موقع، در بودجه با نتیجه رضایت‌بخش) خلاصه می‌کند.
با افزایش استفاده از روش‌های توسعه اجایل در سال‌های اخیر، امکان پیوستن نتایج پروژه‌های اجایل و سنتی آبشاری وجود داشت. در تمام اندازه‌های پروژه، رویکردهای اجایل منجر به پروژه‌های موفق‌تر و شکست‌های کمتری شدند، همانطور که در جدول زیر نشان داده شده است.
چه مشکلاتی در رویکرد سنتی وجود دارد؟
رویکرد سنتی مبتنی بر برنامه از لحاظ ذاتی عیب ندارد؛ فقط برای صنعت نرم‌افزار امروزی مناسب نیست. رویکرد مبتنی بر برنامه در اصل بر اساس مفاهیم مدیریت پروژه سنتی بود که از صنعت ساخت و ساز نشأت می‌گرفت. در صنعت ساخت و ساز، رویکرد مبتنی بر برنامه مناسب است: نقشه‌های معماری که نیازمندی‌ها هستند، ثابت هستند و احتمالاً در حین ساخت و ساز تغییر نخواهند کرد. می‌توانید تخمین بزنید که ساخت ستون‌های فولادی، ریختن بتن و غیره چقدر طول می‌کشد.
دلیل اینکه رویکرد سنتی مبتنی بر برنامه برای صنعت ساخت و ساز مناسب است اما برای صنعت نرم‌افزار مناسب نیست، به تفاوت در نحوه کنترل سیستم‌های تجربی (مانند توسعه نرم‌افزار) و سیستم‌های تعریف‌شده (مانند ساخت و ساز یا تولید) برمی‌گردد. جدول زیر تفاوت‌های بین ویژگی‌های یک فرآیند تعریف‌شده و یک فرآیند تجربی را نشان می‌دهد.
پس از مطالعه جدول، مشخص است که توسعه نرم‌افزار به طور قطع یک فرآیند تجربی است، نه یک فرآیند تعریف‌شده. مشکل اینجاست که برای سال‌ها به توسعه نرم‌افزار به عنوان یک فرآیند تعریف‌شده نگاه می‌کردیم — و این رویکرد کار نمی‌کند.
منابع
- گزارش CHAOS گروه استندیش 2015
- Becoming Agile in an Imperfect Word — توسط Greg Smith & Ahmed Sidky
مطالب دیگر درباره Scrum
- Scrum در 3 دقیقه
- ارزش‌های 5گانه Scrum چیست؟
- تکامل Scrum چیست؟
- مدیریت پروژه کلاسیک در مقابل مدیریت پروژه اجایل
- چرا Scrum دشوار است؟
- سرعت در Scrum چیست؟
- Agile چیست؟ Scrum چیست؟
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.