Глава 11. Как дробить камни
Изначальная идея историй очень проста: запишите что-то на карточке, обсудите это, согласуйте, что будете разрабатывать. А после завершения разработки закончите цикл анализом того, что у вас вышло и чему это можно научить. Вот и все – не правда ли, просто? Если вы хоть немного работали в сфере разработки программного обеспечения, то знаете, что ничего простого тут нет. Истории проходят долгий пусть с множеством обсуждений, вовлечением множества людей, чтобы сначала продвинуть идею продукта, функциональности или улучшения, а потом продвинуть этот продукт на рынке. Хорошая новость в том, что вы можете использовать истории и их изложение на протяжении всего пути. И я обещаю, что, положившись на метод историй, вы окажете себе значительную услугу.
Размер имеет значение
В предыдущей главе мы остановились на торте Сидни и идее разделения больших тортов на маленькие тортики. Но программный продукт – несколько менее осязаемая вещь, и, в отличие от торта, его нельзя измерить в дюймах, сантиметрах, унциях или граммах.
Изначальная идея заключалась в том, что пользователь или другое лицо, которое в чем-то нуждается, может записать свою потребность на карточке, а затем мы можем это обсудить. Тот, от кого поступил запрос, не заботился о том, много ли времени потребуется на решение его проблемы, – он просто сформулировал потребность как она есть.
С точки зрения пользователя размер истории верен, если он удовлетворяет его потребность.
Когда приходит время писать код, можно оценить значительные преимущества программирования, тестирования и интеграции программного продукта по небольшим частям. Если я смогу вскоре увидеть и протестировать маленькие части, значит, смогу и судить о том, как быстро продвигается наша разработка и каков ее уровень качества. Если я могу разделить что-то большое на много маленьких частей, членам моей команды легче брать в работу и выпускать эти части одновременно. Можно взять за правило делить истории на части такого размера, чтобы на их программирование и тестирование требовалось не более нескольких дней.
С точки зрения команды разработки, размер истории верен, если программирование и тестирование занимает не более пары дней.
Но с точки зрения бизнеса может быть более разумно предъявлять пользователям и заказчикам программное обеспечение, содержащее набор нескольких функциональностей. Если вы выпускаете совершенно новый продукт, первая версия может быть довольно большой. Эту версию я ранее называл минимально жизнеспособным решением, и основной целью его разработки было получение особых результатов от выделенной группы пользователей. В идеале бизнес должен стремиться к тому, чтобы почаще и побольше выпускать таких продуктов, размер которых оптимален для пользователей или для получения результатов, отвечающих потребностям бизнеса. Но если вашим продуктом пользуется большая разношерстная группа клиентов и у вас нет инфраструктуры или бизнес-модели, поддерживающей более последовательный процесс релиза, то, конечно, ваши бизнес-релизы могут быть довольно большими.
С точки зрения бизнеса размер истории верен, если он позволяет бизнесу достичь желаемых результатов.
Я мог бы сказать, что правильного размера историй не существует, но это не так. Правильный размер – тот, который соответствует проходящему обсуждению.
Эти большие истории содержат много меньших, которые, в свою очередь, содержат много еще меньших историй. В зависимости от того, с кем вы говорите, возможно, придется перевести обсуждение на более высокий уровень.
Истории похожи на камни
Воспринимайте истории как камни. Если я возьму очень большой камень, положу его посреди комнаты, а затем разобью молотом на 30 осколков, мы назовем их 30 осколками камня. Если вы возьмете один из этих меньших камней и тоже ударите по нему молотом, он разобьется на более мелкие части. Мы и их можем назвать осколками камня. Или подойти творчески и употребить, скажем, слова «валун» или «щебень». Но я не знаю, когда именно что-то перестает быть валуном и становится просто камнем. Он, может быть, и выглядит как простой камень, пока не упадет вам на ногу – тогда-то вы и почувствуете, что это настоящий валун.
Мой инструмент для разбивания камней – большой молот. И он отлично работает.
Большие истории разбиваются на меньшие истории, и эти меньшие истории тоже могут быть разбиты на совсем маленькие. Но любого размера, даже самого маленького, это все равно история. А какой инструмент лучше всего применить для разбивания историй? Правильно: обсуждение. Иногда достаточно просто немного поразмыслить, но если вы обсуждаете историю и работаете над ней совместно с кем-то еще, то одновременно расширяете одинаковое понимание.
Обсуждение – один из лучших инструментов для разделения больших историй на части.
Многие работники сферы IT, и я не исключение, недовольны отсутствием точности в этом аспекте. В большинстве организаций, с которыми я работал, появлялся свой язык для классификации историй по размеру, но в таком случае мы опять-таки упираемся в проблему «валун или щебень». Точность особенно важна, когда этот камень прилетел в вас, что может объяснить, почему программисты так трепетно относятся к классификации своих историй.
Если вы работаете над языком классификации в своей организации, не старайтесь достичь большой точности. Определения истории и ее верного размера довольно неустойчивы, но это позволяет проявлять определенную гибкость при их использовании на протяжении всего цикла разработки.
Эпики – большие камни, которыми иногда кидаются в людей
Эпик – общепринятый термин (я не знаю, кто первым употребил его) для описания крупных пользовательских историй, так же как слово «валун» используется для обозначения очень большого камня. Буду с вами честен: мне понадобились годы, чтобы воспринимать важные вещи, которые мы разрабатываем, как истории, но сейчас я понимаю, почему они так называются. Термин «эпик» смущает меня до сих пор. Насколько я помню, учитель английской литературы объяснял, что эпические поэмы обычно повествуют о героях, борющихся со злом, – Беовульфе, Ахилле, Фродо – обычно с помощью какого-то волшебного оружия или при поддержке богов. Но, кажется, я отвлекся…
Эпик – это история, размер которой считают значительным, и, значит, она должна быть разбита на меньшие части.
Неплохо иметь специальное название для больших историй, но погодите немного. Термин «эпик» нередко используется в качестве оружия. Я нередко наблюдал, как член команды разработки убеждает представителя бизнеса, менеджера продукта, пользователя или кого-то еще, кто о чем-то просит, что его история – это целый эпик, а не просто история. Обычно это произносится таким тоном, словно автор истории сделал что-то не так и нанес члену команды разработки серьезное оскорбление. Поэтому, если вы член команды разработки, не используйте термин «эпик», чтобы кого-то пристыдить. Это плохое начало
