В игре «Астероиды» нужна была большая осторожность, чтобы случайно не расстрелять не те астероиды, которые нужно, потому что, однажды разбив, вы не сможете собрать их вновь. А вот однажды разделенные истории собрать заново можно.
Чтобы избежать переполнения бэклога множеством маленьких историй, возьмите группу историй, объединенных одной темой, и запишите все их названия на одной карточке в виде маркированного списка. Дайте им одно общее название и озаглавьте так свою новую карточку. Вуаля – у вас снова есть одна большая история.
Если вдуматься, это просто фантастика. Карточка с написанным на ней названием делает осязаемой и управляемой любую витающую в воздухе идею. Идеи гораздо более податливы, чем камни или горы документов. Иногда мы забываем, что другое название разработки программного обеспечения – труд, основанный на знаниях. Если мы в самом деле забываем это и слишком увлекаемся документами и процессами, наша работа становится чем-то скучным и бюрократичным. А когда я общаюсь с людьми, управляющими огромными бэклогами, сплошь заполненными маленькими историями, то чувствую, что они просто задыхаются от бюрократии.
Объединяйте маленькие истории, чтобы очистить бэклог
Я часто работаю с командами разработки продуктов, бэклоги которых заполнены сотнями элементов. И разумеется, в этом случае чаще всего звучит жалоба на большие сложности с расстановкой приоритетов. Когда я заглядываю в их бэклоги, то часто вижу, что они переполнены множеством маленьких историй. Обсуждение каждого из них и вынесение решения о приоритете может занять долгие часы, а то и дни. Но необходимости в этом нет.
Если бы речь шла об игре «Астероиды», вы бы уже проиграли. Но поскольку это не так, попробуйте просто объединить маленькие истории в несколько больших.
1. Если ваши истории собраны в электронный бэклог, перенесите их на карточки или стикеры. Какой бы инструмент вы ни использовали, там наверняка есть функция печати или экспорта компактного списка. Я использую функцию почтовой рассылки в текстовом редакторе, чтобы создать этикетки для всех историй и затем или наклеить их на карточки, или просто напечатать прямо на карточках.
2. Попросите членов команды, которые понимают систему, помочь вам. Запланируйте совещание в комнате, где много места на стенах или столах.
3. Дайте каждому набор карточек и попросите разложить их на столе или расклеить на стенах.
4. Увидев карточку, которая выглядит похожей на ту, что у вас уже есть, разместите их рядом. Пока не слишком задумывайтесь над тем, что значит похожа, – просто следуйте своей интуиции.
5. Эту работу следует выполнять молча, по крайней мере поначалу. Как вы непременно убедитесь, обсуждение скорее замедляет процесс. Кроме того, использование модели и языка жестов для коммуникации – отличное упражнение для развития.
6. Передвигайте и меняйте местами любые карточки, какие хотите. Моделью управляют все, никто не может решать единолично, где должна находиться какая-либо карточка. Если что-то, как вы считаете, находится не на своем месте, переместите это. Если кто-то не согласен с вами, он (-а) может переместить карточку обратно. Это сигнал к началу дискуссии.
7. После того как все карточки оказались на своих местах, возьмите стикеры или карточки другого цвета и создайте заголовок для каждой группы. Напишите на этих карточках имя общей истории – то, что объединяет все карточки в группе. Название «Улучшения графического интерфейса» может быть слишком общим – лучше что-то вроде «Улучшить добавление и редактирование комментариев», так становится ясно, что все улучшения касаются комментариев.
8. Таким образом у вас получатся новые большие истории. Остальные карточки составят основу для маркированного списка в их описании. Теперь можно занести получившееся обратно в бэклог. Или, если вся эта работа не срочная, занесите ее в бэклог возможностей.
Этот способ замечательно работает как для огромных бэклогов, переполненных множеством маленьких элементов, так и для больших скоплений багов. Вы знаете, всегда есть множество низкоприоритетных багов, которые никто никогда не исправляет. Объедините их в группы и заведите заново как баги определенной области системы c более высоким приоритетом. Когда разработчик доберется до исправлений багов высокого приоритета в этой области, заодно исправит и низкоприоритетные. Ваши заказчики и пользователи будут вам благодарны.
Не перестарайтесь, составляя карты
Я часто слышу от людей, пытающихся освоить методику работы с картами историй, что там слишком много работы. Задав вопрос, что же показалось им таким сложным, я, как правило, слышу трагическую повесть о попытке создания огромной карты всей их системы для обсуждения небольшой простой функциональности. Они правы – это слишком. Не следуйте их примеру.
Составьте карту только того, что вам нужно для обсуждения вашей функциональности.
Например, я работал с компанией, которая хотела немного изменить функцию комментирования в их программном продукте для совместного редактирования документов. Сначала команда составила высокоуровневую карту процесса редактирования документов, использовав для этого лишь несколько карточек. Затем, подойдя к области комментирования, они добавили еще немного карточек, которые кратко представляли, что их продукт может делать сейчас, с помощью множества записей на каждой из них. После этого началось обсуждение изменений, которые они хотели внести, добавляя уже гораздо больше карточек для всех деталей и вариантов, которые принимались во внимание.
Добавляя функциональность в существующий продукт, составляйте карту необходимой области, начиная с того момента, где функциональность начинается в пользовательской истории, и заканчивая чуть позже того места, где она кончается. Нет нужды строить карту всего вашего продукта.
Помните, что карты историй должны поддерживать обсуждение ваших пользователей и идей продукта. Хорошее правило выборки: если вам не нужно что-то обсуждать, то и карта для этого тоже не нужна.
Не волнуйтесь по пустякам
Я описал весь процесс разбиения камней от начала до конца и даже предостерег вас от преждевременной обработки этих камней по аналогии со старой игрой Atari, так что вы не будете пытаться разбить их слишком рано. Но говоря обо всех этих стратегиях, мы исходили из того, что все новые истории, которые мы рассматриваем, – крупные. На самом деле во многих случаях это не так. После того как вы предъявили новый продукт или функциональность пользователям, вы неизбежно обнаружите множество очевидных мелких недоделок – всякой ерунды, о которой следовало подумать до предъявления, но, к сожалению, вышло не так. Во всяком случае, у меня это происходит постоянно. Для таких вещей я не провожу обсуждение возможностей и не собираю группу для исследования продукта, потому что необходимость этих поправок очевидна всем. Поэтому эти недоделки отправляются прямиком в бэклог ближайшего релиза и обрабатываются членами команды на ближайшем семинаре, в результате чего в продукт быстро вносятся исправления. Тот же самый процесс существует для багов и множества маленьких улучшений.
