پیاده سازی رویکرد چابک یا رویکرد آبشاری

پیاده سازی رویکرد چابک یا رویکرد آبشاری

اغلب در مقالات و گفتگوهای کنفرانس می‌شنویم که چگونه افراد مشکلات رویکرد “آبشاری” خود را با اجرای رویکرد چابک، اسکرام، XP‌، کانبان، و سایر کلمات کلیدی که  آن‌ها را نام‌گذاری می‌کنیم، حل می‌کنند. دلیل انتقال بسیاری از افراد از رویکرد “چابک” دقیقا چیست؟ با در نظر گرفتن چارچوب‌های محبوب، افراد فرایندهای مربوط به آن‌ها را بدون هیچگونه تغییر سازمانی فرهنگی یا گسترده تر اعمال می‌کنند. نمونه بارز آن زمانی بود که شخصی در یک کنفرانس از پیوستن به رویکرد اسکرام ابراز خوشحالی می‌کرد، توسعه در بخش‌های کوچک تکرار شوند (Iterations) قابل پیش‌بینی برای آن‌ها آسان بود، بنابراین آن‌ها می‌توانند به موقع موارد را تحویل بگیرند. وقتی از آن‌ها پرسیدند که چگونه گزارش‌های خود را اداره می‌کنند، آن‌ها گفتند: “ما این کار را نمی‌کنیم، اولویت‌ها و ترتیب توسعه پس از تعریف دامنه تغییر نمی‌کنند.” بنابراین برای سوال بعدی از آن‌ها پرسیدند، “رویکرد چابک کجا است، اگر شما از تغییرات احتمالی مراقبت نکنید؟ آن‌ها گفتند “چگونه  آن‌ها را نمی‌بینید؟ ما تکرارها و آیین نامه را اجرا می‌کنیم”. بدیهی است، هنگام اجرای برخی از روش‌های چابک، سازمان‌ها بلافاصله سریع نمی‌شوند. با این حال، به نظر نمی‌رسد اجرای فرهنگ چابک واقعی در بعضی موارد به هدف منجر شود. این با آنچه در مورد اجرای همه راهنما‌ها و کتابچه‌های راهنمای چابک گفته می‌شود متناقض است، اما هنوز هم شرکت‌ها به دنبال آن هستند و با کمال تعجب از اجرای آن خوشحال هستند! این نتیجه بسیار جالب بود که سازمان‌ها وقتی این انتقال را انجام می‌دهند، لزوما نمی‌خواهند رویکرد چابک را پیاده‌سازی کنند، آن‌ها فقط می‌خواهند از مدل آبشاری فرار کنند. و فرار از رویکرد آبشاری می‌تواند به اشکال مختلفی به وجود آید، بنابراین ایده کلی رایج برای مقایسه رویکرد “آبشاری” در مقابل “چابک” به عنوان دو افراط در مقابل هم از نظر مفهومی صحیح نیست. برای درک بهتر این مطلب پیشنهاد می‌شود مقاله “برداشت‌های نادرست از رویکرد مدیریت چابک” را نیز مطالعه کنید.

پیاده سازی رویکرد چابک یا رویکرد آبشاری

تاریخچه و معمای مدل آبشاری

هنگام اشاره به مدل آبشاری، همیشه تصویری از ۵ یا ۷ مربع یکی پس از دیگری را تصور می‌کنیم، جایی که هر مربع مرحله‌ای از یک روند توسعه نرم‌افزار را نشان می‌دهد. فرض بر این است که اگر مرحله‌ای تمام شود، ما به مرحله قبل بر نمی‌گردیم. در همان زمان اگر مرحله قبل کامل نشوذ، روند فراتر نمی‌رود. به عنوان جایگزین، افراد در مورد رویکرد چابک (به عنوان مثال اسکرام به عنوان یکی از محبوب‌ترین چارچوب‌ها) که مفهوم مراحل در آن سوال می‌شود صحبت می‌کنند. اما این مقایسه در ذات آن دقیق نیست.

استدلال در انتخاب رویکرد چابک در پروژه‌‌ها

