اشتباهات رایج در اسکرام

اشتباهات رایج در اسکرام

پیاده سازی متد اسکرام برخلاف سادگی متد، خیلی دشوار است. این متد به شدت شکننده بوده و در صورت customize شدن یا چشم پوشی از مراحل و اصول در نظر گرفته شده می‌تواند بشدت مضر باشد. همانطور که قبلا هم گفتم این متد تجربی بوده و هر نکته‌ای در آن مهم است و برای رفع مشکل خاصی در نظر گرفته شده است. چند مورد از اشتباهات رایج یا رفتارهای بدی که در تیم‌های اسکرام اتفاق می‌افتد در ادامه ذکر شده است[۱] که بهتر است سعی کنیم مرتکب آنها نشویم.

  • برنامه ریزی و آماده‌سازی بیش از حد: در متدهای اجایل به ویژه در اسکرام نیازی به برنامه‌ریزی طولانی مدت و بزرگ در ابتدای پروژه نیست. می‌توان کار را با برنامه‌ریزی برای چند اسپرینت شروع کرد و موازی با آن بر اساس فیدبک‌های ثابت و مداوم که در جلسات review بدست می‌آید برنامه‌ریزی‌ها را تنظیم کرد. حتی backlog محصول هم می‌تواند بعد از اولین اسپرینت تکمیل شود، البته این بهبودها و تکمیل back log یک کار مداوم بوده و همیشه به طور موازی با روند انجام کارها پیش می‌رود.
  • تمرکز بر روی ابزار: خیلی از سازمانها از همان ابتدا تمام تمرکز خود را بر روی پیدا کردن یک ابزار مدیریت فرآیند می‌گذارند قبل از اینکه بدانند چگونه اسکرام را باید اجرا کنند. استفاده از ردیابی فرآیند به صورت دستی با استفاده از کاغذ در ابتدای شروع کار می‌تواند مناسب باشد . لزوما نیاز به یک ابزار اتوماتیک نمی‌باشد. در حین اجرای روند و بهبود فرآیند هم می‌توان به این موضوع پرداخت.
  • حل مشکلات در جلسات daily: در جلسات روزانه نباید بر روی یافتن راه حل برای مشکلات پیش آمده وقت گذاشته شود. در این جلسات فقط مشکلات مطرح می‌شود. این جلسه باید کوتاه بوده و  روی مواردی که باید گفته شود متمرکز است. بعد از جلسه کسی که به مشکل برخورده و کسی یا کسانی که راه‌حلی دارند یا علاقه‌مند به بحث هستند می‌توانند باهم جلسه برگزار کنند.
  • تخصیص وظایف: با اینکه مفهوم self-organize در اسکرام وجود دارد ولی هنوز هم برخی فکر می‌کنند که مدیر پروژه یا سرپرست تیم باید کارها را به افراد تیم اختصاص دهد، باید اجازه دهیم افراد خودشان تقسیم کارها و تخصیص آن را بر عهده بگیرند.
  • شروع مجدد اسپرینت کنسل شده: اگرچه کنسل شدن یک اسپرینت به ندرت اتفاق می‌افتد ولی اگر منتظر بمانیم تا دوباره همه‌چیز درست و آماده شود و در حالت ایده آل  دوباره اسپرینت را شروع کنیم درست نیست، بعد از کنسل شدن اسپرینت بلافاصله باید اسپرینت جدید شروع شود.
  • اسکرام مستر به عنوان یک مشارکت کننده: اسکرام مستر باید مانند یک آتشفشان باشد، باید نظاره گر بوده و منتظر یک موقعیت اضطراری باشد تا برای رفع مشکلات و برداشتن موانع از سر راه تیم و فرآیند وارد عمل شود، درگیر شدن اسکرام مستر در کارهای دیگر تمرکز او را از انجام این کارها منحرف می‌کند. پس نباید اسکرام مستر را درگیر کارهای دیگری کرد.
  • در دسترس نبودن مالک محصول: مالک محصول باید در تمام جلسات اسکرام حضور داشته باشد علاوه بر آن باید در طول اسپرینت هم در دسترس باشد و با اعضا مشارکت داشته باشد. البته مالک محصول باید با مشتری و ذینفعان هم در ارتباط باشد و این زمان باید با زمان جلسات تیم تداخل نداشته باشد و مدیریت شده باشد.
  • بسط یافتن اهداف: تیم مشخص می‌کند که در هر اسپرینت چقدر کار قابل انجام است و کسی نباید به تیم فشار بیاورد که بیشتر از تعهداتشان کار انجام دهند، این فشار به مرور باعث ایجاد خشم و بی‌اعتمادی در افراد می‌شود و کارها بی‌کیفیت پیش خواهند رفت.
  • قهرمانان فردی: افراد در تیم اسکرام نباید بیش از حد کار انجام دهند و یا سعی کنند که به هر نحوی قهرمان تیم شناخته شوند. اسکرام به ما کمک می‌کند که یک تیم بزرگ از افراد بسازیم نه یک تیم از افراد عالی، (نقل قول از Barry Turner)
  • سازماندهی back log محصول توسط تیم: تیم دید مناسبی از نیازمندی‌های کاربران و مشتری ندارد و باید بر روی حل مسائل فنی متمرکز شود. مالک محصول است که از اولویت درست کارها باخبر است، مالک محصول باید بر روی [۲]ROI پاسخگو باشد بنابراین باید در مقابل هر نوع فشار از سمت تیم در اولویت انجام کارها و تغییر اولویت مقاومت کند.
  • مشخص کردن راه حل توسط مالک محصول: مالک محصول باید اجازه دهد که تیم با آزادی کامل برای حل مشکلات موجود در back log راه حل ارائه دهد. آیتم‌های تعریف شده در back log نباید دارای مشخصات فنی باشد مگر آنهایی که مستقیماً وابسته به نیازمندی‌های کاربر نهایی با مشتری باشد.
  • وقفه‌های ضروری: وقفه‌های ضروری نباید در اسپرینت اتفاق بیافتد اگر خیلی ضروری باشد باید اسپرینت لغو شود. در غیر اینصورت وقفه باید بر روی back log محصول باشد  و تا شروع اسپرینت بعدی به تأخیر بیفتد.
  • ساخت فرضیه: اغلب اعضای تیم نمی‌توانند در مورد جزئیات کاری که انجام می‌دهند از مالک محصول سوال بپرسند و با یکسری فرضیات کار را انجام می‌دهند در حالیکه در نظر گرفتن بعضی محدودیت‌ها ضروری می‌باشد. بازخورد و ارتباط  بین مالک محصول و اعضای تیم باید مداوم باشد و حتی روزانه انجام شود.
  • آماده نبودن نسخه دمو: بعضی مواقع تیم فراموش می‌کند که برای آماده سازی نسخه قابل ارائه زمان در نظر بگیرند، کارهایی از قبیل آماده سازی محیط نمایش، آماده سازی اسکریپت‌های مورد نیاز، حصول اطمینان از اینکه ذینفعان مربوطه آماده باشند و آماده سازی تمام پیش نیازهای مربوط به ارائه increment محصول. این کارها می‌تواند به عنوان کار در back log محصول در نظر گرفته شود که فراموش نشوند.
  • ارائه prototype نه محصول کارکردی قابل ارائه[۳]: تیم اسکرام باید سعی کند که از همان اسپرینت اول محصول با کیفیت و increment کارکردی قابل نمایش و تست تولید کند. تهیه protype فقط نوشتن کد production را به تأخیر می‌اندازد، از طرفی گرفتن فیدبک مفید از مشتری هم با prototype به صلاح نیست.
  • تیم به صورت توزیع شده: اگرچه اسکرام حضور افراد یک تیم در یک اتاق واحد را اجبار نمی‌کند اما واقعیت اینست که توزیع اعضای تیم اثرات منفی بر روی شفافیت و ارتباطات خواهد داشت که این هم به نوبه خود تاثیر منفی بر روی کیفیت و بهره‌وری دارد. بنابراین بهتر است که اعضای تیم اسکرام متمرکز باشند تا ارتباطات راحت‌تر شود.
  • اسکرام مستر در نقش دستور دهنده: اسکرام مستر باید تسهیل کننده باشد، پشتیبان تیم باشد و در راستای یادگیری اصول و قوانین اسکرام و self-organize شدن تیم، آنها را آموزش دهد. نباید در مورد اینکه عضو تیم چه کاری را انجام می دهد یا اینکه کار بعدی چه خواهد بود حساسیت نشان دهد و یا دخالت کند.
  • تغییر اعضای تیم: اسکرام چارچوبی برای ایجاد تیم‌های توسعه با کارایی بالا می‌باشد، اگر اعضا تغییر کنند باید تمام تلاشها در راستای تشکیل تیم و هماهنگی آنها و بالا بردن کارایی آنها از سر گرفته شود که کاری زمان بر است و به هر دلیلی به هدر رفتن سرمایه محسوب می‌شود.
  • وجود نقش‌های غیر اسکرامی در تیم اسکرام: در سازمان‌ها خیلی رایج است که تیم اسکرام را بدون تغییر تایتل و نقش سازمانی قبلی اعضای تیم، تشکیل می‌دهند. برای مثال به مدیر پروژه ممکن است مسئولیت‌های یک مالک محصول داده شود بدون اینکه سمت سازمانی آن تغییر کند. تیم اسکرام باید فقط شامل اسکرام مستر، مالک محصول و تیم توسعه باشد.
  • فدا کردن کیفیت: اسکرام تاکید ویژه‌ای بر روی ارائه مجصول با کیفیت دارد. معمولا در سازمان‌ها به علت وجود فشار جهت پیاده سازی و ارائه سریع ویژگی‌های محصول کیفیت را فدا می کنند در حالی که باید در همه زمانها کیفیت را در سطح بالایی نگه دارند.
  • تعریف غلط [۴]DOD بین مفهوم “DOD” و “استاندارد” سردرگمی وجود دارد. بعضی مواقع مدیران به اشتباه استانداردها را به عنوان DOD برای تیم تعریف می‌کنند.
  • حاضر نبودن اسکرام مستر: در بعضی از سازمانها تیم اسکرام مسترها را جدا از تیم توسعه‌دهندگان و در یک اتاق دیگر مستقر می‌کنند، در این شرایط اسکرام مستر فقط در شرایطی که در حال رفع یک مشکل خاص یا برطرف کردن مانع خاصی است در دسترس هست. بهتر است اسکرام مستر در اتاق مربوط به تیم توسعه مستقر شود.

موارد گفته شده موارد ساده‌ای هستند ولی وقتی به آنها توجه نشود باعث بروز مشکلات متعددی می‌شود. موارد گفته شده در بالا جز اشتباهات رایجی هستند که در سازمانها اتفاق می‌افتد، موفقیت پیاده سازی اسکرام در یک سازمان به این موارد ریز وابسته است و بهتر است به راحتی از کنارشان رد نشویم.

[۱] “۲۴ Common Scrum Pitfalls Summarized” by Mishkin Bertei
[۲] Return On Investment
[۳] Shippable
[۴] Definition Of Done

 

 

 

 

پاسخ دهید

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