تغییر روش مدیریت از آبشاری به چابک (Agile)

سنگ‌بنای یک تغییر آهسته

بسیاری از کسب و کارها برای مدیریت وظایف پیچیده، هنوز از یک روش موشکافانه و از بالا به پایین استفاده می‌کنند. این رویکرد، رویکرد «آبشاری» نام دارد. در این مطلب، برای کسب نتایج مؤثر، سریع‌تر و اغلب مقرون به صرفه‌تر، نحوه تغییر رویکرد از آبشاری به Agile را بررسی خواهیم کرد.

بسیاری از سازمان‌ها در حال گذار از رویکردهای متداول و افزایشی آبشاری “Waterfall” به سمت چارچوب تطبیقی چابک “Agile” هستند تا از رقبایشان پیشی بگیرند. بنا به گفته مؤسسه مدیریت پروژه آمریکا، تقریباً سه سازمان هستند که گه‌گاه، به طور مکرر یا همیشگی، از متدولوژی Agile استفاده می‌کنند. و این به یک دلیل مهم اتفاق می‌افتد: رویکرد Agile می‌تواند زمان لازم برای ورود محصول به بازار را کاهش دهد، از ابتکارات بیشتری پشتیبانی کند، تجربه مشتری را بالا ببرد و کیفیت محصول را افزایش دهد.

صرف نظر از این مزایا، بسیاری از سازمان‌ها موانعی که بر سر راه بهبود عملکرد وجود دارد را دست کم می‌گیرند. این موانع از ضعف‌های مهارتی تا انگ‌های فرهنگی را شامل می‌شود. جان میلر، مربی رویکرد Agile در دوره Agile For All توصیه می‌کند: «سازمان‌ها معتقدند که می‌خواهند Agile را بپذیرند، اما واقعاً نمی‌دانند که چه چیزی در پی آن اتفاق می‌افتد.» آن‌ها تصور می‌کنند که این فقط یک روش‌شناسی است، اما متوجه نیستند که از طریق آن، چه تغییراتی لازم می‌شود.»

رویکرد آبشاری (Waterfall) و موارد مرتبط

رویکرد آبشاری بسیا سیستماتیک است و از فرآیندهای کاملاً از پیش تعریف‌شده پیروی می‌کند. آزمایش آبشار با استفاده از ویژگی‌های مورد نیاز و سناریوهای مبتنی بر چیدمان (layout-based) ، در مراحل اولیه یک پروژه انجام می‌شود. چارچوب سیستماتیک برای ارائه، اغلب به نیازهای مفهومی مبتنی بر مشتری متکی است. که اغلب نیاز به مهندسی مجدد برنامه در حین فرآیند تأیید دارد.

از آن‌جایی که نیازها به سرعت تغییر می‌کنند، شرایط اولیه و طرح‌بندی ممکن است دیگر برای الزامات و ترجیحات خریدار قابل اجرا نباشند. علاوه بر این، از آن‌جایی که پروژه منسجم است، نیاز به بازه زمانی طولانی‌تری برای تولید دارد.

الگوی طراحی (design pattern)  آبشاری به جای این که تطبیقی باشد، افزایشی است. پروژه به منظور جلو انداختن اولویت آن مراحلی پیش می‌رود که برای ساخت و ساز فیزیکی مناسب‌تر از طرح‌بندی کدگذاری دیجیتال هستند. به نوعی توسعه بر روی بخش‌های برگشت‌ناپذیر بنا شده است. حتی اگر «مکانیسم‌های بازخورد» بین مراحل تغییر را ممکن بسازند، این فرآیند زمان-به-بازار را افزایش می‌دهد.

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

اگرچه استراتژی آبشاری برای پروژه‌های ساده و مختصر به خوبی کار می‌کند، اما برای کارهای پیچیده مانند پروژه‌های دیجیتال، که معمولاً شک و شبهه‌های زیادی دارند، به خوبی کار نمی‌کند. بنابراین در این‌جا چند مثال از این‌که چرا تکنیک‌های آبشاری می‌توانند دردسرساز باشند آورده شده است:

• برای شروع، پیش‌بینی هر نتیجه بالقوه با طیف دقیقی از الزامات  پروژه، دشوار است.
• طرح دقیق آبشاری امکان تصحیح دوره بر اساس یادگیری را که در سراسر سرمایه گذاری انجام می شود را نمی دهد.
• دیسک عدم قطعیت می تواند برآورد دقیق و برنامه ریزی پروژه های آبشاری را بسیار دشوار کند. به همین دلیل است که RFP می تواند بسیار دشوار باشد.

