آیا شما نیز مانند بسیاری از تیمها، همه جلسات اسکرام را در برنامه خود دارید اما هنوز احساس اجایل بودن نمی‌کنید؟
«ده‌ها تیم به‌ظاهر اسکرامی، هر روز در سکوت شکست می‌خورند؛ نه به‌خاطر ابزارها، بلکه به‌خاطر نبود آموزش، درک سطحی از اصول و ناتوانی در اجرای واقعی اسکرام و ذهنیت اجایل.»
ما در این مقاله به سراغ 9 اشتباه پنهان و مرگبار می‌رویم که تیمهای ناآماده و آموزش ندیده، حتی بدون اینکه بدانند، مرتکب آنها می‌شوند. اشتباهاتی که می‌توانند پروژهها را نابود، تیمها را فرسوده و اعتبار سازمان را زیر سؤال ببرند.
اگر حتی یکی از این چالش‌هایی که در ادامه می‌گوییم در تیم شما وجود دارد، وقت آن رسیده که مدتی توقف کنید! بازنگری کنید و اسکرام را از نو و به‌درستی اجرا کنید.
اما ببینیم این 9 اشتباه چه هستند...
-
مرزبندی مبهم نقشها، تیمهای سردرگم!
یکی از اولین مشکلاتی که معمولاً تیمهای تازهکار اسکرام دچار آن می‌شوند این است که دقیقاً نمی‌دانند چه تیمی مسئول چه کاری است و چه تخصص و حوزه فعالیتی برای آن تیم تعریف شده است.
برای مثال، وقتی تیمهای مختلف مثل دولوپرها، تسترها، طراحان و مدیر محصول، مرز مسئولیت‌های یکدیگر را نمی‌شناسند، وظایف اشتباه تخصیص داده می‌شوند، ارتباطات مختل میشود و افراد بیش‌ازحد وارد فضای یکدیگر می‌شوند، و به‌طور کلی کار پیش نمی‌رود.
برای حل این مشکل باید بتوانیم...
مرز بین نقشها را شفاف کنیم. یکی از روش‌های ساده، برگزاری یک جلسه کوتاه تحت عنوان «نقشه مسئولیت‌ها» است که در آن هر نقش، محدوده کاری، خروجی‌های مورد انتظار و وابستگی‌های خود در ورک فلو را مشخص می‌کند. سپس باید این اطلاعات را در قالب یک سند یا جدول ساده، چیزی شبیه به RACI Matrix، ذخیره کرد تا همیشه در دسترس تیم باشد.
علاوه بر این، بهتر است این سند را در شروع هر پروژه یا شروع تغییرات ساختاری تیم به‌روزرسانی و مرور کنیم تا همه بدانند چه کسی مالک چه بخشی از کار است، ارتباطات هدفمند شود و انرژی تیم به‌جای تلف شدن در هماهنگی‌های فرسایشی، صرف ارائه ارزش واقعی به خود تیم و کاربر نهایی شود.
-
وقتی اعضای تیم فقط تماشاچی می‌شوند؛ نه بازیگر!
وقتی اعضای تیم در رویدادهای اسکرام شرکت نمی‌کنند یا صرفاً حضور دارند ولی مشارکت نمی‌کنند، کل ورک فلو تیم آسیب می‌بیند.
مثلاً جلسه برنامه ریزی اسپرینت که قرار است به یک برنامه دقیق و عملی برسد، به حدس و گمان تبدیل میشود؛ زیرا تنها چند نفر کارهای خود را به‌درستی تخمین می‌زنند و دیگران در جلسه چیزی نمی‌گویند و برای رفع تکلیف یک تخمین غیر واقعی می‌زنند یا مشکلات خود را بیان نمی‌کنند. نتیجه این میشود که افراد کارهایی را که تعهد کرده‌اند، در زمان اجرا برایشان غیرممکن به نظر می‌رسد و با ریسک‌های پنهانِ بسیاری روبه‌رو می‌شوند و کل برنامه‌ریزی جلسه پلنینگ زیر سؤال می‌رود.
جلسه رترو و دیلی نیز به همین شکل می‌توانند آسیب ببینند.
راه‌حل این است که...
ابتدا دلیل به وجود آمدن این رویدادها را برای تیم‌مان روشن کنیم و نشان دهیم که چگونه قرار است از ایجاد آشفتگی در طول اسپرینت جلوگیری کنند. سپس جلسات را کوتاه، متمرکز و مرتبط با موضوع اصلی خود نگه داریم تا ارزشمند باقی بمانند، نه اجباری و کم فایده.
حتی می‌توانیم برای افزایش تعامل و مشارکت افراد از ابزارها و بوردهای آنلاین مانند Easy Retro استفاده کنیم.
در نهایت، این انتظار را ایجاد کنیم که مشارکت اختیاری نیست؛ چراکه اصول اسکرام بر پایه تعاملات انسانی بنا شده است و اگر ما بتوانیم روی این تعاملات تمرکز کنیم به‌مراتب نتایج بهتری از جلسات می‌گیریم.
-
تخمین‌های اشتباهی که پروژه را به لبه پرتگاه می‌برند
اگر دست روی دل اسکرام مسترها یا مدیران محصول بگذاری، حتماً یکی از اصلی‌ترین مشکلاتی که به شما خواهند گفت، تخمین‌های غیر دقیق تیم‌شان برای تسک‌هاست.
وقتی فقط به «زمان» فکر می‌کنیم، نتیجهاش تعهدات غیر عملی، افزایش بدهی فنی و افت پیش‌بینی‌پذیری تیم است. واقعیت این است که تخمین سه مفهوم دارد:
-
Effort: افورت یعنی این تسک چقدر تلاش و زحمت از فرد می‌طلبد.
-
Complexity: پیچیدگی، میزان سختی و ریسک کار برای انجام توسط توسعه‌دهنده است. برای اندازه‌گیری از استوری پوینت یا سایز تی‌شرت یا حتی روش‌های خلاقانه‌ای مثل میوه‌ها استفاده میشود.
-
Time: مدت انجام کار؛ بیشتر برای وظایف شفاف مثل تولید محتوا مناسب است، نه اسکرام که ابهام در آن بالاست.
به این منظور بهتر است...
برای تیمهای تازهکار، مدل Cone of Uncertainty کمک می‌کند افراد بازه‌های تخمین را دقیقتر کنند. همچنین مدیر محصول یا اسکرام مستر باید فرهنگی ایجاد کند که در آن تخمین‌های واقع‌بینانه و صحیح‌تر، ارزش بیشتری نسبت به سرعت انجام کار داشته داشته باشند.
-
وقتی «انجام شدن» برای هر کسی یک معنی متفاوت دارد!
بدا به حال تیمی که تعریف مشخص و مستندی برای Definition of Done و Definition of Ready ندارد و سردرگمی و ناهماهنگی زیادی در برنامه‌ریزی، اجرای کار و بازبینی‌هایش ایجاد میشود.
بدون یک DoR شفاف، درست است که یوزر استوری‌ها وارد بک لاگ اسپرینت می‌شوند؛ اما جزئیات لازم، معیارهای پذیرشِ واضح، یا وابستگی‌های حل نشده‌ای دارند که باعث میشود در وسط اسپرینت زمان زیادی صرف روشن کردن این نیازمندی‌ها شود.
به‌طور مشابه، بدون یک DoD محکم و شفاف، اعضای تیم برداشتهای متفاوتی از کامل شدن یک تسک دارند؛ برخی از دولوپرها ممکن است فقط نوشتن کد را کافی بدانند، در حالی که دیگران انتظار تست کامل، مستندسازی و آماده‌سازی برای استقرار را دارند.
این ابهامات باعث میشود کارهای ناتمام وارد بازبینی اسپرینت شوند، دوباره‌کاری‌ها بیشتر شود، استانداردهای کیفیت رعایت نشوند و ذی‌نفعان از این قضیه ناراضی شوند که خروجی‌ها ناقص یا با کیفیت پایین تحویل داده می‌شوند.
همچنین این موضوع توانایی تیم در اندازه‌گیری دقیق ولاسیتی و بهبود از طریق رتروسپکتیوها را کم می‌کند، چرا که معیار «انجام‌شدگی» از اسپرینت به اسپرینت متفاوت است.
در اینجا تیم باید...
به صورت مشارکتی هر دو تعریف DoR و DoD را تدوین و مستندسازی کند و به‌طور منظم آن را مرور کند. به این ترتیب، یوزر استوری‌ها با کیفیتی یکنواخت کامل می‌شوند، کیفیت کار حفظ میشود، دوبارهکاری کم میشود و پیش‌بینی‌پذیری بهبود می‌یابد.
-
اسکوپ اسپرینت، لیست آرزوها نیست که هر لحظه تغییرش دهیم!
اغلب تیمها به این دام می‌افتند:
با پذیرش درخواست‌های جدید در میانه اسپرینت یا اضافه کردن کارهای برنامه‌ریزی‌نشده از قلمرو / Scope اصلی اسپرینت خارج می‌شوند.
این اتفاق متداول زمانی رخ میدهد که یا تیم درک روشنی از اهداف اسپرینت ندارد یا تحت فشار قرار می‌گیرد تا نیازهای فوری ذی‌نفعان را برآورده کند. نتیجه این میشود که تمرکز تیم به سمت کارهای اضافی می‌رود و آیتم‌های اصلی بک لاگ ناتمام باقی می‌مانند.
در این حالت که تعهدات تیم به‌درستی انجام نمی‌شوند، مالک محصول توانایی پیش‌بینی‌پذیری و در نتیجه اعتماد ذی‌نفعان به خود را از دست میدهد. به مرور زمان، این الگو منجر به فرسودگی تیم میشود، چون به‌جای «تحویل تدریجی ارزش واقعی»، دائماً به دنبال کارهای «فوری» هستند.
برای برطرف کردن این مسئله باید...
اهمیت تعهدات و شفافیت اهداف اسپرینت را برای تیم روشن کنیم. هرگونه درخواست جدید باید از طریق مالک یا مدیر محصول بررسی شود و برای اسپرینت بعدی ارزیابی شود؛ نه اینکه در طول اسپرینت و بدون هماهنگی اضافه شود.
با محافظت از اسکوپ اسپرینت و «نه گفتن» به کارهای برنامه‌ریزی‌نشده، تمرکز تیم خود را حفظ کنید، ضریب اطمینان خروجی‌ها را افزایش دهید و دقیقاً همان چیزی را تحویل دهید که از قبل متعهد شده‌اید.
-
QC گلوگاه شده؟ نگذارید تسترها زیر بار له شوند!
گاهی پیش می‌آید که تیم کنترل کیفیت / QC Team به گلوگاهی در فرایند توسعه محصول تبدیل می‌شوند. وقتی فقط تعداد کمی از اعضای تیم مسئول تمام تست‌ها و بازبینی کدها هستند، کارهای آنها در حالت «در انتظار بررسی» انباشته می‌شوند. این فشار تأخیرهایی ایجاد می‌کند، زیرا دولوپرها باید مدت بیشتری منتظر بازخورد یا تأییدیه تیم تست باشند تا بتوانند ادامه دهند.
نقش‌های کلیدی تضمین کیفیت و کنترل کیفیت بار زیادی بر دوش دارند و کند شدن فعالیت آنها منجر به کند شدن چرخه‌های بازخورد میشود و فشار کار در زمان‌های نزدیک به اسپرینت افزایش می‌یابد، بازبینی‌ها عجولانه می‌شوند و عیوب افزایش می‌یابند. در نتیجه کیفیت کلی محصول و روحیه تیم آسیب می‌بیند.
در اینجا باید...
با آموزش به همه اعضای تیم، توسعه‌دهندگان را تشویق به انجام روش‌هایی مانند Shift-Left Testing و بازبینی همتایان / Peer Review کنیم و افراد را در فرایندهای تضمین و کنترل کیفیت مشارکت داد. علاوه بر این، راه‌اندازی روش‌های تست خودکار، بار را از روی دوش تسترهای QC کم می‌کند و سیکل بازخوردگیری را سرعت می‌بخشد و جریان کار را پایدار نگه می‌دارد.
-
وقتی همه مسئول‌اند، هیچ‌کس مسئول نیست!
وای بر تیم‌هایی که کارها در آن مالکیت مشخصی ندارند. این تیمها پر از سردرگمی، دوبارهکاری و انجام ناقص کارها هستند. درست است که در جلسات، بسیاری از کارها تعریف و اولویت‌بندی می‌شوند، اما وقتی دقیقاً مشخص نباشد مسئول یک کار کیست، به جرأت می‌گویم هیچ‌کس مسئول آن نیست و آن کار هیچ‌وقت توسط هیچ‌کس انجام نمی‌شود.
اما چه کنیم؟
مدیر فنی و اسکرام مستر باید ذهنیتی در تیم ایجاد کنند تا افراد خودشان داوطلبانه مالکیت کارها را بردارند و به کمک یکدیگر مشخص کنند که هر بخش از کار را چه فردی انجام دهد و پاسخگو باشد.
با این کار می‌خواهیم پاسخگویی افراد را افزایش دهیم، ابهامات را کاهش دهیم و به تیم کمک کنیم تعهدات خود را با اطمینان بیشتری انجام دهد.
-
تیمی که منتظر دستور است، بالغ و اجایل نیست!
خودسازماندهیِ یک تیم، نشانه بلوغ آن است. وقتی اعضای تیم بیش‌ازحد به مدیران یا اسکرام مستر برای هدایت خود در تعیین تسکها و تصمیم‌گیری‌ها وابسته باشند، چابکی تیم کاهش یافته و سرعت کار کند میشود.
واضح است که در این حالت ابتکار عمل و توانایی حل مسئله در تیم افت می‌کند، همکاری تیمی تضعیف شده، انگیزه‌ها فروکش کرده و مانع از آن میشود که تیم سریعاً خود را با تغییرات و نیازمندی‌های جدید وفق دهد. نتیجه این امر چیزی جز کاهش بهره‌وری و ضعف در تحویل ارزش واقعی نخواهد بود.
پس بهتر است...
برای تقویت توان خودسازماندهی یا Self-organizing تیم، اعضا را تشویق کنیم مالکیت کارهایشان را بر عهده بگیرند و به آنها قدرت تصمیم‌گیری و همکاری آزاد بدهیم. اسکرام مستر باید نقش تسهیلگر و مربی را ایفا کند، نه مدیر یا رئیس؛ تا مهارت‌های حل مسئله تیم بالا رود. آموزش اصول اجایل و ایجاد محیطی امن برای تست و یادگیری نیز می‌تواند توانایی تیم در خودسازماندهی و تحویل مؤثر را تقویت کند.
-
تعارضات شخصی، قاتلان خاموش بهره‌وری تیمی
و در نهایت، تعارضات بین فردی یکی از چالشی‌ترین مشکلات تمام تیمهای دنیاست؛ نه فقط تیمهای اسکرام. ادامه‌دار بودن تعارضات، همکاری را به‌طور کامل مختل کرده و روند پیشرفت را متوقف می‌کند. این تعارضات معمولاً ناشی از عدم برقراری ارتباط صحیح اعضا، سوءتفاهم درباره نقشها، فشارهای ناشی از ددلاین‌ها و تفاوت‌های شخصیتی است.
تمام آن 8 مشکلی که بالاتر گفتیم می‌توانند عامل و جرقه‌ای برای ایجاد تعارضات تیمی و شخصی باشند.
این دست از مسائل باید به‌موقع حل شوند، در غیر این صورت می‌توانند به اعتماد تیم لطمه بزنند و روحیه تیم را به‌شدت تخریب کنند.
باید به تیمهای خود کمک کنیم...
ارتباطی باز و محترمانه داشته باشند و فضایی ایجاد کنیم که همه اعضا احساس امنیت کرده و نگرانی‌های خود را بیان کنند.
تعریف واضح نقشها و تعیین حیطه مسئولیت‌ها نیز که قبلاً به آن اشاره کردیم، به کاهش ابهامات کمک شایانی می‌کند.
جلسات اسکرام مانند رترو، فرصت بسیار خوبی برای مطرح کردن و رفع تعارضات تیم است. به شرطی که اسکرام مسترها به‌شکلی بی‌طرف و بهعنوان تسهیلگر نقش ایفا کنند و تیم را در مسیر حل تعارضات هدایت کنند.
در انتها باید بگوییم...
حال که با 9 چالش واقعی تیمهای اسکرام تازهکار و ناآماده آشنا شدید، وقت آن است که یا تیم‌تان را تجهیز کنید… یا آماده هزینه‌های پنهان، شکست‌های تدریجی و فرسایش بی‌صدای تیم خود شوید.
اجایل فقط با واژه‌ها یا ابزارها اتفاق نمی‌افتد؛ با ایونت‌ها و تابلوی تسکها نیز معنا پیدا نمیکند. در اسکرام تیمی موفق است که آموزش ببیند، تمرین کند و اشتباهاتش را بی‌رحمانه بپذیرد و اصلاح کند.
پس اگر حتی تعدادی از این چالش‌ها در تیم شما وجود دارد، امروز زمان تصمیم‌گیری است:
-
آیا تیم‌تان را به اسکرام واقعی مجهز می‌کنید؟
-
یا اجازه می‌دهید زیر لبخندهای مصنوعی و اسپرینت‌های ناموفق، شکست بخورد؟
انتخاب با شماست. اما موفقیت، همیشه با تیم‌هایی‌ست که زودتر چشم باز میکنند و دست به عمل می‌زنند…
|
«در اجیلیتی، آموزش Scrum با محتوایی ساده و کاربردی ارائه میشود. تمرکز ما بر چالشهای رایج تیمهای ایرانی و نحوه مواجهه با آن‌هاست. اگر به دنبال پیاده‌سازی اسکرام هستید، این مسیر برای شماست.»
|