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

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

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

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

Это Аарон и Майк. Они работают в компании под названием Workiva, где выпускают ряд продуктов на основе платформы Wdesk. Эта организация помогает другим большим компаниям решать серьезные задачи и является одной из крупнейших компаний типа «программное обеспечение как услуга», о которых вы, скорее всего, никогда не слышали.

Аарон и Майк выглядят очень довольными. Но это типично для людей, которые работают вместе над решением сложных задач. Или это потому, что один из парней держит в руке бутылку пива? Нет, дело вовсе не в этом. Они довольны, так как только что нашли решение сложной задачи, а пиво является лишь наградой за труд. Кстати, если вы не получаете пиво или еще какое-нибудь поощрение за решение сложных задач там, где работаете, стоит с кем-нибудь поговорить об этом.

Аарон и Майк только что завершили очередной раунд исследования продукта, и теперь они уверены, что нашли решение, которое стоит разработать и запустить для использования клиентами.

Исследование началось со смутной идеи: выяснить, кому и каким образом могла бы быть полезна функциональности, с которой они начали работать. Они обсудили идею с заказчиками и проверили свои предположения о том, как те работают в данный момент и с какими проблемами сталкиваются. После этого ребята создали простые прототипы. Аарону и Майку оказалось вполне достаточно создать простые электронные прототипы в Axure и удаленно протестировать их вместе с заказчиками, чтобы убедиться, во-первых, что решение применимо и полезно, а во-вторых, что заказчики его оценят. Необходимости встраивать прототип данной функциональности в работающее ПО, чтобы получить ответы на свои вопросы, не было.

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

Очень важно отметить, что эта карта не охватывает весь продукт – она касается лишь функциональности, которую они добавляют в существующее приложение. Вот почему она намного меньше карты Гэри из главы 1 или карты команд Globo.com. Я подчеркиваю это потому, что некоторые ошибочно полагают: они должны составить карту историй всего продукта, чтобы внести крохотное изменение, и по этой причине отказываются от использования карт вообще.

Чтобы внедрить новую функциональность, Майку и Аарону нужно было, чтобы у них и команды выработалось общее мнение о ней. Ребятам из их команды нужно было осознать проблему и возможности для улучшения, а также оценить, сколько времени займет реализация решения. Для этого Майк с Аароном и создали окончательный вариант карты. С ее помощью они изложили историю функциональности шаг за шагом с точки зрения пользователя. Вы заметили, что на карте присутствуют распечатки экранов? При построении карты ее авторы использовали экраны, отмечая на них детали по мере продвижения, чтобы при ознакомлении с историей легче было понять решение. Именно так поступают сотрудники компании Disney, когда излагают сценарий мультфильма с помощью раскадровок.

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

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

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

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

У команды Workiva не было возможности уменьшить количество необходимых элементов в разработке. Они не могли проделать то, что сделала команда Globo.com, как описано в главе 2, то есть оставить часть запланированного на потом. В Workiva было решено, что нужно разрабатывать сразу все. На этапе прототипирования у них уже была возможность исключить многое и подтвердить, что решение до сих пор остается полезным для заказчиков. Тем не менее на карте можно выделить три среза.