ظهور رویکرد چابک (Agile) در عرصه تجارت

Agile بسیار بیشتر از یک کلمه جذاب است. توسعه Agile یک رویکرد تکراری برای مهندسی نرم افزار است. مراحل اولیه توسعه بر برنامه ریزی مراحل متوالی تأثیر می‌گذارد یا آن را مشخص می کند. Agile جایگزینی کاملاً تنظیم شده برای مقابله با مشکل توسعه و انتشار نرم افزار، برای مدل Waterfall است.

Agile برای توسعه نرم افزار از رویکرد کلاسیک استفاده می کند. رویکرد Agile روش‌هایی را که بر پیامدهای قابل پیش‌بینی تکیه دارند حذف می‌کند. روش‌شناسی‌های Agile نه تنها پیچیدگی‌های ذاتی توسعه نرم‌افزار را تشخیص می‌دهند، بلکه از آن بهره می‌برند. تصورات از پیش تعیین شده با ماهیت ارگانیک و رویکرد افزایشی ساختار Agile بیگانه است.

نکاتی برای مدیریت یک تغییر رویکرد بزرگ از آبشاری به Agile

هنگامی که روی پروژه کار واحد کار می کنید، روش‌های Agile ساده‌تر فهمیده می‌شوند. با این حال، تلاش برای مسیریابی یک آبشار مؤثر به سمت تغییر Agile، به عنوان یک آژانس کمی دشوارتر است. زیرا مشاغل همیشه به طور همزمان با پروژه‌های مختلف سر و کار دارند.

در اینجا چند ایده برای آماده‌سازی تیم خود برای تغییر رویکرد از آبشاری به Agile وجود دارد:

پتانسیل تیم

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

برآورد

 ارزیابی میزان دشواری کار جزء مهمی از برنامه‌ریزی مؤثر در رویکرد شتاب است. با ارزیابی سختی در مقدار 1-10 و با استفاده از ساعات کاری به عنوان سطح پیچیدگی، شروع کنید.

قابلیت‌های شخصی

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

سیستم امتیازدهی

 متخصصان قدرتمند Agile از سیستم امتیازدهی پیچیده‌تری استفاده می کنند که بر دنباله فیبوناچی متکی است. این امر به شکل‌گیری توافق تیمی در مورد نحوه انجام هر یک از Sprint‌ های مورد نظر کمک می‌کند.

طول Sprint

Sprint‌ ها معمولاً چند هفته طول می‌کشند، اما ممکن است برای پتانسیل تیم شما یا تلاشی که روی آن کار می‌کنند مناسب نباشد. تا زمانی که به راه حلی دست پیدا کنید که برای همه شرکت‌کنندگان پروژه کارایی داشته باشد، مدت زمان Sprint را تا مقدار نیاز آداپته کنید.

دلایل کلیدی که این تغییر را پشتیبانی می‌کنند

نمودار ریسک Agile در مقایسه با منحنی رو به بالای ریسک Waterfall ، یک نمودار مسطح است. گردش کار رویکرد آبشاری ماهیتی تکراری دارد. در نتیجه، آن‌ها (جریان‌های کاری با مراحل متوالی) از شما می خواهند که یک مرحله را قبل از این‌که مرحله دیگری واقعاً شروع شود، به پایان برسانید.

این به این معنی است که ریسک‌های بالقوه در هر مرحله، در سطل A جمع‌آوری می‌شوند. به عبارت دیگر، روش آبشاری به صورت متوالی و از طریق انباشت سطل (bucket accumulation) کار می کند. در نتیجه، منحنی Waterfall به طور پیوسته در حال افزایش است.

از طریق برنامه ریزی Sprint، در رویکرد Agile معمولاً همه خطرات احتمالی جمع آوری می‌شوند. شما یک سطل ترکیبی ‘B’ در اسکرام های روزمره درست می کنید. مانند Agile ، ریسک را در Sprint‌ها یا تکرارهای مختلف پخش می کنید. و این منحنی Agile را صاف تر می کند.

یک رویکرد آبشاری بی‌نقص از یک رویکرد Agile تقریباً خوب شکست می‌خورد

