پنج دلیل برای اینکه چرا «اسکرام / اجایل» به درد شما نمی‌خورد!

در این مقاله می‌خواهم درباه تجربیاتم از اسکرام و اجایل (چابک) در شرکت‌های مختلف صحبت کنم. این‌بار می‌خواهم از نگاه یک توسعه‌دهنده به آن نگاه کنم، نه از نگاه یک اسکرام‌مستر، مالک محصول، تستر و ... .در اینجا من پنج دلیل برای اینکه چرا «اسکرام / اجایل» به درد شما نمی‌خورد را به شما می‌گویم:۱ مالک محصول (پروداکت اونر) خیلی فنی استبهترین مالکان محصولی که من با آن‌ها کار کردم، غیرفنی بودند. از طرف دیگر، بدترین مالکان محصولی که با آن‌ها کار کردم، افرادی بودند که در گذشته کار توسعه‌دهنده و برنامه‌نویسی انجام می‌دادند. آن‌‌ها فکر می‌کردند که تمام جزییات نرم‌افزاری پروژه و چگونگی پیاده‌سازی آن را به خوبی می‌دانند. البته منظورم این نیست که توسعه‌دهندگان نمی‌توانند صاحبان محصول خوبی باشند، بلکه منظورم این است که باید در مورد ویژگی محصول و مزایای آن برای مشتری فکر کنند، نه جزییات فنی.چنین چیزی در بهترین حالت، ناامیدی و ناراحتی توسعه‌دهنده را به‌همراه دارد و باعث وعده‌های دروغین به مشتری می‌شود. در ادامه مشتری ناراضی می‌شود و همین باعث افزایش سردرگمی‌ خواهد شد.مشکل اینجاست که مالک محصول فنی حتی اگر سعی کند که درباره چگونگی اجرای کار‌ها فکر نکند، باز هم ناخودآگاه در ذهن خود مشغول حل مسئله و بررسی جزییات فنی است.۲ آدم‌ها در جلساتی که به آن‌ها مرتبط نیست، حضور می‌یابنددر بعضی از شرکت‌ها، افراد به عنوان شنونده ساکت در جلسات مختلف حاضر می‌شوند. این شنونده ساکت ممکن است ذی‌نفع، مدیرعامل، مدیر بازرگانی یا مالک محصول باشد. به‌عنوان نمونه جلسه رترو، فقط برای تیم فنی و در صورت وجود، اسکرام‌مستر است. در این جلسه باید فضایی امن برای تیم فراهم شود تا بتوانند درباره همه‌چیز و چگونگی پیشرفت اسپرینت بعدی صحبت کنند. اگر حتی یک نفر از حاضران از اعضای تیم نباشد و کسی احساس راحتی نکند، با مشکل بزرگی مواجه می‌شوید. اسپرینت‌ها همیشه درحال بهبود هستند و هیچ‌وقت به یک اسپرینت بی‌نقص نمی‌رسید. با این حال آیا واقعا می‌خواهید درباره درخواست‌های عجیب و وعده‌های مدیران بالا دستی یا استوری‌های کاربر غیرواقعی جلوی خودشان صحبت کنید؟ شما نه تنها باید فضایی داشته باشید که بگویید چنین مواردی چقدر بد و آزار دهنده است، بلکه باید بتوانید درباره آن‌ها آزادانه با اعضای تیم صحبت کرده و بهترین راه حل را پیدا کنید.۳ شنوندگان ساکت حاضر در جلسات، ساکت نیستندبیشتر اوقات این اتفاق رخ می‌دهد که شنوندگان ساکت، به‌هیچ وجه سکوت نمی‌کنند.معمولا آن‌ها «فقط می‌خواهند یک چیزی را روشن کنند» یا «بگویند که منظور آن‌ها اینطور نبوده است».این منصفانه است، اما باز هم چنین جلساتی نه زمان و نه مکان مناسبی برای یادآوری این نکات است. شنوندگان ساکت باید سکوت کنند تا اعضای تیم بتوانند همه چیز را صحیح و شفاف توضیح بدهند.من به‌شخصه با حضور شنوندگان خاموش در جلسات بسیار مخالف هستم. چون می‌دانم این کار در دنیای واقعی جواب نمی‌دهد. ۴ ارتباط اعضای تیم فقط به استند‌آپ‌های روزانه (دیلی اسکرام یا اسکرام روزانه) محدود استالبته برای شروع بگویم که من بزرگترین طرفدار اسکرام روزانه نیستم. در این جلسات اغلب اسکرام‌مسترها به شما می‌گویند که چگونه باید با اسپرینت پیش بروید و دیگران چه کار می‌کنند. وقتی من از آن‌ها می‌پرسم که چرا باید این جلسات را روزانه انجام دهیم، آن‌ها می‌گویند که ما می‌خواهیم ببینیم می‌توانیم اسپرینت را به پایان برسانیم یا خیر.سپس می‌گویم که من می‌توانم هر زمان بخواهم نمودار برن‌داون را ببینم و این موضوع را بفهمم، اما آن‌ها معمولا دلایل دیگری هم برای برگزاری اسکرام روزانه دارند.به موضوع اصلی برگردیم. من اغلب توسعه‌دهندگان تازه‌کار را می‌بینم که مثلا وقتی در ساعت یک ظهر به مشکلی برمی‌خورند، تا ۱۰ صبح فردا که آن را در جلسه اسکرام روزانه مطرح کنند، صبر می‌کنند. در واقع ۶ ساعت تمام کاری جز نگاه کردن به صفحه و ناامید شدن انجام نمی‌دهند.براساس تجربه می‌گویم که بهترین تیم‌ها آن‌هایی هستند که در سریع‌ترین زمان ممکن با یکدیگر ارتباط برقرار می‌کنند، مشکلات را برطرف و کار با کیفیت انجام می‌دهند. البته نمی‌گویم وقتی همکار شما روی کاری تمرکز کرده، به سراغ او بروید و مزاحم شوید، بلکه می‌گویم می‌توانید برای آن شخص نکات لازم را بنویسید و به او بدهید تا هر زمان که توانست به کمک شما بیاید. با این روش، مشکل گاهی در ۱۵ دقیقه حل می‌شود و گاهی زیر یک ساعت. در هر صورت نباید ۶ ساعت تمام منتظر بمانید.۵ مالکان محصول باید از تیم اسکرام محافظت کننداین یکی از مشکلات شایع در محیط‌های کار با اسکرام است. مالک محصول نقش رابط میان تیم اسکرام و مشتری/ ذی‌نفع را دارد. این دو همدیگر را به سمت دستیابی سریع‌تر به ویژگی‌های مطرح شده هل می‌دهند و توسعه‌دهنده می‌خواهد سیستمی کامل ایجاد کند. ساخت این سیستم کامل ممکن است ۱۰ اسپرینت طول بکشد، اما ما فقط دو اسپرینت وقت داریم.بنابراین باید راهی برای ایجاد فشار کاری متعادل برای هر دو طرف پیدا کرد. متاسفانه چیزی که زیاد از حد رخ می‌دهد این است که تیم اسکرام فیچر (ویژگی‌) غیرممکن از سوی مالک محصول دریافت می‌کند و باید درباره اینکه چگونه می‌تواند چنین چیزی را تحویل بدهد، فکر کند. گاهی شما می‌توانید بخشی از فیچر را حذف کنید اما گاهی این امکان وجود ندارد و در نتیجه آنچه به دست می‌آید، یک فیچر ضعیف است که هیچ‌کس دوست ندارد از آن استفاده کند یا آن را به اجرا درآورد.در اینجا مشکل اعتماد از طرف مالک محصول است. اعتماد در اسکرام / اجایل بسیار مهم است. اگر یک طرف به بقیه اعتماد نداشته باشد، دیگران با مشکل مواجه می‌شوند. زیرا اسکرام درباره باز بودن است و در این چارچوب همه می‌توانند اعتماد لازم را داشته باشند و بگویند درباره چه فکر می‌کنند.ترجمه آزاد: Five reasons why scrum/agile is not working for you!