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

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

۰ 211

در این پست در ادامه مقاله قبلی، به بررسی ۱۲ تله دیگر در اسکرام خواهم پرداخت که امیدوارم با در نظرگرفتن این موارد بتوانید با کارایی بالاتری اسکرام را اجرا کنید.

  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

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

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

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

ارسال پاسخ

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

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

  • یوزر اینترفیس (رابط کاربری) به سبک اجایل #۱

    چند روزی هست که مایکروسافت وب سایت outlook رو معرفی کرده که در واقع نسخه جدیدی از Hotmail هست. در بدو لاگین ظاهری تمیز، ساده و خلوتی رو می بینید که از جهاتی شبیه به اولین نسخه های جی میل به نظر میاد ولی به مراتب جذاب تر. کاربری فوق العاده ساده ای داره در…

  • ۵ افسانه Agile

    بی شک برای استفاده از هر روش جدیدی دلایلی وجود دارد.  یکی از این دلایل می تواند برتری نقاط قوت روش جدید نسبت به روش فعلی باشد. اما آیا همیشه اینطور است؟ اگر شما به یکی از دلایل ذیل می خواهید به اجایل مهاجرت کنید باید بدانید که دچار افسانه زدگی Agile شده اید! 🙂…

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

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

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

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

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

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

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

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

بایگانی

آخرین Tweet ها