Канбан. Альтернативный путь в Agile

Если первые три пункта рецепта внедрены, то дальше все пойдет без сучка без задоринки. Высококачественный код должен выдаваться часто, время выполнения разработки стать относительно коротким, а число незавершенных задач – ограниченным. Новые задания должны поступать в разработку только после того, как сдаются предыдущие и освобождается место. В это время внимание руководства переключается на оптимизацию создаваемых ценностей, а не только на объемы создаваемого кода. Нет смысла сосредоточиваться на расстановке приоритетов, пока выработка непредсказуема. Зачем тратить силы на приоритеты поступления, если это не скажется на конечном результате? Пока эта проблема не решена, лучше использовать драгоценное время на достижение предсказуемости и качества выполнения работ. Уделить внимание расстановке приоритетов задач стоит лишь тогда, когда вы убедитесь, что действительно можете выполнять задачи примерно в том же порядке, в котором они поступают.

Влияние

Расстановкой приоритетов не должна заниматься техническая организация: этот процесс находится вне зоны влияния технического руководства. Чтобы улучшить расстановку приоритетов, владельцу продукта, спонсору или отделу маркетинга следует изменить свое поведение. Технические управленцы могут искать рычаги влияния только после того, как все приоритеты уже установлены.

Чтобы появился достаточный политический и социальный капитал для воздействия на изменения, необходим определенный уровень доверия. Если ваша команда неспособна постоянно выдавать высококачественный код, то ни о каком доверии не может быть и речи. Такая команда имеет мало шансов повлиять на расстановку приоритетов и тем самым оптимизировать ценности, создаваемые в процессе разработки.

В последнее время в agile-сообществе модно говорить об оптимизации бизнес-ценности и о том, что объем выпуска рабочего кода (так называемая скорость разработки ПО) – не такой уж важный показатель. Это потому, что истинное мерило успеха – объем поставленной бизнес-ценности. В конечном счете так и есть, но важно не забывать, что команда должна растить свою зрелость. Большинство организаций неспособны измерить созданную бизнес-ценность и отчитаться по ней. Сначала им следует овладеть базовыми навыками, а уже потом браться за более серьезные вызовы.

Рост зрелости

Я считаю, что команда должна расти таким образом. Сначала следует научиться создавать высококачественный код. Затем сокращается количество незавершенных задач и, соответственно, время выполнения, более частыми становятся релизы. После этого поддерживается баланс нагрузки и пропускной способности, ограничиваются незавершенные задачи, создается резерв времени, что ведет к совершенствованию. Когда процесс разработки программ начинает идти гладко и со временем оптимизируется, улучшается и процесс расстановки приоритетов, что приводит к оптимизации создания ценности. Надежды на оптимизацию бизнес-ценности – это только мечты. Прежде всего примите меры для постепенного взросления коллектива, следуя рецепту успеха.

Атака на источники вариативности для улучшения предсказуемости

Как последствия вариативности, так и борьба с ней в процессе работы – это сложные понятия. Сокращение вариативности в разработке ПО требует от сотрудников изменений в их рабочем процессе – они должны освоить новые техники и изменить личное поведение. Все это непросто, а потому не подходит для новичков и незрелых организаций.

Вариативность приводит к большому количеству незавершенных задач и увеличению времени выполнения. Подробнее об этом читайте в главе 19. Вариативность порождает необходимость в резервах времени вне бутылочных горлышек, чтобы справиться с неустойчивым объемом работы: вариативность воздействует на объем работы, идущий через цепочку создания ценности. Чтобы глубже разобраться в том, почему так происходит, нужно обладать определенными познаниями в системе статистического контроля процессов и теории массового обслуживания, что выходит за рамки этой книги. Мне, например, нравится работа Дональда Уилера и Дональда Рейнертсена о вариативности и массовом обслуживании, так что, если вы хотите узнать об этом больше, начните с нее.

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