چرا اسکرام شما کارآمد نیست - (از دید تیم توسعه)

بسیاری از تیم ها و سازمان ها برای به دست آوردن بهترین استفاده از اسکرام تلاش می کنند. در مقاله دیگری با عنوان " اجایل را به خاطر مشکلات موجود سرزنش نکنید" من این تحلیل را به اشتراک گذاشتم که چرا اجایل یا اسکرام غالباً مقصر شناخته می شوند. در این مقاله به متداول ترین اشتباهات اسکرام که منجر به عملکرد نامناسب و عدم بهره گیری کارآمد از اسکرام می شود خواهیم پرداخت. این بار از منظر تیم توسعه به موضوع نگاه خواهیم کرد.

نقش های اسکرام و مسئولیت های مرتبط

با گذشت سالها یاد گرفته ام و تجربه کرده ام که اکثر علائم مشکلات را می توان به دلیل عدم رعایت مسئولیت های نقش های اسکرام دانست. به همین دلیل این موضوع را در سه پست جداگانه تقسیم کرده ام:

• مالک محصول
• تیم توسعه
• اسکرام مستر

هر مقاله از نقشی که تحت پوشش قرار می دهد موضوع را بررسی میکند. منشاء بسیاری از اختلاف ها را از چگونگی بکارگیری اسکرام (که به آن "اسکرام حرفه ای" گفته می شود) و چگونگی تمرین و سوء تفاهم ها و برداشت های اشتباه، کشف می کنم. این مقالات بر اساس تجربه شخصی من است که در هنگام تمرین نقش های تیم توسعه (عضو)، مالک محصول و اسکرام مستر کسب کرده ام و یا در مثال های تکراری که دانش آموزانم در دوره های Scrum.org به آنها اشاره می کنند.

تیم توسعه

تیم حرفه ای توسعه اسکرام

تیم حرفه ای توسعه اسکرام گروهی از متخصصان تمام وقت است که با هدف دستیابی به یک هدف خاص - هدف اسپرینت -  می توانند محصول بالقوه قابل انتشار را ایجاد کنند. آنها این کار را هر اسپرینت (1 ماه یا کمتر) انجام می دهند. با تبدیل آیتم های Product Backlog به یک محصول کارآمد، مرتباً ریسک را کاهش می دهند:

• ریسک فنی: آیا واقعا کار می کند؟ و آیا با موفقیت با فرآورده قبلی محصول ادغام می شود؟
• ریسک تجاری: آیا واقعا یک مشکل کاربر نهایی حل می شود؟ آیا این فرآورده یک نیاز را بطور هدفمند برآورده می کند؟

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

فراوظیفه ای و خود سازمانده (cross-functional، self-organizing)

تیم توسعه یک تیم کارآمد است. این بدان معناست که آنها تمام مهارتهایی را که برای ارائه یک فرآورده بالقوه قابل انتشار در هر اسپرینت لازم است، دارند و یک تیم خود سازمان دهنده هستند. هیچ کس به تیم توسعه نمی گوید که چگونه کار را انجام دهد. ما برای انجام کارها به آنها اعتماد داریم. براساس هدف اسپرینت که تیم اسکرام در حین برنامه ریزی اسپرینت فعالیت می کند، تیم توسعه به طور مرتب پیشرفت و برنامه خود را برای دستیابی به هدف اسپرینت بررسی و تنظیم می کند (بک لاگ اسپرینت). هنگامی که بینش های جدید نمایان می شوند، احتمالاً Sprint Backlog در سراسر اسپرینت تغییر می کند. تیم توسعه مالک Sprint Backlog است و تنها کسی است که می تواند آن را تغییر دهد. حداقل در هر جلسه اسکرام روزانه (Daily Scrum) آنها فرآورده خود را به سمت هدف اسپرینت بررسی کرده و برای مدت 24 ساعت آینده برنامه ریزی می کنند.

در عین حال، خود سازماندهی متضمن این است که آنها چالش های خود را، چه مربوط به مسائل فنی و چه محصول، و همچنین بین فردی / همکاری مرتبط با خود حل می کنند. با این حال، اسکرام مستر به آنها کمک می کند تا توانایی های خود را برای حل این چالش ها به شیوه ای مؤثر توسعه دهند.

همکاری مشتری و پالایش بک لاگ محصول

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

چرا ممکن است برای شما کار نکند

تفاسیر غلط توسط سازمان

سازمان شما ممکن است کمی انتظارات متفاوت داشته باشد ، مانند:

