Встановлення пріоритетів

Якщо перші три пункти рецепта впроваджено, то далі все піде гладесенько-рівнесенько. Високоякісний код має надходити часто, час виконання розробки має скоротитися, а кількість WIP стане обмеженою. Нові завдання мають надходити лише після закінчення роботи над попередніми і звільнення потужностей. У цей час увага керівництва перемикається на оптимізацію створюваної цінності, а не лише на обсяги створюваного коду. Немає сенсу зосереджуватися на розподілі пріоритетів доти, доки відсутня передбачуваність результатів. Навіщо витрачати сили на пріоритети на вході, якщо це жодним чином не впливає на послідовність задач на виході? Доки цю проблему не вирішено, краще спрямувати зусилля менеджерів на розвиток можливостей команди та поліпшення передбачуваності результатів. Приділяти увагу встановлення пріоритетів завдань варто лише тоді, коли ви переконані, що дійсно можете видавати готові завдання приблизно в тій же послідовності, у якій вони надходять.

Вплив

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

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

Останнім часом в Аgile-спільноті набули популярності тема оптимізації бізнес-цінності й думка, що обсяг випуску робочого коду (так звана «швидкість розробки») не є надто важливим показником. Справж­нім мірилом успіху команди вважається обсяг створеної бізнес-цінності. Зрештою, так і є, але важливо не забувати про «драбину технологічної і процесної зрілості», якою команда має підніматись. Більшість організацій нездатні виміряти обсяг створеної бізнес-цінності та відзвітувати щодо неї. Тому спочатку їм слід опанувати базові навички і лише згодом переходити до серйозніших викликів.

Набуття зрілості

Я вважаю, що команда має «дорослішати» у такий спосіб.

Спочатку їй треба навчитися створювати високоякісний код.

Потім скоротити кількість WIP і, відповідно, час виконання, а також частіше випускати релізи.

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

Нарешті, коли розробка ПЗ відбуватиметься гладко і буде вдосконалюватись, поліпшимо процес встановлення пріоритетів із метою оптимізації створення цінності.

Надії на швидку оптимізацію бізнес-цінності примарні. Працюйте над дорослішанням команди крок за кроком — дотримуйтесь рецепту успіху.