Rewired

Проблема, приводящая к аварийному завершению работы программы или выдаче некорректных результатов

 

Источник: База данных отраслевого программного обеспечения Numetrics - 1 321 проект и аналитика с помощью запатентованного алгоритма нормализации (2021 год)

 

ПРИЛОЖЕНИЕ 13.1

 

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

 

Начнем с agile-методологий. Существует несколько разновидностей: scrum (по названию команды), kanban, SAFe (Scaled Agile Framework) и другие. Каждая из них имеет свой собственный язык, каденции и виды деятельности, что иногда приводит к жарким спорам о том, какая из них лучше.

 

Мы считаем, что все эти обозначения не имеют значения. Некоторые из лучших компаний, которые являются носителями цифровых технологий, даже не называют свои методы работы "agile". Большинство организаций получат пользу от использования фреймворка scrum, и мы используем его в этой книге, хотя признаем, что и другие подходы могут быть эффективными. Однако важно разработать четыре набора определяющих характеристик, которые отличают agile-подразделения от традиционных команд разработчиков ПО. К ним относятся:

 

Миссия с измеримыми результатами. Руководство дает каждому подразделению четкую миссию, основанную на общей цифровой "дорожной карте". Каждая миссия должна быть нацелена на конечные результаты (или ключевые результаты), которые можно измерить и которых группа может достичь в разумные сроки (в месяцах или кварталах, а не в годах).

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

Автономность и ответственность за достижение результатов. Чтобы этот гибкий подход был успешным, подгруппы должны нести ответственность за работу, которую они выполняют. Эта ответственность распространяется не только на разработку решения, но и на реализацию ценности этого решения. Подразделения наделяются полномочиями принимать решения по разработке решений для достижения миссии. Владелец продукта - фактический руководитель подгруппы - постоянно определяет приоритетность функций разработки продукта в бэклоге.

Быстрое развитие и ориентация на потребности пользователей. Основной подход к работе agile pod - тестирование, обучение и постоянное совершенствование решения на основе четкого представления о том, что нужно конечному пользователю. Подгруппы работают над созданием чего-то нового и тестируют его с конечными пользователями каждые две недели, чтобы собрать прямую обратную связь и быстро адаптироваться. Члены группы получают немедленную обратную связь и выполняют ее.

 

По их словам: Освободите свои продуктовые отряды

Один из ключевых сдвигов заключался в том, чтобы сосредоточиться на том, какую ценность мы пытаемся создать. Изменение модели с целью сосредоточиться на опыте сотрудников, в отличие от сосредоточения на том, были ли проекты выполнены в срок и в рамках бюджета, было фундаментальным изменением.

Вторая вещь - это то, что основная операционная модель вращается вокруг отряда [т. е. капсулы], и то, что отряды получают все необходимое, чтобы обеспечить им успех. Это позволяет им быть самостоятельными, чтобы они могли сами определять направление своей деятельности и принимать решения.

Когда вы создаете такую команду, вам нужна роль владельца бизнес-продукта, роль владельца технического продукта, а также скрам-мастера. Это типичная модель отряда с точки зрения технологий. Но переход от проектно-ориентированной модели, в которой некоторые люди заняты лишь 20 % своего времени, - это фундаментальный и необходимый сдвиг.

Это не ракетостроение. Нужно просто собрать все вместе в модель, которая имеет смысл для работы, которую нужно сделать, и оставаться действительно сосредоточенным и преданным этой работе, вот почему вам нужна постоянная команда, которая существует и после первоначальной поставки продукта, который вы пытаетесь создать.

Мы, безусловно, выиграли от этой модели, и мне не звонили люди в любое время дня и ночи с вопросами: "Что мне делать с этим проектом? Как мне принять это решение?" Они могли самостоятельно принимать решения по своим продуктам, при этом отчитываясь, чтобы мы были в курсе происходящего.