در پایان روز، مدیریت یک پروژه بیشتر مربوط به مدیریت ریسک (عدم اطمینان) در راه رسیدن به نتیجه نهایی است. با توجه به این موضوع، افراد می‌توانند استراتژی متفاوتی را انتخاب کنند: برخی از پروژه‌ها نیاز دارند تا حد امکان موارد را پیش‌بینی کنند( رویکرد قابل پیش بینی)، داشتن کتاب دستورالعملی که در صورت بروز هر شرایطی و با گذشت پروژه چه کارهایی باید انجام دهند، و برخی از افراد تمایل دارند مسائل را در صورت بروز نیازها حل کنند و برای آن آماده می‌شوند (رویکردهای تطبیقی). بنابراین، در الگوی پیش‌بینی، افراد سعی می‌کنند تمام نتایج احتمالی را پیش‌بینی کرده و برای هر یک برنامه بریزند. در رویکرد تطبیقی ​​آن‌ها می‌گویند انجام این کار غیرممکن است یا امکان‌پذیر نیست، بنابراین آن‌ها بیشتر ارزیابی مجدد و برنامه‌ریزی مجدد را به عنوان بخشی طبیعی از فرایند می‌دانند. میزان تمایل سازمان‌ها برای انطباق‌پذیری می‌تواند بین سازمان‌ها، صنایع یا فرهنگ‌ها متفاوت است. این بدان معناست که به جای اینکه فقط مقایسه دو رویکرد آبشاری در مقابل چابک داشته، یک پیوستگی کامل از تغییرات در خط بین پیش‌بینی و انطباقی داریم. فردی که تمایل بیش‌تری به پیش‌بینی دارد، چارچوب قابل پیش‌بینی‌تری را نیز انتخاب می‌کند.

پیشنهاد دکتر رویس (پدر مدل آبشاری)

• ابتدا باید یک مرحله طراحی اولیه برنامه بین مرحله تولید الزامات نرم‌افزار و مرحله تجزیه و تحلیل درج شود تا اطمینان حاصل شود که نرم‌افزار به دلیل ذخیره‌سازی، زمان‌بندی و تغییرات داده‌ها (مانند ارزیابی امکان راه حل) خراب نخواهد شد و سپس طراحی مستند شود.
• توصیه بعدی این است که حداقل دو بار این کار را انجام دهید! ابتدا یک نمونه اولیه بسازید، آن را آزمایش کنید، سپس روی آن تکرار کنید. سپس وی در مورد مدیریت و کنترل آزمایش‌ها صحبت می‌کند، به ویژه بر این نکته تاکید می‌کند که “بسیاری از قسمت‌های آزمایش توسط متخصصین آزمون که لزوماً در طرح اصلی نقش ندارند” انجام می‌شود و برای هدایت پروژه در نظر گرفته شده است.
• و در آخر این که، او گفت که شخص باید مشتری را درگیر کند. باز هم خواهم گفت: “مهم این است که مشتری را به شکلی رسمی درگیر کنید تا او در نقاط قبل از خروجی نهایی متعهد شود.”
• آیا اولین چیزی که هنگام شنیدن “آبشار” به ذهنمان خطور می‌کند، درست نیست؟ بیایید این توصیه‌ها را با “مشکلات آبشاری” رایج مقایسه کنیم، راه‌حل‌های کدام یک در رویکرد چابک مطلوب است؟ فقط چند نکته برجسته از منابع مختلف را ببینیم:
  • غالباً طرح‌هایی که بر روی کاغذ امکان پذیر به نظر می‌رسند، در عمل گران و دشوار هستند و نیاز به یک طراحی مجدد دارند و از این رو، تمایز‌های واضح بین مراحل مدل آبشار سنتی را از بین می‌برند.
  • برجسته‌ترین انتقاد به این واقعیت اشاره دارد که اغلب اوقات، مشتریان واقعاً نمی‌دانند قصد دارند ابتدا از چه چیزی استفاده کنند؛ بلکه آن‌چه را که می‌خواهند از تعامل دو طرفه مکرر در طول پروژه پدیدار می‌شود.
  • هنگامی که یک برنامه در مرحله آزمایش است، برگشت به عقب و تغییر چیزی که در مرحله تصور کلی به خوبی در مورد آن فکر نشده است، بسیار دشوار است.
  • تعاملات مشتری بسیار کمتری در طول تولید محصول درگیر است. پس از آماده شدن محصول، فقط می‌توان آن را برای کاربران نهایی نمایش داد. پس از تولید محصول و در صورت بروز هرگونه خرابی، هزینه رفع چنین مواردی بسیار زیاد است، زیرا باید همه موارد از سند تا منطق را به روز کنیم.

توسعه محصول و فرآیند چابک و مدل آبشاری

