Возьмем небольшую команду из 10 человек. Стабильную – они занимаются только 1 продуктом или проектом. Кросс-функциональную – члены команды все вместе обладают всеми компетенциями, что превращать идею/запрос/требование в результат (функцию/характеристику продукта).
Эта команда работает серией коротких проектов длительностью до 1 месяца, а чаще – по 2 недели. Короткие проекты более успешны, потому что более понятны.
Длительность этих проектов фиксирована и не изменяется. Это позволяет выстраивать стабильный предсказуемый процесс, поскольку можно анализировать показатели предыдущих интервалов: производительность, скорость, проблемы. Такие проекты называются итерациями или спринтами.
Команда берет задачи из Бэклога (продукта, проекта). У этого бэклога есть ответственный – Владелец. Он один. Это позволяет избегать конфликтов, ускорять принятие решений, четко понимать ответственность за бизнес-результаты. Владелец отвечает не за качество и процесс, а за бизнес-эффекты задач, которые выполняет команда. Низкие эффекты означают, что Владелец ошибся с выбором задач.
Элементы бэклога – задачи, функции, характеристики, запросы. Список дел по продукту.
В начале каждого мини-проекта команда набирает из верхней части большого бэклога задачи, которые они успеют сделать за итерацию. Сами оценивают, сами детализируют. Такие полномочия отвечать на вопрос “как” добавляют команде мотивации и ответственности за результат.
Бэклог итерации – достаточно стабильный. Он изменяется в деталях, но не кардинально в размере. Если кто-то важный хочет вбросить задачу в ходе спринта, то, во-первых, ему предлагается дождаться следующей итерации, а во-вторых, положить задачу в большой бэклог, где она будет соревноваться в важности с другими задачами (ведь он такой важный не один), и итоговое решение примет Владелец. Если задача объективно важнее других, то она поднимется вверх бэклога, и команда рассмотрит ее при планировании следующей итерации.
В ходе мини-проекта боссы, руководители и другие заинтересованные авторитетные сотрудники не мешают команде выполнять работу, не пристают с расспросами о статусе. Им предлагается дождаться встречи “Обзор итерации с демонстрацией результата”. Во-первых, эта встреча состоится совсем скоро, ведь самая типичная длина итерации – 2 недели. Во-вторых, команда обязана продемонстрировать на ней готовый результат. "А если они делают не то?” Они запланировали итерацию и показали план – именно это они и делают.
В конце каждого проекта команда предоставляет результат. На 100% готовый с точки зрения качества. Готовый с точки зрения качества, но не количества – в нем могут присутствовать не все функции/характеристики продукта, указынные в бэклоге продукта. И если в большом бэклоге есть большие блоки ABCDE, то это не означает, что сначала будет реализован блок А, затем B и так далее. После разделения блоков на мелкие подрезультаты последовательность может оказать любой, например, B.2.5.1, A.4.2.3, C.5.1.3 и далее – главное, чтобы самые ценные минимальные характеристики поставлять раньше остальных.
Готово = на 100%, даже не на 99%. Это помогает создать прозрачность процесса и результатов, и упрощает взаимодействие. Пропадает целая группа типичных разговоров типа: “Вот это готово, но еще не проверено” или “Вот это готово, осталось только объединить с другими частями и…” И вот такие хвосты создают мнимое ощущение готовности, занимают больше времени, чем кажется, и отнимают и энергию у следующей итерации.
Этот результат называется поставкой или инкрементом. Он должен быть в конце каждой итерации. Однако это не всегд нужно и не всегда возможно. Это возможно и очень полезно в ИТ, креативном и издательском бизнесах, и если цикл производства умещается в 1 итерацию (обычно 1–4 недели). Менее применимо в промышленности. Это полезно, если нет уверенности в том, каким должен быть результат или как его создать, если время ограниченно или можем быть сокращено, и если технологически существует возможность относительно недорого переделать неудачную попытку.
Незавершенные задачи из итерации N возвращаются в большой бэклог, заново проходят процедуру приоритизации, и уже оттуда могут попасть в следующую итерацию. А могут и не попасть. Совсем необязательно дочитывать неинтересную книгу и досматривать неинтересный фильм.
Итерации идут одна за другой, без наложений. Как только однако итерация завершилась и итоги подведены, следующая итерация начинается встречей по планированию. Если же итерации пересекаются, то становится непонятно, чем занимается команда в на данном отрезке времени, и появляется желание уточнять статус и постепенно появляются действия/механизмы по микро-координации.
Дополнительно, после обсуждения результата итерации, команда проводит внутреннюю встречу по улучшению своего процесса (ретроспектива, извлеченные уроки).
Эта команда работает серией коротких проектов длительностью до 1 месяца, а чаще – по 2 недели. Короткие проекты более успешны, потому что более понятны.
Длительность этих проектов фиксирована и не изменяется. Это позволяет выстраивать стабильный предсказуемый процесс, поскольку можно анализировать показатели предыдущих интервалов: производительность, скорость, проблемы. Такие проекты называются итерациями или спринтами.
Команда берет задачи из Бэклога (продукта, проекта). У этого бэклога есть ответственный – Владелец. Он один. Это позволяет избегать конфликтов, ускорять принятие решений, четко понимать ответственность за бизнес-результаты. Владелец отвечает не за качество и процесс, а за бизнес-эффекты задач, которые выполняет команда. Низкие эффекты означают, что Владелец ошибся с выбором задач.
Элементы бэклога – задачи, функции, характеристики, запросы. Список дел по продукту.
- Эти элементы упорядочены! По важности, по значимости, по приоритету.
- Элементы в бэклоге – небольшие. Во-первых, это улучшает приоритизацию, потому что часто бывает так, что 80% большой задачи – вообще не важные, и намного менее важны, чем следующие 2–3 задачи. Во-вторых, они должны быть реализуемы в рамках одного мини-проекта, иначе теряется смысл.
В начале каждого мини-проекта команда набирает из верхней части большого бэклога задачи, которые они успеют сделать за итерацию. Сами оценивают, сами детализируют. Такие полномочия отвечать на вопрос “как” добавляют команде мотивации и ответственности за результат.
Бэклог итерации – достаточно стабильный. Он изменяется в деталях, но не кардинально в размере. Если кто-то важный хочет вбросить задачу в ходе спринта, то, во-первых, ему предлагается дождаться следующей итерации, а во-вторых, положить задачу в большой бэклог, где она будет соревноваться в важности с другими задачами (ведь он такой важный не один), и итоговое решение примет Владелец. Если задача объективно важнее других, то она поднимется вверх бэклога, и команда рассмотрит ее при планировании следующей итерации.
В ходе мини-проекта боссы, руководители и другие заинтересованные авторитетные сотрудники не мешают команде выполнять работу, не пристают с расспросами о статусе. Им предлагается дождаться встречи “Обзор итерации с демонстрацией результата”. Во-первых, эта встреча состоится совсем скоро, ведь самая типичная длина итерации – 2 недели. Во-вторых, команда обязана продемонстрировать на ней готовый результат. "А если они делают не то?” Они запланировали итерацию и показали план – именно это они и делают.
В конце каждого проекта команда предоставляет результат. На 100% готовый с точки зрения качества. Готовый с точки зрения качества, но не количества – в нем могут присутствовать не все функции/характеристики продукта, указынные в бэклоге продукта. И если в большом бэклоге есть большие блоки ABCDE, то это не означает, что сначала будет реализован блок А, затем B и так далее. После разделения блоков на мелкие подрезультаты последовательность может оказать любой, например, B.2.5.1, A.4.2.3, C.5.1.3 и далее – главное, чтобы самые ценные минимальные характеристики поставлять раньше остальных.
Готово = на 100%, даже не на 99%. Это помогает создать прозрачность процесса и результатов, и упрощает взаимодействие. Пропадает целая группа типичных разговоров типа: “Вот это готово, но еще не проверено” или “Вот это готово, осталось только объединить с другими частями и…” И вот такие хвосты создают мнимое ощущение готовности, занимают больше времени, чем кажется, и отнимают и энергию у следующей итерации.
Этот результат называется поставкой или инкрементом. Он должен быть в конце каждой итерации. Однако это не всегд нужно и не всегда возможно. Это возможно и очень полезно в ИТ, креативном и издательском бизнесах, и если цикл производства умещается в 1 итерацию (обычно 1–4 недели). Менее применимо в промышленности. Это полезно, если нет уверенности в том, каким должен быть результат или как его создать, если время ограниченно или можем быть сокращено, и если технологически существует возможность относительно недорого переделать неудачную попытку.
Незавершенные задачи из итерации N возвращаются в большой бэклог, заново проходят процедуру приоритизации, и уже оттуда могут попасть в следующую итерацию. А могут и не попасть. Совсем необязательно дочитывать неинтересную книгу и досматривать неинтересный фильм.
Итерации идут одна за другой, без наложений. Как только однако итерация завершилась и итоги подведены, следующая итерация начинается встречей по планированию. Если же итерации пересекаются, то становится непонятно, чем занимается команда в на данном отрезке времени, и появляется желание уточнять статус и постепенно появляются действия/механизмы по микро-координации.
Дополнительно, после обсуждения результата итерации, команда проводит внутреннюю встречу по улучшению своего процесса (ретроспектива, извлеченные уроки).