در این پست در ادامه مقاله قبلی، به بررسی ۱۲ تله دیگر در اسکرام خواهم پرداخت که امیدوارم با در نظرگرفتن این موارد بتوانید با کارایی بالاتری اسکرام را اجرا کنید.
با فرضیات پیش رفتن اغلب اعضای تیم اسکرام، موفق به سوال از Product Owner در مورد جزئیاتی که در حال انجامش هستند نمی شوند و یکی از اعضای تیم مشکلات رو حل می کند در حالیکه که این فرد درباره محدودیت های محصول اطلاعات کاملی ندارد و با فرضیات خودش تصمیم گیری می کند. ارتباط و بازخورد بین خروجی تیم و PO باید روزانه در هر اسپرینت انجام بگیرد.
تکمیل (DONE) نشدن Taskها این خیلی سخت است که بتونیم از به تعویق انداختن کارهایی که کامل نشدند و مقدار کمی از اونها باقی مونده جلوگیری کرد اما این موضوع میتونه به عنوان یک عادت در تیم باشه چرا که همیشه کارهای جدیدی ممکن است اضافه بشوند و کارهای قبلی ۱۰۰ درصد به اتمام نرسند. در چنین حالتی استفاده از Burndown Chart توصیه میشه و همچنین ارائه دمو نیز باید انجام شه حتی اگر همه Task ها تکمیل نشده باشند.
آماده نشدن دمو بعضی اوقات ممکن است تیم فراموش کنه که آماده سازی دمو نیاز به صرف زمان لازم داره مثل تمیز کردن محیطی که تیم در اون داره کار می کنه، آماده سازی مکان ارائه دمو، نوشتن متن هایی که باید در جلسه راجع بهش توضیحاتی داده بشه، اطمینان حاصل کردن از حضور ذینفعان. این فعالیت ها می تونن جزئی از Taskهای موجود در Sprint Backlog باشند.
آماده نشدن پروتوتایپ ها برای ارائه تیم اسکرام تلاش می کنه یک محصول با کیفیت تولید کنه به طوری که از همان اسپرینت های اولیه باید محصول پتانسیل ارائه شدن را در خودش داشته باشه. ساختن کد-پروتوتایپ ها باعث تاخیر در لزوم نوشتن کدهای نهایی میشه. از جزئیات در طراحی و کلاً هر کاری که باعث به تعویق افتادن بشه باید اجتناب کرد.
تیم توزیع یافته اگرچه اسکرام به طور رسمی بر حضور کل اعضای تیم در یک محل تاکیدی نکرده اما حقیقت این است عدم حضور اعضاء تیم در یک محل تاثیر منفی بسیاری در ارتباطات و شفافیت میذاره که در نتیجه این تاثیر به کارایی و کیفیت نیز سرایت خواهد کرد.
اسکرام مستر دایرکتیو اسکرام مستر یک تسهیل گر است که از تیم برای یادگیری قوانین اسکرام و خودسازماندهی پشتیبانی می کند. یک اسکرام مستر هرگز نباید وسوسه شه تا به یکی از اعضای تیم توصیه کنه که کارش رو چطوری باید انجام بده.
تغییر عضویت تیم اسکرام یک چارچوب است برای خلق تیم های توسعه محصول با کارایی بالا. اگر عضویت یکی از اعضای تیم بخواد تغییر کنه باید مدل Forming-Storming-Norming-Performing در تیم دوباره بازسازی شه که این مساله برای تیم و محصول ایجاد سربار خواهد کرد.
نقش های غیر اسکرامی در تیم در برخی از سازمان ها این معمول است که اسکرام رو استفاده کنند بدون اینکه عناوین شغلی و شرح وظایف این عناوین تغییر کنه. مثلاً مدیر پروژه در نقش مالک محصول میشه با همون شرح وظایفی که قبلاً داشته.
رها کردن کیفیت برای تیم اسکرام خیلی ساده است که بجای اینکه در تمام زمان ها کیفیت رو در سطح بالایی حفظ کنه بیاد صرفاً جاهایی که حدس میزنه بیشتر مشکل ساز میشه رو رفع باگ کنه که این البته میتونه متاثر از فشار کاری حاکم بر تیم باشه.
تحمیل محدودیت زمانی یا منابع اسکرام مبتنی بر واقعیت ها است. اگر یکی از ذینفعان خارجی قصد داره تحمیل زمانی یا منابعی بر روی تیم انجام بده، باید بپذیره که این مساله مسلماً منجر به لغزش در کیفیت خواهد شد و این خلاف اصول اسکرام است. واقعیت این است که هیچ کس آینده رو نمیتونه پیش گویی کنه و تحمیل و فشار آوردن به تیم یک وهم است.
تحمیل کردن استانداردها به جای مفهوم DoD عموماً مفهوم DoD با استانداردها اشتباه گرفته میشه. مدیران و بعضی از ذینفعان مفهوم استانداردها رو به جای DoD در نظر میگیرن و توقعشون از تیم این است که استانداردها رو باید انجام بدهند.
حاضر نبودن اسکرام مستر اسکرام مستر به دلیل ماهیت نقشی که در تیم اسکرام داره باید همیشه حاضر باشه و این موضوع کمک زیادی به سرعت بخشیدن در انجام Task ها و حرکت رو به جلوی تیم میشه.
این پست اولین بار در تاریخ 1395/05/18 در وب سایت hamidreza.net انتشار یافته است.
