Agile Доставка 1х1: огляд, найкращі практики та приклади

Усі говорять про “Agile Delivery”, і тому ви хочете отримати швидкий огляд, кілька прикладів і найкращі практики? У цій статті ви знайдете те, що шукаєте.

Agile Delivery - це методологія створення цінності для клієнтів і зацікавлених сторін з використанням гнучких принципів і практик.

Agile Delivery базується на ідеї ітеративної доставки, тобто представлення етапів продукту або послуги на ранніх стадіях і часто, а також навчання на основі відгуків та даних клієнтів для покращення та адаптації.

Agile Delivery - це не те саме, що “Waterfall Delivery”, традиційний спосіб створення цінності, коли планування, концепція, розробка, тестування тощо плануються заздалегідь, а потім виконуються послідовно.

Часто можна почути, що в agile-команди є величезний “backlog”, або невиконаних завдань, який домінуватиме в найближчі місяці. І це часто називають “Agile Waterfall Delivery”. Однак я хотів би уточнити, що такого поняття, як “Agile Waterfall Delivery”, не існує. І якщо хтось стверджує, що використовує його, то це поєднання непоєднуваного.

Agile Основи доставки Agile

Існує три основні принципи доставки Agile, які необхідно розуміти і застосовувати:

• Виконуйте завдання вчасно і часто: Переконайтеся, що всі розуміють, що цінність створюється лише тоді, коли клієнт тримає в руках щось корисне. Все, що відбувається до цього, спричиняє витрати і не створює цінності. Незалежно від того, над чим ви працюєте, це “готово” лише тоді, коли клієнт може цим користуватися. Відповідно, команди повинні братися за нову роботу лише тоді, коли їхня попередня робота використовується клієнтами.
• Отримуйте швидкий та прямий зворотній зв’язок від клієнтів: Коли команди надають інкременти роботи на ранніх термінах і часто, вони можуть отримувати відгуки від реальних клієнтів і діяти на основі цих відгуків. Це працює лише тоді, коли у вас є структура, яка дозволяє вам і вашій команді отримувати відгуки від реальних користувачів на ранніх етапах. Поширена помилка: не дозволяйте менеджерам діяти як замінники відгуків користувачів. Дайте зрозуміти менеджерам, що вони можуть мати визначення “бізнес-цінності”, але не визначення “цінності для клієнта” - воно належить клієнтам і має досліджуватися безпосередньо власником продукту та командами.
• Міжфункціональні команди: Якщо вашій команді доводиться спілкуватися з 10 іншими командами, щоб доставити щось клієнту, гнучка розробка вам не підійде (поки що). Переконайтеся, що у вас є команди, які можуть взяти на себе відповідальність за весь процес, самостійно приймати рішення та спілкуватися з клієнтами.

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

• Скрам: Це гнучкий фреймворк, який допомагає командам створювати цінність ітеративно та поступово.

  • Скрам визначає три ролі: Scrum Master, Product Owner і Команда розробників.
  • Він також визначає чотири події: Планування спринту, щоденний скрам, огляд спринту та ретроспектива спринту.
  • Він визначає три артефакти: Product Backlog, Sprint Backlog та Increment.

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

• Модель Spotify: Модель Spotify - це гнучка організаційна модель, розроблена компанією Spotify, яка займається потоковою передачею музики.
  Модель Spotify поділяє команди на загони, глави, племена та гільдії.

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

Модель Spotify добре підходить для великих організацій або програм зі складними та динамічними вимогами та результатами.

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

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

Найкраща практика: індивідуальні зустрічі з розробниками

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

Користуючись нагодою, хочу звернути вашу увагу на наше безкоштовне програмне забезпечення для проведення зустрічей 1:1, яке було розроблене спеціально для гнучких команд. Зробіть свої зустрічі 1:1 захоплюючими, вимірюйте тенденції і, перш за все, досягайте прогресу в розвитку ваших співробітників! 

Спробуйте один з наших шаблонів, дивіться нижче. Наступний шаблон є стандартним шаблоном, наприклад, для двотижневих зустрічей один на один. Він також включає в себе вимірювану “перевірку настрою” в кінці, яку ви, звичайно, можете налаштувати:

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

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

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