Пользовательские истории. Искусство гибкой разработки ПО - [87]
7. После того как все карточки оказались на своих местах, возьмите стикеры или карточки другого цвета и создайте заголовок для каждой группы. Напишите на этих карточках имя общей истории – то, что объединяет все карточки в группе. Название «Улучшения графического интерфейса» может быть слишком общим – лучше что-то вроде «Улучшить добавление и редактирование комментариев», так становится ясно, что все улучшения касаются комментариев.
8. Таким образом у вас получатся новые большие истории. Остальные карточки составят основу для маркированного списка в их описании. Теперь можно занести получившееся обратно в бэклог. Или, если вся эта работа не срочная, занесите ее в бэклог возможностей.
Этот способ замечательно работает как для огромных бэклогов, переполненных множеством маленьких элементов, так и для больших скоплений багов. Вы знаете, всегда есть множество низкоприоритетных багов, которые никто никогда не исправляет. Объедините их в группы и заведите заново как баги определенной области системы c более высоким приоритетом. Когда разработчик доберется до исправлений багов высокого приоритета в этой области, заодно исправит и низкоприоритетные. Ваши заказчики и пользователи будут вам благодарны.
Не перестарайтесь, составляя карты
Я часто слышу от людей, пытающихся освоить методику работы с картами историй, что там слишком много работы. Задав вопрос, что же показалось им таким сложным, я, как правило, слышу трагическую повесть о попытке создания огромной карты всей их системы для обсуждения небольшой простой функциональности. Они правы – это слишком. Не следуйте их примеру.
Составьте карту только того, что вам нужно для обсуждения вашей функциональности.
Например, я работал с компанией, которая хотела немного изменить функцию комментирования в их программном продукте для совместного редактирования документов. Сначала команда составила высокоуровневую карту процесса редактирования документов, использовав для этого лишь несколько карточек. Затем, подойдя к области комментирования, они добавили еще немного карточек, которые кратко представляли, что их продукт может делать сейчас, с помощью множества записей на каждой из них. После этого началось обсуждение изменений, которые они хотели внести, добавляя уже гораздо больше карточек для всех деталей и вариантов, которые принимались во внимание.
Добавляя функциональность в существующий продукт, составляйте карту необходимой области, начиная с того момента, где функциональность начинается в пользовательской истории, и заканчивая чуть позже того места, где она кончается. Нет нужды строить карту всего вашего продукта.
Помните, что карты историй должны поддерживать обсуждение ваших пользователей и идей продукта. Хорошее правило выборки: если вам не нужно что-то обсуждать, то и карта для этого тоже не нужна.
Не волнуйтесь по пустякам
Я описал весь процесс разбиения камней от начала до конца и даже предостерег вас от преждевременной обработки этих камней по аналогии со старой игрой Atari, так что вы не будете пытаться разбить их слишком рано. Но говоря обо всех этих стратегиях, мы исходили из того, что все новые истории, которые мы рассматриваем, – крупные. На самом деле во многих случаях это не так. После того как вы предъявили новый продукт или функциональность пользователям, вы неизбежно обнаружите множество очевидных мелких недоделок – всякой ерунды, о которой следовало подумать до предъявления, но, к сожалению, вышло не так. Во всяком случае, у меня это происходит постоянно. Для таких вещей я не провожу обсуждение возможностей и не собираю группу для исследования продукта, потому что необходимость этих поправок очевидна всем. Поэтому эти недоделки отправляются прямиком в бэклог ближайшего релиза и обрабатываются членами команды на ближайшем семинаре, в результате чего в продукт быстро вносятся исправления. Тот же самый процесс существует для багов и множества маленьких улучшений.
Это снова мой друг Шериф из Atlassian. На этой фотографии он объясняет мне, что члены команды разработки продукта постоянно собирают и обрабатывают множество мелких улучшений. Они очень волнуются за своих пользователей. Они знают, что стаи мелких багов и неполадок бесят пользователей, и этот факт бесит саму команду. По их словам, это примерно как умереть, «тысячу раз поранившись бумажным листом». Поэтому на стене, рядом с которой команда работает над продуктом Green Hopper, много сгруппированных пометок. Каждый раз, когда какой-нибудь член команды исправляет какой-то мелкий недостаток, он или она делает пометку на стене. Похоже, что в следующем релизе будут исправлены 47 мелких неполадок. Если вы пользуетесь JIRA или Confluence, чуть позже вы можете сказать ребятам спасибо.
Глава 18. Извлекайте уроки из всех своих разработок
Если вы приверженец традиционного подхода к разработке программного обеспечения, то, наверное, думаете, что работа закончена, когда приложение готово. Но разработка Agile и истории предназначены для обучения. Перед тем как приступить к написанию кода, мы тратим много времени на то, чтобы убедиться, стоит ли вообще что-то разрабатывать, и если да, то что именно. А после того, как работа закончена, мы оцениваем полученный результат и спрашиваем себя, стоило ли это создавать и насколько хорошо у нас вышло.
