یه ذره دیگه

زمانی که مدرسه می رفتیم و صبح زود برای کسب علم از خواب ناز بیدارمون می کردن همیشه از دیالوگ های مشهور «فقط 5 دقیقه دیگه یا یه ذره دیگه یا …»  استفاده می کردیم ، حالا در صنعت توسعه نرم افزار هم بعضا مدیران یا ارایه دهندگان محصولات با چنین مشکلی مواجه می شوند و آنها هم احتمالا به مشتری می گویند «حالا این مورد رو هم اضافه کنیم یا حالا این رو هم درست کنیم و…» .

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

 »استفاده» مانند اکسیژن برای ایده ها می باشد. در حقیقت شما نخواهید دانست که یک قابلیت و امکان ضروری می باشد تا زمانی که ضرورت آن ثابت شود و چه زمانی بهتر از استفاده کاربران.

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

یاشیاسیز

همه چیز Timebox هست

امیر مهرانی در وبلاگ خود مطلبی با عنوان ‹مدیریت زمان با تکنیک Time Boxing ‹ نوشته است که بی ربط با مطالب ارائه شده درباره اسکرام و Agile نیست. همانطور که در مطالب و نوشته های در مورد اسکرام خوانده اید تمام جلسات و رویداد ها در اسکرام Time Boxed می باشند به عبارتی هر جلسه و یا رویداد مانند یک اسپرینت قبل از شروع زمان یا طول آن تعیین می شود سپس رویداد مورد نظر به اندازه در نظر گرفته شده اجرا می شود.

تمام نکات مثبت اشاره شده در نوشته یاد شده در رابطه با Time Boxing در اسکرام نیز صدق می کند. برای مثال در نوشته می خوانیم :

Time Boxing به شما کمک می‌کنه تا بتونید برای یک کار محدوده های زمانی کوتاه تعریف کنید. مثلا برای ۳۰ دقیقه روی کار مشخصی متمرکز شوید و آن را به بهترین نحو ممکن انجام بدهید.

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

انجام کار به صورت Time Boxing علاوه بر ایجاد تمرکز روی کار مورد نظر موجب ایجاد روحیه و انرژی در نفر(ات) می شود. بدین صورت که از تکراری شدن کار جلوگیری می کند , هر وقت که به قول امیر مهرانی نفر می خواهد غرق کار شود دینگ Time Boxing نفررا به شروع یک TimeBox جدید دعوت می خواهد کرد و مسلما در این تایم جدید تغییراتی برای بهبود اوضاع نسبت به تایم قبلی ایجاد خواهد شد که این نیز باعث بهتر شدن کار و با انگیزه شدن نفر نیز خواهد شد.

البته کار به صورت Time Boxingدر ابتدا کمی سخت است بخصوص برای ما که عادت داریم یا کاری را شروع نمی کنیم و یا اگر می کنیم تا تمام نکنیم ازش دست نمی کشیم. برای شروع می توانید از روش پامادور که یک روش Time Box هست نیز استفاده نمایید.

یاشیاسیز

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

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

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

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

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

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

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

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

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

فرض کنید یک پروژه با زمان 1 سال داشتیم و بعد از 9 ماه فهمیدیم که در حال کج روی هستیم و خواستیم شفاف سازی نماییم. بعد از شفاف سازی فهمیدیم 200 پوینت آیتم داریم و 3 ماه هم وقت. طول اسپرینت های ما هم 4 هفته بود و با اندازه گیری سرعت به این نتیجه رسیدیم که تیم قادر است در هر اسپرینت 10 پوینت انجام بدهد. حالا این 200 پوینت با این سرعت 10 پوینتی به چند ماه کار نیاز دارد؟

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

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

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

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

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

یاشیاسیز