Please enable JavaScript.
Coggle requires JavaScript to display documents.
Управление продуктом в Scrum (Роман Пихлер) (Работа с бэк-логом (a. …
Управление продуктом в Scrum (Роман Пихлер)
Видение / дорожная карта
a. Видение продукта не должно быть детальным, надо оставлять команде возможность для творчества.
b. Дорожная карта не более чем на 6-12 месяцев.
c. Визионерские спринты
Работа с бэк-логом
a. Работа с бэклогом - 10% времени
всей команды
b. 20% времени каждый член команды должен выделять на любимые темы / истории, которые он сам для себя придумывает. Как в Гугл.
c. Нельзя пренебрегать грумингом. Иначе срывается церемония планирования.
d. Планирование и груминг -
совместный командный труд
. РО - ответственный за принятие решений и самый активный участник.
e. Планирование на 2-3 спринта вперед.
f. К планированию БЛ на спринт должен быть максимально проработан.
g. Максимально работать с командой между планированием и демо (не быть Чайкой)
Структура бэк-лога
a. Модель Кано: основные, производительные и привлекательные функции продукта.
b. Простота продукта. Чем меньше функций, тем лучше.
c. В самом начале БЛ не должен быть длинным и сложным.
d. Отказаться от еженедельного донаполнения БЛ мелкими US – БЛ становиться огромным, неуправляемым, в котором сложно фокусироваться.
e. Подробно описывать и декомпозировать элементы только на ближайшие 2 спринта (в больших проектах на 1 спринт не достаточно).
f. Один бэклог на весь проект, а не отдельные бэклоги у каждой команды. Иначе много встреч по синхронизации.
g. БЛ не должен содержать список просьб к Деду Морозу (все подряд желания). Трудно приоритизировать, ограничивает развитие на основе отзывов клиентов. Оставить в БЛ только то, что относится к видению.
Детализация и описание user-story
a. При оценке US не обязательно, чтобы были детально прописаны требования. Это компенсируется тем, что оценку команда проводит вместе и в режиме обсуждения.
b. US для реализации должны удовлетворять критериям INVEST, т.е. каждая US должна быть:
I
ndependent (независимой)
N
egotiable (согласуемой)
V
aluable (ценной)
E
stimatable (удобной для оценки)
S
mall (небольшой)
T
estable (контролируемой)
c. US для реализации должны удовлетворять критериям DEEP, т.е. каждая US должна быть:
D
etailed (детальной)
E
stimated (оцененной)
E
mergent (независимой)
P
rioritized (приоритезированной)
d. Спецификация под видом БЛ - симптом нездоровых отношений между РО и командой. Со стороны РО должно быть только видение продукта и БЛ в виде перечня US.
e. В каждой US должны быть НФТ.
f. У каждой US должны быть критерии готовности.
g. РО не должен писать US в одиночку и навязывать их команде. Укрепляется разделение на МЫ и ОНИ. Усложняется планирование.
Груминг надо проводить всей командой
вместе.
Управление качеством продукта
a. Контролировать уровень качества, иначе будет расти кол-во дефектов и технический долг, что приведет к отрицательному долгосрочному эффекту.
b. На демо должны быть готовые US, соответствующие критериям качества.
c. Не делать работу в ущерб качеству (побольше функций, временные решения и пр.)
d. Не давить на команду по поводу темпа. Лучше на ретро обсудить способы увеличения скорости или анализ того, почему не достигли цели спринта.
Демо
a. Не надо для демо готовить презу и слайды.
b. Активность и заинтересованность на демо каждого члена команды (и РО, и SM, и остальных).
c. Не создавать на демо излишних иллюзий.
Управление бэк-логом релиза (не спринта)
a. График выгорания работ релиза (не спринта). Смотреть на него после демо.
b. План релиза в виде эпиков и фич. Смотреть и актуализировать после демо. Возможно, имеет смысл визуализировать на флип-чарте или доске.