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

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

Не перестарайтесь, составляя карты

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

Составьте карту только того, что вам нужно для обсуждения вашей функциональности.

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

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

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

Не волнуйтесь по пустякам

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

Спасая мир, идите маленькими шажками