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