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

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

۰ 128
  1. با فرضیات پیش رفتن. اغلب اعضای تیم موفق به سوال از Product Owner در مورد جزئیاتی که در حال انجامش هستند نمی شوند و یکی از اعضای تیم مشکلات رو حل می کند در حالیکه که این فرد درباره محدودیت های محصول اطلاعات کاملی نداره و با فرضیات خودش تصمیم گیری می کنه. ارتباط و بازخورد بین خروجی تیم و PO باید روزانه در هر اسپرینت انجام بگیره.
  2. ناقص ماندن Taskها. این خیلی سخت است که بتونیم از به تعویق انداختن کارهایی که کامل نشدن و مقدار کمی از اونها باقی مونده جلوگیری کرد اما این موضوع میتونه به عنوان یک عادت در تیم باشه چرا که همیشه کارهای جدیدی ممکن است اضافه بشن و کارهای قبلی ۱۰۰ درصد به اتمام نرسن. در چنین حالتی حتماٌ باید از Burndown Chart استفاده کرد و مادامی که کار انجام نشده ای که باید انجام بشه وجود داره دمو رو نباید ارائه کرد.
  3. آماده نشدن دمو. بعضی اوقات ممکن است تیم فراموش کنه که آماده سازی دمو نیاز به صرف زمان لازم داره: تمیز کردن محیطی که تیم در اون داره کار می کنه، آماده سازی مکان ارائه دمو، نوشتن متن هایی که باید در جلسه راجع بهش توضیحاتی داده بشه، اطمینان حاصل کردن از حضور ذینفعان. این فعالیت ها می تونن جزئی از Taskهای موجود در Sprint Backlog باشند.
  4. آماده نشدن پروتوتایپ ها. تیم اسکرام تلاش می کنه یک محصول با کیفیت تولید کنه به طوری که از همان اسپرینت های اولیه باید محصول پتانسیل ارائه شدن را در خودش داشته باشه. ساختن پروتوتایپ های کد باعث تاخیر در لزوم نوشتن کدهای نهایی میشه. از جزئیات در طراحی و کلاً هر کاری که باعث به تعویق افتادن بشه باید اجتناب کرد.
  5. تیم توزیع یافته. اگرچه اسکرام به طور رسمی بر حضور کل اعضای تیم در یک محل تاکیدی نکرده اما حقیقت این است که تیم هایی که اعضاء آن دریک محل حضور نداشته باشند تاثیر منفی بسیاری در ارتباطات و شفافیت میذاره که در نتیجه این تاثیر به کارایی و کیفیت نیز سرایت خواهد کرد.
  6. اسکرام مستر دایرکتیو. اسکرام مستر یک تسهیل گر است که از تیم برای یادگیری قوانین اسکرام و خودسازماندهی پشتیبانی می کند. یک اسکرام مستر هرگز نباید وسوسه شه تا به یکی از اعضای تیم توصیه کنه که کارش رو چطوری باید انجام بده.
  7. تغییر عضویت تیم. اسکرام یک چارچوب است برای خلق تیم های توسعه محصول با کارایی بالا. اگر عضویت یکی از اعضای تیم بخواد تغییر کنه باید مدل Forming-Storming-Norming-Performing در تیم دوباره بازسازی شه که این برای تیم و محصول ایجاد سربار خواهد کرد.
  8. نقش های غیر اسکرامی در تیم. در برخی از سازمان این معمول است که اسکرام رو استفاده کنند بدون اینکه عناوین شغلی و شرح وظایف این عناوین تغییر کنه. مثلاً مدیر پروژه در نقش مالک محصول میشه با همون شرح وظایفی که قبلاً داشته.
  9. رها کردن کیفیت. برای تیم اسکرام خیلی ساده است که بجای اینکه در تمام زمان ها کیفیت رو در سطح بالایی حفظ کنه بیاد صرفاً جاهایی که حدس میزنه بیشتر مشکل ساز میشه رو رفع باگ کنه که این البته میتونه متاثر از فشار کاری حاکم بر تیم باشه.
  10. تحمیل محدودیت زمانی یا منابع. اسکرام مبتنی بر واقعیت ها است. اگر یکی از ذینفعان خارجی قصد داره تحمیل زمانی یا منابعی بر روی تیم انجام بده، باید بپذیره که این مساله مسلماً منجر به لغزش در کیفیت خواهد شد و این خلاف اصول اسکرام است. واقعیت این است که هیچ کس آینده رو نمیتونه پیش گویی کنه و تحمیل و فشار آوردن به تیم یک وهم است.
  11. تحمیل کردن استانداردها به جای مفهوم DoD. عموماً مفهوم DoD با استانداردها اشتباه گرفته میشه. مدیران و بعضی از ذینفعان مفهوم استانداردها رو به جای DoD در نظر میگیرن و توقعشون از تیم این است که استانداردها رو باید انجام بدهند.
  12. حاضر نبودن اسکرام مستر. اسکرام مستر به دلیل ماهیت نقشی که در تیم اسکرام داره باید همیشه حاضر باشه و این موضوع کمک زیادی به سرعت بخشیدن در انجام Task ها و حرکت رو به جلوی تیم میشه.
Share

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

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

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

ارسال پاسخ

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

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

  • Some-Thoughts-On-Failure

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

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

  • 24 تله ی رایج در اسکرام

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

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

پربازدید ترین ها

  • بندهای حیاتی یک قرارداد تولید نرم افزار

    بندهای حیاتی یک قرارداد تولید نرم افزار

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

  • بایدها و نبایدها در ارائه پروپوزال

    بایدها و نبایدها در ارائه پروپوزال

    در اسفند ۸۸ در وب سایت بزرگ برنامه نویس به موجب سوال یکی از دوستان در مورد “شیوه ارائه طرح پیشنهادی نرم افزار”  توضیحاتی هر چند مجمل دادم که خوندنش خالی از لطف نیست: Proposal رو باید بر اساس RFP یا Request For Proposal ای که از مشتری میگیرین تهیه کنید. RFP از اهمیت زیادی…

  • the-internet-of-things

    آینده در دستان اینترنت اشیاء (IoT)

    Internet Of Things تحولی در آینده اینترنت است که مسلماً کسب و کار نرم افزار رو بسیار پر رونق تر و در عین حال فراگیرتر می کنه.  فرض کنید به خرید رفتید و خیلی راحت از یخچال خونتون استعلام میکنید که چه چیزهایی رو باید خریداری کنید؛ نیم ساعت قبل از اومدنتون میتونید سیستم تهویه…

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

بایگانی