اسکرام (Scrum) روشی برای «ریزمدیریت کردن افراد» نیست؛ بلکه چارچوبی برای مدیریت کارهای پیچیده در شرایطی است که همه‌چیز را نمی‌توان از روز اول پیش‌بینی کرد. تیم در بازه‌های کوتاه کار میکند، نتیجه را بررسی میکند، از بازخورد یاد می‌گیرد و برنامه مرحله بعد را بر اساس واقعیت به‌روزرسانی میکند.
اسکرام در مدیریت دقیقاً چیست؟
در بسیاری از سازمان‌ها مدیریت هنوز با این فرض انجام میشود که مدیر باید از ابتدا همه فعالیتها، زمان‌ها و خروجی‌ها را مشخص کند و سپس افراد طبق همان برنامه جلو بروند. این روش در محیط‌های قابل پیش‌بینی میتواند کارآمد باشد، اما وقتی نیاز مشتری، شرایط بازار یا حتی تعریف مسئله در طول مسیر تغییر میکند، برنامه اولیه خیلی زود اعتبار خود را از دست می‌دهد.
اسکرام برای چنین محیطی طراحی شده است. به‌جای اینکه یک برنامه بزرگ برای چند ماه آینده تهیه شود، کار در دورههای کوتاهی به نام اسپرینت (Sprint) انجام میشود. طول هر اسپرینت حداکثر یک ماه است و بسیاری از تیم‌ها دورههای ۱ یا ۲ هفته‌ای را انتخاب می‌کنند.
در پایان هر اسپرینت باید یک نتیجه قابل بررسی وجود داشته باشد. بنابراین مدیریت از «آیا همه طبق برنامه مشغول هستند؟» به سؤال مهم‌تری تغییر میکند: «در این دوره چه ارزش واقعی ایجاد کردیم و اکنون بر اساس چیزی که یاد گرفته‌ایم چه باید بکنیم؟»
- برنامه‌ریزی در بازه‌های کوتاه انجام میشود.
- اولویتها مرتباً بازبینی می‌شوند.
- تیم نسبت به اجرای کار مسئولیت بیشتری پیدا میکند.
- مدیران به‌جای کنترل جزئیات، روی هدف، موانع و نتیجه تمرکز می‌کنند.
۱. سه مسئولیت اصلی در اسکرام چگونه مدیریت را تغییر می‌دهند؟
در اسکرام برخلاف بسیاری از ساختارهای سنتی، یک «مدیر پروژه» که تمام وظایف را بین اعضا تقسیم کند وجود ندارد. چارچوب اسکرام ۳ مسئولیت اصلی را تعریف میکند: Product Owner، Scrum Master و Developers. این تقسیم‌بندی باعث میشود مسئولیت تصمیم‌گیری درباره ارزش، روش کار و اجرای فعالیتها از یکدیگر تفکیک شوند.
Product Owner مسئول بیشینه‌کردن ارزش محصول و مدیریت اولویت‌های Product Backlog است. او قرار نیست هر روز به اعضای تیم بگوید چه کاری انجام دهند؛ بلکه باید مشخص کند چه مسئله‌ای مهم‌تر است و تیم باید روی چه نتیجه‌ای تمرکز کند.
Scrum Master مسئول اجرای دستورات مدیر نیست. وظیفه او کمک به تیم و سازمان برای درک و اجرای صحیح Scrum، حذف موانع فرآیندی و بهبود روش همکاری است.
Developers نیز فقط به برنامه‌نویسان اشاره ندارد. هر فردی که برای تولید نتیجه اسپرینت فعالیت میکند میتواند بخشی از این گروه باشد؛ از طراح و تحلیلگر گرفته تا متخصص بازاریابی یا سایر اعضای یک تیم چندتخصصی.
- Product Owner: مشخص میکند چه چیزی بیشترین ارزش را دارد.
- Scrum Master: به بهبود روش کار و رفع موانع کمک میکند.
- Developers: تصمیم می‌گیرند کار چگونه انجام شود.
نتیجه این ساختار آن است که مدیران ارشد مجبور نیستند تک‌تک فعالیت‌های روزانه را کنترل کنند. آنها میتوانند بیشتر روی تعیین جهت، حل محدودیت‌های سازمانی و ایجاد محیط مناسب برای عملکرد تیم تمرکز کنند.
۲. پنج رویداد اسکرام چگونه از جلسات بی‌هدف جلوگیری می‌کنند؟
اسکرام ۵ رویداد اصلی دارد: Sprint، Sprint Planning، Daily Scrum، Sprint Review و Sprint Retrospective. هر رویداد هدف مشخصی دارد و قرار نیست صرفاً به تقویم جلسات تیم اضافه شود.
Sprint Planning نقطه آغاز برنامه‌ریزی اسپرینت است. تیم مشخص میکند چرا این اسپرینت ارزشمند است، چه چیزهایی باید در آن انجام شود و برای رسیدن به هدف چه روشی مناسب‌تر است.
Daily Scrum یک هماهنگی روزانه کوتاه است. این جلسه برای تیمهای توسعه حداکثر ۱۵ دقیقه زمان دارد و هدف اصلی آن بررسی پیشرفت نسبت به Sprint Goal و تنظیم برنامه کار است، نه ارائه گزارش روزانه به مدیر.
Sprint Review برای بررسی نتیجه واقعی کار برگزار میشود. ذی‌نفعان میتوانند خروجی را مشاهده کنند و بر اساس بازخورد آنها، اولویت‌های آینده تغییر کند.
Sprint Retrospective نیز درباره خود محصول نیست؛ درباره روش کار تیم است. اعضا بررسی می‌کنند چه چیزی خوب پیش رفته، چه مشکلی داشته‌اند و در اسپرینت بعدی چه تغییری باید ایجاد کنند.
- Sprint: ظرف زمانی اصلی انجام کار
- Sprint Planning: تعیین هدف و برنامه اسپرینت
- Daily Scrum: هماهنگی کوتاه روزانه
- Sprint Review: بررسی خروجی و دریافت بازخورد
- Sprint Retrospective: اصلاح روش کار تیم
وجود این چرخه باعث میشود مشکلات برای چند ماه پنهان نمانند. تیم در فاصله‌های کوتاه مجبور است واقعیت را ببیند، نتیجه را ارزیابی کند و در صورت نیاز مسیر خود را اصلاح کند.
۳. چرا اسپرینت‌های کوتاه برای مدیریت عدم قطعیت مؤثر هستند؟
یکی از مهم‌ترین تفاوت‌های مدیریت چابک با برنامه‌ریزی سنتی، نحوه برخورد با عدم قطعیت است. در یک برنامه ۶ ماهه ممکن است فرض کنیم نیاز مشتری، اولویت مدیریت و ظرفیت تیم تغییر نمی‌کند؛ درحالی‌که در بسیاری از کسب‌وکارها چنین فرضی واقع‌بینانه نیست.
در اسکرام، Sprint حداکثر ۱ ماه طول دارد. اگر تیم اسپرینت‌های ۲ هفته‌ای داشته باشد، در یک دوره ۳ ماهه تقریباً ۶ فرصت رسمی برای ارزیابی نتیجه و اصلاح برنامه خواهد داشت. این ویژگی هزینه اشتباه را کاهش می‌دهد، زیرا تیم لازم نیست تا پایان پروژه صبر کند تا متوجه شود مسیر اشتباهی را انتخاب کرده است.
این موضوع به معنای «برنامه‌ریزی نکردن» نیست. اتفاقاً تیم دائماً در حال برنامه‌ریزی است؛ تفاوت در این است که برنامه‌ها بر اساس جدیدترین اطلاعات موجود ساخته می‌شوند.
| مدیریت سنتی | مدیریت با رویکرد اسکرام |
|---|---|
| برنامه تفصیلی بلندمدت | برنامه‌ریزی تدریجی در اسپرینت‌ها |
| تمرکز بر اجرای برنامه اولیه | تمرکز بر رسیدن به هدف و ایجاد ارزش |
| تغییر معمولاً یک اختلال محسوب میشود | تغییر بخشی طبیعی از یادگیری است |
| بازخورد معمولاً در مراحل پایانی | بازخورد در پایان هر اسپرینت |
| تخصیص کار توسط مدیر | خودمدیریتی بیشتر تیم |
برای آشنایی بیشتر با تفاوت این دو نگاه می‌توانید مطلب تفاوت اسکرام با WBS و مدیریت پروژه کلاسیک را نیز مطالعه کنید.
۴. سه Artifact اصلی اسکرام چه کمکی به شفافیت مدیریت می‌کنند؟
یکی از مشکلات رایج تیم‌ها این است که اطلاعات در چند فایل، پیام‌رسان، جلسه و ذهن افراد پراکنده میشود. اسکرام با ۳ Artifact اصلی تلاش میکند بخش مهمی از این ابهام را کاهش دهد: Product Backlog، Sprint Backlog و Increment.
Product Backlog فهرست مرتب‌شده‌ای از کارهایی است که برای محصول یا هدف موردنظر ممکن است نیاز باشد. نکته مهم این است که این فهرست ثابت نیست و با یادگیری تیم تغییر میکند.
Sprint Backlog شامل Sprint Goal، موارد انتخاب‌شده برای اسپرینت و برنامه انجام آن‌هاست. بنابراین اعضا میتوانند بفهمند تمرکز فعلی تیم چیست و چه فعالیت‌هایی برای رسیدن به آن انجام میشود.
Increment نتیجه‌ای است که در طول اسپرینت ایجاد شده و باید با Definition of Done هماهنگ باشد. در نتیجه تیم صرفاً درصد پیشرفت یا تعداد ساعات کارشده را گزارش نمی‌کند؛ بلکه باید خروجی قابل ارزیابی ارائه دهد.
- Product Backlog با Product Goal مرتبط است.
- Sprint Backlog دارای Sprint Goal است.
- Increment باید مطابق Definition of Done باشد.
این ۳ تعهد به مدیر کمک می‌کنند به‌جای پرسیدن «هر نفر امروز چه کار کرده؟»، سؤال‌های ارزشمندتری مطرح کند: هدف ما چیست؟ چقدر به هدف اسپرینت نزدیک شده‌ایم؟ و آیا چیزی که تحویل داده‌ایم واقعاً کامل است؟
۵. آیا اسکرام فقط برای تیمهای نرمافزاری مناسب است؟
اسکرام بیشترین شهرت خود را از صنعت نرمافزار به دست آورده است، اما منطق آن محدود به برنامه‌نویسی نیست. هرجا با یک مسئله پیچیده مواجه باشیم که نتیجه آن از ابتدا کاملاً مشخص نیست، میتوان از بخشی از تفکر اسکرام استفاده کرد.
برای مثال یک تیم بازاریابی میتواند در یک اسپرینت ۲ هفته‌ای هدفی مانند «آزمایش ۳ پیام تبلیغاتی برای افزایش نرخ ثبت‌نام» تعیین کند. تیم در پایان دوره به‌جای اینکه فقط اعلام کند چند پست و چند بنر تولید کرده، باید نتایج آزمایش را بررسی کند و برای دوره بعد تصمیم بگیرد.
یک تیم طراحی محصول نیز میتواند در یک اسپرینت روی اعتبارسنجی یک مسئله مشتری تمرکز کند. تیم فروش، تیم محتوا یا حتی یک واحد داخلی سازمان هم در بعضی شرایط میتواند از همین چرخه استفاده کند.
بااینحال Scrum برای همه فعالیتها انتخاب مناسبی نیست. وقتی یک فرآیند کاملاً تکراری، قابل پیش‌بینی و استاندارد دارید، استفاده از کانبان، مدیریت فرآیند یا یک سیستم عملیاتی ساده ممکن است منطقی‌تر باشد.
۶. مدیر در یک سازمان اسکرامی چه کاری باید انجام دهد؟
یکی از سوءبرداشت‌های رایج این است که در اسکرام دیگر نیازی به مدیریت وجود ندارد. چیزی که کاهش پیدا میکند «مدیریت دستوری فعالیت‌های روزانه» است، نه مسئولیت مدیریت سازمان.
مدیر همچنان باید جهت سازمان را روشن کند، افراد مناسب را در کنار یکدیگر قرار دهد، محدودیت‌های منابع را مدیریت کند و موانعی را برطرف کند که تیم به‌تنهایی قادر به حل آنها نیست. در واقع بخش مهمی از کار مدیر از کنترل مستقیم کار به طراحی یک سیستم کاری مؤثر منتقل میشود.
یک مدیر میتواند حداقل روی ۳ سطح تمرکز کند:
- هدف: آیا تیم می‌داند چه نتیجه‌ای برای کسب‌وکار مهم است؟
- ظرفیت: آیا حجم کاری با توان واقعی تیم تناسب دارد؟
- سیستم: چه مانع سازمانی باعث کندشدن یا دوباره‌کاری میشود؟
اگر مدیر همچنان هر روز کارها را بین اعضا تقسیم کند، تصمیم‌های تخصصی را خودش بگیرد و Daily Scrum را به جلسه گزارشدهی تبدیل کند، عملاً بخش مهمی از مزایای اسکرام از بین میرود.
۷. چگونه میتوان عملکرد تیم اسکرام را اندازه‌گیری کرد؟
اندازه‌گیری در اسکرام باید به تصمیم‌گیری بهتر کمک کند، نه اینکه صرفاً ابزاری برای ارزیابی افراد باشد. اگر هر معیار به هدف فردی تبدیل شود، اعضای تیم ممکن است به‌جای بهبود نتیجه، شروع به بهینه‌سازی همان عدد کنند.
برای مثال Velocity میتواند برای تخمین ظرفیت آینده همان تیم مفید باشد، اما مقایسه Velocity دو تیم معمولاً معنای قابل اتکایی ندارد. هر تیم میتواند روش متفاوتی برای تخمین داشته باشد.
به‌جای وابستگی به یک عدد، بهتر است چند شاخص در کنار یکدیگر دیده شوند:
- نسبت تحقق Sprint Goal
- مدت زمان انجام کارها
- میزان کار باقی‌مانده یا رسوب‌کرده
- تعداد فعالیت‌های تکمیل‌شده در یک بازه
- کیفیت خروجی و میزان دوباره‌کاری
- بازخورد مشتری یا ذی‌نفع
برای مثال بررسی روند عملکرد در ۴ تا ۶ اسپرینت معمولاً تصویر مفیدتری نسبت به قضاوت بر اساس یک اسپرینت ایجاد میکند. هدف باید مشاهده روند و شناسایی موانع باشد، نه رتبه‌بندی افراد.
۸. تیکبورد چگونه میتواند اجرای اسکرام را ساده‌تر کند؟
اسکرام قبل از هر چیز یک چارچوب مدیریتی است و هیچ نرمافزاری به‌تنهایی نمی‌تواند یک تیم را «اسکرامی» کند. بااینحال ابزار مناسب میتواند اجرای فرآیند، شفافیت کارها و پیگیری فعالیتها را ساده‌تر کند.
در تیکبورد میتوان برای هر تیم یا محصول یک برد ساخت و ستون‌هایی متناسب با جریان کار تعریف کرد. کارها را میتوان بین ستون‌ها جابه‌جا کرد، مسئول مشخص کرد، برای آنها اولویت، وزن، تاریخ سررسید، چک‌لیست، برچسب و توضیحات قرار داد و تاریخچه تغییرات را مشاهده کرد.
برای اجرای یک اسپرینت میتوان مجموعه کارهای انتخاب‌شده را روی برد مدیریت کرد و اعضای تیم وضعیت فعالیتها را بدون نیاز به گزارش‌های جداگانه مشاهده کنند. ثبت زمان، تقویم، گفتگو، نظرات و گزارش‌ها نیز میتوانند اطلاعات بیشتری درباره وضعیت واقعی کار در اختیار تیم و مدیر قرار دهند.
- بردهای بصری برای نمایش جریان کار
- Drag & Drop برای تغییر وضعیت فعالیتها
- اولویت و وزن برای سازمان‌دهی بهتر کارها
- تاریخ سررسید و یادآوری
- نظرات و گفتگو برای هماهنگی تیم
- ثبت زمان برای بررسی زمان واقعی فعالیتها
- گزارش‌ها برای تحلیل عملکرد و روند انجام کار
نکته مهم این است که ابزار باید در خدمت فرآیند باشد. ساختن ستون‌هایی با نام Backlog، Doing و Done به‌تنهایی به معنی اجرای Scrum نیست؛ همان‌طور که برگزاری یک جلسه ۱۵ دقیقه‌ای نیز به‌تنهایی Daily Scrum محسوب نمی‌شود.
۹. اشتباهات رایج در پیاده‌سازی اسکرام چیست؟
بسیاری از سازمان‌ها اسکرام را اجرا می‌کنند اما همچنان همان شیوه مدیریتی قبلی را حفظ می‌کنند. نتیجه معمولاً تعداد بیشتری جلسه، اصطلاحات جدید و رضایت کمتر تیم است.
یکی از اشتباهات رایج این است که Sprint Planning به جلسه تقسیم وظایف تبدیل میشود. اشتباه دیگر این است که مدیر در Daily Scrum حضور پیدا میکند تا از تک‌تک افراد گزارش فعالیت دریافت کند.
مشکل سوم زمانی ایجاد میشود که هیچ هدف مشخصی برای اسپرینت وجود ندارد و تیم صرفاً تلاش میکند تعداد زیادی تسک را ببندد. در این شرایط ممکن است ۲۰ فعالیت تکمیل شود اما نتیجه مهمی برای مشتری یا کسب‌وکار ایجاد نشده باشد.
- تبدیل Daily Scrum به گزارشدهی به مدیر
- تغییر مداوم اولویتها در وسط اسپرینت بدون توجه به Sprint Goal
- تخصیص مستقیم تمام کارها توسط مدیر
- نداشتن Product Goal و Sprint Goal روشن
- تمرکز روی تعداد تسک به‌جای ارزش خروجی
- حذف Retrospective به دلیل کمبود وقت
- استفاده از Scrum فقط به‌عنوان مجموعه‌ای از جلسه‌ها
اگر بعد از چند اسپرینت تیم فقط «سریع‌تر کار میکند» اما بهتر تصمیم نمی‌گیرد، مشکلات خود را زودتر کشف نمی‌کند و بازخورد بیشتری از مشتری نمی‌گیرد، احتمالاً اسکرام به شکل سطحی اجرا شده است.
جمع‌بندی
اسکرام بیش از آنکه یک روش برای مدیریت تسک‌ها باشد، یک مدل برای مدیریت کار در شرایط پیچیده و متغیر است. برنامه‌ریزی کوتاه‌مدت، اهداف مشخص، بازخورد مداوم، شفافیت و خودمدیریتی تیم کمک می‌کنند سازمان به‌جای دفاع از برنامه‌ای که ماه‌ها قبل نوشته شده، بر اساس واقعیت تصمیم بگیرد.
برای مدیران، مهم‌ترین تغییر اسکرام شاید این باشد که مدیریت از «کنترل فعالیت افراد» به «مدیریت هدف، سیستم و موانع» منتقل میشود. مدیر همچنان نقش بسیار مهمی دارد، اما ارزش او بیشتر در ایجاد شرایطی است که تیم بتواند تصمیم‌های بهتر بگیرد و نتیجه بهتری ایجاد کند.
اگر قصد دارید اسکرام را در تیم خود اجرا کنید، از تغییر تمام ساختار سازمان شروع نکنید. یک تیم، یک هدف مشخص و یک دوره کوتاه ۱ یا ۲ هفته‌ای انتخاب کنید؛ نتیجه را بررسی کنید و در Retrospective درباره بهبود روش کار تصمیم بگیرید. ابزارهایی مانند تیکبورد نیز میتوانند برای شفاف‌سازی کارها، مدیریت برد، هماهنگی اعضا و بررسی روند اجرا در کنار این فرآیند استفاده شوند.
