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

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

Но горка капкейков не может быть свадебным тортом… или может?[23]

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

Мой друг Люк Хоуман привел забавную поговорку: «Половина готового торта и наполовину готовый торт – не одно и то же». Половины готового пирога может быть недостаточно для всех гостей на свадьбе, но ее хватит, чтобы все смогли отведать его и с нетерпением ждать добавки.

Изначальная идея историй очень проста: запишите что-то на карточке, обсудите это, согласуйте, что будете разрабатывать. А после завершения разработки закончите цикл анализом того, что у вас вышло и чему это можно научить. Вот и все – не правда ли, просто? Если вы хоть немного работали в сфере разработки программного обеспечения, то знаете, что ничего простого тут нет. Истории проходят долгий пусть с множеством обсуждений, вовлечением множества людей, чтобы сначала продвинуть идею продукта, функциональности или улучшения, а потом продвинуть этот продукт на рынке. Хорошая новость в том, что вы можете использовать истории и их изложение на протяжении всего пути. И я обещаю, что, положившись на метод историй, вы окажете себе значительную услугу.

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

Изначальная идея заключалась в том, что пользователь или другое лицо, которое в чем-то нуждается, может записать свою потребность на карточке, а затем мы можем это обсудить. Тот, от кого поступил запрос, не заботился о том, много ли времени потребуется на решение его проблемы, – он просто сформулировал потребность как она есть.

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

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

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

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

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

Мой инструмент для разбивания камней – большой молот. И он отлично работает.

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

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