24 تله ی رایج در اسکرام
مدیریت پروژه نرم افزاری

۲۴ تله ی رایج در اسکرام (بخش اول)

۰ 152

همونطور که می دونید اسکرام محبوب ترین متد 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. مالک محصول می بایست از تمامی اعضای تیم در مورد تعیین راه حل برای مشکلاتی که ممکن است در پروداکت بک لاگ پیش بیاد مشورت بگیره و خودش نباید مستقیماً تصمیم بگیره و به نظر تیم احترام نذاره.

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

در باره نویسنده / 

حمیدرضا متقیان

مدیر محصول Agile. علاقه مند به دنیای وب و ارزش آفرینی در کسب و کار دیجیتالی.

ارسال پاسخ

ایمیل شما نمایش داده نمی‌شود. موارد مورد نیاز علامتگذاری شده است *

*

code

عضویت در خبرنامه

نوشته های تصادفی

  • باور Agile

    باور Agile

    یه روز صبح از خواب بلند میشم و به خودم میگم من میخوام از امروز سلامت تر زندگی کنم و تصمیم میگیرم هر روز یه سیب بخورم. حتماً اون ضرب المثل بلاد بیگانه رو شنیدید که میگه: An Apple a Day Keep Doctor Away.  اما جالب اینجاست که من در کنار خوردن سیب همچنان بخوردن…

  • تقابل آریوپی و اجایل

    تقابل آریوپی و اجایل(عروس بلد نیست برقص ِ می گه زمین کجِ…)

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

  • Some-Thoughts-On-Failure

    چک لیست شکست در RUP

    این مقاله در وبلاگ Jeff Sutherland در سال ۲۰۰۲ به نقل از  کریج لارمن نوشته شده که خوندنش خالی از لطف نیست. این پست در تکمیل پست قبلیم هست تا بعضی از دوستان بدونن که تا چه حد RUP رو اشتباه فهمیدن و اشتباه اجرا میکنن. اگر شما هم مثل ۱۱ مورد زیر در مورد…