برنامه نویسی، مدیریت ۸۰۵۱ بازدید

اسکرام (Scrum) فریمورکی است که به اعضای تیم‌ها کمک می‌کند تا با همدیگر کار کنند. اسکرام نام خود را از یک تکنیک در بازی راگبی جهت آماده‌سازی برای بازی‌های بزرگ گرفته و همانند این بازی، تیم‌ها را تشویق می‌کند که از طریق تجربیات خود چیزهای تازه‌ای بیاموزند، در زمان کار روی یک مسئله، خود-سازمان‌دهی داشته باشند و برد و باخت‌های خود را جهت بهبود مداوم مورد استفاده قرار دهند.

اسکرام چیست؟

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

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

فریمورک اسکرام

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

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

اسکرام

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

ساخته‌های اسکرام

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

بک‌لاگ محصول

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

بک‌لاگ اسپرینت

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

افزایش

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

چنان که از تعاریف فوق مشخص است نسخه‌های بسیار مختلفی از «ساخته‌ها» وجود دارند که می‌توانید انتخاب کنید. به همین لیل است که باید در زمان تکامل یافتن این چیزها ذهنیت بازی داشته باشید. ممکن است تعریف شما از انجام کار، موجب ایجاد استرس در میان اعضای تیم شود. در این صورت باید یک تعریف جدید به این منظور انتخاب کنید.

اسکرام

مراسم و رویدادهای اسکرام

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

در ادامه فهرستی از مراسم کلیدی که تیم اسکرام باید برگزار کند را مشاهده می‌کنید:

سازمان‌دهی بک‌لاگ

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

برنامه‌ریزی اسپرینت

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

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

اسپرینت

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

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

اسکرام روزانه یا سرپایی

این یک جلسه بسیار کوتاه روزانه است که در زمان‌های یکسانی (معمولاً صبح) برگزار می‌شود و باید ساده باشد. بسیاری از تیم‌ها این جلسه را در طی 15 دقیقه تمام می‌کنند، اما مدت زمان اختیاری است. این جلسه به نام جلسه سرپایی روزانه نیز نامیده می‌شود که تأکیدی بر سریع بودن آن است. هدف اسکرام روزانه این است که همه اعضای تیم مطمئن شوند با یکدیگر و با هدف اصلی اسپرینت هماهنگ هستند و برای 24 ساعت آینده برنامه‌ریزی کنند.

جلسه روزانه Scrum جایی است که اعضا باید دغدغه‌های خود را در مورد هدف اسپرینت یا هر گونه مانع بیان کنند.

یک روش رایج برای اجرای جلسه اسکرام روزانه این است که هر یک از اعضای تیم به سه سؤال در زمینه رسیدن به هدف اسپرینت پاسخ بدهد:

  • دیروز چه کار کردم؟
  • امروز قرار است چه کار کنم؟
  • آیا هر نوع مانعی وجود دارد؟

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

بررسی اسپرینت

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

این جلسه بررسی همچنین جایی است که مالک محصول بک‌لاگ محصول را بر اساس اسپرینت جاری بازبینی می‌کند و می‌تواند در نشست برنامه‌ریزی اسپرینت بعدی بررسی کند. در مورد یک اسپرینت یک-ماهه باید جلسه بازنگری حداکثر در یک بازه زمانی چهار ساعته اجرا شود.

گذشته‌نگری اسپرینت

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

اسکرام

نقش‌های ضروری برای موفقیت اسکرام

یک تیم Scrum باید سه نقش خاص داشته باشد: مالک محصول، اسکرام مستر و تیم توسعه. از آنجا که تیم‌های اسکرام چند کارکردی هستند، تیم توسعه شامل افراد تست‌کننده، طراحان، متخصصان UX، و مهندسان OPS به همراه توسعه‌دهندگان است.

مالک محصول اسکرام

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

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

اسکرام مستر

مسترهای Scrum مسئول همه کارهای اسکرام درون تیم‌هایشان هستند. آن‌ها تیم‌ها، مالکان محصول و کسب‌وکار را در فرایند اسکرام هدایت می‌کند و به دنبال روش‌هایی برای تنظیم دقیق رویه‌های خود هستند.

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

تیم توسعه اسکرام

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

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

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

اسکرام، کانبان و اجایل

اسکرام چنان فریمورک محبوب اجایلی است که غالباً اسکرام و اجایل با هم اشتباه گرفته می‌شوند. اما فریمورک‌های دیگری نیز مانند «کانبان» (Kanban)‌ وجود دارند که جایگزین رایجی محسوب می‌شوند؛ ناگفته نماند که پیش از این در مجله فرادرس به صورت مفصل توضیح داده‌ایم که کانبان چیست. برخی شرکت‌ها از یک مدل ترکیبی از اسکرام و کانبان پیروی می‌کنند که نام «اسکرامبان» (Scrumban) یا «کانپلان» (Kanplan) ‌را روی آن گذاشته‌اند و در عمل کانبان به همراه بک‌لاگ است.

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

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

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

اسکرام

مطلب پیشنهادی:
کانبان چیست ؟ – توضیح و کاربرد به زبان ساده
کانبان روشی قدیمی اما اثبات شده برای مدیریت پروژه است که بهینگی را به اوج می‌رساند. در این مقاله همه‌چیز راجع به کانبان را می‌آموزید.

سخن پایانی

فریمورک Scrum خودش مفهوم ساده‌ای دارد. درک قواعد، ساخته‌ها، رویدادها و نقش‌ها آسان است. رویکرد نیمه تجویزی آن در عمل به حذف ابهام از فرایند توسعه کمک می‌کند و از سوی دیگر فضای کافی در اختیار شرکت‌ها قرار می‌دهد تا رویکردهای خاص خود را در آن وارد کنند.

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

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

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

اگر این مطلب برای شما مفید بوده است، آموزش‌ها و مطالب زیر نیز به شما پیشنهاد می‌شوند:

بر اساس رای ۱۴ نفر
آیا این مطلب برای شما مفید بود؟
شما قبلا رای داده‌اید!
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.

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