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

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

۰ 358

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


  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

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

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

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

ارسال پاسخ

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

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.

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

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

    و اما قسمت آخر؛ در دو پست قبلی کلیاتی درباره UI Development مطرح شد. در این قسمت بصورت کاربردی تر در اجایل به این موضوع خواهم پرداخت.  همونطور که می دونید Iterative(تکرارشونده) و Incremental(تدریجی)  بودن توسعه، دو اصل حیاتی در بطن Agile هستن. بعضی ها فکر می کنن که این دو مورد فقط باید در…

  • چک لیست شکست در RUP (آر یو پی)

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

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

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

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

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

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

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

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

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

بایگانی

آخرین Tweet ها

  • Conversion Centred Design (CCD) exists to help designers create user experiences that drive a single business goal.4 روز ago
  • RT @amandaksilver: Developers in demand in every industry. That's because developers are at the center of innovation. The future always beg…2 هفته ago
  • https://t.co/Wl3UuLweYU3 هفته ago