Цитаты из книги «Управление продуктом в Scrum. Agile-методы для вашего бизнеса»

Во время ежедневных scrum-митингов желательно не вмешиваться в самоорганизацию команды, формулировать и назначать задания, комментировать прогресс отдельных сотрудников. Если вас беспокоит ход работы, делитесь своим мнением конструктивно — например, задавая вопросы41. Чтобы прояснить ситуацию с достижением цели спринта, можно сказать: «Я заметил: диаграмма сгорания задач для спринта показывает, что осталось еще много работы до завершения спринта. Вас это беспокоит?» Задавая вопросы, вы привлекаете внимание команды, но оставляете выбор действий за ней.

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

Выпустите обновления, а затем снова улучшайте проект­. Каковы будут последствия, если зафиксировать время, качество или гибкость функциональности? Каковы выгоды от частых и быстрых релизов? И как на них перейти? Что нужно сделать, чтобы организовать выпуск проекта квартальными циклами? Какова скорость работы вашей команды? Что вы используете: диаграмму сгорания работ или план? Кто составляет и обновляет их?

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

Жить от спринта к спринту опасно, а попасться в эту ловушку довольно легко. Из-за этого трудно оценить прогресс проекта и внести нужные изменения в продукт и проект. Необходимо всегда иметь диаграмму сгорания работ или план релиза. Они должны быть размещены в рабочем помещении и на вики-портале проекта и быть легко доступными для всех участ­ников.

лан релиза фиксирует актуальную скорость работы команды и предоставляет прогноз на оставшиеся спринты.

Владелец продукта не должен поощрять компромиссы в качестве программ: не следует принимать результаты работы, не соответствующие заданным критериям. Ненадлежащее качество ведет к дефектным обновлениям продукта, поэтому не получается четко отслеживать прогресс и выпускать частые и быстрые релизы. Более того, компромиссный подход к качеству имеет долгосрочный отрицательный эффект. Вырабатывается технический долг — программы, которые трудно улучшать и поддерживать (Cunningham, 1992). Это может повредить репутации бренда и оставить потребителей неудовлетворенными. Недостаточное качество программ — результат уступок в долговременном росте в пользу краткосрочных выгод. Вы сами себя лишаете успешного, яркого будущего.

результат каждого спринта должен быть (потенциально) готов к постановке инкремента продукта: это будет исполняемая программа, проверенная, задокументированная и готовая к релизу

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

Обладает ли ваш продукт DEEP-характеристиками? Как ведется работа над грумингом бэклога вашего продукта? Насколько сложно коллективно выявлять и описывать требования при каждом спринте? Как вы работаете с нефункциональными требованиями? Где и как они фиксируются?