Наша версія Agile не працює. Поради?

Я працюю над невеликою командою з 4 розробників. Ми впроваджуємо версію Agile, яка, здається, постійно надає нам однакові труднощі тиждень за тижнем, і я шукаю пропозиції, які можуть допомогти нам покращити наш процес.

Фон:

Ми, як правило, робимо 2-тижневі спринти, і кожен спринт ми, як правило, недооцінюємо свою роботу, і ми потрапляємо у проблеми з нашим менеджером, тому що ми відстаємо від графіку.

Ми починаємо кожен спринт, задаючи розповіді, які нам створює наш менеджер. Іноді він також кидає завдання і ми їх оцінюємо. Ми не використовуємо сюжетні точки. Ми використовуємо програмне забезпечення Urban Turtle для "управління нашими спринтами", які по суті є лише історіями та завданнями та пов'язаними з цим згоряннями. Ми не плануємо випуск в кінці спринту.

Найпоширеніша проблема, яка виникає, полягає в тому, що ми плануємо завдання на початку спринту тільки для того, щоб виявити, що він значно більший за обсягом, але все ще високий за пріоритетом, тому нам потрібно працювати додаткові години. Друге найпоширеніше питання полягає в тому, що хтось із нас стикається з технічною проблемою, яка сповільнює спалені години, викликаючи блокпост.

Єдина пропозиція, яка нам надається, - бути більш ініціативною у коригуванні наших оцінок та наданні оновлень під час резервної роботи вранці, щоб ми могли коригувати додатковий час, необхідний.

Однак, мабуть, щось принципово не так у тому, як ми робимо справи. Можливо, існує розрив між очікуванням менеджера на рівні проекту та очікуваннями на рівні спринту. Оскільки ми робимо ці спринтні ітерації відповідно до плану проекту, і тому розширюємо спринт або відкладаємо елементи, накручуємо план проекту. Тому нас, як розробників, рекомендують виконувати Agile, розширюючи оцінки за необхідності, а також завершуючи спринт вчасно, що заплутано.

Це не може бути рідкісною проблемою, тому я сподіваюся, що у тих розумніших, ніж я там, є пропозиція чи два, як ми можемо перестати стикатися з цією самою проблемою кожен спринт. Це засмучує.

тому що ми поза графіком

Цей тип мислення - ваша проблема. Ви не за графіком, графік занадто щільний. Ви повинні почати оцінювати розповіді в абстрактних точках, а не по годинах, а потім протягом 2-3 ітерацій визначити свою швидкість. Ваша швидкість полягає в тому, скільки балів ви зазвичай робите за кожну ітерацію, а не скільки балів, які ваш менеджер хоче вмістити.

Після цього не має значення, чи послідовно ви недооцінюєте завдання - ваша швидкість вже пояснюється цим.

Очевидно, що це неможливо, якщо ви використовуєте години замість балів.

Схоже, проблеми полягають у нездатності вашої команди робити точні оцінки та неможливості передбачити проблеми, які виникають у неминучості.

Невеликі завдання набагато простіше оцінити точно, ніж великі завдання, тому спробуйте розбити свої завдання на набагато менші шматки.

Не дозволяйте нікому оцінювати будь-яке завдання, якщо тільки вони точно не знають, як вони це будуть робити. Для будь-якого завдання, яке розробник не знає, що потрібно виконати, введіть деякий час у цей графік спринту для розробника, щоб провести певні дослідження та розробки, і придумайте точну оцінку. Ніколи менше ніж півдня. Але перенесіть завдання на наступний спринт. Тоді, коли ви прийдете до планування наступного спринту, ви матимете хорошу оцінку. Зауважте, що цей додатковий час не витрачається даремно, оскільки пора розробника в будь-якому випадку закінчувати витрати.

І не бійтеся повернутися до менеджера проекту і сказати йому, що вам потрібно більше спринтів, щоб пройти список завдань. Краще це зробити, ніж прихилити себе до неможливих цілей.

Ви намагаєтесь виділити 100% свого часу? Якщо так, то припиніть це робити. Почніть з додавання всіх годин, котрі ваша команда повинна робити свій внесок у спринт. Зробіть це, припускаючи, що кожен працівник в кращому випадку приділяє 6 годин на день до проекту. Це вважається "ідеальним днем". Ті інші дві години? Перевантажений зустрічами, перервами, адміністративними завданнями, вранці, коли ви читаєте електронну пошту і плануєте свій день і т. Д. Це не "хеджування ваших ставок" або "мішковини", це реалістично.

По-друге, помножте ці 6 годин на день на 80% . Чому? Тому що ми, як люди, смокче передбачити, скільки часу займе завдання. Це пояснює помилки в нашому судження. Знову ж таки, не пісок, це реалістично.

Тепер у вас є число, яке представляє реалістичну кількість годин, які ви очікуєте застосовувати безпосередньо для своїх завдань. Коли ви оцінюєте, перестаньте додавати розповіді, коли наступна історія поставить вас над собою.

