Страница 10 из 16
Чтобы появился достаточный политический и социальный капитал для воздействия на изменения, необходим определенный уровень доверия. Если ваша команда неспособна постоянно выдавать высококачественный код, то ни о каком доверии не может быть и речи. Такая команда имеет мало шансов повлиять на расстановку приоритетов и тем самым оптимизировать ценности, создаваемые в процессе разработки.
В последнее время в agile-сообществе модно говорить об оптимизации бизнес-ценности и о том, что объем выпуска рабочего кода (так называемая скорость разработки ПО) – не такой уж важный показатель. Это потому, что истинное мерило успеха – объем поставленной бизнес-ценности. В конечном счете так и есть, но важно не забывать, что команда должна растить свою зрелость. Большинство организаций неспособны измерить созданную бизнес-ценность и отчитаться по ней. Сначала им следует овладеть базовыми навыками, а уже потом браться за более серьезные вызовы.
Рост зрелости
Я считаю, что команда должна расти таким образом. Сначала следует научиться создавать высококачественный код. Затем сокращается количество незавершенных задач и, соответственно, время выполнения, более частыми становятся релизы. После этого поддерживается баланс нагрузки и пропускной способности, ограничиваются незавершенные задачи, создается резерв времени, что ведет к совершенствованию. Когда процесс разработки программ начинает идти гладко и со временем оптимизируется, улучшается и процесс расстановки приоритетов, что приводит к оптимизации создания ценности. Надежды на оптимизацию бизнес-ценности – это только мечты. Прежде всего примите меры для постепенного взросления коллектива, следуя рецепту успеха.
Атака на источники вариативности для улучшения предсказуемости
Как последствия вариативности, так и борьба с ней в процессе работы – это сложные понятия. Сокращение вариативности в разработке ПО требует от сотрудников изменений в их рабочем процессе – они должны освоить новые техники и изменить личное поведение. Все это непросто, а потому не подходит для новичков и незрелых организаций.
Вариативность приводит к большому количеству незавершенных задач и увеличению времени выполнения. Подробнее об этом читайте в главе 19. Вариативность порождает необходимость в резервах времени вне бутылочных горлышек, чтобы справиться с неустойчивым объемом работы: вариативность воздействует на объем работы, идущий через цепочку создания ценности. Чтобы глубже разобраться в том, почему так происходит, нужно обладать определенными познаниями в системе статистического контроля процессов и теории массового обслуживания, что выходит за рамки этой книги. Мне, например, нравится работа Дональда Уилера и Дональда Рейнертсена о вариативности и массовом обслуживании, так что, если вы хотите узнать об этом больше, начните с нее.
Пока же примите на веру положение о том, что вариативность в размерах задач, требующих усилий на анализ, дизайн, программирование, тестирование, сборку и выдачу релиза, отрицательно влияет на пропускную способность процесса и накладных расходов цепочки создания ценности в разработке ПО.
Однако ряд источников вариативности непосредственно вшит в производственный процесс вследствие неудачного выбора правил работы. Пример в главе 4 рассказывает о некоторых из них: это ежемесячное перепланирование, соглашение о предоставлении услуг, основанное на оценках, приоритет текстовых, то есть не требующих пересборки продукта, изменений в производстве. Все три приведенных примера – это результат работы по правилам, которые нужно изменить. Простое изменение существующих правил может значительно сократить число источников вариативности, влияющих на предсказуемость.
Рецепт успеха и канбан
Канбан делает возможными все шесть этапов рецепта успеха и обеспечивает его реализацию, а рецепт успеха создает доверие к внедряющему его менеджеру. В свою очередь, рецепт успеха иллюстрирует ценность Канбана.
Выводы
• Канбан делает возможным реализацию всех составляющих рецепта успеха.
• Рецепт успеха объясняет ценность Канбана.
• Плохое качество – это главный источник потерь в разработке ПО.
• Снижение количества незавершенных задач повышает качество продукта.
• Повышение качества порождает доверие у сотрудников ниже по цепочке создания ценности – например, операционных инженеров.
• Частый выход релизов порождает доверие со стороны сотрудников выше по цепочке создания ценности – например, отдела маркетинга.
• Вытягивающая система может сбалансировать нагрузку и пропускную способность.
• Вытягивающие системы выявляют бутылочные горлышки и создают резервы времени и усилий в остальных местах.
• Качественная расстановка приоритетов максимизирует производительность цепочки создания ценности в разработке ПО.
• Расстановка приоритетов сама по себе мало значит без хорошего изначального качества и предсказуемости производственной системы.
• Чтобы внести изменения для сокращения вариативности, требуются резервы.
• Сокращение вариативности снижает потребность в резервах.
• Сокращение вариативности позволяет сбалансировать ресурсы (а в дальнейшем, возможно, и сократить численный состав команды).
• Сокращение вариативности снижает требования к ресурсам.
• Сокращение вариативности позволяет уменьшить количество канбан-жетонов, незавершенных задач и приводит к снижению среднего времени выполнения.
• Появление резервов создает возможности для улучшения.
• Усовершенствование процесса ведет к повышению производительности и предсказуемости.
Глава 4
От худшего к лучшему за пять кварталов
В октябре 2004 года Драгош Думитриу был менеджером программ в Microsoft. Он только что возглавил отдел, который имел репутацию худшего IT-подразделения компании.
Должность «менеджер программ» в Microsoft примерно соответствует тому, что в других местах называют менеджером проектов, но обычно включает также некоторую ответственность за анализ и архитектуру. Менеджер программ назначается на инициативу, проект или продукт и отвечает за часть функционала. Чтобы выполнить работу, он привлекает ресурсы из функциональных областей, например разработки и тестирования. Драгош отвечал за техническое обеспечение ПО для бизнес-подразделения XIT. Эта команда (рис. 4.1), зрелость процессов которой оценивалась как CMMI Model Level 5, располагалась в Индии и состояла из трех разработчиков, трех тестировщиков и менеджеров, занимавшихся разработкой небольших обновлений и устранением ошибок примерно в 80 кроссфункциональных IT-приложениях, используемых сотрудниками Microsoft по всему миру. Сам Драгош находился в кампусе в Редмонде. В то же самое время там работал и я.
Рис. 4.1. Команда в Хайдарабаде (Индия). Драгош – четвертый слева
Проблема
Драгош сам вызвался возглавить команду, которая имела худшую репутацию в Microsoft с точки зрения клиентского обслуживания. В круг его обязанностей как агента изменений входило решение проблем длительного времени выполнения задач и плохо сформулированных, из-за сложившейся в компании конъюнктуры, ожиданий заказчиков. Некоторые из его предшественников на этой должности продолжали работать в компании с другими проектами того же подразделения. Они опасались, что если ему удастся улучшить производительность команды, то они будут выглядеть неудачниками.
Программисты и тестировщики этой организации следовали методологии PSP/TSP (Personal Software Process / Team Software Process). Такие требования компании Microsoft были записаны в контракте. Джон Де Ваан в то время – непосредственный подчиненный Билла Гейтса и большой поклонник Уоттса Хамфри из Института программной инженерии. Как глава Engineering Excellence в Microsoft, он мог требовать от IT-отдела и его поставщиков соблюдения определенных процедур. Поэтому изменение метода жизненного цикла разработки ПО было невозможным.