امروزه لغت اسکرام در بین مدیران بسیار رایج شده است. اما واقعا اسکرام چه ایده جدیدی دارد؟ در این مطلب با تئوری اسکرام همراه با اطلاعات عملی درباره نحوه پیادهسازی آن در پروژهها آشنا شوید.
اگر در زمینه مدیریت پروژه های دیجیتال، توسعه نرم افزار و کسب و کارهای آنلاین تجربه داشته باشید، احتمالاً واژه اسکرام به گوشتان آشنا باشد.
اسکرام یک متدولوژی مدیریت پروژه محبوب است که در صنایع مختلف به طور گسترده ای پذیرفته شده است.
برای فهم گستردگی آن کافی است به آمار زیر توجه کنید:
91% از سازمان ها اعلام کرده اند انطباق با اجایل (چابک)، جزو اولویت های استراتژیک آن ها است. منبع: موسسه KPMG
وقتی شرکتها میگویند روشی اجایل (چابک) را دنبال میکنند، اغلب اوقات درباره Scrum صحبت میکنند. این بدان معنی است که در عصر حاضر برای یک مدیر پروژه مؤثر و پیشرو بودن، شما باید درباره Scrum دانش داشته باشید.
Scrum در هسته خود بر ایده قدرتبخشیدن به تیمها برای خودسازماندهی و تصمیمگیری درباره بهترین راه برای دستیابی به اهدافشان تمرکز دارد. این رویکرد میتواند به تیمها در ارائه محصولات و خدمات با کیفیت بالا به صورت سریع و کارآمد کمک کند.
Scrum در انواع صنایع از جمله توسعه نرمافزار، تولید و بازاریابی به طور گستردهای مورد استفاده قرار گرفته است. این به دلیل انعطافپذیری و قابلیت تطبیق آن، و همچنین تمرکز بر همکاری و هم افزایی است.
در این مقاله، ما اصول اساسی Scrum، آرتیفکتها، نقشها و رویدادها را معرفی خواهیم کرد تا به شما در شروع کردن یا به عنوان یک مرور کلی (همه ما گاهی اوقات نیاز به بازنگری داریم) کمک کنیم.
فرقی ندارد مدیر پروژه، رهبر تیم یا عضوی از تیم توسعه باشید. در این پست سعی میکنیم چیزی برای یادگیری شما وجود داشته باشد. بنابراین بیاید به دریای اسکرام شیرجه بزنیم:
متدلوژی اسکرام چیست؟
میتوان روش Scrum را به عنوان یک رویکرد تحویل محصول تعریف کرد که اصول و فرآیندهایی را برای بهبود نتایج پیشنهاد میدهد.
مدیریت پروژه Agile Scrum نیازمندیهای زمان و هزینه پروژهها را تعیین میکند. این روش با استفاده از جعبههای زمانی (مقدار مشخص و محدودی از زمان) برای ایتریشن (تکرار) های فعالیت ها، همچنین backlog محصول و رویدادهای خاص تیم، این هدف را دست یافتنی میکند. این یک چارچوب بسیار تطبیقپذیر است که تاکید آن رساندن سریع تر موارد ارزشمند در فرآیند توسعه است.
در مدیریت Scrum، پروژهها از طریق sprintها پیشرفت میکنند که هر کدام یک ایتریشن از کار به سمت اهداف تیم را نشان میدهند. هر sprint یا ایتریشن، یک increment قابل تحویل تولید میکند.
روش Scrum یکی از روشهای چابک است که از نظر جایگاه پس از روش های پیشبینیپذیر گذشته مثل مثلث مدیریت پروژه یا روش آبشاری (waterfall) توسعه پروژه قرار میگیرد.
در روشهای سنتی مدیریت پروژه، دامنه کار (Scope)، برنامه زمانی (Time) و منابع (Resource) محدود میشوند. اما در روشهای چابک شامل Scrum، منابع و برنامه زمانی تعیین شده و ثابت میباشند، اما دامنه کار میتواند تغییر کند و به آن تطبیق پذیر باشد، بسته به آنچه که در زمان مشخص با منابع ثابت بیشترین اهمیت را دارد.
Scrum در بطن خود تیمها را برای ایجاد یک درگیری سالم بین تحویل چیز درست، از راه درست و با سرعت حداکثری درگیر میسازد.
هدف Scrum بهبود ارتباطات، کار تیمی و سرعت توسعه است. مفاهیمی مانند sprintها، Scrums، backlog و نمودارهای burndown همگی از Scrum مشتق شدهاند.
چرا اسکرام؟
یکی از دلایل اصلی محبوبیت Scrum، توانایی آن در کمک به تیمها برای ارائه محصولات و خدمات با کیفیت بالا به صورت سریع و کارآمد است. با تجزیه پروژهها به قطعات کوچک و قابل مدیریت و روند کار با بازبینی منظم، تیمها میتوانند به سرعت هر گونه مشکلات را شناسایی و رفع کنند. این امر به آنها اجازه میدهد تا در مسیر درست قرار گیرند و در زمان مقرر اهداف خود را برآورده کنند.
دلیل دیگر انتخاب Scrum، تأکید آن بر همکاری و ارتباطات است. در محیط Scrum، اعضای تیم تشویق به همکاری و به اشتراک گذاری ایدهها میشوند و به جای رعایت سلسله مراتب سختگیرانه، با همکاری و ارتباط باز کار میکنند. یعنی در ایده اسکرام نقش مدیر و زیر دست کمرنگ است و به تمام افراد به صورت یکدست و به عنوان اعضای تیم نگاه میشود. این موضوع میتواند احساس مالکیت و مسئولیت را تقویت کند و به تیمها در حفظ انگیزه و مشارکت کمک کند.
به طور کلی، شهرت Scrum به دلیل توانایی آن در کمک به سازمانها و تیمها برای دستیابی به اهداف خود به صورت سریع و کارآمد است. با قدرتبخشیدن به تیمها برای خودسازماندهی و تصمیمگیری، Scrum میتواند به سازمانها در حفظ رقابتپذیری و ارائه محصولات و خدمات با کیفیت بالا کمک کند.
مدل ذهنی اسکرام برگرفته از بیانیه اجایل است
بیانیه چابک (Agile Manifesto) بخش جداییناپذیری از روش Scrum است و میتوان آن را به عنوان روح حاکم بر تمامی روشهای چابک در نظر گرفت. روش Scrum بالای منشور چابک قرار میگیرد تا راهنمایی عملی برای اجرای اصول منشور فراهم کند.
به عبارت دیگر، Scrum یکی از راهنماییهای عملی برای توسعه نتایج در قالب یک روحیه چابک است. در ادامه، تفصیلی از منشور چابک به همراه چند اصل Scrum آورده شده است.
- افراد و تعاملات مقدم بر فرآیند و ابزارها: در ابتدا، تمرکز بر افراد و تعاملات نسبت به فرآیندها و ابزارها قرار میگیرد. در اینجا، ارتباطات کلیدی هستند و نه فرآیندهایی که پروژه شما را اجرا میکنند. در چارچوب Scrum این به این معناست که تیمی خودسازمانده و چند وظیفه ای مورد توجه قرار میگیرد.
- نرم افزار قابل استفاده مقدم بر مستندات مفهومی: در اسکرام تمرکز بر تولید سریع محصولات قابل ارائه است و نه صرف زمان زیاد برای نگارش نیازمندیها. در توسعه نرمافزار با استفاده از Scrum، با اجرای Sprintهای زمانبندی شده، در پایان هر Sprint، یک نسخه افزایشی از محصول قابل ارائه تولید میشود و فیچرهایی به آن اضافه میگردد.
- تعامل با کاربر مقدم بر مذاکرات قراردادی با کارفرما: اسکرام ارزش را بر روی تعامل (collaboration) با مشتری میگذارد و تاکید میکند که در همه نقاط توسعه محصول با مشتری تعامل شود و مشتری در طول فرآیند به طور فعال درگیر شود.
- انجام تغییرات در صورت نیاز به جای دنباله روی از یک برنامه مشخص: به جای دیدن تغییرات به عنوان دشمن، چارچوب چابک تغییر را به عنوان یک چیز خوب میبیند و پاسخگو به آن است. در Scrum، نیازمندیها به طور پیوسته در حال تکامل هستند و تغییر قبول شده است. علاوه بر منشور چابک، Scrum خود پنج ارزش را به عنوان مهمترین عوامل در تسلط افراد و تیمها بر عملکرد موثر دارد: تعهد (commitment)، تمرکز (focus)، شفافیت (openness)، احترام (respect) و شجاعت (courage). این ارزشها به تیم چابک یا تیم Scrum جهت را راهنمایی میکنند و نشان میدهند رفتار مناسب چیست. تصمیماتی که گرفته میشود و گامهایی که انجام میشود باید این ارزشها را تقویت کرده و آنها را تضعیف نکند.
3 ابزار (آرتیفکت) اسکرام چیست؟
ابزارهای Scrum، اطلاعات کلیدی را که تیم Scrum باید در طول توسعه محصول از آن آگاهی داشته باشند، فراهم میکند.
- بک لاگ محصول: لیست نیازمندیهای محصول (Product Backlog) تمام ویژگیها، عملکردها و نیازمندیهایی را که باید در محصول در نظر گرفته شوند را به ترتیب اهمیت فهرست میکند. تغییر نیازمندیهای یک محصول در طول فرآیند توسعه امری رایج است، سازگار با نیازهای تجاری یا روند بازار. لذا لیست نیازمندیهای محصول به طور مداوم به روزرسانی میشود تا این تغییرات را منعکس کند.
- آیتم (کارت) های بک لاگ: این مواردی هستند که به لیست نیازمندیهای محصول میرسند. آنها تغییراتی را که باید انجام شوند و نتیجه مطلوب را با جزئیات بیان میکنند. یکی از راههای بیان نتیجه مطلوب به گونهای که تیم توسعه بفهمد، استفاده از “داستانهای کاربری” (User Stories) است که جملات سادهای هستند که توضیح میدهند که کسب و کار یا کاربر خاصی در محصول به دنبال چه چیزی هستند.برای نوشتن یک داستان کاربری، میتوانید از یک الگوی ساده استفاده کنید که شامل سه مؤلفه است: کاربر، هدف و دلیلِ پشتِ آن هدف است. در ادامه یک نمونه از نحوه نوشتن یک داستان کاربری آورده شده است:”به عنوان [نوع کاربر]، میخواهم [یک هدف] تا [یک دلیل].”بیایید یک نمونه از یک داستان کاربری برای یک برنامه مدیریت وظایف را بررسی کنیم:
“به عنوان مدیر پروژه، میخواهم وظایف را به اعضای تیم اختصاص دهم تا بتوانم پیشرفت آنها را پیگیری کنم و بهموقع تکمیل شود.”
در این نمونه، کاربر مدیر پروژه است، هدف او اختصاص دادن وظایف به اعضای تیم است و دلیل این هدف پیگیری پیشرفت و تضمین تکمیل به موقع آن است.
در ادامه، یک نمونه دیگر:
“به عنوان خریدار آنلاین، میخواهم محصولات را براساس محدوده قیمت فیلتر کنم تا بتوانم کالاهایی که به بودجه من میخورند، پیدا کنم.”
در این حالت، کاربر یک خریدار آنلاین است، هدف او فیلتر کردن محصولات براساس محدوده قیمت است و دلیل این هدف پیدا کردن کالاهایی است که با بودجه وی تناسب دارند.
به خاطر داشته باشید که داستانهای کاربری باید کوتاه، مختصر و تمرکز شده باشند و بر روی نیازها و انگیزههای کاربران تمرکز کنند. آنها به عنوان یک وسیله ارتباطی بین تیم توسعه و ذینفعان عمل کرده و فرایند توسعه را هدایت میکنند و تضمین میکنند که محصول نهایی نیازهای کاربران را برآورده میکند.
- بک لاگ اسپرینت: لیست وظایف اسپرینت (Spring Backlog) از موارد لیست نیازمندیهای محصول که برای یک اسپرینت انتخاب شدهاند، تشکیل میشود. در این لیست نیز برنامهای برای تولید یک ورژن جدید از محصول (Increment) در پایان اسپرینت وجود دارد. لیست وظایف اسپرینت، کاری را که تیم توسعه در اسپرینت بعدی انجام خواهد داد و مواردی که برای تولید یک افزایش مطابق با “تعریف انجام شده” (Definition Of Done یا DOD) نیاز است، تعیین میکند.
چهارچوب اسکرام:
چارچوب Scrum یک روش چابک است که تمرکز آن بر تحویل ارزش به صورت تدریجی و تکراری در طول زمان است. فرآیند با ایجاد یک لیست نیازمندیهای محصول توسط مالک محصول با توجه به ورودیها از مدیران اجرایی، تیمها، سهامداران، مشتریان، کاربران و سایر ذینفعان آغاز میشود و با نمایش کارهای پایان یافته در یک جلسه بررسی اسپرینت (Sprint Review) و سپس با یک نگاه بازبینی اسپرینت (Sprint Retrospective) به پایان میرسد. این فرآیند در فواصل زمانی منظم، معمولاً 1 تا 4 هفته، تکرار میشود.
اسکرام و رویدادهای اسکرام به طور عمدی سبک و ساده است. اسکرام آسان برای یادگیری است، اما ممکن است مسلط شدن بر آن دشوار باشد. هدف آن ارائه یک چارچوب برای تیمهای چندوظیفهای جهت حل مسائل پیچیده است.
به طور ساده اسکرام یک روششناسی یا فرآیند است که از طریق آن میتوان به ذهنیت چابک عمل کرد.
نقش ها در اسکرام
در روش اسکرام، نقشهایی به طور واضح تعریف شدهاند.
- تیم توسعه اسکرام (Development Team)
- اسکرام مستر (Scrum Master)
- مالک محصول (Product Owner)
این نقشها کمک میکنند تا مدل اسکرام را از روشهای چابک مشابهی مانند Extreme Programming، Lean Development و توسعه مبتنی بر آزمون (Test Driven Development یا TDD) متمایز سازند. این نقشها به تعریف دقیقتری از مسئولیتها و وظایف در سیستم اسکرام کمک میکنند. این تفاوت در نقشها باعث بهبود هماهنگی، شفافیت و تضمین میشود که هر نقش مسئولیتهای خاص خود را ایفا کند و به خوبی در تیم کار کند.
محیط اسکرام ترویج میکند که از تیمهای کوچک و قابل انعطافی با حداکثر ۹ نفر استفاده شود که از طریق لیست کارهای محصول کار میکنند. یک قاعده معروف برای اندازه تیم این است که ببینید میتوانید تیم اسکرام را با دو پیتزا (از نوع خانواده اش) سیر کنید!
این قاعده به طور معمول معادل ۵ تا ۹ نفر در یک تیم است. افراد باید تنها به یک تیم اسکرام اختصاص یابند. این قاعده به طور معمول به دلیل شیوه ارتباط تیمها، تطبیق انگیزهها و قابلیت افراد برای حفظ روابط همزمان است.
حال به تشریح هر کدام از نقشهای اسکرام میپردازیم:
- تیم توسعه محصول:
تیم توسعه اسکرام یک گروه از متخصصان است که مسئولیت ارائه یک نسخه قابل انتشار و “کامل” در پایان هر اسپرینت را بر عهده دارند. تیمهای توسعه سه ویژگی متمایز زیر را دارند:
-
- تیمهای توسعه خودسازمانده هستند: یعنی هیچ کس در تیم اسکرام (حتی اسکرام مستر) مجاز به دستور دادن به آنها در رابطه با چگونگی انجام کارها نیست. تیم توسعه خودش تصمیم میگیرد.
- چند وظیفه ای هستند: تمام اعضا باید مهارتهای مورد نیاز برای ایجاد یک نسخه را داشته باشند؛ برخی از اعضا ممکن است مهارتهای متفاوتی داشته باشند، اما همه باید بتوانند به تیم کمک کنند. به طور مثال برنامه نویسان باید از تکنولوژی های کاری همدیگر اطلاعات داشته باشند به طور مثال بک اند و فرانت اند کار یکدیگر را متوجه بشوند.
- به عنوان یک تیم همگی مسئولیت موفقیتها و شکستها را بر عهده دارند: مهم نیست که یک عضو خطایی انجام داده باشد که باعث نشد تیم در پایان یک اسپرینت نسخهای را داشته باشد، تیم توسعه به عنوان یک کل مسئولیت را میپذیرد.
- اسکرام مستر (Scrum Master):
اسکرام مستر مسئول تسهیل فرآیند اسکرام است. او مطمئن میشود که همه اعضا درک قوی از اصول اسکرام داشته باشند و در صورت نیاز راهنمایی و آموزش ارائه میدهد.
استاد اسکرام تیم اسکرام را در طول اجرای جلسه روزانه اسکرام (Daily Scrum) هدایت میکند. او اغلب سه سوال زیر را مطرح میکند:
– دیروز چه کاری انجام دادید؟
– فردا چه کاری انجام خواهید داد؟
– به چه مشکلاتی برخورده اید؟
اسکرام مستر رهبر یا مدیر افراد تیم اسکرام نیست. یعنی به طور مستقیم مسئول نتایج نیست. تیم به صورت کلی باید مسئولیت نهایی محصول را قبول کند.
اسکرام مستر همچنین با مالک محصول همکاری میکند تا اطمینان حاصل شود که پروژه در مسیر صحیح قرار دارد.
وظایف اسکرام مستر شامل موارد زیر میشود:
– تضمین اینکه اهداف اسکرام توسط همه درک شود.
– بهینهسازی مدیریت لیست کارهای محصول.
– برگزاری رویدادهای اسکرام.
– کمک به برطرف کردن موانع در صورت بروز.
وظیفه اسکرام مستر این است که همه را متمرکز و به سمت هدف یکسان هدایت کند. آنها مسئولیت برطرف کردن موانع، جلوگیری از حواشی غیرضروری و کمک به تیم در پیشرفت روز به روز را برعهده دارند. هرچند نتیجه نهایی اسکرام در نهایت به عهده تیم کلی است، اما اسکرام مستر اغلب با فشار زیادی در انجام وظایف خود مواجه میشود تا در سمت خود موفقیت آفرین باشد.
- مالک محصول:
مالک محصول نماینده کسب و کار یا مشتریان هستند. آنها برای اطمینان حاصل کردن از اینکه سایر اعضای تیم اسکرام هدف اسپرینت را فراموش نمیکنند، حضور دارند. به دلیل تنوع گسترده کاربران کسب و کار و مشتریان، مالک محصول باید درک قوی از نیازهای کاربران داشته باشد.
هر اسپرینت با مستندسازی و اولویتبندی نیازها و ویژگیهای مورد نظر محصول توسط مالک محصول برای تیم توسعه شروع میشود. در جلسه برنامهریزی، وظیفه مالک محصول پاسخ دادن به هر گونه سوالی که تیم توسعه درباره مشخصات و نیازها دارد است.
مالک محصول در فرآیند توسعه شرکت نمیکند، اما ممکن است در طول هر اسپرینت برای پاسخ به سوالات ابهامزدایی مورد سوال قرار بگیرد.
مسئولیتهای روزمره یک مالک محصول ممکن است شامل موارد زیر باشد:
– مستندسازی نیازهای محصول
– نوشتن فعالیتها، فیچرهای کلی و داستانهای کاربری
– هماهنگی با مدیریت محصول برای اطمینان حاصل کردن از اینکه نیازهای محصول با نقشه جامع محصول هماهنگ هستند
– پژوهش درباره نیازهای واقعی مشتریان و کاربران محصول
– پاسخ به سوالات ابهامزدایی تیم توسعه
– همکاری با ذینفعان در داخل و خارج از سازمان برای اطمینان حاصل کردن از قابلیت فروش، پیادهسازی و پشتیبانی محصول
مالکان محصول برای یک چرخه توسعه محصول موفق در روش اسکرام بسیار حیاتی هستند. بدون نیازهای واضح و اولویتبندی شده، تیمهای توسعه نمیدانند چه مواردی را در چه ترتیبی توسعه دهند. مالکان محصول اطمینان میدهند که تیمهای توسعه میدانند کدام موارد در حال حاضر برای کار بر روی آنها مهمتر است و چه چیزهایی در آینده قرار است انجام شوند.
رویدادهای اسکرام
در اسکرام، پنج رویداد اصلی وجود دارد:
- اسپرینت
- برنامهریزی اسپرینت (Sprint planning)
- دیلی اسکرام یا جلسه روزانه ایستاده (Daily Scrum)
- بررسی اسپرینت (Sprint review)
- بازبینی اسپرینت (Sprint retrospective)
بعضی از نوعهای رویدادهای اسکرام در طول فرآیند توسعه در زمانهای مشخصی برگزار میشوند. اینها همچنین به عنوان مراسمهای اسکرام شناخته میشوند.
-
اسپرینت:
یک اسپرینت در اسکرام، یک بازه زمانی ثابت و کوتاهمدت است که معمولاً یک ماه یا کمتر است و در آن ایدهها به ارزش تبدیل میشوند. اسپرینت، ضربان قلب اسکرام است و یک بازه زمانی مشخص است که به صورت متناوب تکرار میشود. اغلب تیمها آینده خود را با اسپرینتها اندازهگیری میکنند.
هدف اصلی اسپرینت، تعیین زمان محدود برای انجام کار و تحقق تعهدات تیمهاست. اسپرینتها امکان تعیین اهدافی را در دوره زمانی کوتاهتر، اما بسیار محکم فراهم میکنند. در طول یک اسپرینت، هیچ چیزی نباید تغییر کند که منجر به تهدید هدف اسپرینت شود.
اسپرینت تیم را در مسیر درست نگه میدارد، اما اجازه اصلاح مسیر یا تغییرات از یک اسپرینت به اسپرینت را میدهد. اسپرینتها با اطمینان قابلیت پیشبینی را فراهم میکنند، زیرا تضمین میکنند که آنچه که تیم توسعه به آن تعهد میکند، در یک بازه زمانی کوتاه، برای انجام خواهد بود.
با استفاده از اسپرینتها، عبارت “زمان را خواهیم دید” از بین میرود. ما میدانیم که چه زمانی اتفاق میافتد، زیرا یا در اسپرینت تعهد شده است یا نشده است.
یک اسپرینت میتواند بین ۱ تا ۴ هفته طول داشته باشد، اما بیشتر از این مدت نباید باشد. این محدودیت به تیمها امکان میدهد به سرعت پیشرفتهای تدریجی را ارائه دهند، اما بدون اینکه افراد را سردرگم کنند. اسپرینتها نمیتوانند بیشتر یا کمتر شود. یک اسپرینت تنها در صورتی که هدف اسپرینت منسوخ شود، لغو خواهد شد. تنها مالک محصول دارای اختیار لغو اسپرینت است.
-
برنامه ریزی اسپرینت:
در رویداد برنامهریزی اسپرینت، تیم بر روی مجموعهای از موارد backlog محصول که در اسپرینت آتی تکمیل خواهند شد، توافق میکند. برای هر هفته اسپرینت، یک ساعت برای برنامهریزی اسپرینت اختصاص داده میشود. جلسه برنامهریزی اسپرینت قبل از شروع اسپرینت برگزار میشود، بنابراین اگر اسپرینت آتی برای ۴ هفته است، تیم چهار ساعت را برای این جلسه در نظر خواهد گرفت.
مهمترین بخش جلسه برنامهریزی اسپرینت، آمادهسازی است که قبل از شروع جلسه باید انجام شود. مالک محصول با backlog اولویتبندی شده داستانها و ویژگیهایی که میخواهد تیم توسعه به آنها بپردازد، در جلسه حاضر میشود.
در جلسه برنامهریزی اسپرینت، تیم توسعه و مالک محصول بر روی اینکه چه چیزی مورد نیاز است و چه مقدار زمان برای برآورده شدن این نیازها پیشبینی میشود، توافق میکنند.
اینکه کدام و چند مورد از backlog محصول تکمیل خواهند شد، به تعهد و سرعت تیم توسعه (سرعتی که تیم توسعه میتواند نسخههای جدید را ایجاد کند) بستگی دارد. اگر با یک تیم جدید برنامهریزی میکنید، بهتر است تا زمانی که چند اسپرینت با تیم انجام دادهاید، بر اساس سرعت مورد انتظار محاسبه نکنید.
-
جلسه روزانه اسکرام:
هر روز، جلسه روزانه اسکرام برگزار میشود که در آن اعضای تیم درباره پیشرفتی که کردهاند و مشکلاتی که با آنها روبهرو هستند، بحث میکنند تا با هدف تقویت روحیه بابت پیشرفت، هماهنگی کارهای کنونی و برطرف کردن موانع تیم را در جهت پیشروی نگه دارند.
جلسات اسکرام هر روز در طول یک اسپرینت برگزار میشوند. این جلسات باید بیش از پانزده دقیقه طول نکشند (بخاطر همین سرپا برگزار میشوند) و باید بر تمرکز برای حرکت دادن تیم تمرکز داشته باشند.
جلسات روزانه اسکرام هر روز برگزار میشوند تا جلوی انباشت مشکلات در پسزمینه گرفته شود. هر گونه سوال یا نگرانی باید در جلسه روزانه اسکرام مطرح شود.
-
بررسی اسپرینت:
جلسه بررسی اسپرینت در پایان هر اسپرینت برگزار میشود و هدف اصلی آن مرور پیشرفتهای انجام شده است. در طول جلسه بررسی اسپرینت، مالک محصول ارزیابی میکند که نتایج حاصل، با انتظاراتی که در جلسه برنامهریزی اسپرینت مشخص شده بود، مطابقت دارند یا خیر. در اینجا، مالک محصول بررسی میکند که نسخه کار، معیار تعریف شده برای اتمام کار (definition of done) را برآورده میکند یا خیر.
-
بازبینی اسپرینت:
جلسه بازبینی اسپرینت به تیم شما امکان میدهد به رویدادها و وضعیتهای گذشته نگاهی بیندازد. به مطابقت با راهنمای اسکرام، جلسه بازبینی اسپرینت فرصتی برای تیم اسکرام است تا خود را بررسی کند و برنامهای برای بهبودها در اسپرینت بعدی ایجاد کند. این موضوع قابل درک است، به ویژه اینکه تمرکز توسعه چابک بر بهبود مداوم است. برای بهتر شدن، باید بدانید کدام شمشیر را باید تیز کنید.
بازبینی باید فضایی باز را برای انتقال بازخورد صادقانه در مورد چه چیزهایی خوب پیش میرود، چه چیزهایی میتوانست بهبود یابد و بحثی در مورد چیزهایی که باید در دوره بعد تغییر کنند (با مستندسازی موارد عملی) ایجاد کند.
تفاوت بازبینی (retrospective) و مرور (review) اسپرینت چیست؟
این دو جلسه چه فرقی با هم دارند؟ در زیر این دو جلسه با هم مقایسه شده اند:
جلسه بررسی اسپرینت (Sprint Review): بررسی اسپرینت در انتهای هر اسپرینت برگزار میشود و عمدتاً بر روی نمایش کارهای انجام شده در طول اسپرینت تمرکز دارد. هدف اصلی آن جمعآوری بازخورد، بررسی افزایش و همکاری با ذینفعان است. در طول بررسی اسپرینت، تیم توسعه ویژگیها یا عملکردهای پیادهسازی شده را به ذینفعان نمایش میدهد و بازخورد آنها را دریافت میکند. این فرصتی است برای بررسی و تطبیق محصول بر اساس بازخورد ذینفعان و اطمینان حاصل کردن از تطابق آن با انتظارات و نیازمندیها.
جلسه بازبینی اسپرینت (Sprint Retrospective): بازبینی اسپرینت نیز در انتهای هر اسپرینت برگزار میشود اما تمرکز متفاوتی دارد. هدف آن بررسی روند اسپرینت و شناسایی فرصتهای بهبود است. تیم اسکرام، از جمله تیم توسعه، اسکرام مستر (Scrum Master) و مالک محصول (Product Owner)، در بازبینی اسپرینت بهطور فعال شرکت میکنند. تیم بر روی اینکه چه چیزهای خوب بوده است، چه چیزهای بهتر میتوانست انجام شود و هر تغییری برای بهبود کارایی و کارآیی خود راهبردی است، تأمل میکند. هدف بازبینی اسپرینت، تحقق بهبود مستمر با شناسایی و اجرای تغییرات در فرایندها، ابزارها و روشهای همکاری تیم است.
برنامه ریزی برای پروژه ها در قالب اسکرام
اسکرام میتواند برای پروژههایی با اندازههای مختلف استفاده شود و بر اصل توسعه چابک مبتنی است، که بر نیاز به انعطافپذیری و پاسخگویی به تغییر تأکید دارد.
مرحله اول در استفاده از متدولوژی اسکرام، ایجاد یک مجموعه اولویتبندی شده از محصول است. مجموعه اولویتبندی شده از محصول، یک لیست از کارهایی است که برای دستیابی به هدف پروژه باید انجام شود. کارها میتوانند در هر زمان به مجموعه اولویتبندی شده از محصول افزوده شوند و بر اساس اهمیت، اولویتبندی شوند.
با ایجاد مجموعه اولویتبندی شده از محصول، مرحله بعدی ایجاد یک مجموعه اولویتبندی شده از اسپرینت است. مجموعه اولویتبندی شده از اسپرینت، شامل یک لیست از کارهایی است که در طی یک اسپرینت یا دوره زمانی خاص انجام میشود. کارهای موجود در مجموعه اولویتبندی شده از اسپرینت باید بر اساس کارهای مجموعه اولویتبندی شده از محصول که اهمیت و فوریت بیشتری دارند، انتخاب شوند.
برای اطمینان از اینکه کارها به طور کارآمد و مؤثری انجام میشوند، متدولوژی اسکرام از مجموعهای از دستورالعملهای خاص برای کمک به حفظ قابل مدیریت بودن استفاده میکند. این دستورالعملها عبارتند از:
– کارها باید به قطعات کوچک و قابل مدیریت تقسیم شوند.
– کارها باید به اعضای خاصی از تیم اختصاص یابند.
– اعضای تیم باید به طور منظم برای بهروزرسانی یکدیگر در مورد پیشرفت خود دیدار کنند.
– تیم همواره باید تمرکز خود را بر روی انجام کارهای مهمتر اولیه داشته باشد.
با رعایت دستورالعملهای متدولوژی اسکرام، تیمها میتوانند در هنگام کار بیشتر بهرهور و کارآمدتر باشند. انعطافپذیری این رویکرد به اعمال تغییرات سریع در مواقع نیاز کمک میکند و باعث میشود پروژهها در مسیر و زمان مناسب باقی بمانند. اسکرام همچنین همکاری، تعامل و ارتباط بین اعضای تیم را تشویق میکند که به تضمین نتایج موفق کمک میکند.
نقاط مثبت و مزایای اسکرام
متدولوژی اسکرام یک روش چابک برای تحویل پروژه یا محصول است که به تیمها کمک میکند به صورت کارآمد و موثرتر کار کنند. این رویکرد ساده اما قدرتمندی است که میتواند برای توسعه نرمافزار، طراحی محصول، پروژههای بازاریابی و سایر فعالیتها استفاده شود.
بعضی از مزایای استفاده از متدولوژی اسکرام عبارتند از:
افزایش بهرهوری: وقتی تیمها قادر به کار در دورههای کوتاه زمانی به نام “اسپرینت” باشند، معمولاً میتوانند بیشتر از آنچه که در طول یک دوره زمانی بلندتر روی پروژه کار میکنند، به نتیجه برسند.
افزایش همکاری: متدولوژی اسکرام تشویق به اعضای تیم برای همکاری نزدیک به منظور دستیابی به اهداف مشترک است. این میتواند به کاهش سوءتفاهم و بهبود ارتباط کمک کند.
افزایش انعطافپذیری: متدولوژی اسکرام انعطافپذیر بوده و قابلیت سازگاری با نیازهای خاص تیم پروژه را دارد. این میتواند به تضمین این کمک کند که پروژه اولویت بندی کامل از موارد مهم را رعایت کند و در عین حفظ تعهدات هزینه و برنامهریزی باشد.
بهبود کیفیت: با استفاده از اسپرینتهای کوتاه، تیمها قادر به تمرکز بر انجام وظایف مشخص و اطمینان از کیفیت بالای آنها هستند. این میتواند کمک کند تا از اشتباهات گرانقیمت جلوگیری شود و کیفیت کلی محصول یا خدمات نهایی را بهبود بخشد.
تاریخچه خلاصه ای از اسکرام
1986: هیروتاکا تاکئوچی و ایکوجیرو نوناکا مقاله “بازی جدید توسعه محصول” را در مجله هاروارد بیزینس ریویو منتشر کردند و کلمه “اسکرام” را برای استفاده خارج از بازی راگبی ابداع کردند.
1995: جف ساترلند و کن شوبر اسکرام را در کنفرانس OOPSLA معرفی کردند.
2001: ساترلند، شوبر و 15 توسعهدهنده دیگر “اعلانیه برای توسعه چابک” را ایجاد کردند که به طور معمول به “اعلانیه چابک” مشهور است. انجمن چابک تأسیس شد و اسکرام را به عنوان یکی از روشهای چابک نام برد.
2002: شوبر کتاب “توسعه نرمافزار چابک با اسکرام” را با مایک بیدل منتشر کرد، انجمن اسکرام را تأسیس کرد و شروع به ارائه گواهینامههای اسکرام کرد.
2004: شوبر کتاب “مدیریت پروژه چابک با اسکرام” را منتشر کرد که توسط کتابها و راهنماهای دیگر درباره کاربرد اسکرام در زمینههای مختلف پیگیری شده است.
2007: چارچوب چابک مقیاسپذیر (SAFe) توسعه یافت.
2014: دکتر دیو کورنلیوس، یک مبلغ شناخته شده روش لین و چابک، پژوهش دکتری خود را بر اساس متدولوژی اسکرام ارائه کرد که بر تأثیر اسکرام بر سازمانها تمرکز داشت.
از سال 2014 به بعد، اسکرام در زمینههای جدیدی اعمال شده است، از جمله در مقیاسهای بزرگ در سراسر جهان.
مقایسه اسکرام با رقبا
Agile (چابک) در مقابل اسکرام
به طور ساده، چابک ذهنیت است و اسکرام یکی از روشهای متعددی است که از ذهنیت چابک بهره میبرد. اسکرام در چارچوبی از ذهنیت چابک قرار دارد و در کنار روشهای دیگری که تمرکزشان بر چابک است، از جمله extreme programming، lean، kanban، SAFe، test-driven development، crystal و غیره قرار میگیرد.
تفاوت بین اسکرام و چابک این است که اسکرام یک برنامه یا راهنمایی برای پیادهسازی فرآیندهایی است که با ذهنیت چابک هماهنگ شدهاند. توسعه نرمافزار چابک با استفاده از اسکرام یکی از رویکردهای محبوب در توسعه است.
مقایسه اسکرام و کانبان
روشهای دیگری نیز برای پیادهسازی رویکرد چابک وجود دارد. به عنوان مثال، یک رویکرد محبوب دیگر کانبان است که در مقایسه با اسکرام تفاوتهایی دارد. در کانبان، نیازی به تعریف دقیق نقشها نیست و اجرای اسپرینتها با مدت زمان ثابت را نیز ندارد و در هر لحظه از فرآیند توسعه، آمادگی برای تغییرات در جریان کار وجود دارد.
کلید موفقیت کانبان در محدود کردن تعداد موارد کاری که در حال پیشروی هستند در هر لحظه است. محدودیت موارد کار در حال پیشروی، تیم را مجبور میکند برای حل و پایان دادن به کارهایی که شروع کردهاند، به صورت جمعی عمل کنند، زیرا اگر کارهای قدیمی هنوز به پایان نرسیده باشند، اجازه شروع کارهای جدید در پیشروی را نخواهند داشت. یک تیم اسکرام را میتوان با اسپرینتهایش شناسایی کرد و یک تیم کانبان را میتوان با محدودیتهای موارد کار در حال پیشروی شناسایی کرد.
ممکن است یک تیم اسکرام از یک تخته کانبان برای نمایش بصری موارد کار خود در وضعیتهای مختلف استفاده کند – این کاملاً مجاز است! استفاده از تخته کانبان بر روی عملکرد اسکرام تأثیری ندارد، به شرطی که نقشها، رویدادها و باکسهای زمانی هنوز در استفاده باشند.
نرم افزارهای اسکرام
اسکرام و ابزارهای مرتبط با آن نه تنها برای تیمهای توسعه نرمافزار مفید هستند، بلکه برای سایر محصولات نیز کاربرد دارند. چارچوب اسکرام در بسیاری از شرکت ها قابل استفاده است – از آژانسهای بازاریابی تا شرکتهای ساخت و ساز.
اگر به دنبال استفاده از یک نرم افزار ایرانی و فارسی تحت وب با رابط کاربری ساده برای پیاده سازی اسکرام هستید پیشنهاد ما به شما نرم افزار مدیریت پروژه سازمان یار است.
اما اگر به دنبال یک نرم افزار بین المللی هستید در زیر، برخی از بهترین نرمافزارهای مدیریت پروژه با قابلیتهایی مانند backlog و برنامهریزی sprint آورده شدهاند که به شما در دنبال کردن روش اسکرام کمک میکنند.
- Monday.com: بهترین گزینه برای ایجاد جریان کار سفارشی بین تیمها
- Jira: بهترین گزینه برای اتوماسیون مدیریت پروژه با انعطاف بالا
- Wrike: بهترین نرمافزار مدیریت پروژه برای سازمانهای در حال رشد
بهترین منابع خارجی برای یادگیری اسکرام
Scrum guides: یک راهنمای رسمی (و رایگان) که بدنه دانش اسکرام را شامل می شود. این راهنما توسط بنیان گذاران اسکرام، کن شوابر و جف ساترلند نوشته شده است.
Scrum.org: یک سازمان به شکل حرفه ای شناخته شده است که آموزش و گواهینامه های رسمی از جمله اسکرام مستر حرفه ای، مالک محصول اسکرام حرفه ای و توسعه دهنده اسکرام حرفه ای را ارائه می دهد.
Scrum alliance: یک سازمان که افراد با سطوح تجربه مختلف درباره اسکرام آموزش می دهند. آنها همچنین آموزش و گواهینامه هایی در قالب اسکرام مستر آموزش دیده، مالک محصول معتبر و توسعه دهنده اسکرام معتبر ارائه می دهند.
Scrum inc: تاسیس شده توسط جف ساترلند، هم بنیان گذار اسکرام، که به صورت منظم وبلاگ را به روز می کند. آنها آموزش و گواهینامه نیز ارائه می دهند.
Atlassian: یک شرکت نرم افزاری بزرگ استرالیایی که راهنماهای دقیق و با عملکرد بالا در مورد روش های چابک، از جمله اسکرام، ارائه می دهد.
واژه نامه اسکرام
برای کسانی که با اسکرام آشنایی ندارند، اسکرام ممکن است ترسناک به نظر برسد. در ادامه، برخی از اصطلاحات رایج اسکرام را مرور می کنیم.
در ادامه، لیستی از اصطلاحات اسکرام را برای شما آورده ایم که در هر لحظه می توانید به آنها مراجعه کنید:
چابک: گرایش و چتری که ساختار اسکرام در آن توسعه یافته است. این گرایش انعطاف پذیری و تطبیق را بر ساختار سخت ترجیح می دهد.
نمودار Burn down یا تطابق کارها: یک نمودار که مقدار کاری را که در پشته محصول باقی مانده است نشان می دهد.
نمودار Burn up: یک نمودار که مقدار کاری را که از پشته محصول انجام شده است نشان می دهد.
جلسه روزانه یا Daily Scrum: یک جلسه که روزانه برگزار می شود و در آن پانزده دقیقه برای برنامه ریزی روز آینده کار در نظر گرفته می شود.
Definition of Done یا DOD: انتظاری که باید یک تسک یا کار برای قابل انتشار بودن برآورده کند.
تیم توسعه: تیم درون تیم اسکرام که مدیریت، سازماندهی و انجام کار توسعه لازم برای ایجاد یک افزایش را انجام می دهد.
تجربه گرایی یا Empiricism: کنترل فرآیند که می گوید فقط گذشته قطعی است. این امکان را برای انعطاف بیشتر در چارچوب چابک فراهم می کند. ارزشهای شفافیت، بررسی و تطبیق را قدردانی می کند.
استانداردهای مهندسی: مجموعه ای از استانداردهای مشترک در تیم ها به منظور اطمینان از افزایش ها.
پیش بینی قابلیت ها: مجموعه ای از افزایش ها که تیم توسعه را به عنوان قابل انجام در یک اسپرینت می بیند.
افزایش یا فیچر و یا نسخه جدید: یک قطعه نرم افزار که به افزایش های دیگر اضافه می شود. همه افزایش های کافی، یک محصول را تشکیل می دهند.
پشته محصول: لیستی (معمولاً مرتب شده) از کارهایی که برای ایجاد یک محصول باید انجام شود.
مالک محصول: عضوی از تیم اسکرام که وظیفه حداکثر کردن ارزش یک محصول را دارا می باشد.
تابلو یا تخته اسکرام: یک روش آسان برای تصویرسازی اطلاعاتی است که بین تیم اسکرام به اشتراک گذاشته می شود.
راهنمای اسکرام: تعریف اصلی اسکرام است. این راهنما جزئیات نقش ها، رویدادها، اشیاء و قوانین اسکرام را توضیح می دهد.
اسکرام مستر: مسئول رهبری تیم اسکرام است. اطمینان حاصل می کند که همه اعضا به اصول اسکرام مسلط باشند. در صورت لزوم راهنمایی و آموزش ارائه می دهد.
ارزشهای اسکرام: ارزشهای اصلی که چارچوب اسکرام را رهبری می کنند. این ارزشها شامل تعهد، تمرکز، شفافیت، احترام و شجاعت می باشند.
خودسازماندهی: یک اصل اساسی اسکرام که میگوید تیم ها باید کار خود را بدون تداخل از تیم های دیگر داخلی سازماندهی کنند.
اسپرینت: یک بازه زمانی یک ماه یا کمتر است که در آن رویدادهای اسکرام انجام میشود. اسپرینت ها پشت سر هم انجام میشوند و هیچ وقفه ای بین آنها وجود ندارد.
هدف اسپرینت: هدفی که اسپرینت فعلی دارد.
بازبینی اسپرینت: یک جلسه است که حداکثر چهار ساعت طول میکشد و پایان یک اسپرینت را نشان میدهد. کار بررسی می شود و ذینفعان افزایش را بررسی کرده و اطمینان حاصل می کنند که با تعریف پایان منطبق است.
ذینفع: شخصی که خارج از تیم اسکرام یا داخل آن است. نظریه خارجی را فراهم میکند و به طور فعال در بازبینی های اسپرینت شرکت میکند.
نظر شما در رابطه با اسکرام چیست؟
اگرچه اسکرام مدتی طولانی است که وجود دارد، اما همواره در حال تکامل است. آیا شما با تیمهای توسعه نرمافزار اسکرام را به طور مؤثر پیادهسازی کردهاید؟ چطور در خارج از توسعه نرمافزار؟ دوست داریم نکات و تجربیات شما را بشنویم!
من یکی از روشهای مورد علاقهام را با شما به اشتراک میگذارم تا بحث را آغاز کنیم: وقتی اسکرام را با یک تیمی که تازه با آن آشناست پیادهسازی میکنم، اغلب از واژگان پیچیده مانند اسپرینت، بهروزرسانی پشته کاری، برنامهریزی اسپرینت یا تکرار استفاده نمیکنم. به جای آن میگویم: “خب، زمان آن رسیده تا بر اساس پشته کاری هفته خود را برنامهریزی کنیم.” به این ترتیب، افراد به دلیل واژگان تخصصی نگران نمیشوند و به جای آن، متمرکز بر ارائه کار عالی میشوند.
این روش را که آن را “اسکرام پنهان” مینامم، به عنوان یک روش مؤثر برای من ثابت شده است و هماکنون در هنگام رهبری تیم توسعه محصول چندرشتهای یا فعالیت فردی، یک روش معمول شده است.
حالا به شما برمیگردم، چه چیزهایی درباره اسکرام یاد گرفتهاید؟ چه چیزی را برای بهبود این روش اضافه میکنید؟ در نظرات به ما اطلاع دهید و اگر اصطلاحاتی را برای افزودن به لیست واژهنامه اسکرام دارید، آنها را در نظرات همراه با تعریف اضافه کنید! ما دوست داریم از شما یاد بگیریم.
ثبت ديدگاه