Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Что делать, если вы не знаете, что такое Скрам?
В первую очередь стоит хотя бы прочесть Руководство по Скраму (PDF) и начать ему следовать. Если вы не следуете этому руководству, значит вы делаете что угодно, только не Скрам. По сути Владелец продукта занимается максимизацией ценности продукта для конечного пользователя. Он может делегировать свои обязанности кому-то из команды, но отвечать за результат должен только он один. Также он должен быть единственным источником знаний о продукте для команды. Если у разработчика есть вопрос, он идет только к Владельцу продукта. Тот выясняет все детали, разруливает зависимости (если они есть) и согласует дальнейшие дествия с разработчиком.
Какие ошибки допускают Владельцы продукта в Скраме
Не используют INVEST-метод для формирования Пользовательских историй
Суть метода INVEST проста и заключается в том, что каждая Пользовательская история должна соответствовать следующим критериям:
I — independent. К началу работы над историей все зависимости должны быть решены. Это правило иногда приходится нарушать. Например, сделать 1 туториал займет 5 поинтов, а потом каждый туториал — по 2 поинта.
N — negotiable. У команды разработки должна быть возможность обсудить варианты реализации данной истории. возможно воспользуясь принципом Парето, и сделать 80% работы за 20% времени.
V — valuable. История должна иметь ценность для конечного пользователя. Кнопка с надписью “coming soon” имеет большую ценность для пользователя, чем абстрактная архитектура.
E — estimable. История должна быть оцененной. Иногда для того, чтобы История оставалась независимой нужно эти зависимости решить. Для этого стоит ввести практику Backlog refinement (или Backlog grooming): часто это продолжающийся процесс в ходе работы над инкрементом либо отдельная встреча для Команды разработки. В ходе таких встреч Владелец продукта презентует истории и просит их оценить либо сказать, чего команде не хватает.
S — small. Чем меньше История, тем лучше. Не стоит разбивать истории по архитектурным слоям (база, бекэнд, клиент и тд) — ничего хорошего из этого не выйдет, поскольку история потеряет свою независимость.
T — testable. На моей практике получить стабильно работающий и развивающийся продукт без применения TDD не выйдет, поэтому все истории должны быть тестируемые.
Не дружат со Скрам мастером
Скрам мастер — это лидер-слуга. Он следит за тем, чтобы Правила игры были понятны всем. Он проведет все митинги, поможет привести Бэклог в порядок, выступит в роли коуча и напишет эту статью.
Пытаются заимплементить сразу большую фичу
Часто Владельцы продукта приходят из компаний, которые делают Скрам только на словах. И становится очевидно, что они не понимают, как составлять Пользовательские истории: пытаются их реализовывать по тем же архитектурным слоям либо другими способами игнорируют INVEST метод. Стоит начать с декомпозиции большой фичи на небольшие рабочие прототипы — такие, что можно выпускать раз за разом, каждый спринт работы, тем самым создавать ценность для пользователя.
Устраивают бардак в Бэклоге
Когда Бэклог становится похож на свалку устаревших идей и багов — это самое грустное, что может произойти с проектом. Планирование и груминг превращается в перекладывание Историй из дна Бэклога в начало и обратно. А Разработчик, имеющий свободное время, не сможет найти актуальный баг чтобы починить.
Не планируют наперед
Многие не согласятся, но в Скраме проще простого планировать наперед. Владельцу продукта известна скорость команды. Например, она равна 15 поинтам в неделю. За месяц команда может выдать 60 поинтов, за год — 720 и так далее. Ведь никто не мешает попросить оценить сразу истории наперед и из них уже составлять свои планы?
