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

http://blog.irscrum.com/wp-content/uploads/2011/02/cpr2-300x300.jpg?w=300شاید این حقیقت بسیار تلخی باشد که در عرصه صنعت توسعه نرم افزار تعداد زیادی از پروژه ها با شکست مواجه و در برزخ گرفتار می شوند. نجات دادن و یا بازگردانی این پروژه ها بر روی ریل معمولا کار سختی است زیرا زمانی متوجه می شوند  پروژه مرده است که دیگر امکان بازگردانی وجود ندارد یا حداقل خیلی سخت است.

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

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

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

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

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

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

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

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

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

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

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

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

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

یاشیاسیز

اگر به تازگی با چابک یا اسکرام آشنا شده اید پیشنهاد می کنم این کتابچه چند صفحه را بخوانید و اگر مطالب بیشتری نیاز داشتید شاید این مطلب اول تا آخر چابک برای شما مفید باشد.

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

4 دیدگاه

  1. داریوش   •  

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

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

    • Asad Safari   •  

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

      با تشکر

  2. مريم   •  

    سلام متن بسيار خوبي بود .چند تا سوال داشتم كه اگر جواب بدبد ممنون مي شم
    1.در جايي خوندم كه از اسكرام در پروژه هاي كوچك استفاده مي كنند و در اين اندازه بسيار كار آمد است. آيا در پروژه هاي بزرگ نمي توان از اسكرام بهرهمند شد؟

    2.ارتباط اسكرام و ويژوال استوديو 2010.آيا فيچر خاصي در 2010 اضافه شده كه محيطي را براي كار با اسكرام آماده مي كند .؟؟

    3.ارتباط دقيق اسكرام با TFS
    ممنون…

    • admin   •  

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

      http://groups.google.com/group/iran-agile-community

      موفق باشید

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *