چگونه اسکرام کنیم: یک راهنمای عملی

در صنعت فناوری اطلاعات کنونی، مفهوم چابکی (Agile) به شدت محبوب شده است. همه در مورد آن صحبت می‌کنند. تقریباً تمام شرکت‌های فناوری اطلاعات سطحی از چابکی را پذیرفته‌اند.

بوم فرآیند اسکرام – پارادایم بصری

روش‌های زیادی تحت چتر توسعه چابک وجود دارد، از جمله برنامه‌نویسی افراطی (XP)، اسکرام، روش‌های کریستالی، توسعه نرم‌افزار تطبیقی (ASD)، توسعه مبتنی بر ویژگی (FDD)، توسعه سیستم‌های پویا (DSDM) و روش‌های سبک. RUP، توسعه مبتنی بر تست (TDD) و غیره. در میان بسیاری از روش‌های توسعه چابک، پیاده‌سازی اسکرام محبوب‌تر است.

چتر روش چابک

چابک یا آبشاری؟ به نمودارها نگاه کنید

آخرین گزارش گروه استندیچ پروژه‌هایی را که بین سال‌های 2013 تا 2017 مطالعه کرده‌اند، پوشش می‌دهد. برای این دوره زمانی، نتایج کلی موفقیت، چالش و شکست برای چابک و آبشاری در زیر نشان داده شده است، به طوری که پروژه‌های چابک تقریباً 2 برابر بیشتر احتمال موفقیت دارند و 1/3 کمتر احتمال شکست.

(منبع: vitalitychicago.com — مقایسه نرخ موفقیت پروژه‌های آبشاری و چابک)

آبشاری در مقابل چابک، کدام یک بهتر است؟

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

اسکرام چیست؟

اسکرام یک چارچوب برای توسعه و نگهداری محصولات پیچیده است و یک فرآیند توسعه تدریجی و تکراری است. در این چارچوب، کل فرآیند توسعه شامل چندین چرخه تکرار کوتاه است، که هر چرخه تکرار کوتاه به نام اسپرینت (Sprint) شناخته می‌شود و هر اسپرینت 2 تا 4 هفته طول می‌کشد.

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

چرا اسکرام در برخی شرکت‌ها شکست خورد

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

  • چابک سریع‌تر است — تیم پروژه درک درستی از چابکی ندارد. آنها به سادگی فکر می‌کنند که چابکی به معنای سرعت است، یعنی همگام شدن با پیشرفت، و می‌توانند از هرگونه محدودیت سیستمی آزاد باشند.
  • چابک سریع‌تر است، یا ما باید اضافه‌کاری کنیم — شنیده‌ام که برخی شرکت‌ها باید یک عملکرد جدید توسعه دهند. به دلیل پیاده‌سازی اسکرام، از تیم پروژه خواسته می‌شود که اضافه‌کاری کند و وظایف توسعه 2 هفته یا بیشتر در یک هفته منتشر خواهد شد. پیاده‌سازی اسکرام به این معنی است که تیم پروژه در حال اضافه‌کاری است، که منجر به یک «ترس» در چابکی تیم پروژه می‌شود؛
  • بک‌لاگ محصول به خوبی نگهداری نمی‌شود — PO نمی‌تواند برای کار واجد شرایط باشد، نمی‌تواند داستان‌های کاربری مؤثر را تقسیم کند، یا تقسیم داستان کاربر غیرمنطقی است و نمی‌تواند توسعه تدریجی را تحقق بخشد؛
  • مشکل تشکیل تیم — اسکرام تقاضای بالایی برای تیم‌های خودسازمانده دارد، اما بسیاری از اعضای تیم احساس می‌کنند که به استانداردهای خودسازماندهی نمی‌رسند؛
  • کمبود فرهنگ چابک — اسکرام از شفافیت کار، تکمیل به موقع پروژه و شناسایی وظایف هر فرد حمایت می‌کند. تابلو اسپرینت و نمودار سوختن پروژه بدون مانع هستند و بسیاری از افراد با آن راحت نیستند؛
  • بازرسی و سازگاری در جای خود نیست — در فرآیند تکرار، مشکل نمی‌تواند به موقع کشف شود، یا مشکل پیدا می‌شود و نمی‌توان به طور مؤثر آن را حل کرد، که باعث می‌شود تیم پروژه احساس ناامیدی کند. و بسیاری دیگر.

اگر دانش اسکرام فقط در:

«من صبح یک ایده دارم، بعدازظهر تحقق می‌یابد و شب آنلاین خواهد شد.»

این مناسب نیست. به نظر من، اسکرام قطعاً ارزشمند است. عملکردهای اصلی اسکرام شامل:

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

با این حال، پیاده‌سازی اسکرام به این معنی نیست که تحت قوانین و محدودیت‌های پروژه قرار نمی‌گیرد. پس وضعیت صحیح برای پیاده‌سازی اسکرام چیست؟

مراحل پیاده‌سازی اسکرام

1. تعیین یک PO

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

به عنوان یک مالک، باید تصویر کلی داشته باشد؛ اطلاعات و جهت صنعت را به عمق درک کند؛ قادر به درک جهت محصول باشد، مسئول برنامه‌ریزی و مدیریت کوتاه‌مدت و میان‌مدت و بلندمدت محصول باشد؛ قادر به انجام تحقیقات کاربری و برنامه‌ریزی عملکرد محصول بر اساس الزامات استراتژیک شرکت باشد، نیازهای همیشه در حال تغییر را پیگیری کند و به نوآوری محصولات ادامه دهد.

علاوه بر این، اگر از PO به عنوان یک سازمان استفاده کنید، در یک پروژه توسعه نرم‌افزار، تیم PO ممکن است شامل ذینفعان دیگری مانند مدیران محصول و کاربران نهایی باشد.

2. تشکیل یک تیم توسعه

تیم مجری محصول است و مسئول تحویل افزایش‌های قابل ارسال و افزایش‌های «تکمیل شده» محصول در پایان هر اسپرینت است.

تیم عمدتاً شامل پرسنل توسعه و تست است و تیم باید قادر به پیاده‌سازی چشم‌انداز PO از محصول باشد.

اندازه تیم باید حدود 5 تا 9 نفر باشد.

تیم اسکرام همچنین باید چندمنظوره باشد و اعضای با قابلیت «تمام‌پشته» ترجیح داده می‌شوند، حتی اگرپیاده‌سازی آن در اکثر شرکت‌ها دشوار باشد.

3. انتخاب اسکرام مستر

اسکرام مستر مسئول فرآیند اسکرام است و به PO و تیم توسعه خدمت می‌کند. اسکرام مستر باید حس تشریفات داشته باشد و بتواند به طور مؤثر و کارآمد جلسه برنامه‌ریزی تکراری، جلسه ایستاده روزانه، جلسه نمایش عملکرد و جلسه بازنگری گذشته را سازماندهی کند؛ اسکرام مستر باید دارای درجه بالایی از اجرا باشد و اعتبار خود را حفظ کند تا به تیم کمک کند. بر روی اهداف تحویل و اهداف کیفیت تمرکز کند تا اطمینان حاصل شود که تیم‌ها محصولات با کیفیت بالا را به طور مؤثر تحویل می‌دهند؛ تیم‌ها را به ساخت فرآیندهای کارآمد هدایت کند، تیم‌ها را در مورد ارزش‌ها، اصول و شیوه‌های چابک راهنمایی کند؛ مسئول آموزش سایر اعضای تیم باشد تا اطمینان حاصل شود که اسکرام به درستی استفاده می‌شود؛ ارتباطات، مدیریت مشکلات، حل تعارض، کمک به تیم برای حذف تمام موانع.

4. نگهداری بک‌لاگ محصول

لیست کارهای معوقه محصول مجموعه‌ای از تمام اقلام معوقه است و بر اساس استراتژی شرکت و چشم‌انداز محصول بنا شده است. PO تمام اقلام موجود در لیست کارهای معوقه محصول را بر اساس اولویت‌های ارزش‌های تجاری مرتب می‌کند و یک لیست اقلام اولویت‌بندی شده تشکیل می‌دهد.لیست کارهای معوقه محصول می‌تواند به عنوان «نقشه راه» توسعه محصول عمل کند. برای درک زمینه محصول، اقلام لیست کارهای معوقه بهترین مرجع هستند.

هر روز با تقاضاهای جدید از رقبای جدید مواجه هستیم، که به این معنی است که PO باید به طور مداوم طراحی محصول خود را بهینه‌سازی کند و اولویت‌های لیست کارهای معوقه محصول را برای سازگاری با تغییرات جدید تنظیم کند.

در این فرآیند، PO باید با تمام ذینفعان و تیم‌ها مشورت کند تا اطمینان حاصل شود که لیست کارهای معوقه محصول ادعاهای واقعی کاربران را منعکس می‌کند.

۵. برآورد چابک با استفاده از امتیاز داستان

برآورد چابک به طور نسبی معمولاً در برنامه‌ریزی اسپرینت یا در حین یک اسپرینت انجام می‌شود و لیست کارهای معوقه محصول توسط تیم به همراه مسئولان توسعه و تست واقعی ارزیابی می‌شود.

برای انجام برنامه‌ریزی اسپرینت به طور مؤثرتر در عمل، PO و اسکرام مستر قبل از جلسه برنامه‌ریزی اسپرینت یک برآورد تقریبی انجام خواهند داد. آنها باید این نوع سوالات را بپرسند:

  • ببینید آیا برنامه اسپرینت قابل اجرا است؟
  • آیا اطلاعات کافی برای تکمیل این موارد وجود دارد؟
  • آیا تقسیم اقلام لیست کارهای معوقه محصول معقول است؟

زمانی که تیم توسعه یک برآورد انجام می‌دهد، توصیه می‌شود که روش سنتی (یعنی چند ساعت باید به کار اختصاص یابد) را کنار بگذارد و از رویکرد برآورد چابک با استفاده از امتیاز داستان – عدد فیبوناچی (۱، ۲، ۳، ۵، ۸، ۱۳، ۲۱…) برای ارزیابی تلاش مورد نیاز برای پیاده‌سازی یک مورد استفاده کند.

در زمان برآورد، تیم باید ابتدا یک مورد معوقه را شناسایی کند که ممکن است به شکل داستان کاربر به عنوان مرجع برای برآورد باشد. علاوه بر این، مهم است که توجه داشته باشید کهزمانی که امتیاز داستان واحد ارزیابی بیشتر از ۲۱ باشد، داستان کاربر باید دوباره تقسیم شود و امتیاز داستان کاربر واحد نباید بیشتر از ۸ باشد که وضعیت ایده‌آل است.

روش برآورد چابک

۶. جلسه برنامه‌ریزی اسپرینت

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

چرخه اسپرینت معمولاً ثابت است و عمدتاً برای ۲ تا ۴ هفته است. تیم با داستان کاربر با بالاترین اولویت در لیست کارهای معوقه محصول شروع می‌کند تا ببیند در یک اسپرینت چقدر می‌توان انجام داد.

اگر تیم قبلاً چندین اسپرینت را انجام داده باشد، با ارجاع به:

  • «امتیازهای داستان» تکمیل شده در تکرارهای قبلی،
  • تیم ممکن است امتیازهای داستان تقریبی برای این تکرار را برآورد کند.
  • «امتیازهای داستان» معادل سرعت تیم است.

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

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

۷. جلسه ایستاده روزانه

جلسه ایستاده روزانه منبع حیات برای اسکرام است. شرکت‌کنندگان معمولاً شامل PO، اسکرام مستر و تیم هستند. تیم در یک مکان ثابت و در یک زمان ثابت هر روز به صورت داخلی ارتباط برقرار می‌کند.زمان معمولاً صبح است، مدت زمان بیشتر از ۱۵ دقیقه نیست و ایستاده است. اسکرام مستر از تیم می‌پرسد اعضا سوالات زیر را می‌پرسد:

  • دیروز چه کار کردی؟
  • امروز چه کاری را برنامه‌ریزی کرده‌اید؟
  • موانع و مشکلات چیست؟

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

کارهای تیم به صورت از بالا به پایین اختصاص نمی‌یابند، بلکه به صورت ابتکاری و داوطلبانه تصمیم‌گیری می‌شوند. اگر کار قبلی تکمیل نشده باشد، نمی‌توانید برای کار بعدی درخواست دهید و نمی‌توانید دو کاری که نمی‌توانند در یک روز تکمیل شوند را ادعا کنید.

اسکرام مستر مسئول از بین بردن موانع پیش روی اعضای تیم است.

۸. پیگیری پیشرفت پروژه با تخته کار اسکرام

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

برخی از تیم‌ها در استفاده از ابزارهای شخص ثالث برای استفاده از تخته کار الکترونیکی اسکرام، مانند Visual Paradigm یا Jira خوب هستند؛ برخی از تیم‌ها از استفاده از تخته‌های بزرگ فیزیکی آفلاین خوشحال هستند.

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

تخته کار اسکرام — Visual Paradigm

۹. پیگیری پیشرفت با نمودارهای سوختگی

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

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

۱۰. نمایش محصول

جلسه بازبینی و بازخورد اسکرام — Visual Paradigm

بخش نمایش راهنمای اسکرام به جلسه بازبینی اسپرینت نامیده می‌شود، که بیان می‌کند که باید شامل نمایش کار انجام شده توسط تیم توسعه و پاسخ به سوالات درباره افزایش محصول باشد. این جلسه معمولاً قبل از انتشار این تکرار برگزار می‌شود.مهم‌ترین کار این جلسه تأیید سناریوهای پیاده‌سازی داستان‌های کاربر با ارزیابی‌های پذیرش برای هر یک از اقلام تکمیل شده به منظور تحقق تعریف انجام شده است.

این جلسه جایی است که هر کسی می‌تواند شرکت‌کننده باشد، نه تنها PO، اسکرام مستر و تیم، بلکه ذینفعان، کسب‌وکار و مدیران و حتی مشتریان.

این یک جلسه باز است که هر کسی می‌تواند شرکت‌کننده باشد، نه تنها PO، اسکرام مستر و تیم، بلکه ذینفعان، کسب‌وکار و مدیران و حتی مشتریان.

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

۱۱. بازخورد اسپرینت

جلسه بازنگری اسپرینت معمولاً در روز دوم پس از پایان این اسپرینت برگزار می‌شود.

جلسه بازنگری اسپرینت باید به دقت به سوالات زیر رسیدگی کند:

  • چه چیزی باید بهبود یابد;
  • چرا این اتفاق افتاد؟
  • چرا در آن زمان آن را نادیده گرفتیم;
  • چگونه می‌توانیم کار را تسریع کنیم.

به عنوان یک تیم، برای مؤثر کردن این فرآیند بازنگری اسپرینت، تیم باید به یکدیگر اعتماد کند. ما باید بحث‌ها و استدلال‌ها را بر اساس مسائل پروژه و فنی به یاد داشته باشیم:

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

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

پس از پایان آخرین اسپرینت، وارد تکرار جدید اسپرینت شوید.

خلاصه

اسکرامترکیبی از 3355 است. مفاهیم اصلی چارچوب اسکرام را می‌توان به سادگی به صورت 3.3.5.5 به یاد سپرد:

3 نقش

3 آثار

5 رویداد

5 ارزش

  • باز
  • احترام
  • شجاعت
  • تمرکز
  • تعهد

اهداف 3355 در پشت سه ستون اسکرام قرار دارد

  • شفاف
  • بازرسی
  • سازگاری

تعریف «انجام شده» (DoD) با تحقق 3 ستون از طریق 5 رویداد به دست می‌آیدتیم اسکرام.

چارچوب اسکرام 3355

This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.

Leave a Reply

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