Lean Class
Немеханика Agile
Agile для команды и Agile для бизнеса - это два разных взгляда на предмет.
Agile для бизнеса - это про результат. Это про продукт с точки зрения рынка, про бренд и многое другое. Agile для команды - это про процесс. Как пишется код, как он проверятся, как делается развертывание, какими средствами гарантируется доступность сервисов и т.д.
Здесь проблема не только в том, что у команды и у бизнеса фокус на разные, иногда взаимоисключающие, вещи. В общем случае процесс не гарантирует результат, просто потому, что входные данные могут меняться. А в ситуации постоянных изменений построить процесс, который всегда обеспечит бизнесу требуемый результат, будет как минимум очень трудно.
Этот проект задуман в первую очередь для обмена кейсами и практической помощи командам разработки, которые еще только начинают свой путь через Agile-трансформацию. Этот проект возник потому, что Agile-трансформация - это больно. Потому что в своей практике я не помню случая, чтобы команде действительно объяснили, зачем это все. И потому что важно, чтобы каждая команда понимала, что Agile - это не единорог, не пони с радугой и не модная фишка, а для чего это и почему это.
И что с практической точки зрения Agile - это специфичная для каждой команды имплементация инструментов, овладев которыми, команда сможет снизить энтропию внутри своего проекта на фоне постоянных изменений извне.
Agile - это интерфейс для работы в изменяющейся внешней средой.
И единственно правильного гайдлайна по реализации не завезли.
Принципы
Ценности и принципы Agile, безусловно, являются общим базисом. Из своего проектного опыта я вынес несколько важных практических моментов, которые помогают правильно держать фокус и продолжать двигаться в условиях неопределенности.
-
Время - важнейший ресурс
Lead Time, MTTR, Time-To-Market - временные метрики процесса. Но время - это не только метрика.
При фиксированной емкости команды время становится практически единственным ресурсом, использованием которого команда может управлять.
На какие активности уходит время в спринте - это то, что действительно находится в круге влияния команды. -
Качество процесса подтверждается метриками вашего сервиса
Ваше приложение - это неотъемлемая и самая важная часть продукта. Но это не весь продукт.
Продукт - это в том числе про уровень сервиса; насколько доступно приложение для пользователя, насколько оно быстрое, какое качество релизов, как решаются саппорт тикеты, и так далее.
То, что вы делаете в рамках процесса разработки, обязательно должно находить свое подтверждение в сервисных метриках. -
Стоимость и сроки решения связывают вас с бизнесом
Первый принцип процессного фреймворка SAFe - Take an economic view. И это не просто так. Важно помнить, что деньги для вашего проекта берутся не из тумбочки.
В условиях высококонкурентного рынка 4-6 недель - это приличный срок; инвесторы контролируют движение продукта по согласованному роадмапу и хотят прогнозируемого возврата своих инвестиций.
Какое отношение это имеет к Agile-разработке? Отвечая на вопрос "Как?", команда решает, насколько дорогим будет решение и как долго займет реализация.
Ищите менее дорогие и более быстрые решения. -
Экспертиза и компетенции - ресурсы, влияющие на продукт
Мысль, лежащая на поверхности - недостаток нужных компетенций будет тянуть команду вниз. Другая важная вещь - возобновление или прирост проектной экспертизы требует ресурсов команды.
Т.е. с одной стороны без компетенций и знаний бизнес-домена нельзя построить хороший продукт. С другой стороны, чтобы компенсировать недостаток экспертизы, требуется capacity команды, которое неизбежно будет откусано от бизнес-фич.
Учитывайте эти косты и держите правильный баланс. -
Изменения и ограничения постоянны и объективны
Единственное, в чем вы можете быть стопроцентно уверены - ситуация вокруг вашего проекта будет меняться и вам всегда будет не хватать ресурсов.
Это условия, в которых работает бизнес. Воспринимайте это как часть объективной реальности.
Ищите способы предугадать изменения и начинайте действовать заранее.