Agile Потік доставки: Завжди доставляйте вчасно у 3 етапи

Запитуючи більшість менеджерів про “психологічну безпеку” або “бачення” (докладніше про це: Психологічна безпека ) їхніх гнучких команд розробки програмного забезпечення, вони погоджуються, що ці речі важливі, але… Коли клієнт сигналізує про терміновість або наближається кінцевий термін, усі ці “м’якіші” змінні зазвичай відкладаються. Менеджери найбільше дбають про передбачуваний та функціонуючий потік гнучкої доставки їхньої гнучкої команди.

Якщо ви заглянете в наш блог Echometer ( до нашого блогу ) ви знаєте, що наш контент більше зосереджений на вдосконаленні “м’яких навичок” команд та організацій. Вони часто недооцінюються особами, які приймають рішення. Але не Scrum-майстрами та Agile-коучами.

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

Перший крок по відношенню до вашого потоку поставок Agile

Я говорю про моніторинг потоку доставки Agile ваших завдань. Якщо ви зробите лише кілька речей правильно, ви зможете досягти набагато більш передбачуваних результатів. Навіть ваші графіки розкиду часу циклу або симуляція Монте-Карло для розрахунку кошторису проекту можуть нарешті показати правильні прогнози, замість того, щоб повністю відхилятися від мети (читати далі: 9 Agile Показники для тих, хто приймає рішення ).

Перший симптом, з яким потрібно боротися, - це те, що є завдання, які проходять шлях від “Заплановано” до “Завершено” всього за кілька днів, а є завдання, які тривають більше місяця. Щоб протидіяти цьому, ви повинні переконатися, що завдання завжди містить найменшу можливу версію бажаної функції. Без наворотів, які не є необхідними для основного запиту клієнта. По суті, це MVT, мінімально життєздатне завдання. Це не означає, що це робить кожне завдання маленьким. Але це має допомогти вам досягти стадії, коли завдання займатимуть максимум кілька тижнів, а не місяців.

Другий крок щодо вашого потоку доставки Agile: WIP замість швидкості

Багато Scrum-майстрів або Kanban-коучів вважають, що для валідного вимірювання швидкості тощо важливим є “правильне визначення розміру” завдань або робочих елементів, коли всі робочі елементи мають приблизно однаковий розмір. Тільки тоді story points (які необхідні для вимірювання швидкості) корисні для вимірювання швидкості, оскільки вони більше схожі на порівнянну одиницю часу. 

Але це неправильно: завдання навіть не обов’язково повинні бути однакового розміру. Не варто так вважати, тому що контролювати оцінки Story Point просто занадто складно. Єдине, що ви можете контролювати - це кількість нових завдань, які ви починаєте.

Тож зробіть наступне, щоб стати передбачуваними: слідкуйте за темпом “ново розпочатих завдань” у порівнянні з темпом “завершених завдань”. Ці два показники повинні бути збалансованими. Іншими словами, “вхідний” та “вихідний” темп завдань повинні бути якомога ближчими, в ідеалі навіть збігатися.

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

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

Деякі “позитивні симптоми” здорового гнучкого потоку поставки Agile

На практиці це може призвести до наступної поведінки:

• • Ми не починаємо нові завдання, коли ще багато чого не зроблено. 

• • Ми зосереджуємося на тому, щоб завершити розпочате, перш ніж починати щось нове.

• • Вік завдань ніколи не перевищує кількох тижнів.

• • Якщо немає поважної причини, ми завжди працюємо над найстарішим завданням.

Ліміти WIP (work-in-progress) також допомагають у цьому, хоча їх часто буває недостатньо. Як тільки команда навчиться зосереджуватися на завершенні завдань, а не на тому, щоб просто починати нові, ви будете кращими за більшість команд.

Якщо ви правильно використовуєте Agile Delivery Flow

