Пользовательские истории. Искусство гибкой разработки ПО

Как вновь открыть для себя ценность коротких обсуждений

Мэт Кроппер, ThoughtWorks

Я работал в компании ThoughtWorks бизнес-аналитиком на проекте для правительственного агентства Великобритании. Мы несли ответственность не только за предъявление продукта, но и за обучение команды клиента некоторым практическим приемам методологии Agile. Это было не так-то просто, ведь у нас была большая команда – около 25 технологических или бизнес-специалистов. Представьте себе 25 человек в одной комнате, у каждого свои пожелания о режиме кондиционера, и вы поймете, в какой ситуации мы оказались.

Мы с владельцем продукта договорились, что напишем истории, а потом в начале двухнедельной итерации вся команда соберется и распланирует разработку. В силу необходимости на этом совещании присутствовало очень много людей, что и привело к полному провалу.

«Почему мы должны делать вот так?»

«Эти истории слишком длинные/короткие».

«В этом нет никакого смысла!»

«Я настаиваю, чтобы техническая реализация данного аспекта выполнялась вот так и никак иначе».

Это был долгий и утомительный спор. Честно признаюсь, уходя с совещания, я чувствовал себя ужасно и воспринял все происходившее как личное поражение.

Однако следовало что-то предпринять, чтобы все исправить, и мы решили от одного общего совещания, где обсуждалось бы все и сразу, перейти к небольшим, более фокусированным обсуждениям. Например, на первой неделе итерации мы привели в порядок бэклог. Это сделала небольшая группа людей (владелец продукта, менеджер проекта, бизнес-аналитик и технический архитектор), которые выступали в роли пользователей различных историй. В результате, когда мы позднее формировали итоговый бэклог с участием всей команды, недоумения и недовольства было куда меньше. На этих встречах мы скорректировали и усовершенствовали наши истории, а, например, расстановку приоритетов и оценку сложности реализации проигнорировали. Это сработало.

Мы также старались, чтобы процесс создания историй был более конструктивным. Если у меня возникали какие-то идеи по поводу истории, над которой я работал, я размещал их в верхней части доски с карточками в колонке «Анализ». Каждый день на совещании нашей команды я рассказывал о своей работе над конкретной историей и мог попросить кого-то из команды разработчиков уделить мне время. Мы садились и обсуждали, в каком направлении пойдет работа, как правило затрагивая технические аспекты, а затем записывали все это на бумаге. Мы не использовали Trello, где обычно хранилась наша доска с карточками в электронном виде, а вместо этого концентрировались на личных обсуждениях, иногда с помощью доски для записей. Работа в маленькой группе с глубоким погружением в детали очень полезна, а поскольку это обсуждение редко продолжалось больше 20 минут, оно никому не доставляло неудобств. Всем очень понравилось сотрудничать, содействуя общему делу.

К счастью, огромные совещания по наполнению бэклога ушли в прошлое. Кроме того, мы обнаружили, что размер историй постепенно становится постоянным. В результате этого планирование итераций проходило куда легче, а обсуждения стали более активными. Соответственно, возросло качество документирования историй и качество всей нашей работы.