بیایید همدیگر رو قضاوت نکینم و از تخته اسکرام استفاده کنیم
خب من خیلی اهل نوشتن نیستم و خیلی خلاصه میگم. توی این مطلب احتمالا راجع به اسکرام، مشکلاتی که بین یک صاب‌محصول و یکسری برنامه‌نویس پیش‌اومده، راه‌کارهای تست‌شده و نهایتا کمکی که تخته‌اسکرام کرده، صحبت خواهد شد. یه نکته، خیلی از مشکلات ذکر شده در این مطلب با راه‌کار ارائه‌شده رابطه‌ی جدی‌ای ندارن ولی این راه‌کار در حل اون مشکلات تاثیر مثبت ولو اندک داشته. قبل از شروع بگم که همون‌طور که مستحضرید مانند سایر علوم‌تجربی، مطالب ذکر شده در محیط آزمایشگاهی و با شرایط خاص تجربه شده است. انسان موجود پیچیده‌ایست و ممکنه تمام نتایج زیر متاثر از اثر پروانه‌ای فلان حرکت زشت شما باشه و ربطی به تخته مخته نداشته باشه.
فرست آو آل، اسکرام چیمدی؟
خب اسکرام اینه: https://www.scrum.org/resources/what-is-scrum
ما تو شرکت برای تولید یک پروژه‌ای که به نظر صاب‌شرکت جزو محصولات بدیهی محسوب میشه و استفاده‌کنندگان، روش‌های سوددهی به استفاده‌کنندگان و غیره مشخص بود، از اسکرام استفاده کردیم. برای این‌کار، که به وضوح جزئیات سناریوها و حتی بعضا کلیاتش برای همون صاب‌شرکت دقیق نیست و همچنین بازار به شدت درحال تغییره، ما در بازه‌های زمانی کوتاهی که بهش میگیم اسپرینت، قسمت کوچکی از محصول رو تدقیق(به معنی دقیق کردن تحلیل و طراحی) و پیاده‌سازی میکنیم. در شروع اسپرینت اون قسمت‌هایی که قراره پیاده‌سازی بشه رو به بحث میذاریم و برنامه‌نویس‌ها از نظر سختی‌کار بهش درجه میدن و یه حجم معقولی از کار (متناسب با حجم انجام شده در اسپرینت‌های قبلی)، برای انجام در اون اسپرینت برنامه‌ریزی میشه. درپایان اسپرینت، اول موارد پیاده‌سازی شده تحویل پی‌او میشه و بعدش خوبی‌ها، بدی‌ها، مشکلات و موانع اسپرینت به بحث گذاشته میشه و برای بهبود اسپرینت‌های آتی یه سری تکلیف در همون راستا تعیین میشه.
پی‌او چی میگه؟
در وهله‌ی نخست، و البته در ظاهر، پی‌او یا صاب‌محصول، فردیست که غر میزنه. صاب‌محصول فردیست که قراره نیاز تشریح‌شده توسط یکسری آدم کسب‌وکاری، یا یکسری آدم نیازمند به محصول، رو مستند کنه، تبدیل کنه به یه سری بک‌لاگ که قراره یکسری آدم برنامه‌نویس بفهمن و پیاده‌سازیش کنن. و البته خیلی مهمه که بعد از پیاده‌سازی توسط برنامه‌نویسا، اون محصول واقعا به درد اون نیازمند بخوره. خب پس صاب‌محصول احتمالا حرف دو طرف کسب‌وکار و فنی رو باید بفهمه، ولی خیلی معموله که دو طرف ذکر شده هیچ‌کدوم حرف صاب‌محصول رو نفهمن، چون در عمل از نظر کسب‌وکار، صاب‌محصول یه آدم فنی هستش که ریسک‌های بازار رو درک نمیکنه و در مقابل ددلاینای بازار یه سری مزخرف فنی که بعضا شامل واژه «نمیشه» هستش تحویل میده(یه بار در مواجهه با این سوال که سیستم چنتا یوزر خواهد داشت، طرف خیلی شاکی گفت چه فرقی میکنه؟ ۱۰۰ تا، ۱۰۰۰ تا، تو یه میلیارد درنظر بگیر). و از نظر فنی، صاب‌محصول یه آدم کسب‌وکاریه که همش از ددلاینا حرف میزنه و از پیچیدگی‌های کار سر درنمیاره. صاب‌محصول در واقع یک آدم تنهاست.
مشکل چی بوده حالا؟
مشکل واضح که خیلی وقت‌ها خیلی‌ها درگیرش میشن، عدم رسیدن به اهداف.
دیر زمانی بود که هرچه میرفتیم به هیچی نمیرسیدیم. یه سری جملات دیگه شده بود روزمره.
پی‌او:
- چی شد که به این بک‌لاگ‌ها نرسیدیم؟
- چرا قبل از جلسه خودتون تست نکردید کارهاتونو؟ اینو که جلسه قبل هم گفتیم.
- چرا توی تی‌اف‌اس وضعیت تسک‌ها رو آپدیت نمی‌کنید؟
- چرا جلسات رو دیر میاید؟ اگه واقعا وقت کم بوده چرا انقدر غیبت دارید؟ من که فکر میکنم از بی‌نظمیه و اهمیت ندادن.
- اوه شت، این چی‌چیه ساختید؟ واقعا شرح بک‌لاگ رو خوندید و به این نتیجه رسیدید؟ چیش مبهم بوده؟
- بابا شماها چقدر بهونه‌های تخیلی میگیرید، کار کنید تورو قرعان. یه مشت آدم فراخ.
- آخ اگه به موقع اینو رسونده بودید
برنامه‌نویسا:
- کاش پی‌اومون یه مقدار میفهمید.
- یادمون رفت
- اینکه وضعیت تسک رو آپدیت نکردیم چه تاثیری داره؟ چرا اعتماد ندارید؟ چرا فکر میکنید داریم کم‌کاری میکنیم.
- سخته، نمیتونم حواسمو جمع کنم که هی برم تسک‌هارو آپدیت کنم.
- چرا انقدر کار وسط اسپرینت به صورت ادهاک میاد.
- چرا تعریف بک‌لاگ‌ها انقدر عوض میشه. یه‌ذره ثبات فکری نداره این پی‌او.
- اصلا معلوم نیست برا چی این‌کارارو میکنیم، آخرشم که استفاده نمیشه. ددلاینای الکی.
- تعریف بک‌لاگ مفهموم نیست. پیچیدگی‌های کار رو نمیفهمید، مگه خم رنگ‌رزیه؟
- همش بشور بساب، غر بشنو، اینم شد زندگی؟
مشکل چی بود واقعا؟
پی‌او:
- به خاطر فشار کسب‌وکار و عدم موفقیت فعلی پروژه، روی مشکل برنامه‌نویس‌ها کلید کرده بود و همه چیو از اون زاویه میدید.
خب فرض کنید صاب‌محصول ببینه که نمیتونه اون‌چیزی که میخواد رو تولید کنه، از طرفی هی همه بگن چی شد؟ چرا اینجوریه؟ پس تیم چیکار میکنه؟ کی قراره درست شه؟ و صاب‌محصول حتی نتونه با اعتماد به تیم یه زمان‌بندی ارائه کنه، چون تو ذهن خودش هم تیم قابل اعتماد نیست و نمیشه روی زمان‌ها حساب کرد.
- از تیم جدا شده بود و ارتباطش با تیم فقط متن بک‌لاگ بود.
طبیعتا وقتی عامل شکست شناسایی شد، ازش دوری می‌کنی. اولین روش دوری محیط کار هم اینه که، خب من وظیفمو انجام میدم شما هم وظیفتونو. من بک‌لاگ رو هر چقدر که ممکن بود دقیق نوشتم.
- با آدم‌ها در مورد رفع مشکلات مشورت نمیشد.
- شاید به نظرش اینکه آدم‌ها از شرایط و دلایل تغییرات، یا چگونگی سودآوری یک بک‌لاگ، یا علل حذف یک فیچر بدونن، زیادی بود و اطلاعات اضافی محسوب میشد.
برنامه‌نویس‌ها:
- از بی‌برنامه‌گی خودشون و عدم مدیریت زمانشون آگاه نبودن.
خب خیلی از آدما، کارهاشونو به تعویق میندازن و معمولا فشارکاری در روزهای آخر برنامه به شدت بیشتر از روزهای ابتداییه. یه چرخه معیوب هم ایجاد شده بود. آدم‌ها بعد از جلسه تحویل اسپرینت، انقد غر شنیده بودن که به صورت افسرده‌ای چند روز استراحت میکردن، بعدش چون دیرشده بود، چند روز اضافه‌کاری میکردن، بعدش خسته و احتمالا ناموفق میرسیدن به تحویل اسپرینت. این قضیه خیلی مشهود بود، به طوری‌که گیر اولیه صاب‌محصول به بروزنگه‌داشتن بورد تی‌اف‌اس برای نمایش این تغییر سرعت عجیب بود.
- از ابتدای اسپرینت عمیق به بک‌لاگ‌ها فکر نمیکردن و اواخر اسپرینت با چالش‌های بک‌لاگ مواجه می‌شدن.
یکی از عواقب جدایی پی‌او از تیم این بود که برنامه‌نویس‌ها علاقه‌ای به تفسیر و تدقیق بک‌لاگ نداشتن. شرح رو میخوندن و میگفتن اوکی و بهش فکر نمیکردن. وقتی میرسیدن به پیاده‌سازی بک‌لاگ تازه کلی سوال براشون ایجاد میشد.
- هدف پی‌او یا کسب‌وکار رو از خودشون جدا میدونستن.
برنامه‌نویس‌ها تبدیل به یه‌سری کارمند شده بودند. تسک‌ها رو انجام میدادن و میرفتن. انگار هدف برنامه‌نویس انجام تسک‌ها بوده، فارغ از اینکه کنار هم گذاشتن تسک‌ها اصلا کاربردی داره یا نه.
- حالت تدافعی به خودشون گرفته بودن و سعی میکردن مشکلات رو تا حد ممکن توجیه کنن.
از نظر برنامه‌نویس، اینکه بک‌لاگ به درد میخوره یا نه مشکل پی‌او عه. حتی بدیهی‌ترین قابلیت‌ها فقط به شرط ذکر‌شدن در بک‌لاگ ارائه میشد و در غیر‌این‌صورت انجام نمیشد. در جلسات برنامه‌ریزی، تا حد امکان مسئولیت کمتری قبول میکردن( حالت خوشبینانه اینه که خب مسئولیت کمتر برداریم، حالا اگه شد بیشتر تحویل میدیم، ولی اگه نشه غر نمیشنویم).
بعدش چی شد؟
خیلی به این فکر میکردم که چرا بچه‌ها اینجوری میکنن. یاد حرف‌های دکتر خسروی هم بودم که میگفت ما همیشه از بورد فیزیکی استفاده می‌کردیم و خیلی هم هیجان‌انگیزه. دانیال هم توی یه تماس اسکایپی دو تا خط کشیده بود و از بورد فیزیکی در اونور آب گفته بود. با کیا هم راجع به بازی‌سازی و مزایا و معایب ایجاد رقابت و یه سیستم این‌شکلی فکر کردیم.
یه روز بهاری، یک فکر شیطانی به ذهنم رسید. مدیونید فکر کنید میخواستم مشکلات رو برطرف کنم. من مشکل رو میدونستم، برنامه‌نویس‌ها. هدفم کنترل هرچه بیشتر برنامه‌نویس‌ها بود، جوری که هیچ راه فراری براشون نباشه و مجبور شن کار کنن.
چه چیز‌هایی رو میخواستم کنترل کنم؟
- غیبت (شرکت ما ساعت کاری نداره و غیبت هم معنایی نداره).
- برنامه‌ریزی و مشخص‌کردن تسک‌ها قبل از شروع اسپرینت.
- کار انجام شده در روز.
- اطمینان از اینکه هر آدم توی هر لحظه در حال انجام چه کاریه، یا به عبارت دیگه، هر آدم توی هر لحظه مشغول انجام کار باشه.
- اطمینان از اینکه تسک‌ها بعد از انجام تست میشن.
- نمایش اقتدار و عدم وجود کار ادهاک، لااقل اونجوری که اونا میگن.
- مقایسه حجم کاری هر فرد نسبت به بقیه
نگران نشید، چیزی که در نهایت درست شد به شکل بالا استفاده نشد.
خب برای کنترل، اول باید به آدم‌ها مشخصه داد. یه سری آهنربا با رنگ‌های مختلف تهیه کردیم و به هر فرد یک رنگ اختصاص دادیم. در گوشه تخته وایت‌بورد فلزیمون، لیست آدم‌ها رو نوشتیم و مخزن آهنرباهاشونم همونجا گذاشتیم.
قرار بود، غیبت‌ها کنترل بشه، پس یه تقویم کوچیک شامل روزهای اسپرینت گذاشتیم، قرار شد هرکی هر روزی خواست نباشه، اول اسپرینت آهنرباشو بذاره روی اون روز.
قرار شد تسک‌ها از اول مشخص بشه، بنابراین بک‌لاگ‌ها رو بالای تخته نوشتیم و قرار شد اول اسپرینت تسک‌های هر بک‌لاگ توی مخرن تسک‌ها و در زیر بک‌لاگ گذاشته بشه.
برای کنترل هر فرد، هرکسی باید آهنرباشو بذاره روی هر تسکی که در حال انجامش هست. تخته دم در ورودی تیم هستش و بنابراین هیچ چاره‌ای جز آپدیت کردنش نیست. بالاخره آدم‌ها پا میشن برن یه چایی بریزن، همون لحظه تخته رو میبینن و آپدیت میکنن.
برای کنترل روند و سرعت اجرای تسک‌ها، خب کل تسک‌های اسپرینت هست و نسبت تسک‌هایی که به ستون انجام شده رسیده به کل تسک‌ها مشخصه(از روی حجم و تعداد برگه تسک‌ها در هر ردیف) و نمیشه کارها رو به روزهای آخر موکول کرد.
برای کنترل حجم کار ادهاک ورودی به اسپرینت، یه ستون مجزا برای کارهای ادهاک درنظر گرفتیم. هر اسپرینت یه پشتیبان داره که آهنرباش رو روی ستون ادهاک میذاره. هرکاری توی اون ستون بیاد اون فرد انجام میده. همچنین در آخر اسپرینت نباید حجم تسک‌های اون ستون زیاد باشه.
برای کنترل تست کارها، یک ردیف قبل از دلیورکردن کارها، با عنوان تست وجود داره که تسک‌ها باید از اون بگذرن. هر تسکی که قابل تست توسط پی‌او باشه، پی‌او در حین اسپرینت تست میکنه.
آیا به اهدافم رسیدم؟
با افتخار باید بگم به اهداف کنترلیم نرسیدم و از چند روز بعد از شروع نخواستم که برسم، ولی همه مشکلاتم حل شد. بعد از شروع این کار، دیدم به موضوع عوض شد. آدم‌ها به شکل متمدنانه‌ای به قضیه نگاه میکردن و منم از خودم خجالت می‌کشیدم که دون‌پایه به موضوع به شکل کنترل آدم‌ها، رئیس‌بازی، من بیشتر میفهمم‌طور نگاه کنم. بعدش نگاهم به این ابزار مانیتورینگ، برای کشف مشکلات و خطاها و کمک به حل موضوع بود، نه شناسایی خطاکار. چون در واقع خطاکار مشخصی وجود نداشت، مشکل جمعی و فرایندی بود. من دیگه نمیخواستم که آدم‌ها نرن مرخصی، بلکه میخواستم در تقسیم مرخصی بین خودشون منصف باشن. همینطور توی تقسیم تسک‌ها بینشون. یه جایی حتی به این نتیجه رسیدم که وقتی آهنربای یک آدم روی یک تسک هست، یه معنیش اینه که به من اینتراپت تسک‌های دیگه رو ندید، درگیرم الان. از طرفی، تسک‌ها از ابتدا مشخص میشد و بچه‌ها سرعت انجام کار رو میدیدن. خودم سعی میکردم ادهاک زیاد نشه و بچه‌ها هم اگه زیاد میشد، از خجالتم درمیومدن.
در کل دست‌آوردهای زیر خیلی هیجان‌انگیز بود:
- آدم‌ها دوست نداشتن کسی باشن که بیشتر از بقیه مرخصی میره و کارها رو روی دوش بقیه میندازه، بنابراین اگه خودشون میدیدن که زیاد آهنرباشون توی تعطیلاته، تمام تلاششون رو میکردن کمش کنن. حتما هم اول اسپرینت مشخص میکردن، مگر اینکه غیرقابل پیش‌بینی بوده باشه.
- لحظه حرکت‌دادن تسک‌ها، یه حس خوبی داشت. اینکه کار دان شده، ناخودآگاه کسی که تسکی رو حرکت میداد نگاه بقیه بهش برمیگشت، همه تغییرات رو میدیدن حتی شما دوست پی‌او.
- آدم‌ها انرژیشون رو به صورت متعادل و برنامه‌ریزی شده صرف می‌کردند، یک روز خیلی راحت و یک روز خیلی سخت نداشتن.
- سعی می‌کردیم کار خارج از برنامه‌ریزی خیلی وارد تیم نشه.
- آدم‌ها از ردیف تست استفاده می‌کردند.
- از همین تخته توی جلسات دیلی استفاده می‌کردیم. راحت میکشیدیم جلو و همه اطلاعات لازم از گذشته و برنامه امروز جلو چشممون بود.
- یه‌سری چیزای سوسولی وارد کار شده بود، مثلا اگه یه نفر روی یه تسک میموند، به جای اینکه نگران باشه، یه N میزد روی تسک و هرکی توی اوقات فراغتش بود و میدید میرفت کمکش.
- وقتی آدم‌ها سعی میکردن تسک‌ها رو بزنن، مشکلات و ابهامات بک‌لاگ رو همون اول میگفتن و بحث میکردن، انگار که همه برای مدتی در شروع اسپرینت، پی‌او می‌شدن.
- وقتی تسک‌ها انجام میشد میرفت توی تست، و هرکی صلاح میدید یه P میزد روی تسک، و پی‌او برای تست اون میشتافت. اینجوری ارتباط پی‌او و تیم در طول اسپرینت حفظ میشد.
- این قضیه گسترش پیدا کرد، کنار تخته، یه صفحه کاغذی تست سلامت‌تیمی وجود داره، هر آدمی در پایان روز، رضایتش از تیم وسلامت‌تیم رو ارزیابی میکنه. حالا دیگه این پی‌او نیست که غر بزنه، بلکه همه انتظارشون از تیم رو با یه عدد نمایش میدن.
- در کنار تخته تکالیف مربوط به جلسات ریترو هم هست، تا دیگه این جمله که«قبلا هم گفته بودیم» پیش نیاد.
خود تخته چه مشکلاتی داشت و چیکارش کردی؟
- مصرف کاغذ.
باور کنید هزینه کردن دو تا کاغذ A4 میارزه(واقعا بیشتر نیست). خسیس نباشید، جای دیگه که لازم نیست و باید، صرفه‌جویی کنید.
- هزینه زمانی اجرا.
ایجاد تخته در ابتدای اسپرینت، یه کار فیزیکی تیمی هستش. در حد نیم‌ساعت تیم، درحالی‌که با هم صحبت‌می‌کنیم و شوخی میکنیم، کاغذ‌ها رو می‌چسبونیم، تقویمو بروز میکنیم و پشتیبان رو مشخص میکنیم. این زمان جزو ساعات فراغت محسوب میشه تا کار.
- اگه دو نفر رو یه تسک کار کنن چی؟
خب جفتشون آهنرباشونو بزنن روی یه تسک. هیچ اشکالی نداره، قرار نیست چون آهنربای یکی روی یه تسکه بازخواستش کنیم. یه روزی یه سوال ایجاد شد که آیا من که یه ساعت وقت گذاشتم روی یه تسک، با اونی که ده ساعت روی همون تسک وقت گذاشته ، جفتمون برابریم و آهنربامون روی اون تسکه. جواب، بله، برابرید. کل‌تسک‌هارو تیم انجام داده. اون آهنربا ارزشش فقط در حین انجام کاره، و وقتی کار انجام شد، همه آهنرباها جمع میشه و دیگه کار رو تیم انجام داده. اینو نباید فراموش کنیم.
- نگرانی از اینکه ابزار کنترل بشه.
به هر حال، ابزارهای کمکی مانیتورینگ، میتونن توسط یک فرد نادان، برای کنترل و ارزیابی استفاده بشن، ولی به شخصه به نظرم کاملا بی‌ارزش و اشتباهه و فقط باعث تلاش برای دستیابی به راه‌های پیچوندن میشه. اوایل نگرانی در مورد کنترل حجم کار افراد از روی تعداد آهنرباشون بوجود اومده بود که با حذف سریع آهنربا در ردیف آخر (وقتی تسک از مرحله تست عبور کرد و انجام شده تلقی شد، آهنربای شخص برداشته میشه و آهنرباهای اون ردیف، به صورت بی‌نشان هستند و فقط نقش گیره دارن و ارزش دیگه‌ای ندارن) این مشکل برطرف شد. حل این مشکل به سطح فرهنگی و نحوه تعامل آدم‌ها با یکدیگر بستگی داره.
- کارهای یهویی و فوری
یه علامتی هست به شکل U ، وقتی روی تسکی میزنیم، آدم‌ها سعی میکنن به صورت خارج از نوبت باهاش برخورد کنن. خیلی از این استفاده نمی‌کنیم که خاصیتشو از دست نده.
- نمیدونم چجوری، ولی یه همزمانی خاصی بین این تخته و تلاش برای یادگیری در تیم وجود داره. انگار
که یه ستون دیگه‌ای هم توی تخته باید در کنار بک‌لاگ‌ها و ادهاک‌ها جا باز کنه، یه چیزی شبیه ستون یادگیری. توش پیشرفت فردی و هم‌افزایی تیمی ثبت بشه.
حالا حالتون چطوره؟
خیلی خوب. کار کردن توی این تیم واقعا لذت‌بخشه. اسپرینت‌ها به صورت منظم برگزار میشن. آدم‌ها کاملا در همه مراحل کار مشارکت دارن و کسی در مورد وظیفه من یا وظیفه تو صحبت نمیکنه. قدرت برخورد با تغییرات توی تیم بالاست و راحت دچار آشفتگی نمیشن. با هم دوست هستیم و بیشتر از گذشته خارج از موارد کاری باهم معاشرت میکنیم.
در کل الان به نظرم توی یک تیم کاملا استاندارد با روش اسکرام هستیم و بودن توی این تیم باعث رشد آدم‌ها و البته افتخار خواهد بود.
مطلبی دیگر از این انتشارات
حالم بده، Load Averageم بالازده!
مطلبی دیگر از این انتشارات
نبض سرور زیر سبابه‌ی شما!
مطلبی دیگر از این انتشارات
حافظه (Memory) بار امانت نتوانست کشید!