24 تله ی رایج در اسکرام (بخش اول)1 min read

همونطور که می دونید اسکرام محبوب ترین متد Agile است اما انجام صحیح اسکرام کار ساده ای نیست! برای این که بتونید اسکرام را درست پیش ببرید باید مواظب باشید در این تله ها گرفتار نشید.

افراط در مقدمه­ سازی و برنامه ریزی

قبل از شروع هر اسپرینت در اسکرام نیازی نیست مته به خشخاش بذارید و بخواین در ابتدا مقدمات برگزاری اسپرینت آماده بشه و بعد اون رو برگزار کنید. این اتفاق مخصوصاً در اسپرینت اول خیلی اتفاق میفته. کار رو شروع کنید و در Sprint Review آنچه که اتفاق افتاده رو بررسی کنید. حتی اگر Product Backlog هم برای اسپرینت اول آماده نیست باز مشکلی وجود نداره و می تونید این اسپرینت رو برگزار کنید.

تمرکز بیش از حد  بر روی ابزار

خیلی از افراد یا شرکت ها مرتب دنبال این هستن که ببینن چه ابزار جدیدی به بازار اومده که میتونه در جهت پیشبرد اسکرام بهشون کمک کنه حتی اگر ندونن اصلاً اسکرام چی هست. اولین چیزی هم که در مباحثه ها به شما میگن اینه که ما از فلان ابزار استفاده می کنیم شما از چی استفاده می کنین؟! انگار اسکرام کِرِم دور چشم شده که مارکش مهم باشه! واقعاً شما اسکرام رو با همون حداقل ابزارهای خودش میتونین پیش ببرید. نهایت امر یه Excel نیاز خواهید داشت و لا غیر. وقتی رو هم که صرف جستجو، یادگیری و آزمون و خطای این می کنید که کدوم ابزار به کار شما میاد رو صرف افزایش دانشتون در خود اسکرام کنید.

حل مشکلات در جلسه Stand-up

این جلسه، از جلسه های کوتاه بسیار مفید در اسکرام است و قرار نیست به طول بیانجامد. هرگز وقت این جلسه رو صرف بررسی چراها، علت ها، تعیین مقصرین، نق زدن ها، داستان گفتن ها و … نکنید. همون سه سوال اصلی رو کوتاه و مختصر پاسخ بدید. اسکرام مستر در این جلسه نقش کلیدی ای رو بازی میکنه.

تعیین وظیفه برای اعضای تیم

اساس تیم در اسکرام بر اساس self-organized بودن اون است و چیزی به نام Task-Assign توسط هر عضوی از تیم یا سازمان کارفرما یا سازمان مجری در اسکرام وجود نداره. واقعاً اگه روحیه و فرهنگ این کار رو ندارید اسکرام رو انتخاب نکنید! کاری که میتونه انجام بشه ایجاد اشتیاق در اعضای تیم برای انتخاب یک Task است.

تاخیر در شروع مجدد یک Sprint

اگرچه کنسل شدن یک اسپرینت خیلی نادر است اما این میتونه خیلی وسوسه انگیز باشه که اول صبر کنیم تا همه چی آماده بشه بعد اسپرینت رو مجددا شروع  کنیم. بعد از اینکه اسپرینت به هر دلیلی کنسل شد تیم می بایست به سرعت اسپرینت رو بدون هیچ تاخیری مجدد شروع کنه.

Scrum Master در نقش مشارکت کننده در انجام Taskها

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

غیبت Product Owner

مالک محصول یک عضو تمام وقت تیم اسکرام است و باید در جلسات اسکرام مانند Planning، Review و یا Daily حضور داشته باشه.  کلاً باید در طول تایم کاری فعال و در دسترس تیم باشه. نبود اون تیم رو دچار مشکل خواهد کرد.

افراط در هدف گذاری یک اسپرینت

تیم تصمیم میگیره که در طول یک اسپرینت چه کارهایی رو میتونه انجام بده و در واقع توانش چقدر است. هیچ کس نمیتونه به تیم فشار بیاره تا حجم کار بیشتری رو انجام بده. در صورت این اتفاق اعضای تیم آزرده خاطر خواهند شد و مطمئناً کیفیت کار پایین میاد.

قهرمان سازی های فردگرایانه

اسکرام به ما کمک می کنه تا از افراد، تیم های خوبی بسازیم نه تیم هایی از افراد خوب بسازیم(Barry Turner)! شخص واحد در اسکرام جایگاهی نداره. اگر محصول با ارزش و موفق است کل تیم نقش داره و اگر شکست خورده باز کل تیم مقصر است. ممکن است یکی از اعضای تیم رو قهرمان موفقیت ها بدونن که این اشتباه است و انگیزه رو از سایرین خواهد گرفت.

تیم به تنهایی پروداکت بک لاگ رو سازماندهی میکنه

تیم ِتوسعه، اطلاعی از نیازهای مشتری و اولویت بندی اونها بر اساس ROI نداره در نتیجه نمیتونه آیتم های پروداکت بک لاگ رو اولویت دهی و سازماندهی کنه. این وظیفه مالک محصول است که این کار رو انجام بده. تنها کاری که تیم میتونه در این قسمت انجام بده مشارکت با PO در اولویت بندی هایی است که از لحاظ تکنیکالی باید جابجا بشن و امکان انجامش از لحاظ فنی نیست.

تعیین راه حل توسط Product Owner

مالک محصول می بایست از تمامی اعضای تیم در مورد تعیین راه حل برای مشکلاتی که ممکن است در پروداکت بک لاگ پیش بیاد مشورت بگیره و خودش نباید مستقیماً تصمیم بگیره و به نظر تیم احترام نذاره.

وقفه های اورژانسی

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

+