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

اما یک پروژه بزرگ چابک چگونه شروع می شود؟ یکی از موارد یا مشکلاتی که اکثر مواقع دیده شده این است که با فرض اینکه ما چابک هستیم هیچ پیش شروعی برای آغاز پروژه در نظر گرفته نمی شود و از روز اول شروع به کد نویسی می کنیم یا باز همانند فرآیندهای آبشاری فاز شناخت و تحلیل و طراحی می گذاریم منتهی با لفظ اس‍پرینت.

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

به تازگی در پروژه بزرگی که مربوط به سیستم جامع مالی یک موسسه مالی و اعتباری بود توانستیم تجربه ای داشته باشیم که اشتراک گذاری آن برای دوستان خالی از لطف نخواهد بود.

 

DAD یا Disciplined agile delivery یک الگوی خوب برای شروع پروژه ها

 

اگر با فرآیند DAD آشنا نیستید این نوشته مناسبی برای این منظور نیست و پیشنهاد می کنم این مطلب را مطالعه کنید.

در فرآیند Disciplined agile delivery فازی با نام Inception یا Envision داریم که همان سرآغاز ابتدایی پروژه و نسخه های مختلف است. مشخص بودن خروجی های این فاز کمک می کند تا تیم ها بتوانند با کمترین سردرگمی پروژه ها را شروع کنند.

هدف من توضیح فرآیند DAD نیست و بیشتر می خواهم تجربیاتم را با این فرآیند و ترکیب آن با دیگر روش های را توضیح دهم.

نخستین کار تشکیل تیم کیک آف است

اعضای تیم کیک آف می تواند شامل نقش های زیر باشد:

1- مربی چابک : برای راهبری کلی تیم کیک آف

2- مالک محصول یا مدیر محصول برای تعامل با ذی نفعان

3- معمار سیستم : برای مباحث فنی و انتخاب معماری

گام های یک کیک آف چه چیزهایی است؟

1- تشکیل تیم پروژه (می تواند شامل استخدام نیز باشد)

2- ایجاد سند چشم انداز

3- ایجاد بک لاگ اولیه محصول

4- ایجاد طرح اولیه انتشار محصول

5- شناسایی طرح کلان اولیه فنی پروژه

6 – انتخاب ابزار Issue tracking

7- برپایی محیط توسعه

تشکیل تیم پروژه

در این پروژه بدلیل اینکه ما تیم برنامه نویسی نداشتیم مجبور بودیم نفرات را استخدام کنیم. برای اینکه بدانیم چند نفر را به چه تخصص هایی نیاز داریم ابتدا نیاز داشتیم تا طرح کلان اولیه فنی پروژه شناسایی شود. اما چند نفر؟ ما در اینجا بر اصل MVT یا Minimum Viable Team استوار بودیم یعنی تیم حداقلی که می تواند کار را با سرعت شروع به جلو ببرد.

 

شناسایی ذی نفعان سیستم

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

مثلا در این سیستم می توان گفت : کارمند باجه – رییس با جه – رییس شعبه – کارمند امور شعب – رییس امور شعب و … .

از ذی نفع نباید پرسید که چه قابلیتی می خواهی؟

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

حقیقتا هدف ما از تولید نرم افزار راحت تر کردن زندگی ذی نفعان مان است نه اینکه آن را سخت تر بکنیم.

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

زمانی که از ذی نفع بپرسید چه می خواهی – خواهد گفت نمیشه این اعداد خودکار بیایند داخل اکسل؟ سوال اساسی این است آیا نمی شود همین سیستم دستی به جای فایل اکسل در قالب یک داشبود به صورت اتوماتیک همین کار را انجام دهد؟  این همان مثالی است که آقای فورد گفت؛ از مردم بپرسی چه می خواهی خواهند گفت اسب های تند تر ولی ما برای آنها اتوموبیل ساختیم.

درک نیازها و مساله ها یا به اصلاح نقاط درد ذی نفعان کمک خواهد کرد تا یک سری قابلیت به درد نخور تولید نکنیم.

ایجاد سند چشم انداز

به طور کلی سند چشم انداز در یک کلمه یعنی “چرا” : چرا این پروژه انجام می شود؟ ساختار سندی که ما داشتیم به این صورت بود :

