Вы знаете Трех Амиго?
Не волнуйся. Это не значит, что мы должны писать наши истории на испанском языке! Вместо этого мы рассмотрим один из гибких способов работы — «Три амиго».
Мы узнаем, что такое Three Amigos, на примере того, как сессия может помочь команде лучше понять требования.
Что такое три амиго?
«Три амиго», что в переводе с английского означает «три друга», — это гибкий способ работы, при котором три человека с разными взглядами собираются вместе для уточнения пользовательских историй.
Эти три перспективы, описанные Agile Alliance, состоят из:
- Бизнес — Какую проблему мы пытаемся решить?
- Разработка. Как мы можем создать решение для решения этой проблемы?
- Тестирование — что насчет этого? Что может случиться?
Следовательно, при доработке пользовательской истории должны присутствовать разработчик, тестер и бизнес-аналитик (BA), чтобы в достаточной мере понять требования.
Как работают три амиго?
Давайте рассмотрим пример команды, обсуждающей пользовательскую историю на сеансе с тремя амигоми.
Команда садится вместе со следующей пользовательской историей для доработки:
As an employee, I want to submit my timesheet so I can get paid
Разработчик: Итак, что нам нужно зафиксировать в расписании?
Б.А.: Нам нужно зафиксировать количество часов, отработанных каждый день в течение календарного месяца.
Разработчик: Никаких проблем. Мы можем создать форму, в которой пользователи могут ежедневно вводить свое рабочее время. Затем, когда пользователь нажимает «Отправить», мы можем отправить электронное письмо в отдел кадров для обработки расписания.
БА: К сожалению, электронная почта не поможет. Нам нужно отправить эту информацию в нашу систему управления персоналом, поскольку у нас есть автоматизированный процесс расчета заработной платы.
Разработчик: Хорошо, в таком случае мы можем отправить его в HR-систему через HR API.
Тестер: Что произойдет, если они введут неверную информацию?
Разработчик: Мы можем предоставить обратную связь пользователю. Например, мы можем показать сообщение проверки, когда пользователь предоставляет неверные данные.
Тестер: Что такое неверные данные? Может ли пользователь ввести отрицательное число отработанных часов? Существует ли максимальное количество часов, которое пользователь может работать в данный день?
БА: Нет, пользователь должен иметь возможность вводить только положительные числа до двенадцати.
Тестировщик: Хорошо, мы должны написать тестовый пример, чтобы покрыть это.
Разработчик: Я также позабочусь о том, чтобы у нас была соответствующая проверка количества часов.
БА: Кроме того, я только что вспомнил, что нам нужно отправить уведомление по электронной почте линейному руководителю для утверждения.
Разработчик: Значит, нам нужно убедиться, что мы отправляем табель учета рабочего времени в состоянии «проверка», чтобы сотрудник не получал зарплату, пока его не утвердит его непосредственный руководитель?
БА: Верно.
Тестер: Что делать, если линейный руководитель отсутствует?
БА: Хороший вопрос. Мы также должны отправить электронное письмо непосредственному руководителю Б.
Тестировщик: Что, если линейный руководитель захочет отклонить представленный табель учета рабочего времени?
Разработчик: Оказывается, это большая работа по развитию. Могу ли я предложить создать новые пользовательские истории для этих дополнительных сценариев?
Команда соглашается, что пользовательские истории теперь довольно объемные, поэтому разделите работу по уведомлению по электронной почте на отдельные пользовательские истории для последующего уточнения:
As a line manager, I want to get notified if one of my staff submit a timesheet so I can review it As a line manager, I want to be able to approve my staff timesheets so I can ensure my staff get paid As a line manager, I want to be able to reject a timesheet so I can ensure my staff aren't paid incorrectly
Разработчик: Есть ли что-то еще, что нам нужно учитывать для записи деталей табеля учета рабочего времени?
Б.А.: Думаю, на этом все. Мы можем повторить это в будущем, если понадобится.
Команда переходит к следующей истории.
Что команда обнаружила на этой сессии?
Для этой истории одного пользователя команда обнаружила следующее:
- Во-первых, необходимо зафиксировать количество отработанных часов за каждый день месяца.
- Во-вторых, количество отработанных часов должно быть положительным, вплоть до двенадцати.
- В-третьих, форма должна быть проверена, и пользователю должна быть предоставлена обратная связь.
- Наконец, когда пользователь отправляет свое расписание, система должна отправить данные в HR API в состоянии проверки.
Кроме того, команда создала три новых пользовательских истории.
Теперь они лучше подготовлены к оценке и выполнению этой работы.
Лучшие практики
Не существует правильного или неправильного способа улучшить пользовательские истории с помощью трех амиго. Вместо этого я бы предложил попробовать, чтобы найти то, что лучше всего подходит для вашей команды. Тем не менее, вот несколько хороших практик, которые могут помочь:
- Сеансы тайм-бокса — Тайм-боксинг помогает сфокусировать команду; вы всегда можете вернуться к истории позже, если не закончите ее уточнение. От 45 минут до часа, как правило, хорошее эмпирическое правило.
- Меняйте членов команды на каждой сессии — это помогает делиться знаниями в команде.
- Имейте по одному члену из каждой области — разные точки зрения обеспечивают дополнительную ценность.
- Не торопитесь — это займет столько времени, сколько потребуется. Уточнение историй заранее означает, что мы не задаем столько вопросов, когда находимся в разработке.
Выводы
Из приведенного выше примера мы можем увидеть значение Трех Амиго.
Разработчик помог определиться с решением проблемы.
Тестер предоставил ценность, выделив потенциальные проблемы.
BA предоставил информацию прямо здесь и сейчас, поэтому команде не нужно было уходить, чтобы найти ответы, в которых они отчаянно нуждались.
Команда теперь более уверена в том, что примет участие в следующем спринте!
