داستان یک کیک آف چابک – سیستم جامع مالی

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

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

بسیاری از فرآیندهای چابک در خصوص فاز ابتدایی شروع پروژه سکوت کرده اند و یا صرفا با ارایه یک سری روش این را از سر خود باز کرده اند. مثلا مفهوم اسپرینت 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 یا برپایی محیط تست و … )  ولی مواردی که قید شد را می توان به عنوان حداقل ها در نظر گرفت.

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

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

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

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

اسد صفری

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

6 دیدگاه

  1. شاهین   •  

    سلام
    مثل همیشه مقاله خیلی خوبی بود به خصوص اینکه نظریات و تجربیات شما واقعا همیشه برای خواننده هایی مثل من (که سالهاست برنامه نویسن و توجه خاصی هم به مسائل فرایند تولید نرم افزار نیز دارند) مفید و با ارزش هستند.
    ولی من میخوام یه ذره انتقاد کنم. من بارها در مقاله های مختلف شما دیدم که به خیلی از محصولات نرم افزاری به عنوان “پروژه” یاد کرده اید. حتی یک بار شما در مورد کلوچه سازی و توسعه نرم افزار نوشتید که خیلی جالب و در عین حال مهم بود و آنجا توسعه نرم افزار را چیزی متفاوت با تولید کلوچه خواندید. بهتر نیست این “پروژه” را با “محصول” جا به جا کنیم؟ چون پروژه باید تمام شود و تحویل داده شود ولی وقتی از محصول محصبت میکنیم تعریف چنین نقطه ای سخت و شاید ناممکن است و از طرفی نتیجه کار همیشه در حال بهبود و باعث رضایت کاربر است. در حقیقت حتی در متدلوژی های چابک نیز با تحویل های منظم و ذره ذره نبود نقطه پایانی برای یک محصول را جواب می دهیم. توجه دارید که حتی PM امروزه به product manager تعبیر میشود بیشتر تا مدیر پروژه. من واقعا تعجب کردم که شما در مورد یک سیستم جامع مالی به عنوان یک پروژه یاد کردید. به نظرم من deploy یک سیستم جامع میتوانید یک پروژه باشد ولی توسعه آن مسلما یک پروژه با ابتدا و انتهای مشخص نیست.
    انتقاد دوم من به این تعبیر “… بر اساس نیاز های سیستم (و نه بر اساس هیجان فنی ) …” می باشد. و این شاید دومین یا سومین بار است که شما روی آن تاکید کرده اید. در صورتی که ما میدانیم که ما در ایران همیشه در استفاده از تکنولوژی های روز عقب بوده و کاملا آشنا و راحت نیستیم. لابد به دلیل اینکه نه کنفرانسی هست نه مجموعه هایی که به دنبال آموزش و شناساندن آخرین تکنولوژی ها باشن. برای همین همیشه استفاده از تکنولوژی ها به عنوان هیجان فنی تلقی شده. که من فکر میکنم این اشتباه هست. و به عنوان کسی که سالهاست کد میزنم و پروژه ها و محصولات خوبی نوشته ام میدانم که فرق انگلار و ری اکت آنچنان کشنده نیست و انتخاب هریک میتواند کار را پیش ببرد و اینکه در ادامه دچار مشکل شویم صرفا ضعف تیم توسعه است. من جایی کار کرده ام که وقتی wpf و mvvm کار میکردیم (که چیز ساده و بزن بره نیست اصطلاحا). میگفتند من پروژه را به سمت شکست برده ام چون از win forms استفاده نکرده ام. و من میگفتم که اگه win form را بخواهید اصولی انجام دهید خیلی سخت تر خواهد بود و آنها اصلا نمیفهمیدند. و فکر میکردند که wpf و mvvm کار را سخت کرده در صورتی که کار اصولی سخت است و این ابزار اتفاقا آن را ساده کرده است. در صورتی که محصول نسبتا خوبی ارائه دادیم و تیم با اصول و توانمندی نیز برای آن شرکت فراهم کردیم. یک نفر آنجا نبود که بداند unit test چیست چه برسد به tdd ولی تا روز آخر افراد توانای تیم آدمهای خودخواه و دیکتاتوری شناخته میشدن که هیجان تکنولوژی دارند. پس حرف من این است که سواد کم تیم راهبری و تیم توسعه است که باعث میشود که فلان تکنولوژی بد باشد و فلان خوب. تصمیمات کلان هیچ کدام خوب نیستند. پس جنگ و دعوا بر سر مسائل کلان خیلی سودمند نیست. و اتفاقا جزئیات خیلی خیلی مهم اند و باید با دقت فراوان انجام و علامت گذاری و مستند شوند. اگر اجزا خوب انجام شوند حتی یک معماری غلط نیز میتواند موفق عمل کند (رجوع کنید به صدها کتابخانه ی سیستمی متن باز موجود. من خود تخصصم برنامه نویسی سیستمی و پردازش تصویر است و واقعا خنده ام میگیره وقتی میبینم عده ای برسر دو تکنولوژی مشابه جر و بحث میکنند. اگر بدانند کتابخانه های زیرساخت این کتابخانه های جاوا اسکریپتی در چه معماری ای نوشته شده اند آن وقت به حقیقت خواهند رسید.)

  2. شاهین   •  

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

  3. جواد   •  

    سلام
    ممنون از به اشتراك گذاري تجربيات با ارزشتون. اين نمونه ها و تجربه ها به همراه مفاهيمي كه منتشر ميكنيد منبع نايابي هستن كه متأسفانه نظيرشون تو فضاي محتواي فارسي اينترنت بسيار كم هست.
    باز ممنون از مطلب گرانقدر منتشر شده

  4. Pingback: دنیای چابک – گزارشی بر اولین دوره Disciplined Agile ایران

  5. تشکر از اشتراک تجربه تون اقای اسد صفری.
    به نظرم در بخش استخدام تیم توسعه فقط حضور یه معمار با تجربه کافی است و بر اساس انتخاب معماری در مرحله بعد باید تیم تشکیل شود.

پاسخ دهید

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