Не перестарайтесь, составляя карты
Я часто слышу от людей, пытающихся освоить методику работы с картами историй, что там слишком много работы. Задав вопрос, что же показалось им таким сложным, я, как правило, слышу трагическую повесть о попытке создания огромной карты всей их системы для обсуждения небольшой простой функциональности. Они правы – это слишком. Не следуйте их примеру.
Составьте карту только того, что вам нужно для обсуждения вашей функциональности.
Например, я работал с компанией, которая хотела немного изменить функцию комментирования в их программном продукте для совместного редактирования документов. Сначала команда составила высокоуровневую карту процесса редактирования документов, использовав для этого лишь несколько карточек. Затем, подойдя к области комментирования, они добавили еще немного карточек, которые кратко представляли, что их продукт может делать сейчас, с помощью множества записей на каждой из них. После этого началось обсуждение изменений, которые они хотели внести, добавляя уже гораздо больше карточек для всех деталей и вариантов, которые принимались во внимание.
Добавляя функциональность в существующий продукт, составляйте карту необходимой области, начиная с того момента, где функциональность начинается в пользовательской истории, и заканчивая чуть позже того места, где она кончается. Нет нужды строить карту всего вашего продукта.
Помните, что карты историй должны поддерживать обсуждение ваших пользователей и идей продукта. Хорошее правило выборки: если вам не нужно что-то обсуждать, то и карта для этого тоже не нужна.
Не волнуйтесь по пустякам
Я описал весь процесс разбиения камней от начала до конца и даже предостерег вас от преждевременной обработки этих камней по аналогии со старой игрой Atari, так что вы не будете пытаться разбить их слишком рано. Но говоря обо всех этих стратегиях, мы исходили из того, что все новые истории, которые мы рассматриваем, – крупные. На самом деле во многих случаях это не так. После того как вы предъявили новый продукт или функциональность пользователям, вы неизбежно обнаружите множество очевидных мелких недоделок – всякой ерунды, о которой следовало подумать до предъявления, но, к сожалению, вышло не так. Во всяком случае, у меня это происходит постоянно. Для таких вещей я не провожу обсуждение возможностей и не собираю группу для исследования продукта, потому что необходимость этих поправок очевидна всем. Поэтому эти недоделки отправляются прямиком в бэклог ближайшего релиза и обрабатываются членами команды на ближайшем семинаре, в результате чего в продукт быстро вносятся исправления. Тот же самый процесс существует для багов и множества маленьких улучшений.