وبلاگ افشار محبی

چندین سال است که از اسکرام، و به طور کلی تر از اجایل، به عنوان بهترین متودولوژی برای توسعه نرم افزار استفاده می کنیم. قبلش هم از RUP و امثالهم استفاده می کردیم که البته قافیه را به اسکرام باختند و استفاده شان خیلی محدود شد. اسکرام و بقیه فریمورک های اجایل به مذاق تیم ها و افراد از جمله خود من خیلی خوش آمدند. تا آنجا که الان اصطلاحات اسکرام/اجایل در همه جا از جمله در آگهی استخدام ها به وفور دیده می شود. منظورم کلماتی مثل Product Owner، اسکرام مستر، Pair Programming، اسپرینت، User Story، دیلی اسکرام، Sprint Planning و موارد دیگر است.

اسکرام نظم زیادی به تولید نرم افزار داده و باعث وحدت تیم های تولید نرم افزار شده است. اما، من فکر می کنم هنوز در خیلی از شرایط نیاز به چیز دیگری به جز اسکرام داریم. چون، شرایط بعضی از پروژه ها منطبق با اسکرام نیست.

1. پروژه های خیلی از شرکت ها آنقدر بزرگ نیستند که یک تیم چهار نفره برنامه نویسی به مدت مثلا شش ماه روی آن کار کنند. بعضی از این پروژه ها خیلی کوتاه مدت هستند. مثلا در طول یک یا ماه به پایان می رسند. در نتیجه، بعضی مفاهیم اسکرام در مورد آنها ملموس نیست. مثلا جلسات retrospective برای پروژه ای که فقط قرار است چند اسپرینت طول بکشد خیلی تاثیر گذار نیست. یا نمودار Burn-down آنقدر فرصت پیدا نمی کند که جا بیفتد و شرایط واقعی را منعکس کند.
2. گاهی اوقات مشکل این است که تیم اسکرام از بقیه تسک ها ایزوله نیست. بخشی از توان تیم اختصاص دارد به رفع باگ پروژه ای که هم اکنون زیر بار قرار دارد. در نتیجه زمان واقعی تیم از یک اسپرینت به اسپرینت دیگر به هم می ریزد. در یک اسپرینت 100 نفر ساعت داریم، در یک اسپرینت دیگر 130 ساعت و در یکی دیگر 85 ساعت. این طوری، هم برنامه ریزی مختل می شود و هم چیزی مثل Burn-down chart بی معنی می شود.
3. پارت تایم بودن اعضای تیم هم مثل ایزوله نبودن اعضای تیم، در روند تیم ایجاد مشکل می کند. اولین مشکلش این است که دیلی اسکرام را سخت و ارتباط اعضای تیم را به دست انداز می اندازد. ایجاد انتظار در انجام تسک ها به علت وابسته بودن اعضا به همدیگر نیز از دیگر مشکلات است.
4. یک مدل مشکل دیگر که در بعضی شرکت ها رایج است، کار هم زمان روی چند پروژه است. یعنی تیم چند اسپرینت را به طور کامل به پروژه الف اختصاص می دهد، سپس نیمی از وقت اسپرینت بعدی را به پروژه الف و نیم دیگر را به پروژه ب اختصاص می دهد. در اسپرینت بعدی سهم پروژ ب افزایش پیدا می کند و بی نظمی به همین ترتیب ادامه پیدا می کند. گاهی اوقات اعضای تیم به خاطر سویچ کردن های متعدد دچار مشکلات شدید Performance می شوند.
5. چون شرکت ها می خواهند بازگشت سریع سرمایه داشته باشند یا این که می خواهند Time to market را به شدت کاهش دهند، در نتیجه طول اسپرینت را در حداقل زمان ممکن نگه می دارند. طول زمان توصیه شده برای اسپرینت دو هفته است، اما علی الظاهر، اسپرینت یک هفته ای نیز مجاز است. چیزی که من از تجربه ام برداشت می کنم این است که تایم یک هفته ای کمی عجله ای به نظر می رسد. و باعث می شود که فرصت کافی برای انجام بقیه پرکتیس های اسکرام مثل دیلی اسکرام و جلسه رترو وجود نداشته باشد.
6. مشکل دیگری که در خیلی از شرکت ها وجود دارد، نقصان User Story List، تحلیل ناتمام نیازمندی ها و عدم تکمیل feature های مورد نیاز است. فرض بر این است که تیم در جلسه planning لیستی از User Story ها را می بینید و از بین آنها، چند تا را که اولویت بالاتری دارد را انتخاب می کند. سپس آنها را بررسی و پس از شکستن به تسک های کوچک تر و اختصاص آن به افراد تیم، آنها را در برنامه اسپرینت جاری قرار می دهد. مع الوصف در عمل دیده می شود که تازه توی جلسه Sprint Planning است که مستندات خوانده می شود، تحلیل ها بهبود پیدا می کند و feature های مورد نیاز پروژه طراحی می شود. به عبارت دیگر نه تنها جلسه Backlog refinement (Backlog grooming) در جلسه Sprint Planning ادغام می شود، بلکه بخشی از ویژگی های محصول که باید توسط خود مشتری یا اقلا توسط Product Owner طراحی می شد نیز در جلسه Sprint planning رسوخ می کند.
7. خیلی از Item هایی که در جلسات Sprint Planning مورد بحث قرار می گیرند شامل یک تسک طراحی هم هستند. مثلا شامل طراحی ساختار جداول دیتابیس یا نحوه تعامل API ها با یکدیگر هم می شوند. تا آنجا که عقل من قد می دهد، این جور تسک ها بخشی از خود آیتم است که بایستی توسط اعضای تیم حین انجام آیتم انجام شود و مورد بررسی قرار بگیرد. اما دیده می شود که این مدل طراحی ها هم به عنوان بخشی از Sprint Planning در نظر گرفته می شود و همانجا وسط جلسه Sprint Planning انجام می شود.
8. در بعضی تیم های خاص، بخش بیرونی تیم که کارش طراحی محصول و شناخت محصول است با اعضای داخلی تیم هماهنگ نیستند. انگار که فقط بخشی از تیم، اسکرام را پذیرفته و به عنوان مبنای کار در نظر می گیرد. بخش بیرونی، feature ها را به موقع آماده نمی کند، اولویت ها را مدام عوض می کند و وسط اسپرینت تسک اضافه می کند. البته در این مورد خاص، مشکل از تیم است که اسکرام را رعایت نمی کند. اینجا نمی توان از عدم انطباق اسکرام با فرایندهای تیم صحبت کرد.