البته جنبه‌های معمولی توسعه پیش بینی وجود دارد که ممکن است در مقایسه با توسعه انطباقی آزار دهنده است یا ضد تولید به نظر برسد، اما اجازه دهید فعلاً آن‌ها را کنار بگذاریم. نکته در اینجا این است که بسیاری از آنچه افراد مشکلات اصلی مربوط به توسعه رویکرد “آبشار” می‌نامند، قبلاً ابزارهایی برای حل مشکلات با توسعه یک نرم‌افزار پیش بینی در همان مقاله اول داشتند. حال بگذارید در این باره فکر کنیم: بین تاریخ انتشار مقاله و اکنون حدود ۵۰ سال تفکر وجود داشته است. البته چارچوب‌های مدیریت توسعه یافته و پیشرفته‌تر شده و با دنیای مدرن سازگار شده است. بنابراین چرا ما هنوز در مورد همه مشکلات یکسانی که دکتر رویس درباره آن‌ها صحبت کرد، مانند اینکه محصولات به صورت امکان پذیر طراحی نمی‌شوند، و یا مشتریان در تولید محصول درگیر نمی‌شوند، و یا کیفیت در طول طراحی و توسعه در نظر گرفته نمی‌شود، صحبت می‌کنیم؟ اما وقتی مردم فرایندهای چابک را اجرا می‌کنند، این مشکلات حل می‌شود حتی بدون اینکه واقعا با طبیعت سازگار شوند! جواب واضح و بسیار غم انگیز است. آن‌چه شرکت‌ها با آن روبرو هستند، شیوه‌های نادرست مدیریت پروژه است و راه حل آن‌ها، اجرای فرایندهای جدید است. که در واقع هدفی برای تبدیل شدن از پیش‌بینی کننده بودن به سازگاری ندارد. آن‌ها در سمت چپ از زنجیره مدیریت عدم اطمینان، احساس اطمینان می‌کنند، که خوب است. اما آن‌ها از عدم اجرای شیوه‌های مناسب ناشی از موقعیت آن‌ها در پارادایم رنج می‌برند. چابک اکنون کلمه کلیدی اصلی است، بنابراین وقتی یک شرکت متوجه می‌شود که فاقد فرهنگ مدیریت پروژه است، اولین چیزی که به ذهن آن‌ها خطور می‌کند این است: “ما باید چابک شویم”.

آیا فرآیند چابک پاسخگو خواهد بود؟

با وجود اکثر فرایندهای  چابک، که فرهنگ مسئولیت مشترک و مشارکت کامل را وضع می‌کنند، می‌توان نقص‌های مدیریت پروژه را اصلاح کرد، که در نهایت منجر به پروژه‌های بهتری می‌شود. این امر باعث می‌شود فرایندها کمتر موردی شوند، که ارزش به ارمغان می‌آورند. اجرای یک پروژه بزرگ قابل پیش‌بینی بسیار دشوار است؛ فشار بر مدیریت پروژه زیاد است. هنگامی که این مسئولیت‌ها به طور جزئی در تیم پخش می‌شود، و با بخشی از فرایندهای دیگر جایگزین می‌شوند و در طی جلسات آموزشی به عنوان بخشی از یک تحول دوباره مورد بازبینی قرار می‌گیرند، قطعاً در سازمان شاهد پیشرفت‌هایی خواهیم بود.

اهمیت موضوع و تحولات فرآیند چابک

نمیتوان دقیق گفت که تفکر بالا صحیح است یا خیر، اما برخی از “تحولات چابک” را بدون اجرای واقعی یک ذهنیت تطبیقی توضیح می‌دهد. اشتباه نکنید، این بدین معنی نیست که اجرای چارچوب‌های چابک لازم نیست و همه ما باید به موقع برگردیم و تمام روش‌های سنگینی را که قبلاً داشتیم، از بین ببریم. بلکه اینگونه می‌توان نتیجه گرفت که، هنگام ابتلا به بیماری، همیشه می‌خواهیم علت اصلی را بفهمیم و فقط علائم را درمان نکنیم. در بیشتر موارد، در صورت درک علل، درمان تغییر نخواهد کرد، اما گاهی اوقات نیز چنین خواهد شد. همین مسئله در مورد سازمان‌ها نیز صدق می‌کند. بهتر است “چرایی” پشت یک تحول چابک را درک کنی. آیا به این دلیل است که سازمان می‌خواهد در دامنه پیش‌بینی سازگاری به سمت راست حرکت کند، یا به دلیل این که سازمان فاقد کیفیت و بهترین شیوه‌ها در الگوی فعلی است؟ اگر یک کسب و کار با مشکلات و نتایج غیر رضایت بخشی روبرو است، زمان تحول است. برای تعریف یک استراتژی تغییر مناسب، یک شرکت باید زمینه تحول و نیازهای اصلی تحریک کننده آن را درک کند (‌به مدل مفهومی تحلیلگر کسب و کار اصلی مراجعه کنید). ما به عنوان تحلیل‌گر کسب و کار باید آن را بهتر از دیگران درک کنیم. درک دلایل تغییر به اجرای آن کمک خواهد کرد و برخی از هزینه‌های غیر ضروری را که یک شرکت دارد کاهش می‌دهد. همیشه بهتر است که حقیقت را در نظر بگیرید، که از سردرگمی و متعاقباً گفتگوهای گیج کننده جلوگیری می‌کند.