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

В таких типах организаций бизнес-аналитики часто исполняют обязанности по «сбору требований». Они являются передаточным звеном между программистами и представителями бизнеса, например менеджерами банковского или страхового продукта. Когда этим представителям бизнеса нужны изменения IT-инфраструктуры, которая поддерживает их продукт, они работают с бизнес-аналитиками, чтобы сформулировать эти изменения. Очевидно, что в данном случае они выступают в роли клиентов, а бизнес-аналитики – в роли исполнителей, в результате чего и запускается описанный ранее антишаблон.

Как-то в одном разговоре мой друг Дэвид Хассман предложил лучшую метафору для отношений, которые на самом деле должны существовать между бизнес-аналитиками и представителями бизнеса, – они должны быть такими же, как отношения между музыкальным продюсером и его группой. Дэвид знает в этом толк, потому что он не только гуру Agile, но и экс-гитарист хеви-метал-группы Slave Raider, существовавшей в 1980-х годах. Ему приходилось как работать с продюсерами, так и быть продюсером самому. Группа вступает в шоу-бизнес с энтузиазмом и, хочется надеяться, некоторым талантом, но участники не разбираются в подводных камнях шоу-бизнеса или в процессе записи альбома. В этом компетентен продюсер. Это его работа – помочь группе выпустить настолько успешный альбом, насколько это возможно. Хорошие продюсеры могут вырастить из талантливого новичка популярного, коммерчески успешного артиста.

Такова и работа бизнес-аналитика в IT. Используйте видение представителей бизнеса и помогите им воплотить его в успех. Вы не можете работать как приемщик заказов – вы должны выступать в роли доктора. Иногда это означает необходимость объяснять представителям бизнеса то, что они не хотят слышать. Но если вы искренне хотите помочь им добиться успеха, они заметят это и оценят вашу помощь.

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

Для идеи, весьма простой в своей основе, вся эта история с историями становится слишком запутанной на практике. Если кто-нибудь когда-нибудь говорил вам, что разработка программного обеспечения – да и предъявление любого продукта – прошла легко и просто, это было вранье.

Истории объединяют в себе много разных вещей. Мы употребляем это слово, подразумевая карточку, фрагмент программного продукта, который разрабатываем, и особенно способ обсуждения, которое проводим, чтобы решить, что нужно создать. Истории могут описывать очень большие возможности или сложно формулируемые части предоставления продукта, которые сами по себе могут не значить ничего особенного для заказчиков или пользователей. Работа с историями – продолжительный процесс обсуждений и дискуссий, в результате чего большие истории должны быть разбиты на маленькие части. На протяжении всех этих обсуждений мы концентрируемся не только на том, что можем создать, но также для кого и почему это делаем. Карты историй – лишь один из способов облегчить разбиение больших частей на маленькие, при котором мы не упускаем из виду людей, использующих продукт с удовольствием и пользой для себя.

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

Я надеюсь, вы тоже думаете, что это замечательно.

Разрешите мне вернуться к сходству историй с камнями. Части, на которые вы разобьете камень, все равно можно назвать камнями, просто меньшего размера. Но это все еще такие же камни, как тот, первоначальный, который нам нужно было внимательно рассмотреть, чтобы понять, достоин он разбиения или нет. Давайте условно назовем его «нулевой камень». В терминах метода историй я бы употребил слово «возможность».

Под возможностями я подразумеваю идеи, которые, по нашему мнению, могли бы решить проблему. Нет, я вовсе не тот человек, чей стакан всегда наполовину пуст, но все-таки не очень умно считать любую возникшую идею достойной реализации в нашем продукте, ведь, как вы знаете, времени и людей, чтобы реализовать все, никогда не бывает достаточно. Но даже если бы у вас было сколько угодно ресурсов, ваши заказчики были бы слегка шокированы таким продуктом.

Когда мы предлагаем для обсуждения какую-нибудь идею, обычно эта идея довольно велика, хоть и не всегда. На жаргоне историй мы можем назвать такую идею эпиком, но я предпочитаю слово «возможность». Независимо от того, как вы их называете, это все еще истории, и главная цель их начальных обсуждений – решить, стоит ли продолжать работу над этими историями или просто отбросить их. Для каждой возможности мы можем обсудить:

• для кого она. На этом уровне чаще всего упоминаются разные группы пользователей, заказчиков или целевой сегмент рынка;

• какие проблемы она может решить. Нужно разобраться, какие проблемы всех типов пользователей мы можем решить. А также как они решают свои проблемы сейчас – вручную, или с помощью продуктов наших конкурентов, или, что еще хуже, с помощью продукта, который неудобен для них сейчас и неэффективен;

• что представляет собой идея. У нас могут быть соображения о том, какими должны быть продукт или функциональность. Об этом следует поговорить;

• почему именно эта возможность. Хороший момент для обсуждения причин, почему вашей организации выгодно создавать программные продукты для этих пользователей. Чаще всего решение проблем пользователей оказывается недостаточно весомым аргументом. Нужно предусмотреть отдачу от инвестиций в программное решение, а также соответствует ли эта инвестиция действующей бизнес-стратегии. Я не говорю, что нужно вычислять рентабельность инвестиций, так как на данной стадии, имея всего лишь истории, это сложно сделать. Просто обсудите в общем, какую пользу получит организация, если решение будет реализовано;

• каков ее размер. На этом уровне, даже если размах идей велик, мы можем сделать осторожные оценки времени на разработку, пусть даже они и не будут особенно точными. Лучше всего рассмотреть данную возможность в сравнении с чем-то, что мы уже делали раньше: «Это звучит похоже на ту, другую функцию, которую мы выпустили в прошлом релизе. На нее потратили несколько недель, значит, и эта займет примерно столько же». Для принятия решения о том, стоит ли продолжать работу над идеей, полезно знать, сколько времени займет ее разработка – дни, недели или месяцы.