Scrum_6374359_m_PAID-1024x412

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

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

بنابراین تصمیم گرفتم آموزشی در این مورد داشته باشم.

تعیین نقش ها و افراد:

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

قدمی بعدی پیدا کردن مالک محصول (product owner) است

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

ساخت Backlog محصول

شما در این مرحله باید Backlog محصول را درست نمایید و یا اینکه تسهیلاتی ایجاد نمایید که تیم اسکرام این کار انجام دهند . تاکید می شود که این کار حتما و حتما باید با حضور مالک محصول و یا افراد ذینفع محصول انجام گیرد .

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

نیاز های عملیاتی (Functional)باید به صورت یک ویژگی (Feature) در Backlog  محصول ثبت شود . نیازهای غیر عملیاتی (Non-functional) را نیز می توان در Backlog قرار داد , برای مثال “محصول نیاز دارد که سریعتر کار کند” یا “ما باید مطمئن شویم که محصول کاملا امن است” و… . این موارد همه ویژگی محصول نیستند ولی می توان به عنوان یک آیتم توجیه پذیر در Backlog ثبت کرد.

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

موارد پایین نیز بسیار موثر می باشند:
اولویت بندی در حقیقت یک مسئله تجاری می باشد : مالک محصول می تواند با تزریق پول زیاد به گروه , آیتم ها زیادی را زودتر تحویل بگیرد و یا برعکس هر آیتم به صورت طولانی مدت در صف بماند . پس این مشکل اسکرام مستر نیست که یک آیتم زود تحویل داده شد و یکی دیرتر و این مورد را می تواند مالک محصول مدیریت بکند.
البته مواردی که در بالای لیست و یا در اول صف می باشند بدلیل اهمیت آنها برای صاحب محصول به مراتب سریع تر از آیتم های بعدی تکمیل خواهند شد.
مطلب بسیار مهمی که باید در هر آیتم مد نظر گرفته شود این است که , هر آیتم باید به صورت کاملا جداگانه تعریف شود و نه به صورت جزئی از یک شبکه به هم پیچیده . در صورتی که شما به صورت جداگانه هر بخش را تعریف نمایید , پس نتیجه هر بخش قابل ارائه (Deliverable) می باشد .این بزرگترین مزیت اسکرام می باشد که در هر مرحله , خروجی قابل ارائه به مشتری است و مشتری می تواند از آن استفاده نماید.
اما این کار مارا در طراحی لاگ های Backlog مشکل می کند , بدلیل اینکه باید دقت نماییم از هم پیوستگی اجزای متفاوت تا جایی که ممکن است بپرهیزیم در غیر اینصورت کل اسکرام و مدیریت ما زیر سوال میرود.

چگونگی برآورد Backlog محصول

برای اینکه بتوان اندازه هر آیتم Back log محصول را فهمید نیاز داریم تا بر آورد در سطوح بالا انجام بپذیرد .
فهمیدن این موضوع برای ما بسیار سودمند است زیرا این مورد ما را در اولویت بندی ها یاری خواهد رساند . یا اگر بخواهیم از منظر مدیریتی به این مسئله نگاه کنیم , این یک دیدگاه یا perspective به مدیریت پروژه در مورد این که تیم های کاری برای تولید این محصول چه قدر باید کار کنند خواهد داد.

منظور از برآورد سطوح بالا این است که بدلیل اینکه آگاهی ما در مورد هر آیتم Backlog بسیار ناچیز می باشد و ما دقیقا شاید با ریز آیتم ها آشنا نباشیم پس نمی توانیم از پایین به بالا برویم پس باید از بالا به پایین بیاییم .

برآورد توسط سیستم امتیاز دهی
شاید شما با سری اعداد فیبو ناچی آشنا باشید. این سری اعداد مربوط به قوانین توزیع می باشند.

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

خوب حالا می خواهید یک گزارش دیگر طراحی کنید . حالا کار شما راحت است چونکه قبلا گزارشی با امتیاز ۳ در دست دارید . خوب نسبت به پیچیدگی به گزارش قبلی به این هم می شود امتیاز داد. اگر ۲ باشد خوب یکم راحت تر از مورد قبلی می باشد و اگر ۲۱ باشید این بسیار مشکل تر می باشد .
می توان با جمع بندی این امتیاز ها , زمان انجام هر آیتم بک لاگ رو اندازه گرفت و به این خواهیم گفت Measurement

مطالب مطرح شده اولین گام در استفاده از روش scrum برای مدیریت پروژه بود.

دیدگاه کاربران