Створити чіткі очікування: Таким чином, ви все одно не можете контролювати, чи займе завдання два або три дні. Але принаймні ви будете впевнені, що ваша команда не працює над такою кількістю завдань, що 2-3-денні завдання в підсумку займають місяць.

Наскільки краще працювала б ваша команда, якби ви знали, що практично всі зобов’язання з постачання будуть виконані протягом декількох тижнів? Звісно, це за умови, що ви впроваджуєте всі вищезгадані речі: Встановлення MVT, суворого ліміту WIP та зобов’язання не перезапускати завдання, доки не буде завершено інше завдання.

Крок 3: Почніть працювати над покращенням процесу доставки Agile

В теорії ви знаєте, що робити. Як краще розпочати на практиці? Створивши усвідомлення та “готовність до змін” в команді. В найкращому випадку, через саморефлексію.

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

Я можу порекомендувати обговорити згадані мною моделі поведінки за допомогою нашого гнучкого інструменту ретроспективи Echometer у вашій ретроспективі (читати далі): 7 інструментів ретроспективи у порівнянні ). Ви навіть можете зробити це частиною ваших робочих угод або регулярних Health Checks, щоб підвищити обізнаність, регулярно ставлячи запитання.

Наступні питання - це наш шаблон ретроспективи для “гнучкої доставки” (докладніше про це: 22 веселі шаблони для гнучкої ретроспективи ). Ми починаємо з кількох тверджень Health Check і запитуємо команду, чи вони схильні погоджуватися або не погоджуватися з ними. Після цього ставимо кілька відкритих запитань:

Ретроспектива поставок Agile

Health Check Елементи

Коли наш спосіб роботи призводив до неоптимального робочого процесу? (наприклад, нечіткі, невідповідні або недотримані інструкції)

Як ви можете собі уявити, останній пункт перевірки працездатності (перевірка причини) вже передбачає потенційний захід, щось, що ви можете спробувати протягом одного-двох гнучких спринтів, щоб побачити, чи це може вам допомогти: обмеження кількості завдань зі статусом “Work in Progress”.

Закладаємо фундамент: Укладіть домовленості про командну роботу

У вас є відчуття, що ваша команда ще не готова до такого роду рефлексії? В такому випадку ви повинні спочатку поміркувати про “хорошу роботу” в цілому, а потім встановити деякі основні правила, так звані робочі угоди або Working Agreements. Наступний шаблон майстер-класу може допомогти вам в цьому. Ви можете використовувати його як особливу форму ретроспективи на початку проєкту або як додатковий майстер-клас.

Спочатку ви повинні зрозуміти, наскільки єдина ваша команда відчуває себе імпліцитно - дивіться пункт перевірки працездатності. Тоді ви повинні практично перевірити це за допомогою кількох відкритих питань. Кожен член команди повинен закінчити речення (див. додаткові питання) якомога більшою кількістю відповідей, які приходять йому/їй в голову:

Ретроспектива командних зобов’язань

Health Check Елементи

Вирішення конфліктів: “Якщо я помічаю, що в нашій команді виникає конфлікт, то…

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

Цікава, креативна альтернатива

Якщо ці методи ретроспективи здаються вам надто “сухими”, існує ще один метод ретроспективи, який зосереджується на відображенні якості результатів вашої команди ( Веселі 54 ретроспективні методи можна знайти тут ): Ретроспектива “Троє поросят”. Це проста альтернатива для того, щоб почати рефлексувати і покращувати свою роботу, заснована на казці про трьох поросят, які побудували будиночки з різних матеріалів.

Висновок - Agile Delivery Flow

Неважливо, як ви почнете, найважливіше - це почати взагалі. Команди, які активно стежать за своїм потоком поставок Agile, є кращими командами.

До речі, багато ідей, які ви тут знайдете, також добре підсумовані в подкасті “Agile Bites”, який я дуже рекомендую (Посилання на подкаст: Укуси Agile). 

Насолоджуйтесь розвитком своєї команди!