من حس می کنم تقریبا همه مواردی که ذکر شد در حال اشاره به این موضوع هستند که عدم انطباق اسکرام و روش هایی که در تیم استفاده می شوند لزوما به معنی استفاده نادرست از اسکرام نیست. به نظرم حالا که نمی توان تیم را اجبار به انطباق با اسکرام کرد، یا باید اسکرام را سفارشی سازی کرد یا باید سراغ متودولوژی دیگری رفت. البته سفارشی سازی اسکرام خیلی زیاد انجام می شود و شاید کل این 8 مورد را شاید بتوان به عنوان نسخه جدیدی از اسکرام در نظر گرفت. یا حتی شاید بتوان به عنوان یک متودولوژی اجایل جدید و هم عرض اسکرام مطرحش کرد.

اما من خیلی خوش بین نیستم به این موضوع. حس می کنم به جای دستکاری های بنیادی اسکرام باید برگردیم به تعریف اجایل و ببنیم که آیا اجایل چیز بهتری برای ما ندارد؟ شاید لازم باشد سراغ Kanban، XP، Feature driven development، Lean Startup یا چیزی خارج از فضای اجایل برویم. تعداد شرکت های کوچک دنیا یا تیم ها و پروژه های کوچک در دنیا خیلی هم کم نیستند. شاید دیگرانی هم مثل ما با این مشکلات دست و پنجه نرم می کنند. مثل این که وقتش است تحقیق و مطالعه مان را روی موضوع بالا ببریم و ببینیم که آیا می توانیم روش توسعه مان را بهتر کنیم یا نه.

سلب مسئولیت: ممکن است در این متن بعضی تعاریف یا اصطلاحات اسکرام یا اجایل یا بقیه موضوعات را درست به کار نبرده باشم. هدفم در اینجا انتقال ذهنیات خودم و مفاهیم بوده نه معرفی و بررسی دقیق موضوعات.