Что делать, если вы не знаете, что такое Скрам?
В первую очередь стоит хотя бы прочесть Руководство по Скраму (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 и так далее. Ведь никто не мешает попросить оценить сразу истории наперед и из них уже составлять свои планы?
Комментарии (10)
ksigne
01.12.2019 02:24Ведь никто не мешает попросить оценить сразу истории наперед и из них уже составлять свои планы?
Здесь был предусмотрен сарказм?
Shpiler
01.12.2019 05:40А как быть, если заказчику не нужен мотоцикл с вашей схемы? Он оплатил автомобиль, хочет автомобиль и согласен ждать пока его не до делают целиком и полностью. Мне кажется в таком случае работа по схеме not like this потребует несколько меньшего объёма работы
AVil
01.12.2019 08:41Как мне кажется, в этом и есть смысл Скрама — выявить реальную потребность пользователя продукта за счет малых итераций и быстро перестроиться. Решается это общением с Заказчиком. Если Заказчик изначально против, то поставка итерациями не получится и применение Скрам не имеет под собой фундамента — это будет лишь синтетическая итеративность в рамках того же водопада.
Shpiler
02.12.2019 06:03Вот мне достаточно сложно представить себе заказчика, которого бы устроил хоть на 99% готовый результат, экономическая ценность которого из-за оставшегося процента меньше нуля, то есть системой невозможно пользоваться по назначению. Может просто область такая (роботизируем горнодобывающую технику, у заказчика потребность очевидна и одна — сделайте так, что оно добывало не хуже человека и управлялось локально нанятым оболтусом), может и бывают заказчики, не ведающие чего хотят, но вот эти попытки внедрить скрам туда, где он и не подходит, право уже не знаю что с этим делать. Может я таки чего то решительно не понимаю о скраме?
ggo
03.12.2019 10:31Да, есть куча областей, где не нужен мотоцикл. Нужен сразу автомобиль.
Это все лишь означает что не нужно пользовать Скрам.
Да, скрам не универсален, как и все остальное в мире. Пользуйте то, что лучше всего работает в конкретном контексте.
402d
01.12.2019 11:13Типовая картинка для иллюстрации методики скрама мне никогда
не нравилась. Любой продукт решает какую то задачу пользователя.
Пусть мы решили выпускать дрели. Как один умный человек сказал,
в этом случае фактически мы продаем ДЫРКИ.
Пользователь будет выбирать продукт из условий минимизации себестоимости единичного отверстия для себя. И если это не забывать, то сразу становиться прозрачно
(какой будет рынок сбыта)
И итерации продукта можно проиллюстрировать
от простого коловорота до станка с ЧПУ. И максимальная выгода
скорее всего будет на уровне переносного перфоратора.
Mikluho
01.12.2019 12:13+1Слабенько…
Помесь капитанства с очень узким взглядом. Местами и вовсе Истрия про бузину и дядьку.
На мой взгляд, две главные проблемы тех, кого назначили владельцем продукта — это микроменеджмент и царёвство (я начальник, ты дурак). Остальное уже про неправильный скрам.
OnYourLips
01.12.2019 16:38На моей практике получить стабильно работающий и развивающийся продукт без применения TDD не выйдет, поэтому все истории должны быть тестируемые.
Вы неправильный термин используете.
TDD касается исключительно инженеров разработки ПО, причем зачастую каждого разработчика в отдельности, он про превентивное модульное тестирование, про него незачем знать не только менеджменту, но и даже QA.
Возможно вы имели ввиду BDD или другие виды тестирования.
В любом случае я настоятельно рекомендую узнать разницу.
insane-jo
Вот по поводу планирования и сравнения с периодом в год противоречит и принципам скрама самого, и тексту выше про изучение пользовательской истории. В этом и есть преимущество скрама — итеративность. А в случае с годом это просто waterfall с еженедельными планерками.
Пока команда разрабатывает и закрывает историю спринта — готовятся будущие истории, но никак не на год вперёд.