Цитаты из книг автора «Роман Пихлер»

владелец продукта — это прежде всего член scrum-команды, он тесно сотрудничает с коллегами. Scrum-мастер и команда помогают владельцу продукта, совместно работая над бэклогом продукта,

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

Эти два варианта ортогональны друг другу: функциональные команды организуются вокруг бэклога продукта, а компонентные — вокруг программной архитектуры

роль владельца продукта требует полной вовлеченности.

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

Немецкая пословица «Самопознание — первый шаг к совершенствованию» отлично резюмирует главную идею ретроспективных анализов.

Необходимо провести тщательный анализ обновления продукта и принять или отклонить каждый элемент бэклога продукта, внедрить который обязалась команда

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

«Я заметил: диаграмма сгорания задач для спринта показывает, что осталось еще много работы до завершения спринта. Вас это беспокоит?» Задавая вопросы, вы привлекаете внимание команды, но оставляете выбор действий за ней.

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