Waterfall با اجتناب از هرگونه تغییر، محصول نهایی شما را کامل می کند. و از شما می خواهد که محصول را به طور گسترده آزمایش و کیفیت‌سنجی کنید. در مقابل، هیچ مورد یا مدل سرمایه‌گذاری وجود ندارد که در Agile ایده آل باشد. در نتیجه، تکرارها یا Sprint ها برای رسیدن به حداقل محصول قابل دوام زمان بندی می‌شوند. این ارزیابی کیفیت توسط تیمی متشکل از تکنسین ها، توسعه دهندگان و بازبینان انجام می‌شود.

این انعطاف پذیری و امکان‌سنجی رویکرد Agile را افزایش می دهد. برخلاف Waterfall، Agile کسب و کار را در جریان نگه می دارد. نیازی نیست که کسب و کار بفهمد که در سطل زباله شما در آبشار چه اتفاقی می افتد، که ممکن است خطاهای بیشتری را ایجاد کند. حتی در این صورت، با Agile ، شرکت کار را با افزایش‌های تکراری دریافت خواهد کرد. در نتیجه خطاها در حین حفظ ارتباط مثبت با آنها کاهش می‌یابند.

از Waterfall به Agile : تغییر قدم به قدم انجام می‌گیرد

گام 1

متد Agile را در مراحل کوچک بپذیرید تا یک چارچوب قوی در طول زمان بسازید. راه ایده آل برای رسیدن به این موضوع، پیشنهاد بخش کوچکی از پروژه است. استفاده از شیوه های Agile مانند scrum ، برنامه نویسی extreme یا kanban نیز توصیه می شود. هنگامی که تجربه استفاده از Agile را به دست آوردید، می توانید ویژگی‌های بیشتری را اضافه کنید.

گام 2

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

گام 3

مطمئن شوید که صاحب محصول، تیم توسعه و تصمیم گیرندگان شما از نقش ها و مسئولیت های مربوطه آگاه هستند. هیچ پیش فرضی نزنید در صورت لزوم، همه را وادار کنید تا مانیفست Agile را تفسیر کنند.

گام 4

مطمئن شوید که با استفاده از مجموعه‌ای از ابزارها، همه می‌دانند که چگونه و کجا باید کار مشترک انجام دهند. مطمئن شوید که همه از کانال های ارتباطی جایگزین مانند لیست های mailing ، IRC و Skype اطلاع دارند.

گام 5

با تیم توسعه نرم افزار و صاحب محصول همکاری کنید تا اولین فرآیند تکراری (Sprint) را استراتژی‌بندی کنید. آنها را در مورد انتظارات تکرار اولیه آگاه کنید و بر این اساس با تکیه بر قابلیت دسترسی و مجموعه مهارت آنها برنامه‌ریزی کنید. یک Sprint”” باید یک تا دو هفته طول بکشد.

گام 6

پس از “جلسه برنامه ریزی Sprint”، تیم توسعه باید در سریع‌ترین زمان ممکن شروع به کدنویسی کند. به آنها اطلاع دهید که هدف اصلی شما این است که تا پایان اولین Sprint ، مجموعه‌ای از ویژگی‌های ساده اما کاربردی داشته باشید، و آنها می‌توانند تصمیم بگیرند که چه کاری انجام دهند.

نقشه راه محصول با تأثیرات ناشی از تغییر رویکرد به Agile جهت‌گیری جدیدی خواهد داشت

نقشه راه محصول می تواند به تبدیل رویکرد از Waterfall به Agile کمک کند. با استفاده از نرم‌افزار مدیریت محصول، می‌توانید چارچوب‌های محصول Agile  را به تکه‌های قابل مدیریتی تقسیم کنید که می‌توانند در یک Sprint کامل شوند. چارچوب‌های محصول Agile می‌تواند به تیم‌ها کمک کند تا با تقسیم ویژگی‌ها به وظایف کوچک، به سمت یک رویکرد Agile حرکت کنند. مدیران محصول می توانند در این شرایط از انواع ابزارهای چارچوب محصول بهره مند شوند.

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

Agile همچنین توانایی شرکت شما برای نظارت بر اثربخشی را افزایش می دهد و برای افزایش روحیه تیمی خوب است. حتی اگر تیم‌های مشترک کار خود را منتشر کنند و در پایان هر Sprint بازخورد دریافت کنند. از این رو، واقعاً می‌توان نتیجه گرفت که انتقال از Waterfall به Agile  امروزه یک معامله‌ای آسان است. در حالی که این معامله برای شرکت‌ها بسیار سودمند است.

منبع: HackerNoon  نویسنده: هلی پاتل