• فقط وظایفی را که تعریف کردیم انجام دهید. شما دست هستید، نه مغز.
• سرعت مشخصه خوبی برای سنجش عملکرد تیم توسعه است.
• اگر نیاز داریم که سریعتر کار خود را انجام دهیم، ساده ترین راه این است که باید سخت تر کار کنید.
• مالک محصول می تواند با بالا بردن سرعت، کیفیت را هم افزایش دهد.
• اگر درخواست آخرین لحظه ای داشته باشیم می توانیم آن را هر طور شده در اسپرینت قرار دهیم.
• اگر تیم توسعه فرا وظیفه ای(cross-functional) نباشد، اشکالی ندارد. آنها می توانند با همکاری سایر بخش ها هرگونه شکاف ممکن را پر کنند.
• از آنجایی که تیم توسعه خود سازمانده است ما باید آنها را از نزدیک کنترل کرده و تحت نظر داشته باشیم. در غیر این صورت منجر به هرج و مرج خواهد شد.
• خوشبختانه ما اسکرام مستر و مالک محصول را داریم تا از نزدیک آنها را مدیریت کنیم.
• ما باید مشتریان و کاربران نهایی را از تیم توسعه دور نگه داریم تا آنها بتوانند زمان بیشتری را در تولید محصول صرف کنند.
• اگر ما مشتریان خود را بیشتر و حتی در حین توسعه درگیر کنیم، آنان این احساس را پیدا می کنند که ناتوان هستیم و قادر به فهمیدن پیشاپیش نیازهای آنها نیستیم.
• مشتریان ما اغلب نمی خواهند که آزاد باشیم.

تفاسیر غلط توسط تیم توسعه

یا شاید شما - به عنوان عضو تیم توسعه - درک متفاوتی از نقش تیم توسعه داشته باشید ، مانند:

• من فقط باید روی کارهای خودم در اسپرینت تمرکز کنم.
• مهمترین چیز این است که من بهره ور هستم.
• همکاری با هم منجر به پایین آمدن راندمان ما می شود و این یعنی اتلاف.
• اگر نتوانم کار خودم را تمام کنم از آنجایی که کار من به دیگران بستگی دارد، مشکل من نیست.
• کار با کاربران نهایی مرا از انجام کار خود دور می کند.
• اگر تمام کارهایی را که در طول برنامه ریزی اسپرینت مشخص شده بود به پایان برسانیم، برابر با یک اسپرینت موفق است.
• مالک محصول باید کلیه الزامات را با جزئیات توصیف کند تا در حین اسپرینت هیچ گونه ابهامی وجود نداشته باشد.
• اگر در تیم توسعه مشکلی داریم، اسکرام مسترها آن را پیگیری خواهند کرد.
• در حقیقت، ما می توانیم تمام مواردی را که ما را از انجام کار خود منحرف می کند به اسکرام مستر ارجاع دهیم.
• اگر شرایط پیش بینی نشده ای وجود داشته باشد، باید از مالک محصول بخواهیم تصمیم بگیرد.
• اگر صاحب محصول به ما گفت که کارهای اضافی را انجام دهیم، مجاز هستیم که کیفیت را قربانی کنیم تا آن کار انجام شود.
• مادامی که همه جوانب عملکردی را از اسپرینت بک لاگ خود پوشش دهیم، اشکالی ندارد که نتوانیم تمام کارها را بر اساس "تعریف انجام شده" لحاظ کنیم. می توانیم کار باقی مانده را در اسپرینت بعدی به پایان برسانیم.
• کلیه ارتباطات با ذینفعان باید از طریق مالک محصول انجام شود.
• ما فقط در طول جلسه بررسی اسپرینت مالک محصول را در مورد اسپرینت مطلع خواهیم کرد.
• اگر همه کارهایمان از اسپرینت را در انتهای اسپرینت ادغام کنیم، به اندازه کافی خوب است.

شما چه کاری برای این موضوع می توانید انجام دهید

مستمرا آنچه را که از یک تیم توسعه حرفه ای اسکرام انتظار دارید را بررسی کنید. به عنوان مثال با شرکت در یک دوره تخصصی مبانی حرفه ای اسکرام یا توسعه دهنده حرفه ای اسکرام، مطالعه کتاب "Scrum - a Pocket Guide" و بررسی مجدد کتاب "راهنمای اسکرام". علاوه بر این، در مورد نحوه تمرین نقشها در اسکرام کارآمد در این لحظه تأمل کنید. فقط در این صورت می توانید اختلافات را تشخیص دهید و در نتیجه می توانید بفهمید که چه کاری می توانید انجام دهید تا آن را به نحوی بهتر تغییر دهید. اسکرام مسترهای شما می توانند در اینجا به شما کمک کنند.

لینک مقاله اصلی:

https://www.scrum.org/resources/blog/development-team-why-your-scrum-doesnt-work-23

• پیج لینکدین
• پیج اینستاگرام
• پروفایل در scrum.org