тл; ДР;
В чем разница между:
A) Полученные детали, определения области и критерии приемлемости, полученные в результате продолжающегося «разговора с пользовательской историей», который команда должна вести с PO, BA и заинтересованными сторонами во время спринта.
И
B) Незапланированное изменение масштаба (из-за которого пропускается оценка истории, история не завершает спринт и т. д.).
В частности, как вы докажете расползание объема работ и оценку/смещение графика, вызванное А по сравнению с Б?
Полная история
У меня есть гибкая команда кросс-функциональных фронтенд- и бэкенд-инженеров, дизайнеров, QA-тестеров. Мы работаем в непрерывном потоке Канбана, основанном на вытягивании, отделенном от ряда церемоний Scrum, таких как стендапы, обработка невыполненных работ, ретроспективы и т. д.
Мы получаем документацию по проекту/функции от исполнительной команды, определяющую высокую ценность для бизнеса и высокоуровневые низкодетальные спецификации желаемого проекта/функции.
Я выступаю в роли PO (помимо других шляп, которые я ношу), что означает, что я участвую в этом уровне руководства, изучая видение функций, потребности бизнеса и более тонкую бизнес-логику во время этого процесса.
Затем команда приступает к разработке функций и разбивает исходную документацию на пользовательские истории, каждая из которых определяет историю типа MVP, которая может принести пользу сама по себе. Команда готовит историю и приходит к общему соглашению. На данный момент команда и PO стремятся иметь определенную бизнес-логику на 99,99%, но оставляют открытым вопрос «как».
Когда начинается разработка, команде предлагается продолжить разговор с пользовательской историей, чтобы выявить все более и более мелкие детали, касающиеся пользовательского интерфейса, UX и второстепенной бизнес-логики. Это требует разговоров со мной, нашим креативным директором по художественному/дизайнерскому направлению и нашим генеральным директором по стратегическому направлению продукта. Наряду с этим разговором идет разработка и исследование пользовательского интерфейса, в результате чего генерируются знания, которые, в свою очередь, порождают новое понимание и, возможно, новые или измененные бизнес-требования.
Проблема, с которой я столкнулся, — это почти бесконечная «внутренняя итерация» в этом разговоре с пользовательской историей. Креативный директор занимается совершенствованием UI/UX, генеральный директор занимается совершенствованием бизнес-поведения функции, а я изо всех сил пытаюсь найти баланс между предоставлением MVP и предоставлением функции, которой довольны все заинтересованные стороны.
Мое текущее решение состоит в том, чтобы преодолеть эту тонкую грань, разбив основные отклонения от первоначальной пользовательской истории на отдельную пользовательскую историю, позволяя при этом вносить незначительные изменения всех видов в рамках существующей пользовательской истории. Этот подход выглядит нормально , но я чувствую, что он может противоречить мышлению Agile/Lean. Опять же, я чувствую, что A) MVP с подписанием PO/стейкхолдером и B) Обсуждение пользовательской истории могут по-своему противоречить друг другу и что они не могут применяться одновременно.
Похоже, у вас проблемы с тем, как пишутся истории. Истории представляют собой цель , имеющую ценность для актера .
Если подумать о версии пользовательских историй Майка Кона: « [Актер] хочет выполнить [цель] , чтобы получить [ценность] ». Если вы можете идентифицировать эти три элемента, область действия следует логически.
Разговор, который должен произойти в пользовательской истории, касается самого простого или самого дешевого способа получить эту ценность , доставляемую действующему лицу , путем включения цели .
Например, представьте себе эту историю для сайтов Stack Exchange:
Как зарегистрированный пользователь , я хочу изменить свой аватар , чтобы мой аватар был таким же, как на других сайтах .
Каков самый простой и дешевый способ добиться этого? Вот где обсуждение должно произойти. Это должно начаться во время планирования, и это может выглядеть так:
Член команды А: «Мы могли бы добавить новую форму с загрузкой файла на страницу пользователя»
Член команды B: «А как насчет перетаскивания изображения из файла на сам аватар?»
Член команды А: «Да, это проще, давайте так»
Затем решение аннотируется на карточке (или на том, что вы используете для отслеживания историй). Это деталь реализации.
Во время разработки возникает несколько проблем/возможностей.
Как мы обрабатываем эти случаи?
Пункт 1 означает, что для предоставления согласованной ценности пользователю необходима дополнительная работа, в частности, в этом случае это может быть метка, объясняющая пользователю функциональность. Это явно часть истории . Это необходимо сделать для того, чтобы история была полной и ценной. Решение должно быть отмечено на карточке.
Пункт 2 — это понимание, которое было получено по мере того, как команда получала больше знаний по этому вопросу. Это обеспечивает дополнительную ценность, но не является необходимой для достижения согласованной цели: ценность превышает то, что было согласовано. Поэтому в этом случае в бэклог добавляется новая история: «Как зарегистрированный пользователь , я хочу изменить свой аватар через копирование/вставку , чтобы я мог изменить его, не сохраняя локальный файл в своей системе ».
Как видите, должно быть довольно легко понять, что является «расползанием области», а что нет. Имейте в виду, что в agile не существует такой вещи, как расширение масштаба: расширение масштаба — это важный побочный продукт методологии, это то, что мы на самом деле поощряем , и оно имеет правильное место в виде новых историй.
Ваша ситуация кажется мне довольно знакомой (как и многим другим в реальном мире, я подозреваю).
Подход Agile приветствует изменения, даже изменения в последнюю минуту, поэтому заинтересованные стороны могут постоянно улучшать/расширять пользовательские истории и добавлять дополнительные детали или даже новые требования. Как вы говорите, непросто держать отдельные пользовательские истории «под контролем». Когда история уже запущена, ее не следует изменять или расширять настолько, чтобы сделать предыдущие оценки и планы недействительными. Однако можно изменить или уточнить мелкие детали на основе отзывов заинтересованных сторон. Как вы заметили, здесь есть тонкая грань баланса. Но в нем нет ничего негибкого по своей сути; Я считаю, что все agile-команды постоянно сталкиваются с этой дилеммой.
это, как вы тоже заметили, между созданием подписанной документации по проекту/функции на раннем этапе и постоянной подготовкой истории. Я чувствую, что может существовать разрыв на организационном уровне между гибким процессом вашей команды и более традиционным подходом других отделов, включая исполнительную команду.
Я думаю, что с их точки зрения часть проблемы может заключаться в том, что они не видят отдельных пользовательских историй, созданных вашей командой, а только исходный полный документ, в котором нет четких границ между различными функциями. Таким образом, они не замечают, что «слишком сильно» расширяют существующую историю, чтобы добавить совершенно новую историю.
Это может помочь им подробно объяснить, как работает ваша команда, что такое agile-подход и почему, каковы его преимущества по сравнению с традиционным подходом Big Specification Up Front. А также объяснить им текущую проблему с точки зрения вашей команды. В идеале вы могли бы убедить их принять пользовательские истории с самого начала процесса. Это может упростить определение относительного размера каждой истории (используя обратную связь от команды разработчиков) и избежать их чрезмерного раздувания.
(Это может быть сложно или, в худшем случае, даже невозможно, в зависимости от множества факторов, включая образ мышления высшего руководства, ситуацию в вашей команде и статус отдела, организационную культуру, «политику», состояние agile трансформация внутри вашей организации и т. д. Так что оцените их и действуйте с осторожностью или вообще не действуйте, если считаете это слишком рискованным. Без более подробной информации невозможно дать более конкретный совет по этому поводу. За исключением, может быть, двух:
Другим важным фактором является обеспечение того, чтобы в спринт попадали только достаточно небольшие истории. На этом этапе история должна быть достаточно маленькой, чтобы ее было удобно закончить за один спринт; предпочтительно, это не должно требовать более чем нескольких человеко-дней работы. Если он слишком большой, его следует разбить на более мелкие истории. Работа с достаточно небольшими историями также помогает контролировать «расползание масштаба», так как вы можете добавить к небольшой истории лишь ограниченное количество вещей, прежде чем заметите, что она начинает становиться слишком большой, поэтому пришло время ее нарезать.
в порядке и полностью гибок, по крайней мере, если все сделано правильно. То есть до тех пор, пока заинтересованные стороны и команда могут договориться о наборе последовательных усовершенствований истории или эпоса, чтобы команда могла предоставить заинтересованным сторонам новые функции в виде серии ценных приращений продукта. Научиться разбивать истории на подходящие маленькие кусочки — это искусство, требующее терпения и длительной практики. И здесь может очень помочь обратная связь от вас и вашей команды в адрес стейкхолдеров, а также регулярная демонстрация им завершенных, работающих инкрементов продукта — не знаю, как часто вы это делаете?
Попытка ответить на мой собственный вопрос
Мои первоначальные ощущения таковы:
Необходимо больше руководителей в Agile: руководители слишком вовлечены в детали и внедрение «как сделать»; это создает более нисходящий подход, основанный на контрактах, чем итеративный подход, основанный на гипотезах.
Если бы команда выполняла настоящую итеративную разработку , это не было бы проблемой: команда итеративно и постепенно эволюционировала бы к правильному решению. Исполнительный директор и команда продукта/аналитика должны продолжать определять стратегию и видение высокого уровня и позволить команде заниматься бизнесом и исследованием UX, необходимыми для достижения оптимального решения.
Если бы PO / BA составляли настоящие спецификации продукта, основанные на гипотезах и данных , это не было бы проблемой. Вместо этого PO / BA и исполнительная команда занимаются историческим и «интуитивным» дизайном функций, основанным на том, «что работало раньше» и «что, по моему мнению, сработает»; это вызывает
Команде необходимо изучить бизнес на гораздо более глубоком уровне, чтобы иметь возможность принимать определенные решения от имени клиента/пользователя, не требуя большого количества заказов на поставку или участия руководства. Если бы команда могла выбирать между двумя вариантами бизнес-логики, основываясь на своих знаниях о продукте, пользователе и рынке, она двигалась бы к подлинной самоорганизации и владению продуктом.
Четкая ответственность команды : заставьте команду понять, почему они создают функцию определенным образом, и взять на себя ответственность за ее успех. Это требует предоставления командам возможности принимать независимые решения, а затем измерять успех/неудачу. Больше независимости связано с большей ответственностью и подотчетностью.
Продукту требуется выделенный полный рабочий день PO, который является экспертом в предметной области и имеет в своем распоряжении команду бизнес-аналитиков и / или аналитиков данных для участия в истинной разработке, основанной на гипотезах и итерациях.
В целом, это очень сложный и трудоемкий процесс, не говоря уже о риске.
Бернардо