اسپرینت ها جایگاه مقدسی در چابک دارند و اغلب به عنوان ابزاری برای کارآمد کردن تیم های مهندسی مورد استفاده قرار می گیرند. این رویدادهای بسته‌بندی زمانی دو هفته‌ای، فهرست خواسته‌های محصول شما را به وظایف عملی تبدیل می‌کند، طوفان فکری را به نتایج ملموس تبدیل می‌کند، و حتی فرهنگ نقد و بررسی‌ها را ایجاد می‌کند.
اسپرینت ها فقط تحویل پروژه ها را تسریع نمی کنند، بلکه حتی فرهنگ مسئولیت پذیری را به خصوص در تیم های توزیع شده جغرافیایی ایجاد می کنند. در حالی که اسپرینت ها همیشه راهی مطمئن برای مدیریت سریع پروژه بوده اند، اما اگر به درستی انجام نشوند، می توانند عدم تعادل در فرآیند ایجاد کنند.
اسپرینت ها هرگز ما را شکست نمی دهند، ما در دوی سرعت شکست می خوریم.
اجرای یک اسپرینت جدید مانند اجرای یک پروژه است و در عین حال فضایی برای پیشرفت ایجاد می کند. از آنجایی که دوی سرعت رویدادهای کوتاه مدتی هستند، تیم ها اغلب در تشخیص اینکه چه زمانی یک سرعت از مسیر اهداف اولیه پذیرفته شده خود خارج می شود، تلاش می کنند. خوشبختانه، چندین شاخص کلیدی وجود دارد که می تواند زمانی که برنامه ریزی اسپرینت با شکست مواجه می شود، علامت دهد.
1. کارهای برنامه ریزی نشده بیشتر در طول اسپرینت
در یک دنیای عالی، دوی سرعت باید همه چیز را در مورد کار خود برنامه ریزی کنید و برنامه خود را انجام دهید. اما توسعه محصول یک فرآیند پیوسته است که شامل تکرارهای متعدد و وابستگی های خارجی بسیار زیادی است. کار برنامه ریزی نشده در یک سرعت اجتناب ناپذیر است و اکثر تیم ها حتی بخشی از زمان غیر اصلی خود را برای کارهای برنامه ریزی نشده رزرو می کنند. با این حال، اگر تیم ها بیش از 10 درصد از زمان موثر کدنویسی خود را با کارهای برنامه ریزی نشده صرف کنند. این یک عنصر عالی برای یک اسپرینت ناموفق است.
کار برنامه‌ریزی نشده هر چیزی است که مانع از انجام کار واقعی توسط برنامه‌نویس می‌شود- از روشن نگه داشتن چراغ‌ها تا گیرکردن به دلیل ساختار پوسته‌دار. به یاد دارید زمانی که مجبور شدید کد خود را متوقف کنید، زیرا یک وصله کد بازنویسی نشد و ناموفق بود؟ کاری که برنامه ریزی نشده انجام می دهد. این باعث می‌شود دائماً برنامه‌نویس آتش‌بازی کند، حتی حواس آنها را از کارهای واقعی اسپرینت منحرف می‌کند.
کارهای بدون برنامه ریزی بالا اولین و مهمترین ضدالگوی سرعت فعلی شماست.
اگر تیم به درستی سطح تلاش مورد نیاز برای کار برنامه ریزی شده را تخمین نزند یا مسائل بالقوه ای را که ممکن است پیش بیاید در نظر نگیرد، می تواند منجر به افزایش کارهای برنامه ریزی نشده شود. به‌علاوه، می‌تواند بهره‌وری توسعه‌دهنده و روحیه تیم را نیز به خطر بیندازد زیرا کار اضافی می‌تواند در مسیر اهداف از پیش تصمیم‌گیری‌شده اسپرینت قرار گیرد.
چگونه به کارهای ناخواسته رسیدگی کنیم؟
حقیقت این است که کار برنامه ریزی نشده باقی مانده است و نمی توان آن را به طور کامل حذف کرد. اما چند کار وجود دارد که می‌توانیم برای محدود کردن غافلگیری‌ها و عدم ردیابی کار سرعتی شما و غلبه بر تعداد معوقه‌های سرعت شما انجام دهیم.
داده‌ها یکی از پاسخ‌ها به چالش کار برنامه‌ریزی نشده برای تیم‌های مهندسی است. در یکپارچهسازی سرعت بعدی خود، یک بحث ۱۵ دقیقه‌ای برای بحث در مورد سهم کار برنامه‌ریزی نشده در مقابل نکات داستانی برنامه‌ریزی‌شده صرف کنید. به این ترتیب، تیم‌ها می‌توانند در ساعاتی از خلأ برای کارهای برنامه‌ریزی نشده در اسپرینت آتی فشار بیاورند.
اسناد خوب بسیاری از چالش های تحویل را برای تیم های مهندسی حل می کند. و یکی از آنها کار بدون برنامه است. منابع پشتیبانی، هرگونه اطلاعات دروازه‌بانی، پشتیبانی آموزشی، یا زمینه‌های بیشتر در یک خرابی ساخت، کمک زیادی به کاهش برخی از کارهای برنامه‌ریزی نشده دارد.
2. اشکالات در مقابل داستان در مقابل مسائل
اطمینان از همسویی کار به اندازه اطمینان از همسویی تیم از طریق اهداف اسپرینت مهم است. ترکیبی سالم از اشکالات، داستان‌ها و گزارش مشکلات برای هر توسعه‌دهنده در هر سرعت می‌تواند به دستیابی به آن کمک کند.
خستگی اشکال واقعی است. زمانی اتفاق می‌افتد که یک توسعه‌دهنده بیش از حد وقت خود را صرف اشکال‌زدایی کند، به جای ارائه یک نقطه داستان. اشکالات اجتناب ناپذیر هستند، درست مانند کارهای برنامه ریزی نشده. اما، اگر یک توسعه‌دهنده زمان زیادی را صرف می‌کند، حتی بیش از 20٪ از کل زمان اسپرینت خود را برای حل مشکلات کد صرف می‌کند – این موضوعی است که تیم‌های پرچم قرمز بعدی باید مراقب آن باشند.
اختصاص منابع بیش از حد به اشکالات، گاهی اوقات به قیمت از دست دادن ویژگی های پر ارزش تمام می شود. علاوه بر این، اگر تیمی بیش از حد اشکالات را در اولویت قرار دهد، در آستانه همکاری مختل شده و سرعت اسپرینت پایین است. این معمولا زمانی اتفاق می افتد که تیم ها به درستی پیچیدگی کار را برآورد نکرده باشند.
چگونه خستگی باگ را به حداقل برسانیم؟
راه حل سریع این است که برای هر اشکالی که بخشی از سرعت واقعی شما نیست، یک نقطه داستان جداگانه ایجاد کنید. با این حال، ایجاد نقاط داستانی جدید نمی تواند مشکل واقعی اشکالات نامتناسب را در سرعت شما حل کند.
حالا بیایید در مورد راه پایدارتر صحبت کنیم.
از یک ابزار تجزیه و تحلیل مهندسی برای تجسم خرابی مشکل اسپرینت خود استفاده کنید. بخش‌های اولویت‌دار را برای همه انواع مشکلات ایجاد کنید – اشکالات، نقاط داستان، حتی اتفاقات. سعی کنید هر مشکلی که ممکن است تیم مهندسی شما با آن مواجه شود را مستند کنید. در طول جلسه برنامه ریزی، این موضوعات را از نظر اولویت فیلتر کنید.
3. سلامت تیم رو به کاهش
رضایت توسعه‌دهنده همواره با اثربخشی اسپرینت متناسب است، با این حال اکثر مدیران در پیوند دادن زحمت توسعه‌دهنده با شکست‌های اسپرینت شکست می‌خورند. اکثر تیم‌های مهندسی از رویکرد «توسعه‌دهندگان با عملکرد بهتر کار می‌کنند» استفاده می‌کنند. این یک دستور العمل عالی برای دوی سرعت ضعیف و حتی ناموفق است.
EMها بهتر از هرکسی برنامه‌نویس‌های خود را می‌شناسند- توانایی‌ها، کاستی‌ها و در چه شرایطی از آنها پیشی می‌گیرد. تخصیص وظایف به توسعه دهندگان فراتر از ظرفیت کاری آنها می تواند توانایی تیم را در ارائه خدمات از بین ببرد.
اکثر توسعه دهندگان درونگراها را کنار می گذارند، و در واقع برای آنها سخت است که هر بار که بیش از حد فشار می آورند، صحبت کنند. برآورد بیش از حد پهنای باند حجم کار می تواند باعث شود که توسعه دهندگان خیلی زود دچار فرسودگی شوند، حتی آنها را به ترک یا تولید کار غیرمولد سوق دهد.
چگونه از بهره وری توسعه دهندگان اطمینان حاصل کنیم؟
در اینجا، مسئولیت باید بر عهده مدیران مهندسی باشد تا ترکیبی سالم از مسائل برای هر توسعه دهنده ایجاد کنند. اگر یک برنامه‌نویس در روزهای ابتدایی اسپرینت بیش از حد توسط هشدار حادثه صفحه‌بندی شود، مدیران می‌توانند برخی از چراغ‌های خود را به موقع قطع کنند و توسعه‌دهندگان را به سمت انتشار ویژگی سوق دهند.
گاهی اوقات، حتی تخصیص زمان سستی برای توسعه دهندگان نیز می تواند به آنها کمک کند تا در اسپرینت آتی تجدید قوا کنند و دوباره پیشرفت کنند.
4. پرش از بازنگری های اسپرینت
ایده اجرای یکپارچهسازی با سرعت دویدن این است که در کنار چالش‌ها و مسدودکننده‌ها، مستندسازی کنیم که چه چیزی در این اسپرینت مؤثر بوده و چه چیزی مؤثر نبوده است. یک جلسه گذشته نگر دوی سرعت مکانی ایده آل برای تیم ها برای بحث درباره بازخورد و جمع آوری لیستی از پیشرفت های عملی است، و در عین حال اکثر اعضای تیم عمدا از آنها صرف نظر می کنند.
اکثر توسعه دهندگان از یکپارچهسازی با سیستمعامل متنفرند. از نظر آنها، گذشته نگرها یکنواخت هستند، فاقد داده هایی برای پشتوانه نتایج اسپرینت هستند، یا حتی تغییر واقعی را در سرعت های بعدی ایجاد می کنند. گاهی اوقات، این یکپارچه‌سازی‌ها به صورت نیمه تمام انجام می‌شوند، در موارد دیگر، عدم مشاهده عملکرد اسپرینت مانع از اجرای یکپارچهسازی با سرعت عملی می‌شود. اگر مرورهای گذشته به طور مداوم و بدون هیچ نتیجه مشخصی انجام شوند، ممکن است به اتلاف وقت تبدیل شوند و کارایی خود را از دست بدهند.
چگونه رتروهای اسپرینت موثر انجام دهیم؟
به گذشته نگر اسکرام به عنوان فرصتی برای تیم های مهندسی فکر کنید تا در مورد عملکرد خود فکر کنند. تجزیه و تحلیل کار می تواند دید را در روندهای سرعت افزایش دهد، بنابراین تیم ها درک واقعی از همه چیزهایی که در این اسپرینت کارآمد/نباید داشته باشند، داشته باشند.
با بینش‌های مبتنی بر داده، تیم‌ها می‌توانند به راحتی چالش‌های اسپرینت را حل کنند و حتی دلایل اصلی مسدودکننده‌ها را شناسایی کنند. این داده ها بحث های سازنده را برای یافتن راه حل های بلندمدت تشویق می کند. به عنوان مثال، اگر تیم‌ها متوجه شوند که به دلیل زمان چرخه زیاد، ویژگی‌های کمتری را منتشر کرده‌اند، می‌توانند عمیق‌تر در مورد آنچه باعث افزایش ناگهانی شده است، آن را قبل از جلسه برنامه‌ریزی اسپرینت بعدی حل کنند.
نتیجه
اندی هیلز وقتی هر دوی سرعت را یک آزمایش نامید تا ببیند آیا ما به مشکلی که می‌خواهیم حل کنیم پاسخ می‌دهیم بسیار منطقی بود؟ انجام صحیح دوی سرعت اولین گام به سوی تحویل پروژه های موفق و توسعه محصول استثنایی است.
کل تیم خود را در این فرآیند ثبت نام کنید، از برنامه‌ریزی گرفته تا پارازیت‌های اواسط اسپرینت و نسخه‌های قدیمی. اهداف قابل اندازه گیری و قابل دستیابی را تعیین کنید، زمان بافر کافی را اختصاص دهید، و بر روی داده ها تمرکز کنید تا بینش هایی را که می تواند روش تیم ها را در اجرای اسپرینت ها تغییر دهد.
یک اسپرینت سالم یک برد-برد برای همه در چرخه تجاری است: از مشتریان گرفته تا CTO، مدیران عامل، مدیران مهندسی و مشارکت کنندگان فردی.
از اثربخشی سرعت با Hatica اطمینان حاصل کنید! امروز در وبلاگ Hatica مشترک شوید تا درباره رفع انسداد توسعه دهندگان و افزایش بهره وری با تجزیه و تحلیل مهندسی اطلاعات بیشتری کسب کنید.
