راههای مختلفی برای پیادهسازی ذهنیت اجایل در فرایند توسعه محصول وجود دارد. با وجود تنوع سیستمها، روشها و فریومورکهای بسیار متعدد، میتوان با قطعیت گفت اسکرام و کانبان و (البته فرزند خلف آنها اسکرامبان) در زمره محبوبترین چارچوبها قرار دارند.
با وجود شباهتها در هدف نهایی - بهبود همکاری تیمی، شفافیت فرایندها و تحویل سریع محصول - اسکرام و کانبان از نظر ساختار، رویکرد و انعطافپذیری تفاوتهای اساسی دارند که انتخاب درست چارچوب را برای هر تیم تعیین میکند. در این مقاله میخواهیم کمی در تفاوت و تمایزهای این دو متد دقیقتر شویم.
اسکرام چیست؟
اسکرام یک فریمورک نسبتاً سفتوسخت مدیریت پروژه است. در اسکرام اعضای تیم در بازههای زمانی محدود بر روی آمادهسازی آیتمهایی مشخص کار میکنند. برنامهریزی، اجرا و بررسی کارها همگی در چرخههای زمانی کوتاهمدت انجام میشوند. در پایان هر چرخه باید خروجیهای مشخصی به ذینفعان یا مشتریان آن پروژه ارائه شوند.
اسکرام با شکلگیری یک تیم اسکرام آغاز میشود؛ تیم اسکرام متشکل از سه نقش ثابت است: مالک محصول، اسکرام مستر، تیم توسعهدهندگان.
اعضای این تیم در چرخههای زمانی دو تا چهار هفتهای که به آن اسپرینت میگویند، بر روی تحویل یک خروجی ارزشمند تمرکز میکنند. در اسکرام اعضای تیم با دریافت مستمر باخورد از کاربران و مشتریان، تلاش میکنند محصولی را توسعه دهند که دقیقاً مطابق با خواستهها و نیازهای کاربران باشد.
اسکرام در اجرا
اسکرام نه تنها یک روش مدیریت پروژه، بلکه روشی برای ایجاد و تقویت فرهنگ تیمی است. در این روش، هر فرد از تیم مسئولیتهای خاص خود را میداند و به طور مداوم از طریق جلسات روزانه و بررسی وضعیت، با تیم هماهنگ باقی میماند.
همانطور که یک تیم ورزشی برای پیروزی به هماهنگی و تخصصهای فردی نیاز دارد، تیمهای اسکرام هم باید به عنوان یک واحد هماهنگ و همراستا با یکدیگر کار کنند. این فرهنگ تیمی است که میتواند اسکرام را از یک متدولوژی ساده مدیریت پروژه به یک تجربه قدرتمند تیمی تبدیل کند.
حالا اجازه بدهید اسکرام را در یک پروژه فرضی با هم بررسی کنیم تا درک بهتری از ساز و کارهای آن پیدا کنیم.
اسکرام در یک پروژه فرضی:
تصور کنید تیمی میخواهد یک اپلیکیشن موبایل را برای یک فروشگاه آنلاین توسعه دهد؛ اعضای تیم، نقشها، رویدادها و روند کار میتواند چیزی شبیه به این باشد:
تیم فرضی اسکرام ما که شامل ۶ عضو است:
-
مالک محصول: سارا
-
اسکرام مستر: آرش
-
توسعهدهنده بکاند/Backend Developer: علی
-
توسعهدهنده فرانتاند/Frontend Developer: نیکا
-
طراح رابط کاربری/UI-UX Designer: لیلا
-
مهندس تست/Test Engineer: امیر
- مرحله اول: برنامهریزی اسپرینت/Sprint Planning
در ابتدای هر اسپرینت، تیم اسکرام جلسهای به نام برنامهریزی اسپرینت برگزار میکند. در این جلسه، اعضای تیم وظایف و تسکهای لازم برای اسپرینت بعدی را مشخص میکنند. مدت هر اسپرینت برای این تیم ۲ هفته است.
-
مالک محصول (سارا): وظیفه دارد که بکلاگ محصول یا فهرست کارهایی که باید انجام شوند را اولویتبندی کند. برای این پروژه، یکی از ویژگیهای مهم، «صفحه ورود به حساب کاربری» است.
-
اسکرام مستر (آرش): نقش تسهیلکننده را دارد و به تیم کمک میکند تا جلسه بهصورت مؤثر برگزار شود.
-
توسعهدهندگان (علی و نیکا): به همراه مالک محصول و اسکرام مستر (و توسعهدهندههای تیم) تخمین میزنند که هر تسک چقدر زمان میبرد.
-
طراح UI/UX (لیلا): باید طراحی صفحه ورود را در این اسپرینت تکمیل کند.
-
مهندس تست (امیر): مسئول نوشتن تستهای مربوط به صفحه ورود است.
پس تسکهای اسپرینت اول از این قرارند:
-
طراحی UI صفحه ورود (تسک لیلا)
-
پیادهسازی API برای ورود (تسک علی)
-
پیادهسازی فرم ورود در فرانت (تسک نیکا)
-
نوشتن تستهای صفحه ورود (تسک امیر)
- مرحله دوم: جلسات روزانه اسکرام/Daily Scrum
در طول اسپرینت، تیم به صورت روزانه جلسات ۱۵ دقیقهای به نام جلسه روزانه اسکرام برگزار میکند. هدف از این جلسه، بررسی پیشرفت تیم و شناسایی موانع است.
-
نیکا: امروز فرم ورود را به طور کامل پیادهسازی کردم، اما با مشکل ارتباط فرم با Backend مواجه شدم.
-
علی: من در حال کار بر روی API ورود هستم و برای برقراری ارتباط با پایگاه داده مسئله دارم.
-
لیلا: طراحی صفحه ورود تمام شده، اما باید هماهنگ شوم با نیکا برای اتصال آن به فرم.
-
امیر: من در حال نوشتن تستها برای بخش ورودی هستم، اما بهزودی باید از نیکا برای تست UI کمک بگیرم.
خروجی جلسه دیلی:
-
هماهنگی بین Frontend و Backend برای پیادهسازی صحیح فرم ورود.
-
نیاز به طراحی مجدد برخی از بخشهای UI پس از دریافت بازخورد از توسعهدهندگان.
-
مرحله سوم: اسپرینت بازبینی/Sprint Review
بعد از اتمام اسپرینت، تیم جلسهای به نام اسپرینت بازبینی برگزار میکند که در آن تمامی ویژگیهای پیادهسازیشده را به مالک محصول و سایر ذینفعان نشان داده و پیشرفت کار را پرزنت میکنند.
در این جلسه:
-
سارا: «در این اسپرینت، هدف ما تکمیل صفحه ورود به حساب کاربری بود. این ویژگی شامل طراحی جدید، پیادهسازی API و تستهای مربوطه میشد.»
-
لیلا: «در ابتدا، طراحی جدید صفحه ورود را بر اساس نیازهای کاربران و بازخوردهای قبلی ایجاد کردیم. این طراحی شامل فیلدهای ورودی، دکمهها و پیامهای خطا است.»
-
علی: «پس از تأیید طراحی، API لازم برای احراز هویت کاربران را پیادهسازی کردیم. این API از استانداردهای امنیتی لازم برخوردار است.»
-
نیکا: «در بخش فرانت، فرم ورود را بر اساس طراحی جدید پیادهسازی کردیم و آن را به API متصل کردیم.»
-
امیر: «تمامی سناریوهای تست برای صفحه ورود را نوشتیم و اطمینان حاصل کردیم که همه چیز به درستی کار میکند.»
-
مرحله چهارم: اسپرینت بازنگری/Sprint Retrospective
در پایان هر اسپرینت، تیم جلسهای به نام اسپرینت بازنگری برگزار میکند که در آن به مسائل ارتباطی و بهینهسازی فرایند اسپرینت پرداخته میشود. در این جلسه اعضای تیم به طور صادقانه درباره موارد زیر صحبت میکنند:
-
چه کارهایی به خوبی پیش رفت؟
-
چه چالشهایی وجود داشت؟
-
چه تغییراتی میتوانند در اسپرینت بعدی به بهبود عملکرد تیم کمک کنند؟
بازخورد تیم:
-
علی (توسعهدهنده Backend): چالش اصلی من این بود که اطلاعات کافی در مورد نیازهای Frontend نداشتم. در اسپرینت بعدی باید ارتباط بیشتری با نیکا داشته باشیم.
-
نیکا (توسعهدهنده Frontend): ارتباطم با لیلا خوب بود، اما گاهی اوقات به دلیل تغییرات در طراحی، نیاز به تغییرات در کدنویسی داشتم.
-
سارا (مالک محصول): گاهی اوقات اولویتبندی کارها بهطور دقیق مشخص نمیشد، در اسپرینت بعدی باید این موضوع را بهتر مدیریت کنیم.
کانبان چیست؟
کانبان یک فریمورک بسیار منعطف برای مدیریت پروژههای توسعه نرمافزار است. چارچوب Kanban با بهکارگیری یک «جریان کار/Workflow» تصویری، به تیمهای توسعه محصول کمک میکند بهرهوری خود را افزایش دهند.
کانبان با استفاده از بورد با سه ستون که یک هر مرحلهای متفاوت از کار را نشان میدهند سعی میکند تیمها را در یک جریان سیال برای انجام کارها قرار دهد. سه ستون «باید انجام شوند/To-Do»، «در حال انجام/Doing»، «انجامشده/Done» تصویری شفاف از وضعیت پیشرفت پروژه در اختیار اعضای تیم میگذارد.
کانبان در اجرا
تابلوی کانبان با تقسیم وظایف به ستونهای مختلف مانند «برای انجام»، «در حال انجام» و «انجام شده» به تیمها این امکان را میدهد که وضعیت هر تسک را بهوضوح مشاهده کنند. این شفافیت، تمرکز تیم را افزایش میدهد.
همچنین، با محدود کردن «کار در حال انجام/Work-In-Progress» یا تعداد تسکها از احساس بار اضافی و فشار بیش از حد جلوگیری میشود؛ این مزیت روانشناختی کانبان نسبت به بسیاری از فریمورکهای دیگر است که میتواند از فرسودگی روانی اعضای تیم جلوگیری کند.
با وجود مزایای فراوان، کانبان با چالشهایی نیز مواجه است. تعیین تعداد بهینه تسکهای در حال انجام و ایجاد تعادل بین سرعت و کیفیت، از جمله این چالشها هستند. تعیین WIP مناسب، نیازمند تجربه و آشنایی با ظرفیت تیم است و میتواند برای تیمهای کمتجربه بسیار دشوار باشد.
کانبان در یک پروژه فرضی:
اجازه بدهید مثالی که بالاتر برای اسکرام داشتیم را این بار برای کانبان تکرار کنیم؛ صرفاً برای یادآوری یک بار دیگر اعضای تیم شش نفره را مرور کنیم:
-
مالک محصول: سارا
-
اسکرام مستر: آرش
-
توسعهدهنده: علی
-
توسعهدهنده: نیکا
-
طراح رابط کاربری: لیلا
-
مهندس تست: امیر
مرحله اول: راهاندازی «بورد کانبان»
تیم کانبان از بورد کانبان که یک تخته فیزیکی یا دیجیتالی است استفاده میکند که شامل سه ستون اصلی است:
-
در انتظار انجام/To-Do
-
در حال انجام/Doing
-
انجام شده/Done
اعضای تیم وظایف را بهصورت کارتهایی روی تخته قرار میدهد. برای این پروژه، برخی از وظایف اولیه به این صورت تعریف میشوند:
-
طراحی UI صفحه ورود (تسک لیلا)
-
پیادهسازی API برای ورود (تسک علی)
-
پیادهسازی فرم ورود در فرانت (تسک نیکا)
-
نوشتن تستهای صفحه ورود (تسک امیر)
مرحله دوم: کار در چرخه کانبان
در کانبان، بهجای برنامهریزی برای بازه زمانی مشخص (مانند اسپرینت)، وظایف به ترتیب اولویت و ظرفیت تیم انجام میشوند.
در این مرحله اعضای تیم باید با توافق یکدیگر و با توجه به شناختی که از خود و پروژه دارند، برای تعداد تسکهایی که به صورت همزمان میتوانند در ستون «در حال انجام» قرار بگیرند، یک محدودیت تعیین کنند.
این یعنی وظایف تنها زمانی از ستون اولیه به ستون «در حال انجام» منتقل میشوند که این ستون ظرفیت خالی داشته باشد. تیم شش نفره ما تصمیم گرفته است که تعداد تسکهای جاری هرگز از «چهار» مورد تجاوز نکند.
روز اول:
-
در انتظار انجام: همه وظایف در این ستون قرار دارند.
-
طراحی UI صفحه ورود (تسک لیلا)
-
پیادهسازی API برای ورود (تسک علی)
-
پیادهسازی فرم ورود در فرانت (تسک نیکا)
-
نوشتن تستهای صفحه ورود (تسک امیر)
-
در حال انجام:
-
لیلا طراحی UI را شروع میکند.
-
علی شروع به پیادهسازی API میکند.
-
انجام شده: خالی است.
روز چهارم:
-
در انتظار انجام: نوشتن تستها (امیر)
-
در حال انجام:
-
لیلا طراحی UI را تمام و آن را به ستون «انجام شده» منتقل کرده است.
-
نیکا پیادهسازی فرم ورود را آغاز کرده است.
-
علی همچنان روی API کار میکند.
-
انجام شده: طراحی UI
روز هفتم:
-
در انتظار انجام: خالی است.
-
در حال انجام: خالی است.
-
انجام شده: همه وظایف (طراحی UI، پیادهسازی API، پیادهسازی فرم، نوشتن تستها) به پایان رسیدهاند.
جلسات تیم
کانبان نیاز به جلسات روزانه اجباری ندارد، اما تیم برای هماهنگی بهتر، جلسات منظمی را برنامهریزی میکند:
جلسه استندآپ:
-
هدف: بررسی وضعیت تخته کانبان و شناسایی موانع.
-
نیکا: «منتظرم API توسط علی تمام شود تا بتوانم فرم ورود را متصل کنم.»
-
علی: «API تا امروز عصر آماده میشود.»
-
لیلا: «برای یک تغییر کوچک در طراحی نیاز به بازخورد دارم.»
مرحله سوم: تحویل مداوم
در کانبان، تیم پس از اتمام هر وظیفه، آن را مستقیماً به مالک محصول و تیمهای مرتبط ارائه میدهد:
-
لیلا طراحی را کامل میکند و بلافاصله برای بازخورد به سارا ارائه میدهد.
-
پس از تکمیل API، علی آن را برای تست در اختیار امیر قرار میدهد.
مرحله چهارم: بازبینی عملکرد
تیم در بازههای زمانی مشخص (مثلاً هر دو هفته) جلسه بازبینی برگزار میکند. در این جلسه، اعضا درباره فرایند کار در کانبان صحبت میکنند:
-
چه چیزی خوب پیش رفت؟
-
علی: «تمرکز روی یک وظیفه در هر لحظه کمک کرد کارها سریعتر انجام شوند.»
-
چه چالشهایی وجود داشت؟
-
نیکا: «گاهی اوقات وظایف دیر آماده میشدند و باید منتظر میماندم.»
-
چه چیزی باید تغییر کند؟
-
سارا: «باید تعداد وظایف همزمان در ستون In Progress محدود شود تا تمرکز تیم افزایش یابد.»
مزایا و معایب: یک مقایسه کوتاه
وقتی میخواهیم دو چیز با هم مقایسه کنیم، ناگزیر باید مزیتها و ضعفهای آن دو پدیده را زیر ذرهبین ببریم. شناخت نقاط ضعف و قوت هر روش به شما کمک میکند بتوانید میزان بهرهوری تیم خود را در بهکارگیری آن روش افزایش دهید و از افتادن به چالههای آن اجتناب کنید.
|
اسکرام |
کانبان |
|
|
مزیتها |
|
|
|
ضعفها |
|
|
کدام یک بهتر است؟
کدومو انتخاب کنیم؟ کدومو جواب کنیم؟ سوال خوبیه! اجازه بدین صریح بگم: در اکثر مواقع حق انتخابی ندارین! انتخاب یه فریمورک برای جلو بردن یه پروژه به فاکتورهایی وابسته است که در خیلی اوقات حق انتخاب رو از افراد میگیره!
در این بخش اما سعی میکنیم کمی جزییتر و شفافتر توضیح بدهیم تفاوت این فریمورکها در کجا بیشترین نمود و اثرگذاری را دارند.
اسکرام بیشتر برای پروژههایی مناسب است که ددلاینهای معین و خروجیهای مشخص دارد.
اسکرام بیشتر برای تیمهایی مناسب است که با روتین و زمانبندی مشخص، بهرهروی بالاتری دارند.
اسکرام برای تیمهایی که آمادگی امور غیرمنتظره را ندارند میتواند چالش ایجاد کند.
کانبان مناسب پروژههایی است که جریان کاری سیال و پیوستهای دارند.
کانبان مناسب تیمهایی است که تکمیل کار از زمان انجام آن برایشان مهمتر است.
کانبان برای تیمهایی که در خودمدیریتی تمرین ندیدهاند میتواند دشوار باشد.
هیچکدام از این دو فریمورک به خودی خود و ذاتاً بهتر از دیگری نیست؛ هر کدام از آنها بسته به شرایط نقاط ضعف و قوت خود را دارند. انتخاب از بین اسکرام و کانبان بیش از هر چیز به ظرفیتها و نیازهای تیم، اولویتها و اهداف پروژه و سبک و فرهنگ کاری سازمان وابسته است.
تفاوتهای کلیدی در یک نگاه
|
اسکرام |
کانبان |
|
|
پیشینه ایجاد |
توسعه نرمافزار |
تولید |
|
فلسفه |
حل مشکلات پیچیده در عین تحویل خروجیهای ارزشمند |
استفاده از تصویر برای پیشبرد جریانها و فرایندها |
|
اندازه تیم |
معمولاً بین 3 تا 9 نفر |
برخلاف اکثر تیمهای اجایل، محدودیتی در تعداد اعضای تیم وجود ندارد. |
|
نقشها |
دارای سه نقش اصلی: اسکرام مستر که معمولاً زمانبندیها را مشخص میکند، مالک محصول که اهداف را تعیین میکند و تیم توسعه |
معمولاً یک مدیر پروژه در تیم حاضر است اما هیچ نقش از پیشتعیینشدهای وجود ندارد. |
|
تفویض وظایف |
تسکها به افراد محول میشود |
تسکها توسط اعضای تیم به اشتراک گذاشته میشود |
|
جلسات |
برنامهریزی بکلاگ محصول، برنامهریزی اسپرینت، دیلی اسکرام، بازبینی اسپرینت، بازنگری اسپرینت |
دیلی استندآپ؛ جلسات کوتاه روزانهای که برابر بورد کانبان برگزار میشوند. |
|
مدل اولویتبندی تسکها |
زیاد به کم |
برابر (در دل هر اسپرینت) |
|
انعطافپذیری |
تغییرات تنها در پایان هر اسپرینت ممکن هستند |
تغییرات در هر زمانی قابل اجرا هستند |
|
چرخههای زمانی |
دارای چرخههای زمانی کوتاه 2 تا 4 هفتهای |
جریان سیال و پیوسته کار که به بازههای زمانی تقسیم نمیشود. |
|
معیارها |
Velocity یا شتاب پیشرفت کارها در هر اسپرینت |
خروجی یا چرخه زمانی کل پروژه |
|
مناسبتر برای |
تیمهایی با اهداف پیچیده |
تیمهای متعدد یا تیمهایی با تعداد نفرات بالا |
جمعبندی
اسکرام و کانبان هر دو چارچوبهای اجایل هستند که برای مدیریت پروژهها طراحی شدهاند. اسکرام با استفاده از اسپرینتهای زمانبندیشده و ساختاری مشخص، برای پروژههایی با اهداف و خروجیهای معین و از پیش تعریفشده مناسب است. این روش بیشتر بر انجام وظایف در بازههای زمانی کوتاه تأکید دارد.
در مقابل، کانبان رویکردی انعطافپذیرتر را برای پروژههای با ماهیت پویا و تغییرپذیر فراهم میآورد. این چارچوب به تیمها اجازه میدهد تا بدون نیاز به زمانبندیهای مشخص، به جریان کار و اولویتهای جدید پاسخ دهند. در کانبان، مدیریت جریان کار و محدودیت تعداد وظایف در هر مرحله، از نکات کلیدی است.
انتخاب بین اسکرام و کانبان بستگی به نیازها و ویژگیهای خاص پروژه و تیم دارد. برای پروژههایی با خروجیهای مشخص و زمانبندی ثابت، اسکرام گزینه بهتری است، در حالی که کانبان برای پروژههای نیازمند انعطاف بیشتر و تغییرات مداوم کارآمدتر خواهد بود.
|
مدیریت محصول، نقشه راهیست بین نیاز کاربران و توانایی تیم. در اجیلیتی، آموزش مدیریت محصول با نگاهی به چالشها و فرصتهای بازار ایران ارائه میشود.
|