Нарешті, не дозволяйте власнику продукту додавати завдання. Планування Scrum - це команда , PO не є частиною команди, яка виконує роботу. Звичайно, в реальному світі, якщо спеціаліст з питань обізнаності є більш обізнаним, ніж хтось із команди, її внесок може бути дуже корисним. І все-таки, якщо команда забирає жар за відставання, команді потрібно взяти на себе відповідальність, які саме завдання вони будуть виконувати. Ваша мета - вміти відповідати критеріям прийняття; якщо завдання не веде безпосередньо до цього, не робіть цього.

Пам'ятайте, Scrum не в тому, щоб бути більш продуктивним. Йдеться про те, щоб бути більш відкритим та комунікативним. Робота займе все, що потрібно для її завершення. Scrum є, щоб зробити його легше оцінювати, легше спілкуватися із зацікавленими сторонами та легше взяти на себе зобов’язання.

Критерії прийняття погано визначені на початку спринту?

Початкові оцінки часто є занадто низькими, оскільки сюжетні картки мають погані критерії прийняття (якщо такі є) при їх оцінці. А як щодо переходу на розробку, що керується прийняттям тестів (ATDD), також розповідь про те, щоб допомогти команді зрозуміти, що таке картка?

Історії занадто великі?

Ще одна причина, коли ви дізнаєтесь, що серед середини спринту, що ваші історії тривають довше, ніж очікувалося, може бути те, що вони занадто великі. Ви бачили Agile у колоді Flashcard? У них є флеш-карта під назвою "Зменшити історії XL, щоб підходити". Він дає стратегію для розбиття історій, таких як відстрочка крайових випадків, побічні ефекти, нефункціональні аспекти або поводження з помилками для пізніших історій.

Не можете оцінити, оскільки у вас недостатньо інформації?

@sleske робить гарну пропозицію щодо шипів . Спробуйте виявити технічні невідомі під час оцінки. Якщо є якесь - або, якщо ви можете відкласти цю історію в більш пізній спринт і замість того, щоб зробити тайм-штучного розслідування (шип) , це спринт , щоб спробувати дізнатися , що потрібно , щоб мати можливість оцінити. Не захоплюйтесь і розв'язуйте оригінальну історію - шип робиться, коли ви знаєте достатньо, щоб оцінити історію.

Збій швидше

І я погоджуюся з @Patrick Hughes - подумайте про перехід до спринтів на 1 тиждень, щоб швидше побачити проблеми.

Окрім гарних пропозицій від @Kevin та @Patrick ...

Agile підходи не "один розмір підходить усім", але цей коментар привернув мою увагу:

Ми реалізуємо версію Agile, яка, здається, постійно надає нам однакові труднощі

Вам краще почати з методології "за книгою" (Scrum є домінуючою в наші дні) - і робіть ТОЧНО те, що зробила якась інша успішна команда ... Зробіть це для декількох спринтів ... І тільки потім починайте розглядати зміни, необхідні для оптимізації місцевих умов.

Оренда досвідченого тренера Scrum (на кілька повторень) може стати справжньою різницею. Існує тонкість у спритності права.

Спочатку я рекомендую слідувати книзі scrum-xp-from-the-trenches . Подивіться на сторінці 26 пункт про обчислення швидкості. Ідея полягає у тому, щоб визначити фокус-фактор і сказати, що для наступного спринту:

доступні людино-дні * фактор фокусування = розрахункова швидкість

Оцінка швидкості - це сума оцінок історій, які ви плануєте втілити під час наступного спринту.

І після одного спринту ви обчислюєте тривалість фактора фокусу спринту як:

фактор фокусування = фактична швидкість / доступні людино-дні

де фактична швидкість - це сума оцінок оповідань, які ви реалізували під час спринту.

Потім ви повторно використовуєте цей фактичний фактор фокусування для наступного спринту, і через кілька спринтів ви зможете бути більш точними, скільки ви дійсно можете досягти під час спринту ...

Поки ви не отримаєте ваші оцінки, щоб скоротити спринти до одного тижня, таким чином ви швидше розпізнаєте надмір і зможете реагувати меншими кроками.

Витратьте більше часу наперед, розробляючи завдання, щоб отримати деяку дихальну кімнату для розпізнавання побічних ефектів, які, ймовірно, викликають кровотечу. Можливо також, що самі завдання занадто довгі для належної гнучкої оцінки, дивіться, чи можна розбити завдання на більш короткі кроки, які буде простіше ковтати.

Дозвольте всім комфортно відправляти червоний прапор, як тільки вони потрапляють на корч, а не застрягають у проблемі на кілька годин. Спробуйте відмежувати его та звинувачувати цей процес, для деяких це легше, ніж інші =)

І як @Kevin виховується, ви ніколи насправді не плануєте 100% безпосередньо на завдання, тому що завжди є накладні витрати, як зустрічі і так далі, яких ви не можете визнати любителями часу.

Коли на фронті планування все буде круто, а потім повернетесь на два тижні, ви магічно забираєте трохи часу з меншої кількості зустрічей.