1- عنوان پروژه

2- منافع تجاری : پس از اجرای این پروژه چه منافعی نصیب سازمان  می شود

3- ذی نفعان سیستم

4- مشکلات و مسایل : هر ذی نفع چه مساله دارد؟ مثلا رییس باجه مجبور است تمامی مراحل کنترل سقف مجاز وام را دستی انجام دهد و این بسیار زمان بر و خسته کننده است.

5- ویژگی و قابلیت های عمده سیستم

6- ویژگی های مهم غیر کارکردی سیستم : مثلا این سیستم باید قابلیت گسترش پذیری بالایی داشته باشد.

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

 

ایجاد بک لاگ اولیه محصول

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

 

Epic – > Feature – > User story

 

برای مثال

مدیریت مشتریان > پروفایل > مشاهده پروفایل

مدیریت مشتریان > پروفایل > ثبت کامنت ملاحظات

مدیریت کاربران > مدیریت سطوح دسترسی > تعریف نقش ها

در ابتدا ما سعی کردیم اکثر زیر سیستم ها و Epic های سیستم را کشف کنیم. قصد ما از اینکار شناسایی دامنه کلی سیستم برای مدیریت دامنه سیستم بود. پس از اینکار با الویت بندی سیستم ها و Epic ها اقدام به استخراج جزپیات مربوطه مهترین آنها کردیم. به صورتی که جزپیات 20٪ Epic مهم را در آوردیم و آنها را در قالب بک لاگ داخل فایل اکسل مکتوب کردیم.

ایجاد طرح اولیه انتشار محصول

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

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

شناسایی طرح کلان اولیه فنی پروژه

یکی از مهمترین کارهای در این بخش انتخاب معماری کاندید و طرح کلان فنی پروژه است. یعنی این پروژه قرار است بر اساس چه طرحی جلو برود؟ اینکه معماری چند لایه است؟ آیا معماری سرویس گرا است؟ از روش Domain driven می خواهیم استفاده کنیم؟ دیتابیس چه چیزی می خواهد باشد؟ دات نت یا جاوا؟ وب اپ یا دسکتاپ اپ؟

وجود یک نفر معمار خوب و با تجربه نجات بخش شما خواهد بود زیراکه تصمیمات فنی در این بخش بسیار حیاتی خواهند بود و معماری که بتواند بر اساس نیاز های سیستم (و نه بر اساس هیجان فنی ) معماری سیستم را انتخاب کند یک موهبت الهی است.

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

1- بهتر است در همین فاز یک نمونه کوچک با معماری انتخاب شده انجام شود تا ریسک پیاده سازی کشف شود شاید ما توانایی اجرای چنین تکنولوژی را نداشته باشیم یا این از نظر زمانی برای ما صرف نداشته باشد

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

انتخاب ابزار Issue tracking

درست است که کار با استیکی نوت ها جذاب است ولی در پروژه های بزرگ تر وجود یک ابزار تعاملی  بسیار مهم است، ابزاری که بتواند :

1- باعث شفافیت تمامی مصنوعات برای ذی نفعان شود

2- بک لاگ محصول را در اختیار همه قرار دهد

3- قابلیت پیگیری و رهیگیری تغییرات را داشته باشد

4- وجود ابزار مستند سازی

ابزارهایی مانند Jira – TFS  – Version One  یا صد ها ابزار دیگر. در انتخاب ابزار به تجربیات قبلی تیم و تکنولوژی هایی که انتخاب کردید دقت داشته باشید مثلا دات نتی ها با TFS راحت تر خواهند بود.

برپایی محیط توسعه

شاید آخرین کار برپایی محیط توسعه و شروع تولید باشد که می تواند شامل :

1- نصب سرور توسعه

2- نصب نرم افزار مدیریت Source

3- نصب ابزار های توسعه

4- آماده سازی کامپیوترهای برنامه نویسان

 

شاید به جز این موارد کارهای دیگری نیز باشد که بتوان در این فاز انجام داد (مانند نصب و راه اندازی ابزار Continuous Integration یا برپایی محیط تست و … )  ولی مواردی که قید شد را می توان به عنوان حداقل ها در نظر گرفت.

چابک و موفق باشید