خانه > Agile, Scrum > نجات پروژه شکست خورده توسط اسکرام

نجات پروژه شکست خورده توسط اسکرام


https://sirasad.files.wordpress.com/2011/02/cpr2-300x300.jpg?w=300شاید این حقیقت بسیار تلخی باشد که در عرصه صنعت توسعه نرم افزار تعداد زیادی از پروژه ها با شکست مواجه و در برزخ گرفتار می شوند. نجات دادن و یا بازگردانی این پروژه ها بر روی ریل معمولا کار سختی است زیرا زمانی متوجه می شوند  پروژه مرده است که دیگر امکان بازگردانی وجود ندارد یا حداقل خیلی سخت است.

علت اینکه بازگردانی این پروژه ها سخت یا غیر ممکن می شود این است که دیر متوجه می شویم (دیر با واقعیت روبرو می شویم) پروژه شکست خورده است و در این موقع هم اکثر پل های پشت سرمان را بدون اینکه بدانیم شکسته ایم… . کنترل پروژه رفته رفته از دست خارج شده است – اصلا معلوم نیست چه میزانی از پروژه تکمیل و چه میزانی باقی مانده است – خروجی ها ارائه شده پر از مشکل می باشد – مشتری اعصبانی است – اعتماد بین اعضای تیم از بین رفته است و خبری هم از کار تیمی نیست و … .

در این مواقع اسکرام می تواند کمک کننده به احیای پروژه باشد. یعنی در هر جایی از پروژه که بودیم و با هر متدی که کار می کردیم می توانیم از این به بعد دست به دامن اسکرام شویم تا شاید اوضاع روبراه شود.

اولین کاری که اسکرام می تواند برای اینگونه پروژه ها انجام دهد این است که مشخص نماید هم اکنون پروژه در چه وضعیتی است زیرا که خاصیت شفاف سازی پروژه یکی از مزایای اصلی اسکرام می باشد. شفاف سازی اوضاع باعث می شود همه با واقعیت موجود روبرو شوند و مثلا از دادن قول هایی مانند «تا آخر هفته پروژه تکمیل است»پرهیز نمایند و بر اساس واقعیت ها برنامه ریزی نمایند.

شاید سوال پیش بیاید که چگونه باید شفاف سازی کرد؟

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

بک لاگ موارد ساخته نشده که دقیقا مانند بک لاگ محصول می باشد و بک لاگ موارد مشکل دار و تست نشده هم شامل آیتم هایی خواهد بود که یا تست نشده اند (تست پذیرش مشتری و تست یکپارچه سازی و … ) و یا مشکل دار هستند. گذشته از اینکه یک یا دو بک لاگ داشته باشید باید بک لاگ (ها) را برآورد نمایید که آن هم بر اساس Story Point  خواهد بود.

سپس برای شفاف سازی بیشتر 2 اسپرینت معمولی را با استفاده از آیتم های بک لاگ (های) ایجاد شده اجرا می کنیم. اسپرینت ها هم دقیقا مانند اسپرینت های معمولی اسکرام اجرا خواهند شد. اجرای این 2 اسپرینت برای بدست آوردن ظرفیت و سرعت تیم (ها) در طول پروژه می باشد. به عبارتی با یک حساب 2 × 2 تا می فهمیم که حدودا چه زمانی می توانیم پروژه را با افراد موجود به سرانجام برسانیم و این یعنی شفاف سازی پروژه.

https://sirasad.files.wordpress.com/2011/02/wayne-rooney-007.jpg?w=460 فرض کنید یک پروژه با زمان 1 سال داشتیم و بعد از 9 ماه فهمیدیم که در حال کج روی هستیم و خواستیم شفاف سازی نماییم. بعد از شفاف سازی فهمیدیم 200 پوینت آیتم داریم و 3 ماه هم وقت. طول اسپرینت های ما هم 4 هفته بود و با اندازه گیری سرعت به این نتیجه رسیدیم که تیم قادر است در هر اسپرینت 10 پوینت انجام بدهد. حالا این 200 پوینت با این سرعت 10 پوینتی به چند ماه کار نیاز دارد؟

بعد از این , مشکل مدیریتی خواهد بود. مثلا مدیریت می تواند با افزایش تعداد نفرات و تیم ها سرعت و ظرفیت انجام کار را بالا ببرد و یا می تواند با رایزنی از دامنه پروژه بکاهد و یا امثالهم.

اما بهترین تصمیم و یا عملکرد مدیریتی در این شرایط می تواند رفع موانع و درگیری های موجود می باشد, موانعی مانند موارد زیر :

  • فشار بر روی تیم
  • تست ها و پروسه های غیر موثر (مانند قوانین کدنویسی شرکتی)
  • فقدان کار تیمی و انگیزه در نفرات
  • انتظارات غیر واقعی
  • عدم تمرکز شرکت بر روی پروژه
  • مدیریت دستور- و – کنترل به جای خود سازماندهی

هر یک از این موارد ذکر شده تاثیر به سزایی بر روی ظرفیت و سرعت تیم و دیگر المان های موفقیت پروژه خواهد داشت مثلا فشار بیش از حد روی تیم باعث از بین رفتن انگیزه در تیم می شود و این نیز باعث افت شدید سرعت خواهد شد و … .

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

یاشیاسیز

Advertisements
  1. داریوش
    فوریه 25, 2011 در 10:48 ب.ظ.

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

    بار دیگر به نظر همه جانبه به روشمندی‌های چابک توصیه می‌کنم و از ارائه آن به عنوان راه حل عمومی برای تمام مشکلات ایجاد نرم‌افزار به شکل آنی برائت می‌جویم!

    • فوریه 26, 2011 در 6:13 ق.ظ.

      از تذکر به جای حضرت عالی تشکر می کنم و قصد بنده هم این بود در نوشته های بعدی به این بپردازم که اسکرام و یا هر روشی Silver Bullet نیست و شاید دوای درد شرکت شما این نباشد. البته باید به این نکته هم توجه کرد که منظور این نوشته بیشتر به صورت عام و در شرایط تقریبا ایده آل و شرکت ها و افراد چابک شونده بود و نه موارد خاص.

      با تشکر

  1. No trackbacks yet.

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

%d وب‌نوشت‌نویس این را دوست دارند: