Новичок в Agile? ИНВЕСТИРУЙТЕ в хорошие пользовательские истории — [Agile для всех]
Просмотры сообщений: 46 594
Как <пользователь> Я хочу <функция> чтобы <значение> .
Выше приведен очень простой шаблон пользовательской истории. Как может быть так сложно сделать что-то настолько простое? Пользовательские истории составляют основу гибкой разработки. Они являются основным вкладом в команду. Команда берет пользовательские истории и создает приращения продукта на основе этих историй. К сожалению, получить пользовательские истории «правильно» сложно сразу. Владелец продукта (или другая роль, связанная с продуктом) должен научиться создавать пользовательские истории, отвечающие потребностям команды. Этому навыку можно научиться со временем, но я собираюсь сэкономить вам время на обучении.
Чтобы создавать хорошие пользовательские истории, начните с того, что не забывайте ИНВЕСТИРОВАТЬ в хорошие пользовательские истории.
INVEST — это аббревиатура, которая включает в себя следующие понятия, которые составляют хорошую пользовательскую историю:
- Независимый
- Возможен торг
- Ценный
- Оценивается
- Маленький
- Тестируемый
Давайте рассмотрим каждый из них с простым объяснением.
Независимость: Истории должны быть как можно более независимыми. Думая о независимости, часто легче думать о «независимости от порядка». Другими словами, над историями можно работать в любом порядке. Почему это важно? Это позволяет правильно расставить приоритеты для каждой истории. Когда в игру вступают зависимости, может оказаться невозможным реализовать ценную историю без реализации других, гораздо менее ценных историй.
Оборот: История — это не контракт. История — это приглашение к разговору. История улавливает суть желаемого. Фактический результат должен быть результатом совместных переговоров между заказчиком (или доверенным лицом заказчика, например владельцем продукта), разработчиком и тестировщиком (как минимум).
Цель состоит в том, чтобы удовлетворить потребности клиентов, а не разработать что-то в соответствии с пользовательской историей, если этого недостаточно! Помните, что вы всегда можете задать волшебный вопрос, чтобы поддержать разговор.
Ценность: Если история не имеет заметной ценности, ее не следует делать. Период. Надеемся, что пользовательские истории расставлены по приоритетам в бэклоге в соответствии с ценностью для бизнеса, так что это должно быть очевидно. Некоторые говорят, что каждая история должна быть ценной для покупателя или пользователя. Мне не нравится такой образ мышления, потому что ценность для бизнеса включает в себя больше, чем просто ценность для клиента или пользователя. Он включает в себя внутреннюю ценность, которая полезна для вещей, которые обычно называют «нефункциональными требованиями» или чем-то подобным. Я предпочитаю говорить, что история имеет ценность для «пользователя» в пользовательской истории. Таким образом, становится ясно, кто должен быть удовлетворен.
Наконец, помните пункт «чтобы <значение>» пользовательской истории. Это не просто так — это именно та ценность, которую мы пытаемся донести, завершая историю!
Оцениваемый: История должна быть оценена или оценена, чтобы можно было правильно расставить приоритеты. Значение с высокой ценностью, но очень длительным временем разработки, может не быть элементом с наивысшим приоритетом из-за продолжительности времени, необходимого для его разработки. Что происходит, если историю нельзя оценить? Вы можете разделить историю и, возможно, получить больше ясности. Иногда разделение истории не помогает. Если такая ситуация возникает, может быть необходимо сначала провести некоторое исследование истории. Пожалуйста, пожалуйста, засеките время исследования! Если вы этого не сделаете, это займет все доступное время, тем самым лишив продукт чего-то другого, что можно было бы сделать вместо этого.
Маленький: Очевидно, что истории — это небольшие фрагменты работы, но насколько маленькими они должны быть? Ответ зависит от команды и используемой методологии.
Я преподаю Agile и предлагаю двухнедельные итерации, которые позволяют пользовательским историям в среднем работать 3-4 дня — ВСЕГО! Сюда входит вся работа по доведению истории до состояния «готово». Также помните, что пользовательские истории не должны быть золотыми. Вы должны сделать самую простую вещь, которая работает, а затем остановиться!
Ознакомьтесь с нашими обширными ресурсами о том, как разделить пользовательские истории.
Тестируемый: Каждая история должна быть тестируемой, чтобы быть «готовой». На самом деле, мне нравится думать о проверяемых критериях приемлемости, которые можно написать сразу. Подобный подход поощряет более активное сотрудничество, повышает качество за счет продвижения QA в процессе и позволяет легко перейти к процессу разработки, основанной на приемочном тестировании (ATDD). Как и в случае с обсуждением выше, задавание волшебного вопроса также может помочь обеспечить возможность тестирования пользовательской истории.
Если владельцы продукта и их команды работают вместе, чтобы ИНВЕСТИРОВАТЬ в хорошие пользовательские истории, кривая обучения от совместной работы будет намного короче.
ИНВЕСТИРУЙТЕ хорошие привычки, которые устраняют некоторые из более серьезных проблем пользовательских историй, таких как зависимости, слишком большой размер, сложность тестирования и т. д. Найдите время, чтобы ИНВЕСТИРОВАТЬ в хорошие истории, и вы увидите кардинальные изменения в том, насколько эффективным станет планирование, а также насколько продуктивной станет команда.
До следующего раза я буду ИНВЕСТИРОВАТЬ в хорошие пользовательские истории, потому что это определенно помогает в Превращении Agile в реальность™.
Категории: Agile Ideas, Новичок, Планирование, Практика, Владелец продукта, Советы
Боб Хартман
Известный как Agile Bob, обладает более чем 35-летним опытом и обширными отраслевыми знаниями, полученными практически на всех должностях в индустрии программного обеспечения, включая разработчика, тестировщика, составителя документации, тренера, менеджера по продукту, менеджера проекта, бизнес-аналитика, старший инженер-программист, менеджер по развитию и исполнительный директор.
За последние 20 с лишним лет Боб прошел путь от одного из первых последователей Agile до своего нынешнего статуса сертифицированного тренера по Scrum® (CST) и сертифицированного корпоративного тренера℠ (CEC), а также эксперта в области обучения, коучинга и наставничества во всех областях деятельности. Гибкая разработка. Боб — популярный спикер, выступавший на многочисленных крупных конференциях, семинарах, семинарах и собраниях групп пользователей, где его увлекательный стиль, целостный взгляд на разработку и личные анекдоты всегда были хорошо приняты посетителями. Чтобы увидеть его предстоящие курсы, нажмите «Предстоящие курсы» в разделе «Agile For All» в меню в верхней части экрана.
6 атрибутов эффективных пользовательских историй – INVEST – Кайзенко аббревиатура нам в помощь
помните правила написания эффективных пользовательских историй: независимые, подлежащие обсуждению,
Ценный, достойный оценки, небольшой и поддающийся проверке.
Независимый: Насколько это возможно, постарайтесь, чтобы истории не были взаимозависимыми, так как это может привести к проблемам с расстановкой приоритетов и планированием.
Независимый отличается от логического порядка развития вещей. Под независимыми мы подразумеваем сюжетные особенности. Например, предположим, что мы поддерживаем оплату кредитной картой и хотим поддерживать оплату картами American Express, Mastercard и Visa. Что ж, если бы у нас была история для MasterCard и другая для Visa, тогда оценки будут зависеть от того, какую из них мы сделаем в первую очередь, потому что тогда реализация другой истории будет относительно простой. Поэтому мы хотели бы уточнить и сделать одну историю, представляющую «предоставление основного способа оплаты с использованием VISA». Затем другие истории могут измениться на «предоставить дополнительный способ оплаты с помощью American Express».
Договорная: Рассказ должен быть кратким. Это не подробный договор. Его цель — поощрить непрерывный диалог и обсуждение объема между заказчиком и разработчиками.
Ценность: История должна представлять ценность для покупателя или пользователя.
Если клиент не может придумать формулировку ценности, то, возможно, нам следует снизить приоритетность истории или, возможно, работа не нужна, и нам следует полностью ее исключить.
Еще одна причина, по которой нужно указывать значение, заключается в том, что значение представляет собой то, почему мы создаем определенную функцию. Представление команде «Почему» (ценность), а не только «Что» (функция) может вызвать разные идеи альтернативных функций, которые легче или быстрее разрабатывать, но при этом достигать той же цели и обеспечивать ту же ценность для бизнеса.
Кроме того, поскольку история доставляет часть
функционал, заказчик может прикинуть сколько стоит этот функционал
а затем решить, нужно ли им это еще.
Наконец, помните, что не всякая ценность определяется деньгами. Снижение риска — это ценность. Так же как и изучение или приобретение знаний.
Оценка: Разработчики должны уметь оценивать историю. Он должен быть написан таким образом, чтобы разработчики могли его понять и иметь представление о том, как его реализовать.