Виды работ аналитика
- Разработка требований
- Сопровождение реализации и тестирования, включая:проверку тест-кейсов (опционально, зависит от менеджмента конкретного проекта)
приемку реализации бизнес-аналитиком (опционально, зависит от менеджмента конкретного проекта) - Участие в локальном демо (опционально, зависит от менеджмента конкретного проекта)
- Демонстрация заказчику
- Проверка Deploy Checklist (опционально, зависит от менеджмента конкретного проекта)
Создание требований – это самая важная и трудоемкая часть работы аналитика. Она должна занимать 70% времени, причем лучше, если это будут самые эффективные часы дня (как правило, это время до 15 часов).
Распределение работ в течение дня
За основу взять такое распределение времени:
- 5,5 часов - на разработку требований
- 0,5 - на планирование
- 2 часа - на какую-то из деятельностей:изучение нового (имеются ввиду технологии, сервисы, разделы коробочной функциональности продукта, которые необходимы для создания требований, находящихся в работе)
сопровождение реализации и тестирования,
проверка реализации,
демонстрация заказчику и обработка результатов демонстрации.
Планирование работ по подготовке пользовательской истории
Работа по подготовке пользовательской истории состоит из 2х этапов:
- Грумминг
- Разработка требований
Грумминг
На этапе грумминга проводятся встречи - грумминги, с целью разделить требования эпики и пользовательские истории, определить границы историй (что будем делать и что делать точно не будем) и последовательность разработки требований (при необходимости с разбивкой по спринтам). Участниками груммингов являются:
- со стороны заказчика обязательно - Владелец продукта,
опционально - Менеджер проекта, представители бизнеса, представители смежных систем, представители сопровождения системы, - со стороны разработки обязательно - Владелец продукта и Архитектор, бизнес-аналитики, запланированные на разработку требований,
опционально - бизнес-аналитики смежных историй, Lead'ы разработки, Lead тестирования. - Этот этап может идти до начала спринта, в котором запланирована аналитика этой задачи, либо в самом начале этого спринта. После этого этапа по каждой истории определяется ее сложность и, соответственно, длительность, а так же взаимосвязь с другими историями.
Грумминг проводит бизнес-аналитик. Итоги встречи бизнес-аналитик обрабатывает при участии Product Owner'a и архитектора. В результате этого этапа должен образоваться список пользовательских историй в привязке к эпикам, информация о границах User Story, последовательность разработки требований по ним, сроки разработки требований по историям, вошедшим в ближайший спринт.
Разработка требований
Разработка требований включает все работы, которые необходимы для написания, проверки и согласования пользовательской истории. Как правило все действия не удается выполнить в один проход. Схематично этапы разработки требований представлены на Рис.1.
- На этапе выявления требований вы задаете вопросы заказчику: собираете и проводите встречи, пишете письма, слушаете/читаете ответы, возможно, наблюдаете за действиями (бизнес-процессом).
- Далее на этапе анализа вы обрабатываете эту информацию и разбираетесь в ней, классифицируете ее на разные категории и связываете потребности клиента с возможными программными требованиями. В результате анализа может оказаться, что нужно уточнить некоторые требования, поэтому вы возвращаетесь назад и дополняете набор требований.
- После этого, на этапе спецификации вы структурируете информацию от пользователей и выведенные требования в виде письменных требований-утверждений и диаграмм в пользовательской истории. При письменной фиксации может потребоваться вернуться назад и выполнить дополнительный анализ, чтобы закрыть пробелы в знаниях.
- Затем, на этапе проверки, вы просите ряд заинтересованных лиц подтвердить, что представленное вами точно и полно отражает потребности, и исправить ошибки - это этап Review пользовательской истории (Product Owner разработки, Архитектор, Lead тестирования ) и ее согласования с заказчиком.
Результат работ по разработке требований - это согласованная история.
Сколько времени нужно на написание пользовательской истории?
- 1-2 на написание легкой (где день – это 5,5 часов, см. раздел "Распределение работ в течение дня" выше)
- 3-4 на написание средней
- 5-7 на написание сложной
Это время с учетом корректировок после внутренней проверки истории Product Owner`ом и Архитектором. Соответственно, нужно понимать, что необходимо оставить себе запас времени на корректировку, поэтому отдавать историю на Review примерно через ½ или 2/3 запланированного на историю срока.
Еще примерно 1-1,5 дня, в зависимости от сложности, может уйти на обработку комментариев заказчика при согласовании истории.
Как избежать того, чтобы история после передачи на согласование заказчику оказалась не соответствующей ожиданиям?
Нужно как можно раньше показывать ее заказчику. Для этого проводятся встречи для совместного обзор, на ней нужно подсвечивать неоднозначные моменты.
Предполагается, что когда история передается на внутреннее Review, такой обзор с заказчиком уже сделан.
