یکی از مهمترین مسائلی که خیلی اوقات در تیمهای نرمافزاری مشاهده میشه، اصرار به استفاده از متدلوژیهای اجایل و بهخصوص اسکرام هست! واقعیت اینه که اسکرام تنها یکی از چندین متد مدیریت اجایل هست و لزوماً بهترین نیست؛ موضوعی که خیلی از مدیران به اون بیتوجه هستن اینه که برنامهریزی هر پروژه نرمافزاری در هر محیطی با این متدلوژی کارآمد نیست و حتی ممکنه در نهایت باعث بروز مشکلات و پیچیدگیهای بیشتری بشه.
تجربه من هم به عنوان مدیر محصول تو این سالها به من ثابت کرد که اسکرام همیشه بهترین پاسخ برای شرایط فعلی نیست!
شرایطی که در ابتدای حضور من به عنوان مالک محصول تیم توسعه سامانههای موبایلی در داتین با اون مواجه بودم، این بود که:
- بیشتر اعضای تیم ده نفره توسعه محصول، تجربه کار در فضای اسکرام رو نداشتن
- شرکت در جلسات متعدد (که یکی از ویژگیهای اسکرام هست) معمولاً برای اعضای تیم خوشایند نیست
- نقشها (Roles) در تیم، مشخص و از قبل تعریف شده نبود
- اجرای تسکها چندان در قید و بند زمانبندیها و چارچوبهای خاصی نبود
- تسکها به صورت مداوم در رفت و برگشت بودن و این با ویژگی DoD در اسکرام در تناقض بود!
تحت این شرایط اجبار تیم به استفاده از متدلوژی اسکرام نه امکانپذیر بود و نه منطقی؛ چون شرایط تیم و ماهیت فعالیت ما در تیم موبایل بانک بهگونهای بود که با چارچوب اسکرام در تناقض بود. به همین دلیل تصمیم بر این شد که از چارچوب اسکرامبان استفاده کنیم و به تدریج تیم رو به سمت اسکرام هدایت کنیم. اینکه اسکرام تحت چه شرایطی میتونه برای تیمهای نرمافزاری مشکلساز بشه، و چرا باید از متدلوژیهای دیگهای به جای اسکرام استفاده بشه و تجربه عملی من از کاربرد اسکرامبان در تیم موبایل بانک داتین، مواردی هستن که در این مقاله بهشون پرداختم.
قبل از هرچیز بهتره کمی درباره «متدلوژی اسکرام» (Scrum) توضیح بدم. همونطور که میدونید اسکرام یکی از متدلوژیهای توسعه نرمافزار به روش اجایل هست که یک پروژه رو به تسکهای قابل مدیریت و کوچکتر تقسیم میکنه. این تسکها توی بازههای زمانی مشخصی به نام اسپرینتها انجام میشه که معمولاً بین ۱ تا ۴ هفته طول میکشه.
اسکرام بر پایه مفهوم «رتروسپکتیو» (Retrospective) یا «بازنگری» و «ریویو» بنا شده. یعنی در انتهای هر اسپرینت، با توجه به نتایجی که به دست مشتری رسیده و بازخوردی که دریافت میشه، اصلاحات یا تغییرات موردنیاز در اسپرینت بعدی صورت میگیره.
یکی دیگه از ویژگیهای مهم اسکرام، جلسات متعدد اون هست. جلسات برنامهریزی اسپرینتها، جلسات دیلی اسکرام، اسپرینت ریویو و اسپرینت رتروسپکتیو از جمله جلسات مهم چارچوب اسکرام هستن. اینجا خیلی از تیمهایی که تا بهحال با اسکرام کار نکردن با چالش مواجه میشن و تیم ما هم در داتین از این قاعده مستثنی نبود.
چالش مهمی که ما برای پیادهسازی اسکرام در تیم موبایل بانک داتین با اون روبرو شدیم این بود که شرکت در جلسات متعدد معمولاً برای خیلی از افراد خوشایند نیست. ترس از دست دادن زمان، جلسات بدون بازده، مشخص نبودن هدف جلسات و ... از جمله نگرشهای منفی نادرستی هستن که افراد نسبت به جلسات دارن. اما اگر راهی پیدا میشد تا افراد با معجزه جلسات و تاثیر اون در برنامهریزی، افزایش بهرهوری تیم، بهبود خروجیها و تعامل بین افراد آشنا میشدن، این تصور اشتباه هم از بین میرفت.
استفاده از اسکرام با جلسات متعددش در این شرایط کار درستی نبود؛ به همین دلیل ما تصمیم گرفتیم از اسکرامبان استفاده کنیم که تعداد جلسات اندکی داره. (درباره اسکرامبان و پیادهسازی اون در ادامه صحبت میکنم.)
یکی از ویژگیهای متدلوژی اسکرام، نوشتن «داستان کاربر» (User Story) هست. داستان کاربر یک ابزار مهم هست که اسکرام در اختیار تیمهای توسعه قرار داده تا به کمک اون بتونن توصیف دقیقی از محصول موردانتظار مشتری دریافت کنن.
داستان کاربر به طور خلاصه طبق الگوی زیر مشخص میشه:
As a [Type of users], I want to [Perform an action], so that [A benefit of the said feature]
برای مثال، یوزر استوری پرداخت صورتحسابها به شکل زیر تعریف میشه:
بهعنوان کاربر عادی یک اپلیکیشن موبایل بانک (User)، من میخواهم بتوانم صورتحسابها را از طریق اپلیکیشن موبایل بانک پرداخت کنم (Action)، تا بتوانم از پرداخت سریع و بهموقع صورتحسابها اطمینان حاصل کنم (Benefit).
از آنجا که ما در داتین معمولاً با درخواستهایی روبرو هستیم که از سمت بانک مرکزی وارد تیم میشن، و همچنین به علت اینکه اکثر این درخواستها باید در زمانهای تعیین شده توسط بانک مرکزی پیادهسازی بشن و غیرشفاف بودن نیازمندیهای محصول، امکان تعریف User Story ها توسط مالک محصول وجود نداره.
در چنین شرایطی که حتی مالک محصول هم به طور دقیق نسبت به نیازمندیهای محصول بینش نداره، تعریف بک لاگ و یوزر استوریهای دقیق امکانپذیر نیست؛ حتی اگر به طور تقریبی یک سری یوزر استوری تعریف بشه، باز هم در میانه هر اسپرینت و با توجه به بینشی که در طول کار پیدا میکنیم، امکان تغییر یوزر استوریها وجود داره.
همونطور که میدونید در اسکرام ما تسکها رو به یوزر استوریها و جزئیات زیاد شکسته و برای آنها تخمین زمانی (در حد تخمین ساعت) در نظر میگیریم. زمانی که امکان تعریف یوزر استوری وجود نداشته باشه، شکستن تسکها و تخمین اونها هم غیرممکن هست. تخمینهای قابل اجرا روی پروژههایی که وارد تیم ما در داتین میشن به علت شفاف نبودن نیازمندیها، عمدتاً انقدر وسیع هستن که ویژگی شکستن تسکها و تخمین دقیق اونها در اسکرام رو زیر سوال میبره.
کارهای اضطراری و برنامهریزینشده میتونن با ماهیت متدلوژی اسکرام در تضاد باشن و اجرای درست اون رو سخت کنن. وقتی در فضای بانکی کار میکنید، پروژههای برنامهریزینشده متعددی از سمت بانک وارد تیم میشه که معمولاً پیادهسازی اونها محدودیت زمانی داره؛ به همین دلیل استفاده از اسکرام در این شرایط نه ساده هست و نه منطقی!
در هر پروژه نرمافزاری تست، شناسایی باگها و رفع اونها مهمه؛ اما این مسئله در فضای بانکی که ما با پول، تراکنشهای مالی و مسائل امنیتی مختلفی مواجه هستیم، اهمیت چندین برابری داره. به علت این حساسیت، پروژههای ما در داتین با باگهای مختلفی روبرو میشه و سناریوهای تست معمولاً زیاد هستن؛ چرا که باید همه چیز تست بشه تا مشکلی در اجرا به وجود نیاد. تست نرمافزار و رفع سریع باگها وقتی با اسکرام کار میکنید کار سادهای نیست و برنامهریزی دقیق رو با مشکل مواجه میکنه.
در چارچوب اسکرام «مستقل بودن» (Independent) بودن تیمها مسئله مهمی هست. تیم ما در داتین یک تیم سرویسگیرنده از سایر تیمها هست و این قابلیت برنامهریزی ما را طبق چارچوب اسکرام به شدت پایین میاره.
با وجود همه اینها، استفاده از اسکرام اگر در جای درست خودش انجام بشه بسیار مفید هست؛ از جمله مزایای مهم اسکرام میشه به موارد زیر اشاره کرد:
به همه دلایلی که در این بخش گفته شد، استفاده از اسکرام در تیم ما در داتین امکانپذیر نبود و ما تصمیم گرفتیم از متدلوژی اسکرام بان استفاده کنیم. قبل از اینکه درباره این متدلوژی صحبت کنم، بهتره اول نگاهی به کانبان داشته باشیم.
«متدلوژی کانبان» (Kanban) هم یکی دیگه از چارچوبهای محبوب مدیریت براساس متدلوژی اجایل هست. کانبان بر پایه «جریان مداوم کار» (Workflow Continuity) و «مصورسازی» (Visualization) بنا شده و بهخاطر سادگی و سازگاری بالا شهرت پیدا کرده.
در روش کانبان از تخته کانبان استفاده میشه که معمولاً از سه ستون تشکیل شده؛ این ستونها در یک نگاه میتونن روند اجرای پروژه رو نمایش بدن. در هر ستون تعدادی کارت وجود داره که هر کارت نماینده یک تسک (Task) هست و با ادامه روند پیشرفت کار، کارتها از اولین ستون سمت چپ به آخرین ستون سمت راست منتقل میشن.
ستونهای تخته کانبان عبارتند از:
To-Do: تسکهایی که هنوز شروع نشدهن
WIP: کارهای در جریان اجرا
Done: تسکهایی که تمام شدن
با مقایسه اسکرام و کانبان میشه به چند مزیت مهم درباره کانبان رسید:
با اینحال متدلوژی کانبان هم کثل اسکرام دارای نقصهایی هست. به هرحال هیچ متد بینقصی رو در دنیای اجایل نمیشه پیدا کرد. برخی از مشکلات سیستم کانبان عبارتند از:
همونطور که گفتم هم چارچوب اسکرام و هم کانبان دارای مزایا و معایب متعددی هستن. پروژههای دنیای امروز نیازمندیها و پیچیدگیهای زیادی دارن؛ گذشته از پیچیدگیهای دنیای تکنولوژی، ماهیت پروژههای بانکی و نیازمندیهای اضطراری که از سمت بالا وارد تیم میشه، باعث شد ما تصمیم به استفاده از «متدلوژی اسکرامبان» (Scrumban) بگیریم. با استفاده از سینرژی ایجاد شده از ترکیب مزایای اسکرام و کانبان، میشه این پیچیدگی رو بهتر مدیریت کرد و بهترین نتایج رو در عین تداوم کار به دست آورد.
مفهوم اسکرامبان در ابتدا با هدف مهاجرت تیمها از کانبان به چارچوب اسکرام ایجاد شده بود؛ اما با گذشت زمان به علت اینکه جنبههای مثبت اسکرام و کانبان رو با هم ترکیب کرده و خروجیهای خوبی به همراه داشت، محبوبیت زیادی پیدا کرد.
برای اینکه با این متدلوژی بیشتر آشنا بشیم، بد نیست نگاهی به دو بال «اسکرامبان»، یعنی اسکرام و کانبان داشته باشیم.
ویژگی که اسکرامبان از اسکرام قرض گرفته، سرعت بالای تطبیقپذیری نسبت به تغییرات پروژههاست که این کار رو با شکستن پروژه به چرخههای کوچکتر انجام می ده. با این تفاوت که در اسکرامبان به این چرخهها به جای اسپرینت، «تکرار» (Iteration) گفته میشه. همچنین مثل چارچوب اسکرام، پروژههای اسکرامبان هم در ابتدا با یک جلسه برنامهریزی و ایجاد بک لاگ شروع میشن. در هر تکرار تعدادی از آیتمهای بک لاگ تکمیل میشن تا زمانی که هیچ آیتمی باقی نمونده باشه.
در اسکرامبان خیلی از مفاهیم اسکرام مثل فیدبک مشتری، اسکرام مستر، یوزر استوری و جلسات دیلی اسکرام حذف میشن یا به صورت دلخواه اجرا میشن.
یک بخش مهم در متدلوژی کانبان مصورسازی جریان پیشرفت تسکهاست. اسکرامبان هم از رویکرد مصورسازی جریان کار در کانبان برای بهبود فرایندها استفاده میکنه. در واقع میشه گفت اسکرامبان به طور کامل رویکرد کانبان رو در پیش میگیره؛ تخته کانبان و اسکرامبان کاملاً مشابه بوده و شامل ستونها و کارتهایی هستن که معرف مراحل اجرای پروژه و تسکهاست.
علاوه بر این، در متدلوژی اسکرامبان از «اصل محدودیت کارهای در دست اقدام» (WIPها) در یک زمان استفاده میشه؛ این اصل به اعضای تیمها کمک میکنه تا فشار کاری رو کاهش بدن.
با وجود همه مزایای گفته شده برای اسکرامبان، اهدف این نیست که گفته بشه در هر کسب و کاری میشه اون رو به کار گرفت و به نتایج خوبی رسید. بلکه منظور این هست که تحت برخی شرایط اسکرامبان میتونه روش مناسبی برای مدیریت پروژهها باشه.
کی به جای اسکرام از اسکرامبان استفاده میکنیم؟
- تیمهای نرمافزاری که یوزر استوری های آنها به طور مداوم تغییر میکنه
- تیمهای نرمافزاری که دائماً با باگهای برنامهنویسی برخورد میکنن
- تیمهایی که روی توسعه یک محصول کاملاً جدید متمرکز هستن
- زمانی که اسکرام به دلیل مشکلات موجود در جریان کار، فرایندها و منابع نمیتونه موثر عمل کنه
مراحل اجرای یک پروژه طبق متدلوژی اسکرامبان رو میشه به طور خلاصه در ۷ گام تعریف کرد:
۱- ایجاد لیستی از آیتمهای کاری که هرکدوم بخشی از نرمافزار رو تشکیل میدن
۲- تغییر آیتمها به تسکها و قرار دادن آنها در ستون To-Doاز تخته اسکرامبان
۳- اولویتبندی آیتمها و شروع برنامهریزی تکرارها
۴- شروع تکرار و انتقال آیتمها از ستون To-Doبه ستون WIP
۵- اتمام تسکها و انتقال آنها به ستون Done
۶- اتمام تسکهای تکرار و برنامهریزی برای شروع تکرار بعدی
۷- تکرار فرایند تا اتمام کامل پروژه
تیمهای اسکرامبان معمولاً کمتر از ۱۲ نفر عضو دارن و نقشهای مشخصی در این تیمها وجود داره. گذشته از جلسه برنامهریزی اولیه، برگزاری تمام انواع جلسات دیلی در این متدلوژی انتخابی هست. در ادامه نگاهی سریع به تفاوتهای اسکرامبان و سایر متدلوژیهای توسعه نرمافزار به شیوه چابک داریم:
اندازه تیم
- کانبان: محدودیتی برای تعداد اعضای وجود ندارد.
- اسکرام: تیمهای اسکرام باید خیلی کوچک باشند. بسیاری از این تیمها با تعداد اعضای بین ۳ تا ۹ نفر فعالیت میکنند.
- اسکرامبان: اندازه مشخصی ندارد؛ تعداد اعضای پیشنهادی حداکثر ۱۲ نفر است.
نقشها
- کانبان: معمولاً یک مدیر پروژه حضور دارد و نقشهای دیگر به طور سختگیرانه وجود ندارند.
- اسکرام: یک تیم اسکرام دارای سه نقش کلیدی «مالک محصول»، «اسکرام مستر» و «تیم توسعه محصول» است.
- اسکرامبان: معمولاً یک مدیر پروژه حضور دارد و نقشهای دیگر به طور سختگیرانه وجود ندارند.
جلسات
- کانبان: جلسات کوتاه دیلی استندآپ در مقابل تخته کانبان
- اسکرام: در متدلوژی اسکرام پنج جلسه مهم «برنامهریزی بک لاگ محصول»، «برنامهریزی اسپرینت»، «دیلی اسکرام»، «اسپرینت ریویو» و «اسپرینت رتروسپکتیو» وجود دارد.
- اسکرامبان: یک جلسه ابتدایی برای برنامهریزی برگزار میشود (مشابه با جلسه برنامهریزی اسپرینت)
چرخههای کاری
- کانبان: جریان کار به چرخههای جداگانه شکسته نمیشود.
- اسکرام: چرخههای کاری کوتاه به نام اسپرینتها که ۲ تا ۴ هفته طول میکشند. در هر اسپرینت روی تعدادی از یوزر استوریها کار میشود تا زمانی که پروژه به اتمام برسد.
- اسکرامبان: چرخههای کاری کوتاه مدت به نام تکرار که حداکثر ۲ هفته هستند.
مفاهیم اصلی که در اسکرامبان وجود دارند عبارتند از:
در اسکرامبان توصیه میشه از تکرارهای ۲ هفتهای برای اجرای تسکها استفاده بشه. هدف اینه که در انتهای هر تکرار، نتایج تسکها تحویل داده بشه. شاید بشه گفت تکرارها در متد اسکرامبان خیلی شبیه به اسپرینتهای روش اسکرام هستن؛ اما تفاوتهای عمدهای با هم دارن:
در فرایند برنامهریزی اسکرامبان از مفهومی به نام «برنامهریزی براساس تقاضا» (on-demand planning) استفاده میشه. جلسات برنامهریزی در اسکرامبان براساس شرایطی که تسکهای ستون In-Progress دارن برگزار میشه. زمانی که تعداد تسکها به حد مشخصی برسه، یک تریگر برای برنامهریزی فعال میشه و اعضای تیم میفهمن که زمان فرایند برنامهریزی فرا رسیده.
«برنامهریزی باکت» (Bucket Planning) در اسکرامبان برای برنامهریزیهای طولانی مدت انجام میشه. پیش از اینکه تخته اسکرامبان طراحی بشه لازمه سه باکت برنامهریزی بشه (برنامهریزی سه سطلی در اسکرام). این باکتها عبارتند از:
در اسکرام نقشهای مشخصی در یک تیم تعریف میشه ؛ اما در اسکرامبان تمام نقشها به طور کامل حذف شده و به همه اعضا نقش یکسانی داده میشه. همچنین در این متدلوژی اعضای تیم میتونن تسکها رو آزادانه اولویتبندی کنن. این باعث میشه فشار روی اعضای تیم کاهش پیدا کرده و بتونن با بالاترین عملکرد فعالیت کنن.
انجام همزمان چند کار میتونه اثر منفی روی عملکرد افراد داشته باشه. در اسکرامبان با اعمال محدودیتهای WIP، از مالتی تسکینگ جلوگیری شده و افراد تنها روی یک تسک متمرکز خواهند بود. این ویژگی در نهایت باعث مدیریت بهتر گلوگاهها، افزایش بهرهوری و ارزشآفرینی بیشتر میشه.
اعضای تیم میتونن خود تسکهایشان را انتخاب کنن؛ با اینحال در متدلوژی اسکرامبان، مدیرها ترتیب اولویتهای تسکها رو با شمارهگذاری آنها (یا سایر روشها) مشخص میکنن تا اعضای تیم نسبت به درجه اهمیت تسکها آگاه بشن.
علت محبوبیت اسکرامبان این هست که محدودیتهای متد اسکرام و کانبان رو نداره اما ویژگیهای مثبت اونا رو تقویت میکنه. اسکرامبان مدیریت پروژه رو ساده کرده، شفافیت رو افزایش میده و حس دستیابی به اهداف رو در افراد با شکستن پروژهها به بخشهای کوچکتر زنده میکنه. مهمترین مزایای متدلوژی اسکرامبان عبارت هستن از:
در متد اسکرام نقشهای مختلفی مثل مالک محصول و اسکرام مستر وجود داره، جلسات مختلفی مثل برنامهریزی اسپرینت و اسپرینت ریویو برگزار میشه و مفاهیم جدیدی مثل یوزر استوری و ... در این متد تعریف میشه. نکته مهم اینه که این مسائل میتونن اسکرام رو تبدیل به یک متدلوژی خیلی پیچیده کنن که عادت کردن به اون برای افراد سخت هست. این در حالیه که در اکثر پروژهها اعضای تیم زیر خروارها تسک دفن میشن و اصلاً فرصتی برای عادت کردن به این روش پیدا نمیکنن! اما اسکرامبان هیچکدام از این مفاهیم پیچیده رو نداره. فرایندهای پیچیده، جلسات متعدد و مفاهیم جدید در این متد حذف شدن. این موضوع سبب سادگی بیش از اندازه اسکرامبان و افزایش قابلیت تطبیقپذیری اعضای تیم با این روش میشه.
متدلوژی اسکرامبان براساس فرایندهای مصور کانبان بنا شده و دنبال کردن روند اجرای پروژه در آن بسیار راحته. هروقت که یکی از اعضای تیم درباره روند پروژه با مشکلی مواجه میشه تنها کاری که باید بکنه نگاه کردن به تخته اسکرامبان هست؛ با یک نگاه کلی به این تخته میشه فهمید چه کارهایی در جریان هست، چه کارهایی به اتمام رسیدهن و چه کارهایی قرار هست انجام بشن. علاوه بر این شناسایی گلوگاهها و وقفههای بین پروژه در این متدلوژی بسیار سادهتره. برای مثال اگر تعداد کارهای ستون WIP در حال زیاد شدن باش و تعداد کارتهای منتقل شده به بخش Done به اندازه کافی نباشه میشه متوجه شد که مشکلی در روند اجرای تسکها به وجود اومده.
هدف اسکرامبان افزایش بهرهوری در اجرای فرایندها هست و برگزاری جلسات برنامهریزی تنها در مواقع نیاز انجام میشه. علاوه بر این، اعضای تیمها نیازی به صرف زمان بیش از حد برای گزارشدهی و آمادگی برای جلسات دیلی استندآپها ندارن که این به اونها در تمرکز روی کارها کمک میکنه.
تیمهای کاری که با متدلوژی اسکرامبان فعالیت میکنن از قید و بند نقشهای کاری رها هستن و میتونن بدون درگیری بیش از حد مدیران، تسکهاشونن رو انتخاب کنن. علاوه بر این، نیازی نیست نگران جلسات روزانه و سایر گزارشات باشن که این موضوع به کاهش تنشهای محیط کار کمک میکنه.
یکی از مشکلات پروژههای بزرگ اینه که اجرای اونها سالها طول میکشه. بازه زمانی طولانی روند اجرای چنین پروژههایی میتونه انگیزه اعضای تیم رو نابود کنه. با اینحال در اسکرامبان، پروژه به چرخههای کوچک شکسته شده و دستیابی به اهداف کوچکتر اون قابل مشاهده هست. از اونجا که اتمام این چرخهها سادهتره، افراد حس دستیابی به هدف رو دریافت کرده و این باعث ایجاد انگیزه در اونها برای تلاش بیشتر میشه.
