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