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