چگونه از متدولوژی اجایل - اسکرام برای ایجاد یک محصول نرم افزاری استفاده کنیم ؟

مراحل مختلف برای حاضر کردن یک قهوه شاید در نگاه اول بسیار ساده باشد. اما همین مراحل ساده می تواند نتایج بسیار متفاوتی را ایجاد کند. هر چقدر انجام یک فرایند پیچیده تر باشد نیاز به ابزارهایی جهت کنترل این پیچیدگی، بیشتر می شود. کتاب های آشپزی یکی از این ابزارها هستند که آشپزها را در پختن یک غذا کمک می کنند.

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

متدولوژي خط مشي‌هاي گام به گام موسسه‌ها وشركت‌ها است كه براي تكميل يك يا چند مرحله از مراحل چرخه‌ي تكاملي به كار گرفته مي‌شود . هر متدولوژي تكنيك‌ها و استانداردهاي خاص خود را به چرخه‌ي تكاملي تحميل مي‌كند.

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

محصول نرم افزاری همواره نیازمندی های سمت کاربر نهایی را هدف قرار داده و سعی در حل پیچیدگی های مختلف در دل خود داشته و نهایت امر لذت استفاده از محصول را به کاربر نهایی ( مشتری)‌ عرضه می کند.

نیاز مندی های مشتری در متدولوژی اجایل - اسکرام با عنوان داستان مشتری User Story شناخته می شود. این داستان ها در مجموعه product backlog گردآوری می شود تا بتوان بر اساس نیازهای مشتری اولویت بندی شود. مسوولیت این اولویت بندی و گردآوری آن بر عهده product Manager است.

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

برای مدیریت زمان ،‌هماهنگی جلسات و مانیتور کردن پیشرفت کار، فرد دیگری به نام اسکرام مستر در کنار تیم برنامه نویس ها و تست کننده ها قرار می گیرد.

اگر نمی توانید اندازه بگیرید،‌ پس نمی توانید پیشرفت کنید. پیتر دراکر

برای اینکه بتوان میزان ظرفیت تیم و میزان بهره وری آن ها را سنجید باید به هر user Story یک وزن اطلاق شود . واحد این وزن Story Point می باشد.

اما در باره نحوه وزن دادن هر داستان : ساده ترین درخواست مشتری را انتخاب کنید . به آن Story Point 2 بدهید. موارد دیگر باید بر اساس رابطه سختی آن ها با این داستان وزن دهی شوند. مورد بعدی را انتخاب کنید اگر دو برابر سخت تر از این داستان بود به آن ۴ و اگر کمی سخت بود به آن ۳ و اگر به سختی این داستان بود به آن ۱ بدهید .

تعداد زیادی user Story در مجموعه product backlog ( لیست آرزومندی) جمع آوری شده است. نیاز داریم که تعداد زیادی کار را انجام دهیم. ابتدا اولویت بندی user Story ها که توسط product Manager انجام شد، سپس بررسی میزان ظرفیت تیم و اکنون شاخص زمان را نیاز داریم که وارد بازی کنیم.

با توجه به اینکه اسکرام یک چرخه تکراری است و ما نیاز داریم این چرخه زمانی را مشخص کنیم.

ما هر کدام از این بازه های زمانی که برای انجام تعداد مشخصی از user Story ها در نظر می گیریم، Sprint (اسپرینت) می خوانیم.

و همانند product backlog که شامل همه user story های موجود است، Sprint Backlog تنها شامل user Story های انتخاب شده برای اسپرینت بخصوص می باشد.

به طور خلاصه تیم بر اساس ظرفیت و یا سرعت خود و رعایت اولویت های مالک محصول تعدادی User Story را از داخل Product Backlog انتخاب و به داخل Sprint Backlog کپی می کند. این فعالیت در طی جلسه برنامه ریزی اسپرینت و یا Sprint Planning انجام می شود . این جلسه در ابتدای هر اسپرینت برگزار می شود.

حال در انتهای زمان هر اسپرینت می توان اندازه گیری کرد که آیا تمام تعهدات انجام شده است یا نه ؟‌ آیا همه story ها تکمیل و تست و قابل ارائه به مشتری هست یا نه ؟ این جلسه که در پایان هر اسپرینت برگزار می شود به اسم sprint Review شناخته می شود.

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

با توجه به اینکه یک اسپرینت در زمان خود انجام شده یا نه می توان آماری را بدست آورد و این آمار را به صورت نموداری به نام burn down chart نمایش داد.

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

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

▪ کدامیک از عملکردهای ما درست بود؟

▪ کدامیک از عملکردهای ما نیاز به اصلاح دارد؟

▪ چه بهبودهایی را می توان برای آینده در نظر گرفت؟

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

می توانید از لینک زیر آموزش تصویری را مشاهده کنید تا اطلاعات بیشتری را کسب کنید.

فریم ورک اسکرام در ۲۰ دقیقه

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

علی صمدی