در این مقاله قصد داریم شما را با یک فریمورک توسعه نرم افزار بنام اسکرام (Scrum) آشنا کنیم. در هر پروژه‌ای، زمانبندی یکی از عوامل مهم در موفقیت است. احتمالا اولین سوالی که برایتان پیش می‌آید این است که اسکرام چیست؟ برای آشنایی کامل با اسکرام با ما همراه باشید.
اسکرام چیست؟
اسکرام یک فریمورک توسعه نرم افزار اجایل است. در واقع می‌توان گفت یکی از مشهورترین آنهاست. در حال حاضر 70 درصد شرکت‌های توسعه نرم افزاری در حال استفاده از اسکرام هستند، یا از اسکرام به همراه یکی دیگر از سیستم‌های توسعه مانند XP استفاده می‌کنند.
نکته مهمی که باید به آن اشاره کنیم این است که بدانید اسکرام و اجایل یک چیز نیستند. اجایل مفهومی است که بسیاری از فریمورک‌ها و متدولوژی‌ها بر اساس آن ساخته شده است و اسکرام یکی از آن فریمورک‌ها است. به بیان دیگر اسکرام یک امکان ویژه است که شما مفهوم اجایل را در دنیای واقعی تمرین کنید.
معرفی سیستم‌های اجایل
- Scrum: اسکرام اواخر دهه 90 میلادی عرضه شده است و یک فریمورک ساده و سبک است.
- DSDM: از نظر زمان عرضه تقریبا هزمان با اسکرام است و بیشتر به خاطر سازگاری با PRINCE2 طراحی شده است.
- XP: از سال 1990 بیشتر برای تمرین در توسعه نرم افزار اعم از برنامه نویسی دونفره، توسعه آزمون محور و غیره استفاده می‌شود.
Kanban (ScrumBan): کنبان بیشتر به عنوان یک تکنیک در تولید شناخته شده است، اما به طور ترکیبی با اجایل نیز استفاده می‌شود، همچنین می‌تواند به همراه برخی المان‌های اضافی به عنوان یک سیستم استفاده شود.
اجایل چیست؟
بسیاری از مردم درک درستی از اجایل ندارند، در حالی که بسیار ساده است. در واقع اجایل به جای استفاده از یک سیستم پیشگو از یک توسعه تطبیقی استفاده میکند.
حال سوال اینجاست که سیستم‌های توسعه پیشگو و سیستم‌های توسعه تطبیقی چیستند؟
توسعه پیشگو (Predictive development)
توسعه پیشگو زمانی کاربرد دارد که شما دقیقا می‌دانید که قرار است چه محصولی را تولید کنید. بنابراین با برنامه‌ریزی و طراحی محصول از قبل همه مراحل را پیش‌بینی می‌کنیم و سپس هدف ما پیروی از برنامه‌ها و تولید محصول است. این روش همان روش سنتی است که در صنعت IT به آن آبشار (waterfall) نیز گفته می‌شود.
سوالی که در اینجا مطرح می‌شود این است که چرا نمی‌توانیم در برخی از پروژه‌ها پیشگو باشیم؟ پس چه کاری می‌توانیم انجام دهیم؟
سازگاری (Adaptation)
زمانی که همه چیز از قبل مشخص نیست و نمی‌توانیم از یک سیستم پیشگو استفاده کنیم، یک سیستم انطباقی جایگزینی عالی است. سیستم‌های انطباقی معمولاً "اجایل" نامیده می‌شوند. این سیستم زمانی کاربرد دارد که نتیجه‌ای در ذهن داریم اما نمی‌دانیم چه نوع محصولی می‌تواند آن نتیجه و هدف را تولید کند و بنابراین پیش‌بینی امکان‌پذیر نیست. دقیقا همان زمانی که درک درستی از بازار و مشتری وجود ندارد و بازار دائما در حال تغییر است.
در این حالت، تعدادی چرخه خواهیم داشت. در هر چرخه، زیرمجموعه‌ای از محصول طراحی، برنامه‌ریزی، ساخته، آزمایش و برای استقرار آماده می‌شود. ما آن را در اختیار مشتری یا کاربر نهایی قرار می‌دهیم و بازخورد دریافت می‌کنیم. ما براساس بازخورد "سازگار" خواهیم شد. ما درک می‌کنیم که خروجی چرخه بعدی باید چه باشد.
چرخه‌ها اجرا می‌شوند، تا زمانی که مقدار کافی در جدیدترین محصول ایجاد شود و ما به اندازه کافی به نتیجه مورد انتظار نزدیک شویم، این سازگاری است.
این نوع سیستم همان اجایل است که از آن به نام مدرن نیز یاد می‌شود که رابطه آن متناظر است با متدهای پیشگو که سنتی نامیده می‌شوند.
آیا اجایل جدید است؟
در مورد اینکه اجایل جدید است یا خیر؟ می‌توان گفت این مفاهیم از قبل وجود داشته است اما سیستم اجایل جدید است. همانطور که امروزه ما سازگاری را به عنوان یکی دیگر از روش‌های مناسب توسعه پذیرفته‌ایم. البته باید گفت که روش‌های پیش بینی "اشتباه" نیست و در واقع هر دو معتبر هستند و ما باید درک کنیم که کدام یک مناسب پروژه است.
شروع پروژه
اولین قدم برای شروع پروژه ایجاد بک‌لاگ محصول (Product Backlog) یا همان لیست فیچرهای پروژه است. در واقع ما دامنه پروژه را تعریف می‌کنیم.
ایجاد بک‌لاگ به معنی برنامه‌ریزی نیست، زیرا اسکرام پیشگو نیست در واقع ما به جای ایجاد بک‌لاگ کامل محصول، فقط موارد کافی را برای چند چرخه بعدی (ایتریشن یا اسپرینت نیز گفته می‌شوند) تعریف می‌کنیم. چرخه اول را شروع می‌کنیم و به صورت تطبیقی بروزرسانی بک‌لاگ محصول را ادامه می‌دهیم.
یکی از اصول اجایل سادگی آن است و ما می‌توانیم به جای استفاده از نرم افزار، بک‌لاگ محصول را روی کارت‌های یادداشت یا برگه‌های یادداشت چسبنده ایجاد کنیم.
این سوال مطرح می‌شود که در بک‌لاگ محصول چه آیتم‌هایی قرار می‌گیرند؟ آیا آیتمی مانند "ساخت معماری راه حل" در بک‌لاگ قرار می‌گیرد؟
آیتم‌های بک‌لاگ محصول
قرار دادن آیتمی مانند "ساخت معماری راه حل" در بک‌لاگ محصول کار درست نیست، زیرا این کار پیشگویی است.
در اینجا ما فقط توابع را داریم. یعنی مواردی که مشتری می‌تواند آنها را درک کند و در صورت تولید می‌تواند آنها را امتحان کند و به ما بازخورد دهد. به همین دلیل آیتم‌های موجود در بک‌لاگ باید دارای دو ویژگی زیر باشند:
غیر فنی باشند
از موارد مطرح شده در بک‌لاگ برای ارتباط با مشتری استفاده می‌کنیم و مشتری دانش فنی ندارد. در یک رابطه درک متقابل کلید موفقیت است. مشتری در این ارتباط باید راحت باشد تا بتواند در پیشرفت کار کمک کند.
باید از یکدیگر مستقل باشند
باید بتوانیم هریک از موارد بک‌لاگ را براساس ارزش تجاری آنها مرتب کنیم و بر موارد مهم‌تر تمرکز کنیم.
نکته: یک گزینه عالی برای موارد بک‌لاگ استفاده از "داستان های کاربر" است. داستان کاربر چیست؟استوری‌‌های کاربر (user stories) چیست؟
یک روش خوب برای نوشتن آیتم‌های بک‌لاگ محصول، استفاده از داستان‌های کاربر یا در واقع همان انتظاراتی است که کاربر با زبان و درک خود آنها را بیان میکند. به طور مثال یک کاربر نهایی، میخواهم گزارشی از فعالیت حساب خود دریافت کنم، تا بررسی کنم که همه چیز خوب است یا خیر. بله این انتظار به عنوان یک چرخه بسیار کوچک است اما مدیریت پروژه آسان می‌شود. ما می‌توانیم در هر تکرار چندین آیتم انجام شده 100% را به جای یک مورد بزرگ و ناقص داشته باشیم، که به سختی کامل می‌شود، نمی‌توان آن را مدیریت کرد و زمان واقعی اتمام آن را بیان کرد.
مثال زیر، یک قالب کلی برای یک یوزر استوری است:
به عنوان یک نقش کاربری، عملکردی را میخواهم، [بنابراین هدف اینه]
بخش سوم اختیاری است؛ هنگامی که خیلی بدیهی است از نوشتن آن صرفنظر می‌کنیم. برای مثال؛ به عنوان یک مدیر سیستم، میخواهم پسوردها را ریست کنم.
بنابراین، درباره‌اش چه فکری می‌کنید؛ به عنوان یک مدیر سیستم، میخواهم یک دیتابیس SQL برای سیستم داشته باشم، آیا یوزر استوری دارای ساختار خوبی است؟
خیر. به دلیل اینکه بخش دوم یوزر استوری باید درباره یک اکشن باشد، این بخش درباره انجام دادن کارهایی است، نه داشتن چیزهایی آیا می‌دانید چه کسی آیتم‌های بک‌لاگ محصول را ایجاد کرده است؟
مالک محصول The Product Owner
مالک محصول مسئول ساختن آیتم‌های بک‌لاگ محصول است.
برای هر پروژه، یک مالک محصول تمام وقت یا نیمه وقت وجود دارد که دائما با مشتری در تماس است و نیازهای او را درک و به آیتم‌های بک‌لاگ اضافه میکند. صاحب محصول باید یک تحلیلگر تجارت نیز باشد تا بتواند موارد بک لاگ را اولویت‌دهی و در هر تکرار اولویت‌ها را بروزرسانی کند. ممکن است در پی ارتباط با مشتری و نیاز سنجی یک مورد از انتهای لیست بک‌لاگ به ابتدا منتقل شود. بنابراین، ما فقط چند روز را صرف ایجاد آیتم‌های کافی در بک‌لاگ محصول می‌کنیم و سپس تکرار اول را شروع می‌کنیم. این تکرارها در اسکرام، اسپرینت نامیده می‌شوند.
هنگامی که قصد شروع استفاده از اسکرام در یک شرکت را داریم، یکی از جدی‌ترین مشکلاتی که وجود دارد ایجاد تطابق بین نقش‌های قدیمی با نقش‌های جدید است. گاهی اوقات اصلا نمی‌توانیم نقشی برای یک شخص بیابیم! به هر حال، راهکار مناسب این است که درباره شیوه تطابق افراد در پروژه و شرکت فعلی خود فکر کنید.
اسپرینت
اسپرینت یک اصطلاح در اسکرام است که برای تکرار به کار برده می‌شود. تکرارها (ایتریشن‌ها)، چرخه‌هایی هستند که طی آن بر روی زیر مجموعه‌ای از فیچرها تمرکز کرده و محصولی قابل استفاده ایجاد می‌کنیم. مدت زمان اسپرینت‌ها باید کوتاه‌تر از یک ماه باشند، معمولا اسپرینت‌های دوهفته‌ای یا سه هفته‌ای رایج هستند و توصیه می‌شوند.
مدت زمان اسپرینت، در ابتدای پروژه مشخص می‌شود، مدت زمان همه آنها یکسان است و هرگز تمدید نمی‌شوند، حتی اگر نتیجه مورد انتظار چرخه حاصل نشده باشد. بنابراین ما آیتم‌های بک‌لاگ را داریم و اولین اسپرینت را شروع خواهیم کرد. اولین کاری که باید انجام دهیم چیست؟
برنامه‌ریزی اسپرینت (Sprint Planning)
برنامه‌ریزی، اولین کاری است که ما در اسپرینت انجام می‌دهیم. شاید این سوال پیش بیاید که اگر اجایل پیش‌بینی کننده نیست چطور برنامه‌ریزی کنیم؟ هنوز هم برخی اشکال برنامه‌ریزی را در اجایل داریم. برای هر اسپرینت، جلسه برنامه‌ریزی باید تشکیل شود که برای یک اسپرینت یک ماهه این جلسه 8 ساعت است و برای اسپرینت‌های کوتاه‌تر، زمان جلسه برنامه‌ریزی کمتر می‌شود. در طول این جلسه، ما تعدادی از آیتم‌های موجود در بالای بک‌لاگ محصول را انتخاب کرده و در بک‌لاگ اسپرینت قرار می‌دهیم. این برنامه ما برای اسپرینت خواهد بود. آیتم‌های موجود در بالای بک‌لاگ اهمیت بالاتری دارند و این انتخاب به معنی تمرکز بر روی موارد مهم‌تر در هر اسپرینت است.
سوالی که مطرح می‌شود این است که چند آیتم را باید انتخاب کنیم؟ پاسخ این سوال، به سایز آیتم‌های موجود در محصول بستگی دارد. چه کسی باید آیتم‌ها را تخمین بزند؟ در ادامه توضیح خواهیم داد.
برآورد (Estimation)
تخمین باید توسط کسانی انجام شود که قرار است کار را انجام دهند. این کار توسط تیم توسعه انجام می‌شود. نقش دوم در اسکرام را تیم توسعه بازی میکند (اولین نقش در اسکرام به عهده مالک محصول است). در هر تیم، 3 تا 9 توسعه‌دهنده وجود دارد. "توسعه‌دهنده" اصطلاحی است که به تحلیلگران، طراحان، برنامه‌نویسان، کارشناسان تست نرم افزار، طراحان رابط کاربری و هر فرد دیگری که در ایجاد راه حل مشارکت دارد، اطلاق می‌شود.
هنگامی که مالک محصول آیتم جدیدی را در بک‌لاگ محصول ایجاد میکند، معنای آن را برای تیم توسعه توضیح داده و تخمین را می‌خواهد. سپس توسعه‌دهندگان درباره آن بحث کرده و تخمین می‌زنند. مالک محصول تخمین را به آیتم بک‌لاگ محصول اضافه میکند. به این روش اصلاح یا بازبینی بک‌لاگ محصول می‌گویند.
بنابراین، واحد برای اندازه آیتم‌ها چه باید باشد؟
بنابراین، فقط برای حصول اطمینان؛ تخمین به طور مداوم، بهتر از برنامه‌ریزی اسپرینت است.
واحد اندازه‌گیری
برای اندازه‌گیری به جای، واحدهای مبتنی بر زمان مانند ساعت‌های کاری انسان از واحدهای نسبی مبتنی بر تلاش استفاده کنیم. در صورت استفاده از ساعت و مقایسه ساعت‌های کاری با تولیدات ممکن است نتایج بی‌کیفیت حاصل شود. هنگامی که 10 آیتم بک‌لاگ محصول ایجاد می‌کنید، ارزش این اسپرینت 381 ساعت کاری انسانی (man-hours) است. 6 نفر در اسپرینت‌های دو هفته‌ای کار می‌کنند، که 528 ساعت کاری می‌شود. چرا خروجی شما کم است؟ چه چیزی اشتباه است؟
ما این را نمی‌خواهیم، زیر اگر توسعه‌دهنده‌ها را مقصر بدانید، آنها مارجین ایمنی را به تخمین‌هایشان اضافه می‌کنند.به جای اینکه بگویند چیزی به ۲۰ نفر در ساعت نیاز دارد، می‌گویند ۳۵ نفر در ساعت طول می‌کشد تا مورد سوال قرار نگیرید. این مشکلات زیادی ایجاد میکند. برای مبتدی‌ها، کار سندرم دانش‌آموز برای پر کردن زمان موجود گسترش می‌یابد. وقتی حاشیه اضافه می‌کنند، به طور خودکار تولید کاهش می‌یابد.
به همین دلیل است که ما واحدهای زمان محور را دوست نداریم. در عوض، از استوری پوینت نسبی و تلاش محور استفاده می‌کنیم. آیا با استوری پوینت آشنایی دارید؟
14- استوری پوینت‌ها
ما از استوری پوینت به جای نفر ساعت و سایر واحدهای زمان محور استفاده می‌کنیم. بیایید ببینیم چگونه کار میکند.
تعریف مرجع
ما یک یوزر استوری ساده و کوچک را به عنوان مرجع انتخاب می‌کنیم. این تعریف یک استوری پوینت در پروژه ما خواهد بود.
تخمین زدن
هر زمان که بخواهیم چیزی را تخمین بزنیم، آن را با مرجع مقایسه می‌کنیم. اگر دو برابر مرجع کار ببرد، 2sp (یعنی 2 استوری پوینت) و اگر نصف مرجع زمان ببرد، 0.5sp حساب می‌شود و غیره.
می‌دانم به چه چیزی فکر می‌کنید؛ این واقعیت که استوری پوینت‌ها قابل تبدیل به زمان هستند. بله درست است. ما این کار را با استفاده از «سرعت» انجام می‌دهیم. آیا می‌توانید حدس بزنید که سرعت چیست؟
سرعت
بیایید فرض کنیم که این خروجی ما برای اسپرینت‌های قبلی بود.
- اسپرینت ۱: 73sp
- اسپرینت ۲: 110sp
- اسپرینت ۳: 98sp
- اسپرینت ۴: 131sp
- اسپرینت ۵: 122sp
در این صورت می‌توان گفت که به طور متوسط در هر اسپرینت 107sp تحویل داده‌ایم. این همان چیزی است که ما آن را «سرعت» می‌نامیم. سرعت ما در پایان اسپرینت پنجم 107sp در هر اسپرینت است.
بنابراین، می‌توانیم به این اطلاعات دست پیدا کنیم:
برای اسپرینت بعدی چقدر باید کار کنیم؟ چیزی حدود ۱۰۷sp
۱۰۰۰ استوری پوینت در بک‌لاگ محصول‌مان باقی‌مانده است و فکر نمی‌کنیم بتوانیم ایده‌های جدیدی برای بک‌لاگ ارائه دهیم. چه زمانی قرار است پروژه را به اتمام برسانیم؟ 1000 استوری پوینت تقسیم بر 107 استوری پوینت در هر اسپرینت = حدود ۱۰ اسپرینت
البته سرعت همیشه تغییر میکند. به عنوان مثال، اگر خروجی ما در اسپرینت ششم 140sp باشد، سرعت ما 112sp می‌شود. این برای تنظیم تمام محاسبات و پیش‌بینی‌های واقعی‌تر یک فرصت است.
طبیعی است که در ابتدای پروژه تغییرات زیادی در سرعت داشته باشید که پس از پنج تا هشت اسپرینت پایدار می‌شود.
بنابراین، ما می‌دانیم که چگونه تخمین بزنیم و چه کسی باید تخمین بزند. فرض کنید ۶ توسعه‌دهنده وجود دارند و قرار است اینکار را انجام دهند. آنها این مورد را بر اساس توضیحات صاحب محصول درک و در مورد تکنیک‌ها و رویکرد بحث کرده‌اند. حالا چه؟ باید تک‌تک رای بدهند؟
برنامه‌ریزی پوکر
اگر توسعه‌دهندگان یک‌به‌یک رای دهند، اولین رای‌ها بقیه را مهار میکند و کیفیت برآوردها را کاهش می‌دهد.
برای جلوگیری از این سوگیری شناختی (cognitive bias)، ما معمولا از برنامه‌ریزی پوکر (Planning poker) استفاده می‌کنیم. هر فرد تعدادی کارت دارد که اعدادی روی آنها نوشته شده است. افراد بر اساس نظر خود کارتی را انتخاب می‌کنند و آن را رو به پایین نگه می‌دارند. وقتی همه آماده باشند، کارت‌ها نشان داده می‌شوند.
سپس مقادیر را بررسی می‌کنیم. برای مثال، اگر کسی معتقد است که آیتم 2sp است، در حالی که شخص دیگری به 20sp اعتقاد دارد، می‌توانیم مطمئن باشیم که حداقل یکی از آنها آیتم را به درستی درک نکرده است. بنابراین، دوباره در مورد آن بحث می‌کنیم و دوباره رای می‌دهیم.
وقتی رای‌ها در یک رنج قرار می‌گیرند، میانگین آنها را محاسبه می‌کنیم و این مقدار کار تخمینی برای آیتم بک‌لاگ محصول است.
چیزهای زیادی وجود دارد که باید در اسکرام در نظر بگیریم. آیا می‌توانیم انتظار داشته باشیم که صاحب محصول و تیم توسعه به اندازه کافی متخصص باشند تا همه چیز را به درستی انجام دهند؟ اگر چیزی را از دست بدهند چه؟
اسکرام مستر
ما به کسی نیاز داریم که به تیم اسکرام کمک کند از فریمورک به درستی استفاده کند. این شخص اسکرام مستر نام دارد. آنها کارشناسان اسکرام هستند که اطمینان حاصل می‌کنند همه درک درستی از فریمورک دارند. در غیر این صورت، او آنها را آموزش می‌دهد و متقاعد میکند که کار درست را انجام دهند.
اسکرام مستر به جای محتوا (راه حل، دامنه و غیره) بر روی پروسه متمرکز است. علاوه بر این، اسکرام مستر مسئول رفع موانع هم است. وقتی اعضای تیم با مشکلی مواجه می‌شوند، به سراغ اسکرام مستر می‌روند و اسکرام مستر سعی میکند مشکل را حل کند. البته، این در مورد مشکلات غیر فنی صدق میکند.
من تاکنون به سه نقش اسکرام اشاره کردم. بیایید قبل از ادامه مقاله، خلاصه‌ای سریع از نقش‌ها داشته باشیم.
تیم اسکرام
سه نقش در یک تیم اسکرام وجود دارد:
- مالک محصول - شخصی با محوریت کسب‌وکار که مالک بک‌لاگ محصول است و آیتم‌ها را برای به حداکثر رساندن ارزش تجاری مرتب میکند.
- اسکرام مستر – متخصص اسکرام که آموزش می‌دهد و موانع را برطرف میکند.
- تیم توسعه - همه کارشناسان مورد نیاز در پروژه
تیم توسعه باید دو ویژگی مهم داشته باشد:
- عملکرد متقابل (cross-functional): به این معنی است که آنها باید تمام تخصص مورد نیاز برای ایجاد محصول را بدون وابستگی به افراد خارجی داشته باشند.
- خود سازماندهی (self-organized): به این معنی است که آنها به جای دریافت دستور، راه خود را پیدا می‌کنند و البته به این دلیل مسئولیت‌های بالاتری دارند.
تعریف نقش‌های دیگر یا حتی عنوان مجاز نیست. به عنوان مثال، ما یک «تستر» در تیم نداریم. یک یا چند توسعه‌دهنده در تیم متخصص برای آزمایش وجود دارد، اما هنوز هم توسعه‌دهندگان نامیده می‌شوند. ما می‌خواهیم همه به یکدیگر کمک کنند و به جای فعالیت‌های تخصصی، روی خروجی متمرکز شوند.
ما رهبر تیم هم نداریم. زیرا در این صورت باقی توسعه‌دهندگان کمتر احساس مسئولیت خواهند کرد. لطفاً توجه داشته باشید که اسکرام مستر نیز نباید مانند یک رهبر تیم عمل کند. آنها فقط کمک و حمایت می‌کنند.
پس نقش مدیر پروژه چیست؟
مدیر پروژه
برخی از سیستم‌های اجایل نقش مدیر پروژه را دارند، اما ما آن را در اسکرام نداریم. ما حتی نقشی که واقعاً شبیه مدیر پروژه باشد هم نداریم. اسکرام مستر تنها مسئول بخش‌هایی از فعالیت‌های مدیریت پروژه (مانند مدیریت فرآیند و حل مشکلات) است و مالک محصول نیز مسئولیت‌هایی دارد (به عنوان مثال اولویت‌بندی و تعریف محدوده). حتی تیم توسعه مسئول برخی از فعالیت‌های مدیریت پروژه (به عنوان مثال تخمین) است.
نکته این است که فعالیت‌های مدیریت پروژه بین تمام اعضای تیم در اسکرام پخش می‌شود.
خب، ما در مورد برنامه‌ریزی اسپرینت بحث می‌کردیم، که اولین رویداد در هر اسپرینت است، زمانی که تعدادی از آیتم‌ها را از بک‌لاگ محصول انتخاب می‌کنیم و در بک‌لاگ اسپرینت قرار می‌دهیم. آنگاه زمان شروع کار است.
توسعه
به محض اتمام جلسه برنامه‌ریزی اسپرینت، ما مجاز به افزودن، حذف یا تغییر موارد موجود در بک‌لاگ اسپرینت نیستیم. این به این دلیل است که ما می‌خواهیم متمرکز بمانیم و کارها را انجام دهیم.
توسعه‌دهندگان شروع به کار روی چند آیتم در بالای اسپرینت بک‌لاگ می‌کنند و قبل از رفتن به آیتم‌های بعدی، آنها را ۱۰۰٪ انجام می‌دهند. آنها موارد را طراحی، برنامه‌ریزی، ادغام و آزمایش می‌کنند.
«تست کردن» شامل همه انواع تست است، زیرا ما واقعاً نیاز داریم که موارد ۱۰۰٪ انجام شوند تا بتوانیم فیدبک موثر را فعال کنیم. بنابراین، تست پذیرش کاربر نیز بخشی از آن است. به محض اینکه همه چیز کامل شد، توسعه‌دهندگان از نمایندگان کاربر، برای تست‌های پذیرش کاربر درخواست می‌کنند. تست در تمام طول اسپرینت انجام می‌شود. ما برای زمان خاصی در آینده منتظر نمی‌مانیم.
همکاری برای ما مهم است. توسعه‌دهندگان باید همه با هم کار کنند و در یک صفحه باشند. چگونه؟
اسکرام روزانه
هنگامی که توسعه‌دهندگان در حال کار هستند، جلسات روزانه‌ی ۱۵ دقیقه‌ای به نام اسکرام روزانه دارند. این فقط برای توسعه‌دهندگان است و هیچکس دیگری نمی‌تواند شرکت کند. البته، هر کسی می‌تواند بدون اینکه صحبت کند در جلسه حضور داشته باشد.
هر توسعه‌دهنده به سه سوال پاسخ می‌دهد:
- از دیروز تا حالا چیکار کردم
- تا فردا قرار است چه کاری انجام دهم
- چه مشکلاتی ممکن است داشته باشم
ما در مورد مشکلات بحث نمی‌کنیم! به یاد داشته باشید، جلسه باید در ۱۵ دقیقه انجام شود. بعد از آن می‌توانیم مشکلات را مطرح کنیم و اگر مشکل فنی نبود و نتوانستیم آن را حل کنیم می‌توانیم از اسکرام مستر کمک بخواهیم.
به نظر شما چه کسی باید عملکرد اسپرینت را بسنجد؟
سنجش عملکرد اسپرینت
چه کسی باید عملکرد اسپرینت‌ها را بسنجد؟ صاحب محصول؟ اسکرام مستر؟ یا تیم توسعه؟
آیا به یاد دارید که یکی از ویژگی‌های تیم توسعه این است که باید خود سازماندهی شود؟ بنابراین، آنها باید مسئول سنجش عملکرد خود باشند.
این کار باید به روشی موثر انجام شود. ردیابی منابع واقعی نسبت به منابع برنامه‌ریزی شده و مواردی از این قبیل مفید نیستند. ما فقط بررسی می‌کنیم که چند مورد را تکمیل کرده‌ایم و آیا می‌توانیم همه چیز را تا پایان اسپرینت تحویل دهیم یا خیر.
اگر متوجه شویم که نمی‌توانیم همه چیز را تحویل دهیم، با مالک محصول تماس می‌گیریم تا بیاید و ترتیب آیتم‌های موجود در اسپرینت بک‌لاگ را بررسی کند. ما موارد را اضافه، حذف یا تغییر نمی‌دهیم.
فرض کنید چیزی در بازار تغییر کرده است و مشتری دیگر به نیمی از آیتم‌های بک‌لاگ اسپرینت نیاز ندارد. چه کار باید بکنیم؟ به هر حال، ما مجاز به حذف موارد از بک‌لاگ اسپرینت نیستیم.
کنسل کردن اسپرینت
اگر مشتری دیگر به آیتم‌های اسپرینت بک‌لاگ نیاز نداشته باشد، یا به طور کلی، دیگر به اسپرینت بک‌لاگ نیازی نباشد، مالک محصول این اختیار را دارد که اسپرینت را کنسل کند.
در این صورت بلافاصله با یک برنامه‌ریزی یک اسپرینت جدید را شروع خواهیم کرد. البته، قبل از شروع اسپرینت جدید، تمام تغییرات بر روی بک‌لاگ محصول اعمال می‌شود.
ما انتظار کنسلی اسپرینت را نداریم. این یک اقدام افراطی است. اگر اسپرینت‌های کوتاه کافی داشته باشیم، معمولاً چنین تغییرات چشمگیری نخواهیم داشت. به طور کلی، اسپرینت‌های کوتاه‌تر، خطرات را کاهش می‌دهد.
خب، بیایید یک جمع‌بندی سریع قبل از ادامه مقاله داشته باشیم. پیشنهاد می‌کنیم کمی وقت بگذارید و مواردی را که در مورد آن صحبت کردیم، مرور کنید. لازم نیست دوباره درس‌ها را مرور کنید، فقط از حافظه خود استفاده کنید.
جمع‌بندی
کمی در مورد مفهوم چابکی، و این واقعیت که چابکی در مورد تطبیق‌پذیر بودن به جای پیش‌بینی است. این بدان معناست که ما به جای کل، زیرمجموعه‌های محصول را طراحی و برنامه‌ریزی می‌کنیم و از فیدبک استفاده می‌کنیم تا جلوتر برویم. نکته کلیدی در اینجا این است که ما واقعاً نمی‌دانیم چه نوع محصولی نتیجه مورد انتظار را ایجاد میکند.
نقش‌ها و مسئولیت‌های اسکرام
تنها سه نقش وجود دارد و ما نقش یا عنوان جدیدی را تعریف نمی‌کنیم
- آنها باید دارای عملکرد متقابل باشند و خود سازماندهی شوند
- اسپرینت: تایم باکس برای ایجاد تکه‌های کار نرم‌افزار و دریافت فیدبک حداکثر یک ماه است (تطبیق)
- برنامه‌ریزی اسپرینت: زمانی که برای اسپرینت برنامه‌ریزی می‌کنیم، اولین کاری که در اسپرینت انجام می‌شود، ۸ساعت برای یک ماه در اسپرینت است.
- بک‌لاگ محصول: لیست اولویت‌بندی‌شده‌ی فیچرهایی که قرار است توسعه دهیم.
- اسپرینت بک‌لاگ: برنامه‌ریزی اسپرینت
- روشی که ما تخمین می‌زنیم، شامل مسئولیت‌ها، واحدها و تکنیک‌ها (مانند برنامه‌ریزی پوکر، محاسبه سرعت)
مرور اسپرینت
ما در پایان هر اسپرینت دو جلسه داریم. اولی اسپرینت ریویو یا اسپرینت دمو نام دارد. تایم جلسه برای اسپرینت یک ماهه ۴ ساعت و برای اسپرینت‌های کوتاه‌تر به نسبت کوتاه‌تر است. این جلسات زمانی برگزار می‌شوند است که تیم اسکرام و مشتری برای بررسی دو چیز دور هم جمع می‌شوند:
- خروجی تکمیل شده: مشتری خروجی را امتحان میکند و فیدبک ارائه می‌دهد. فیدبک در بک‌لاگ محصول اعمال می‌شود و بر اسپرینت بعدی تأثیر می‌گذارد. انطباق!
- پیشرفت پروژه: مالک محصول، مسئول محاسبه عملکرد پروژه به عنوان یک کل است و اطلاعات را در اختیار مشتری قرار می‌دهد. مهمترین بخش اطلاعات در اینجا، تاریخ تکمیل پیش‌بینی شده است.
نحوه درک و تعریف «خروجی» مهم است. به نظر شما چه مواردی را باید در نظر بگیریم تا برای سازگاری و انطباق مفید باشد؟
افزایش یا جمع‌بندی
خروجی اسپرینت‌ها که نسخه جدید نرم‌افزار با امکانات بیشتر است، «افزایش» یا «جمع‌بندی» نامیده می‌شود.
ویژگی اصلی جمع‌بندی‌ها (increment) این است که باید به طور بالقوه قابل آزادسازی شوند. ما مجبور نیستیم همه آنها را آزاد کنیم، زیرا این کار آسان نیست. اما همیشه باید به طور بالقوه آزاد شوند. این کار به این خاطر است که ما می‌خواهیم برای ارائه یک تجربه واقعی به مشتری و ارائه فیدبک موثر به ما، قابل استفاده باشد. بازخورد، اساس انطباق و اجایل همه چیز در مورد انطباق است.
از سوی دیگر، اگر همیشه قابل انتشار و انتخاب مناسبی برای پروژه باشد، می‌توانیم هر چندتا اسپرینت را نیز منتشر کنیم. در این صورت، ما مزایای اولیه را برای مشتری به ارمغان خواهیم آورد که عالی است.
برای اینکه به طور بالقوه قابل انتشار باشد، فقط موارد ۱۰۰٪ انجام شده بک‌لاگ محصول را در آن قرار می‌دهیم. اگر یک مورد ۹۹.۹۹٪ تکمیل شده باشد، برای اسپرینت‌های آینده به بک‌لاگ محصول برمی گردد.
بنابراین، چگونه می‌توانیم بفهمیم که آیا کاری ۱۰۰٪ انجام شده است؟
تعریف کار انجام شده (Done)
ما باید یک تعریف مستند، مناسب، ارتباطی و درک شده از کار انجام شده داشته باشیم. اینگونه است که می‌دانیم چه وقت کاری انجام شده است و تمام چیزهایی را که باید برای هر آیتم بک‌لاگ محصول انجام دهیم، توضیح دهد.
چه چیزی می‌توانیم در آنجا داشته باشیم؟ این موارد رایج هستند:
- پروسه‌های توسعه: آنالیز، دیزاین، برنامه‌ریزی، یکپارچه سازی، آزمایش، مستندسازی
- متدهای کیفیت و معیارهای پذیرش
- فیچرهای غیرعملیاتی
تنها چیزی که ممکن است لازم باشد در مورد آن صحبت کنیم ویژگی‌های غیر عملیاتی است. آنها چیزهایی مانند عملکرد، امنیت، مقیاس‌پذیری و قابلیت نگهداری هستند. از آنجایی که عملکردی نیستند، ما معمولاً نمی‌توانیم موارد غیر فنی را برای آنها در بک لاگ محصول ایجاد کنیم. از سوی دیگر، آنها باید برای همه موارد نرمال و کاربردی بک‌لاگ محصول در نظر گرفته شوند. به همین دلیل Definition of Done بهترین مکان برای آنهاست.
وقتی کار با اسپرینت ریویو تمام شد، باید قبل از پایان دادن به اسپرینت فعلی و شروع اسپرینت بعدی، مراقب چیز دیگری باشیم. می‌توانید حدس بزنید چیست؟
گذشته نگری اسپرینت (Sprint Retrospective)
آخرین کاری که باید انجام دهیم این است که روی بهبود مستمر خود سرمایه‌گذاری کنیم. همیشه جا برای پیشرفت وجود دارد و ما انتظار داریم در هر اسپرینت کمی بهتر باشیم.
ما در پایان هر اسپرینت جلسه‌ای به نام Sprint Retrospective داریم. برای اسپرینت یک ماهه ۳ ساعت و برای اسپرینت‌های کوتاه‌تر، کمتر زمان میبرد.
در طول این جلسه، ما برای یک بهبود کوچک در اسپرینت بعدی برنامه‌ریزی می‌کنیم. ما آن را به یک پیشرفت کوچک محدود می‌کنیم تا واقع‌بینانه باشد. همچنین ایده خوبی است که آن را به وضوح و قابل اندازه گیری تعریف کنید تا ببینیم آیا در به کارگیری آن موفق بوده‌ایم یا خیر.
لطفاً توجه داشته باشید که Sprint Retrospective فقط در مورد بهبود پروسه و نحوه کار ما است. در مورد راه حل خوب نیست زیرا ما راه حل را هم بهبود می‌بخشیم. اما این کار در اینجا انجام نمی‌شود. آیا روش اجایل مورد استفاده برای بهبود راه حل را می‌دانید؟
چرخه
بعد از پایان اسپرینت چه اتفاقی می‌افتد؟
ما بلافاصله اسپرینت بعدی را دقیقاً با همان روش شروع می‌کنیم. همه اسپرینت‌ها یکسان هستند و در ابتدا برای آماده‌سازی و زیرساخت‌ها وقت نمی‌گذاریم. آنها باید به تدریج در طول اسپرینت انجام شوند.
ما معمولا پروژه را تا زمانی ادامه می‌دهیم که متوجه شویم مقدار ارزش تجاری ایجاد شده توسط اسپرینت‌های دیرهنگام، آنها را توجیه نمی‌کند. به یاد دارید که ما همیشه مهمترین موارد را انتخاب می‌کنیم، بنابراین پس از مدتی، فقط ویژگی‌های فانتزی در بک‌لاگ محصول ما باقی می‌ماند.
اگر مشتری اصرار دارد، مطمئناً می‌توانید ادامه دهید تا همه ویژگی‌های ممکن ایجاد شوند. با این وجود، باید به آنها فرصت دهید تا ارزش کسب‌وکار را درک کنند و پروژه را در زمان مناسب متوقف کنند.
صحبت از مشتری شد، نظر شما در مورد قراردادها چیست؟
قراردادها
بگذارید ساده بگویم که قراردادهای قیمت ثابت اینجا جواب نمی‌دهد و ما به قراردادهای زمان و ابزار نیاز داریم.
دلیل آن واضح است. یک قرارداد سنتی قیمت ثابت بر اساس تعریف اولیه محصول است و اجایل نیست. چگونه می‌توانید قیمت ثابتی بدهید، وقتی دقیقاً نمی‌دانید قرار است چه چیزی را توسعه دهید؟
متأسفانه بسیاری از مشتریان این موضوع را درک نمی‌کنند. آنها از شما می‌خواهند که اجایل باشید (فقط به این دلیل که جالب است؟)، سپس شما را مجبور می‌کنند که قراردادهای قیمت ثابت را بپذیرید یا اسنادی مانند مشخصات الزامات و معماری راه حل را به آنها ارائه دهید.
بدیهی است که دو راه حل وجود دارد:
- نادیده گرفتن این دسته از مشتریان و جستجوی مشتریان بهتر، که ممکن است توانایی انجام آن را نداشته باشید.
- مدیریت کنید! راه‌حل‌هایی برای قراردادهای قیمت ثابت در اسکرام وجود دارد. همه آنها سعی می‌کنند قرارداد را به زمان و ابزار تبدیل کنند بدون اینکه مشخص شود.
من قصد دارم منابعی را برای مطالعات بیشتر شما معرفی کنم و در ادامه آن در مورد گواهینامه‌های موجود صحبت کنم.
مرجع اسکرام
احتمالاً دوست دارید یک مرجع برای اسکرام داشته باشید. چیزی که آن را تعریف میکند. آنچه شما به دنبال آن هستید The Scrum Guide از scrum.org است و می‌توانید آن را به زبان مورد علاقه خود به صورت رایگان دانلود کنید.
یک کتاب ساده که می‌توانم پیشنهاد کنم Scrum and XP from the Trenches است. این کتاب نیز رایگان است و به چندین زبان در دسترس است. هنریک کنیبرگ داستان نحوه استفاده از اسکرام در پروژه‌های دنیای واقعی خود را به شما می‌گوید و مطمئن هستم که شما آن را دوست خواهید داشت.
دیگر کتاب‌های مورد علاقه من، که نسبتاً پیشرفته هستند عبارتند از:
- Essential Scrum
- Agile Product Management with Scrum
- Succeeding with Agile
- Agile Estimating and Planning
- User Stories Applied
خب، گواهینامه‌های اسکرام چه هستند؟
گواهینامه‌های اسکرام
برنامه‌ریزی برای گرفتن گواهینامه تصمیم خوبی است، زیرا شما را در یادگیری مصمم‌تر میکند. علاوه بر این، اعتبار برای حرفه شما مفید است.
اینها برخی از مهمترین گواهینامه‌های اسکرام هستند:
- ASF (Foundation Agile Scrum)، از EXIN. این در مورد مفهوم اجایل و فریمورک اسکرام است. می‌توانید پس از مطالعه به صورت سلف استادی، با کمک دوره‌های آموزشی الکترونیکی یا دوره‌های کلاسی در آزمون شرکت کنید.
- PSM I (Professional Scrum Master level 1) یا سطح 1 اسکرام مستر حرفه‌ای ، از scrum.org این یک امتحان سخت، اما مقرون به صرفه‌تر است.
- CSM (Certified Scrum Master)، از Scrum Alliance. این یک امتحان بسیار آسان است و باید دوره‌های کلاسی را بگذرانید.
- ACP (Agile Certified Practitioner) از PMI. این در مورد مفهوم اجایل، شیوه‌ها و تکنیک‌های رایج و البته اسکرام است.
اینها گواهینامه‌های اصلی هستند. علاوه بر اینها، گواهینامه‌هایی برای مالکیت و توسعه محصول نیز وجود دارد که بر روش‌های دیگری مانند AgilePM متمرکز شده‌اند.
دیدگاه‌ها
ثبت دیدگاه