Майк Кон. Пользовательские истории
Гибкая разработка программного обеспечения.
Надеялся почитать про тестирование, но это таки Agile, один из вариантов.
Автор очень не любит вотерфоллы и вообще спеки. Ему главное - общение команды с заказчиком. максимум - на карточках юзер-сторий помечаются приемочные тесты. Собственно, даже детали надо обговаривать как можно позже - когда уже заказчик поймет, что ему нужно.
Обычный рабочий процесс:
- заказчик объясняет, чего хочет;
- команда вместе с заказчиком мозговым штурмом определяет набор ролей, которые будут работать с приложением; Тут иногда можно создавать личности - но надо ли? каждой роли прописываются некоторые базовые способности и базовые действия с приложением;
- команда вместе с заказчиком мозговым штурмом определяет юзер-стории для каждой роли;
- команда в присутствии заказчика но без его участия определяет эстимейты для каждой юзер-стори;
- заказчик в присутствии команды определяет приоритеты каждой стори (или в баллах, или по стилю MoSCoW - Must have, Should have, Could have, We don't have);
- заказчик вместе с командой определяет размер итерации (2-4 недели, как правило), в зависимости от того, когда он хочет релиз;
- заказчик вместе с командой определяет состав итерации;
- в ходе итерации команда постоянно спрашивает заказчика, если что-то не понятно;
- заказчик может докидывать новые юзер-стори, менять приоритеты старым, менять старые, удалять старые - в ходе итерации не очень желательно, но допустимо, команда имеет право объяснить заказчику, насколько катастрофичным будет изменение/добавление;
- в конце итерации анализируют, что успели, что нет, почему, составляют план на следующую и шаги повторяются, пока не будет достигнут релиз - или дата релиза (и что успели - то успели), или выполнение всех юзер-стори.
При этом если определена дата - "плавает" набор фич, которые успеют реализовать; если определен набор фич - "плавать" начинает число итераций.
Наверное, это действительно круто.
Если есть адекватный заказчик, который действительно настолько вовлекается в процесс. Наверное, такие действительно где-то водятся. Например, в далекой стране Тир-На-Ног, на берегах молочных рек :)
Если проект не слишком большой.
Если команда не слишком большая.
Иначе, как кажется, можно использовать только какие-то части.
Иначе, как кажется, все может закончится плохо.
Сама User-story - это, как я понял, одно действие пользователя, которое приносит результат. Например, "Юзер размещает резюме на сайте".
Второй вариант определения:
- есть Сценарий, описывающий всю работу пользователя с системой/частью системы;
- Сценарий состоит из Юз-кейсов, описывающих конкретные действия с вариантами (просроченная карточка для оплаты, денег не хватает, и т.д.)
Так вот, грубо говоря, Юзер-стори - это и есть отдельно взятый вариант Юз-кейса
Размер юзер-стори (надо ли ее разбивать на под-истории или же объединять несколько в одну) определяется просто - на разработку должно уходить от 0,5 до 4 "идеального дня". Если больше четырех - имеет смысл пилить. Если меньше - имеет смысл склеивать обратно.
Юзер-стори можно комментировать, но не слишком подробно. Как выразился Кон - чтобы у команды не возникало ложное чувство, что все уже решено и обсуждать больше нечего.
Заказчик пишет к историям приемочные тесты, отталкиваясь от которых (а также от комментариев и - главное - от обсуждения) тестеры команды пишут тесты. По Кону - нужно автоматизировать так много тестов, как возможно. В идеале - до 90%.
Подробнее про роли, представителей пользователей, написание историй и т.д. - в книжке :)
Надеялся почитать про тестирование, но это таки Agile, один из вариантов.
Автор очень не любит вотерфоллы и вообще спеки. Ему главное - общение команды с заказчиком. максимум - на карточках юзер-сторий помечаются приемочные тесты. Собственно, даже детали надо обговаривать как можно позже - когда уже заказчик поймет, что ему нужно.
Обычный рабочий процесс:
- заказчик объясняет, чего хочет;
- команда вместе с заказчиком мозговым штурмом определяет набор ролей, которые будут работать с приложением; Тут иногда можно создавать личности - но надо ли? каждой роли прописываются некоторые базовые способности и базовые действия с приложением;
- команда вместе с заказчиком мозговым штурмом определяет юзер-стории для каждой роли;
- команда в присутствии заказчика но без его участия определяет эстимейты для каждой юзер-стори;
- заказчик в присутствии команды определяет приоритеты каждой стори (или в баллах, или по стилю MoSCoW - Must have, Should have, Could have, We don't have);
- заказчик вместе с командой определяет размер итерации (2-4 недели, как правило), в зависимости от того, когда он хочет релиз;
- заказчик вместе с командой определяет состав итерации;
- в ходе итерации команда постоянно спрашивает заказчика, если что-то не понятно;
- заказчик может докидывать новые юзер-стори, менять приоритеты старым, менять старые, удалять старые - в ходе итерации не очень желательно, но допустимо, команда имеет право объяснить заказчику, насколько катастрофичным будет изменение/добавление;
- в конце итерации анализируют, что успели, что нет, почему, составляют план на следующую и шаги повторяются, пока не будет достигнут релиз - или дата релиза (и что успели - то успели), или выполнение всех юзер-стори.
При этом если определена дата - "плавает" набор фич, которые успеют реализовать; если определен набор фич - "плавать" начинает число итераций.
Наверное, это действительно круто.
Если есть адекватный заказчик, который действительно настолько вовлекается в процесс. Наверное, такие действительно где-то водятся. Например, в далекой стране Тир-На-Ног, на берегах молочных рек :)
Если проект не слишком большой.
Если команда не слишком большая.
Иначе, как кажется, можно использовать только какие-то части.
Иначе, как кажется, все может закончится плохо.
Сама User-story - это, как я понял, одно действие пользователя, которое приносит результат. Например, "Юзер размещает резюме на сайте".
Второй вариант определения:
- есть Сценарий, описывающий всю работу пользователя с системой/частью системы;
- Сценарий состоит из Юз-кейсов, описывающих конкретные действия с вариантами (просроченная карточка для оплаты, денег не хватает, и т.д.)
Так вот, грубо говоря, Юзер-стори - это и есть отдельно взятый вариант Юз-кейса
Размер юзер-стори (надо ли ее разбивать на под-истории или же объединять несколько в одну) определяется просто - на разработку должно уходить от 0,5 до 4 "идеального дня". Если больше четырех - имеет смысл пилить. Если меньше - имеет смысл склеивать обратно.
Юзер-стори можно комментировать, но не слишком подробно. Как выразился Кон - чтобы у команды не возникало ложное чувство, что все уже решено и обсуждать больше нечего.
Заказчик пишет к историям приемочные тесты, отталкиваясь от которых (а также от комментариев и - главное - от обсуждения) тестеры команды пишут тесты. По Кону - нужно автоматизировать так много тестов, как возможно. В идеале - до 90%.
Подробнее про роли, представителей пользователей, написание историй и т.д. - в книжке :)