Что теперь? Если истории нужны для планирования и управления дискуссиями, с помощью которых разрабатывается программное обеспечение, похоже, всем нам придется очень много разговаривать.
Карточки, обсуждения, много карточек, много обсуждений…
Первая серия обсуждений помогла вам проникнуть в смысл открывшейся возможности. Вы обсудили, кто мог бы использовать ваш продукт, и представили, каким образом эти люди могли бы извлечь для себя пользу. Ваши дискуссии были достаточно глубоки, чтобы разбить большую возможность на компактные части и затем решить, какие из них должны войти в ближайший релиз, а какие можно отложить. Вы собрали истории, которые описывают следующий жизнеспособный релиз, в бэклоге.
Если вы разумный человек, а я уверен, что это так, следующие обсуждения затронут то, как должно выглядеть приложение, как оно будет себя вести, как изменения встроятся в уже существующий продукт и программную архитектуру. Наибольшее внимание в этих дискуссиях уделяется рискам. Вы разделили идею на части, которые можно быстро разработать и в результате как можно больше изучить за короткое время. А поскольку вы разумный человек, истории в вашем бэклоге разделены по следующему принципу: на ранних этапах – изучение, в середине – активная разработка, в конце – совершенствование и корректировка.
Сейчас наконец настало время для проведения лучших, завершающих обсуждений.
Огранка и полировка
Мы приступили к работе с огромным энтузиазмом. Мы уверены: разработка программного обеспечения, которое описано в наших историях, будет идти гладко и без сюрпризов, если мы точно сформулируем, что именно хотим разработать. Но даже после всех этих обсуждений и составления историй обычно обнаруживается некоторое количество острых углов, на которые все постоянно натыкаются. Скорее всего, во время обсуждений не удалось внимательно рассмотреть эти моменты, как следует разобраться, какими они должны быть, и точно предсказать, сколько времени потребуется на их разработку. Но не стоит расстраиваться – у нас есть волшебная машина, которая быстро все исправит.
Представьте себе компактную и красивую волшебную машину. В большую воронку с левой стороны мы бросаем грубоватые шероховатые истории из нашего релизного бэклога. Изнутри машины доносятся свист, звон и клацанье. После этого из тонкой трубочки с правой стороны выходят маленькие, аккуратно отполированные изделия. Каждое изделие – это элемент, который команда может использовать, чтобы разработать идеальное, изящное, высококачественное программное обеспечение.
Со стороны такая машина и в самом деле кажется волшебной. Но внутри нее вы и ваша команда обсуждаете, дорабатываете и совершенствуете попавший в машину элемент. Этот особый секретный механизм, скрытый внутри машины, называется семинаром по историям.
Как вы, вероятно, помните из главы 11, семинары по историям – это небольшие, но продуктивные обсуждения, где все работают вместе, чтобы проговорить истории еще один, последний раз и в процессе твердо решить, что именно они собираются создать. Это очень глубокие обсуждения историй, результатом которых становится подтверждение принятых решений. Это значит, что мы подошли к третьему «П» в триаде «пишем – проговариваем – подтверждаем». И именно это «П» поможет нам окончательно огранить и до блеска отполировать наши камни.
Проведение семинаров по историям
Вам понадобится небольшая группа людей, куда должны войти программист, тестировщик, специалисты по изучению пользователей и интерфейса – дизайнеры UI или аналитики в зависимости от того, как принято в вашей организации. Чтобы работа у доски была эффективной, группа не должна быть очень большой. Обычно – от трех до пяти человек.
На семинаре нужно работать, а не просто разговаривать. Совещание давно уже стало эвфемизмом непродуктивного совместного времяпрепровождения. В течение семинара должно состояться много продуктивных обсуждений, детальных объяснений. Нужно чертить схемы на доске и рисовать эскизы в блокноте. Необходимо сотрудничество, чтобы как можно точнее решить, что именно мы разрабатываем. Нужно стремиться к тому, чтобы все участники покинули комнату совещаний с прочным ощущением одинакового понимания, поэтому должно обеспечиваться пространство для продуктивных обсуждений на словах и в картинках.
Предметом всех обсуждений до этого момента были детали, но мы погружались в них ровно настолько, чтобы принять необходимые на тот момент решения. Теперь же нужно принимать решения, чтобы точно ответить на вопрос: «Что конкретно мы разрабатываем?»
Возможно, именно при этом обсуждении выяснится, что ваша история слишком велика. Я подразумеваю под этим – слишком велика для предмета, который можно немедленно отдать в разработку и на его реализацию понадобится примерно пара дней. Да, размер не всегда оказывается слишком большим, но если вы подозреваете что-то в этом роде, просто проверьте и порадуйтесь, если убедитесь в обратном. В любом случае, в комнате вместе с вами находятся как раз те люди, которые должны помочь разбить эту историю на более мелкие. Размер историй должен быть таким, чтобы было удобно их реализовать, тестировать и выпустить в рамках продукта, над развитием которого работает вся команда.
Рецепт семинара по историям
Используйте семинары по историям, чтобы довести понимание до совершенства и точно определить, что конкретно должна создать команда разработки. Семинар – это обсуждение продукта (поддерживаемое множеством данных и картинок), которое поможет команде принять необходимые решения и определить признаки готовности, то есть критерии приемки того, что было решено разработать.
Перед началом семинара нужно уведомить команду о историях, которые вы планируете обсуждать. Развесьте их на стенах или разошлите по электронной почте. Попросите команду проголосовать, учтите их мнение при окончательном выборе.
Небольшое количество людей – условие продуктивности семинара . От трех до пяти человек – наилучший вариант.
Тщательно подбирайте участников . Чтобы обсуждение было эффективным, включите:
• кого-то, кто хорошо понимает пользователей и пользовательские интерфейсы, их требования и возможности, – чаще всего это владелец продукта, специалист по пользовательскому взаимодействию или бизнес-аналитик;
• одного или двух программистов, имеющих представление о коде, который вы хотите добавить в продукт, и поэтому хорошо понимающих степень реалистичности разработки;
• тестировщика, отвечающего за качество продукта, потому что именно он задаст каверзные вопросы, известные как «Что, если», о которых не подумают остальные, обычно настроенные оптимистично.
Другие люди и другие роли тоже могут быть полезны, но не забывайте об оптимальном количестве участников дискуссии – не больше, чем в компании за обеденным столом.
Вы убедитесь, что один человек вполне может выступать в двух ролях, или, как говорят, носить сразу две шляпы. Например, во многих IT-организациях я встречал тестировщиков, одновременно исполняющих обязанности бизнес-аналитиков. Но если силами присутствующих не удалось преодолеть все камни преткновения, приостановите семинар и найдите кого-то еще, кто может помочь в решении трудного вопроса.
Тщательно анализируйте и рассматривайте варианты . Используйте обсуждения, чтобы детально проанализировать:
• кто конкретно ваши пользователи;
• как конкретно, по мнению команды, они будут использовать продукт;
• как конкретно будет выглядеть продукт, то есть его интерфейс;
• как конкретно ведет себя программный продукт внутри интерфейса – какие бизнес-правила действуют, как нужно валидировать данные;
• сколько времени потребует разработка продукта с учетом всех технических деталей (на этом этапе мы обсуждаем все настолько подробно, что оценки могут быть довольно точными).
Помните: пока еще ничего не решено окончательно. Если дискуссия приводит к решениям, которые слишком сложны или дороги, вернитесь на шаг назад и обсудите проблемы, которые вы решаете, а также альтернативные способы решения.
Придите к соглашению о том, что нужно разработать . После того как по результатам обсуждения вам удалось выработать одинаковое понимание, перейдите к поиску ответов на вопросы.
• По каким критериям можно будет определить, что работа над программным обеспечением закончена?
• Что будет происходить во время демонстрации программного обеспечения, когда мы будем оценивать его все вместе?
Говорите и записывайте . Используйте доски или большие листы бумаги, чтобы рисовать картинки, записывать примеры и рассматривать варианты. Не позволяйте своим решениям испариться. Записывайте их на досках или на бумаге, чтобы каждый мог их видеть. Сфотографируйте записи и картинки, чтобы позднее задокументировать информацию.
Оперируйте примерами . Где только возможно, используйте специфические примеры поведения пользователей: какие конкретно данные могут быть введены, что именно пользователи увидят в результате, – словом, любые примеры, которые лучше всего иллюстрируют вашу историю.
Разделяйте и уменьшайте . Обсуждая детали и думая о затратах на разработку, вы, возможно, обнаружите, что истории слишком велики, чтобы уместиться в стандартный цикл. Поработайте вместе с группой, чтобы разделить крупные истории или уменьшить их, удалив все лишнее.
Но все это не будет работать, если:
• нет совместной работы – кто-то один описывает, что нужно сделать, а все остальные слушают;
• разговор идет только о критериях приемки, но никто не вспоминает об истории и о «Кто?», «Что?», «Почему?»;
• не рассматриваются варианты реализации как с функциональной, так и с технической стороны.
Планирование спринта или итерации
Некоторые практики Agile воспринимают эти важнейшие обсуждения историй во время сессий планирования как планирование итерации или спринта. Это не так страшно, если вы имеете дело с командами, эффективно работающими вместе и начинающими дискуссию, хорошо понимая своей продукт. У команд, с которыми я работал на протяжении многих лет, это был устоявшийся способ работы.
Тем не менее самая частая жалоба, которую я слышу от команд, работающих по Agile, заключается в том, что эти совещания по планированию – зачастую долгие изматывающие мероприятия. В какой-то момент все соглашаются разработать то-то и то-то, даже если на самом деле никакого общего понимания нет, просто чтобы закончить это мучительное совещание.
Быть среди своих
Никола Адамс и Стив Барретт, RAC Insurance (Perth, Australia)
Мой первый опыт работы в мире проектов Agile в роли бизнес-аналитика был тяжелым и горьким уроком о превосходстве командной работы над печатным словом.
Никола Адамс
Контекст
Историю трансформации от методологии водопада к Agile в компании RAC Incurance (Западная Австралия) рассказывает Никола, квалифицированный бизнес-аналитик с большим опытом в традиционном подходе к разработке программного обеспечения. В ее обязанности входило сотрудничество с бизнесом, понимание предметной области и составление функциональных спецификаций, в соответствии с которыми команда IT создавала продукт. Коммуникация происходила по следующей схеме.
Наибольшее внимание уделялось детальным спецификациям, где старались не пропустить ни одной детали. Поскольку было очевидно, что разработчики не читают документацию, были внедрены специальные стратегии смягчения проблемы (например, пошаговые руководства по спецификациям), но они не решали ее полностью. Как правило, между окончанием работы над спецификацией и моментом, когда ее нужно было использовать для поддержки разработки и тестирования, проходило довольно много времени.
С чего все началось?
Устоявшийся подход к письменным спецификациям не стали отменять в одночасье. Концепцию написания требований на обратной стороне карточки внедрить было нелегко. Как Никола могла ожидать, что разработчики и тестировщики внедрят необходимую функциональность, за которую она несла ответственность, если у них нет необходимой информации? Фокус просто переместился на создание последовательностей действий пользователя, почти ничем не отличающихся от традиционных функциональных требований, за исключением размера; схема коммуникации не изменилась.
Чтобы передать требования команде на сессиях разработки, Никола:
• собирала требования партнеров по бизнесу;
• глубоко анализировала требования и данные;
• создавала последовательности действий пользователя (каждая занимала от одной до пяти страниц), где описывались требования, дизайн решения и критерии приемки;
• излагала эти требования команде с использованием проектора и отвечала на вопросы присутствующих.
К несчастью, результаты не впечатляли. Подготовительные сессии были скучными и утомительными, большая часть команды никак не включалась в обсуждение. Кроме того, Никола чувствовала, что зря тратит время на подготовку историй, так как команда чаще всего игнорировала их во время разработки.
После одной из сессий Сэм, эксперт в предметной области, одновременно играющий роль владельца продукта, заметил: «Если это и есть проект Agile, я не желаю в этом участвовать!»
Нужно было что-то делать.
Что поменялось?
Менеджер проекта Стив собрал команду, чтобы обсудить проблему. В результате команда приняла несколько важных решений: исключить из процесса документы с историями, привлечь к подготовке историй как команду бизнеса, так и разработчиков, а также явно включить в процесс окончательную обработку бэклога и работу над историями.
Теперь Никола не просто выполняла требуемые от нее действия, а активно участвовала в процессе. Следующая сессия разработки разительно отличалась от всех предшествующих. В конференц-зале не сидела скучающая команда, пассивно наблюдающая за экраном, где демонстрировались истории действий пользователя. Члены команды, включая владельца продукта, экспертов в предметной области и разработчиков, активно работали с визуальными моделями и другими артефактами и живо обсуждали истории.
Схема коммуникации изменилась. Никола больше не работала «испорченным телефоном» между бизнесом и IT – теперь она выступала координатором обсуждений между теми, кто понимал цели бизнеса, теми, кто хорошо знал нужды пользователей, и командой разработки, которая знала, что можно реализовать.
И представителям бизнеса, и команде разработки очень понравился новый формат, все они активно включились в процесс. Наконец удалось достичь одинакового понимания проблем, требующих решения, различные точки зрения, существовавшие в группе, позволили команде найти оптимальные решения в условиях ограничений, а Никола уже не чувствовала такого сильного давления и больше времени посвящала работе. Никола наконец ощутила себя своей!
В толпе не может быть сотрудничества
Утомительные совещания по планированию – такая распространенная проблема, что многие команды интуитивно предпочитают проводить обсуждения историй в дни, предшествующие таким совещаниям. Как правило, такие обсуждения занесены в их ежедневники как «совещания по предпланированию», «окончательная обработка бэклога» или «лакировка бэклога». Но что происходит чаще всего? Та самая тягомотина, которую они так ненавидят на планировании, просто переносится на другой день. Словно пытаясь усугубить проблему, членов команды просят прервать их текущую продуктивную работу, чтобы посидеть на скучном совещании. Неудивительно, что никто не испытывает восторга по этому поводу.
Проблема не в том, что обсуждать истории очень сложно. Да, иногда это может вызывать трудности, но абсолютно любые обсуждения станут гораздо тяжелее, если вы попытаетесь привлечь к ним слишком много людей. Если к тому же большая часть этих людей не заинтересована в участии или не мотивирована, считайте, что дело провалено. Вы знаете, о ком я говорю, – эти люди надеются, что никто не замечает их смартфоны, на которых они играют под столом.
Позвольте членам команды самим решать, хотят ли они участвовать в обсуждении. Если позднее они будут жаловаться на принятые решения, просто не забудьте пригласить их в следующий раз.
Если хотят участвовать все, попробуйте шаблон сотрудничества «Аквариум», описанный в следующем примере. В этом случае заинтересованные могут прийти, принять участие, если хотят, или уйти, если обнаружат, что не происходит ничего интересного.
Шаблон сотрудничества «Аквариум»
Если среди ваших сотрудников найдется несколько человек, которые очень хотят, чтобы их пригласили на обсуждение, но количество участников и без того так велико, что под угрозу поставлена продуктивность, попробуйте шаблон сотрудничества «Аквариум». Он заключается в том, чтобы дать им возможность присутствовать, не участвуя активно или минимально влияя на окончательный результат. Чаще всего люди обнаруживают, что происходящее не настолько важно, как они ожидали. Спустя какое-то время вы и сами заметите, что они охотно предоставляют другим возможность обсуждать детали, а затем узнают результаты из последующих обсуждений.
Процесс происходит так: от трех до пяти человек работают вместе у доски. Это значит, что они в аквариуме.
Другие находящиеся в комнате могут наблюдать за ними и слушать, но не говорить. Они – вне аквариума.
Если кто-то находящийся вне аквариума хочет принять участие, он может «нырнуть». Но когда один человек заходит извне, кто-то изнутри должен «вынырнуть».
Таким образом обсуждение остается компактным и продуктивным, все информированы и включены в процесс. Кроме того, это хороший способ обучения: новички включаются в процесс, не замедляя его скорости.
Важность компактности
Помните обсуждение торта и капкейков из главы 10? Сейчас как раз настало время разбить наши торты на капкейки наименьшего размера из возможных. Именно сейчас, когда присутствуют разработчики, тестировщики и другие специалисты, непосредственно участвующие в создании программного продукта, можно по-настоящему взяться за разделение истории на части.
Надеюсь, вы знаете, что корень слова software (программное обеспечение), soft, означает «мягкий». Это значение не ограничивается тем, что мы подразумеваем, говоря о губках или булочках. Лучше подойдет ассоциация с большим документом или книгой. Если бы вы писали книгу, как стараюсь делать сейчас я, вы бы не пытались сделать все за один раз. Вы бы написали, допустим, главу в один присест. Я, например, пишу за раз одну главу, а Питер, опытный и доброжелательный редактор, с которым я сотрудничаю, просматривает ее, делая необходимые предложения и поправки.
Но это не значит, что глава готова. До этого еще далеко.
Мне нужно вернуться к ней снова и подумать, где в тексте должны быть иллюстрации. Я должен решить, стоит ли добавить сноски, ссылки, объяснения терминов из глоссария или элементы указателя. Затем другие редакторы издательства проходятся по всем главам, внося финальные правки. Получается, что я разделяю работу, делая ее итерационно, и таким образом вижу, как книга постепенно обретает форму.
Сейчас вы читаете главу «Огранка, полировка, разработка». Если так, то, видимо, это значит, что мой тортик успешно испекся. Если бы я решил позаботиться о финальных критериях приемки, то, наверное, сформулировал бы такие.
• Материал понятен мне и лично проверен мной.
• Материал понятен моим редакторам и отредактирован ими.
• Книга снабжена иллюстрациями, которые облегчат читателям понимание материала и визуализируют ключевые моменты.
• Книга снабжена предметным указателем, с помощью которого читатели легко могут найти объяснение термина в соответствующей главе.
• Книга снабжена глоссарием, который читатели могут использовать, чтобы уточнить определения терминов, встречающихся в данной главе.
Это немаленькое количество работы. Даже сейчас, печатая первый, черновой вариант критериев, я понимаю, что предстоит сделать еще очень много. Но я не собираюсь закончить все это до перехода к следующей главе, потому что мне хотелось бы сначала увидеть книгу целиком. Поэтому я разбиваю работу на капкейки – маленькие законченные фрагменты, не готовые к публикациям, но поддерживающие мою уверенность в том, что я двигаюсь в правильном направлении, работая над книгой.
Я разделил бы работу над книгой на следующие истории.
• Огранка, полировка и создание первого чернового текста.
• Огранка, полировка и создание второго чернового текста.
• Огранка, полировка и создание текста с иллюстрациями.
• Огранка, полировка и создание текста с учтенными замечаниями и поправками.
• Огранка, полировка и создание текста с предметным указателем.
• Огранка, полировка и создание текста с глоссарием.
• Огранка, полировка и создание окончательной версии текста.
Для каждого из этих этапов я могу создать полноценную историю, в которой описано, что представляет собой этап, а также перечислены шаги, которые я (с помощью Питера в части редактирования) должен проделать, чтобы получить в конце этапа текст со всеми запланированными улучшениями и поправками. Как вы можете видеть, по мере завершения каждого этапа глава становится все более проработанной и приближается к состоянию готовности. Теоретически вы вполне могли бы прочитать и даже найти небесполезной первую версию, которая появилась после завершения первого этапа. Но я не хочу ее никому показывать, и вряд ли она бы вам очень понравилась.
Поскольку я уверен, что вы хорошо знаете свое дело, думаю, вы заметили, что этот список маленьких компактных историй во многом очень похож на критерии приемки для этой главы. В этом и заключается суть. Именно обсуждение критериев приемки должно подсказать нам, на какие меньшие части лучше всего разбить работу, чтобы их удобно было создавать и контролировать по ходу дела.
Очень важно контролировать работу постоянно, чтобы можно было оценить ее и при необходимости скорректировать курс. Вот здесь, например, вы могли бы прочитать очень неудачный пример, который я изначально вставил в это место. Но этого не произойдет, потому что, написав текст, я позже перечитал его и удалил этот пример.
При традиционном подходе к разработке программного обеспечения работу по контролю и удалению неудачных фрагментов непременно объяснили бы плохими требованиями. Но после того, как вы надели плащ и шляпу рыцаря Agile, эта работа становится обучением и итеративным улучшением.
Игра «Хорошо – лучше – идеально»
Одна из моих любимых и очень простых техник окончательного разбиения историй – игра «Хорошо – лучше – идеально». Чтобы играть в нее, нужны большая история и пачка стикеров. Результат игры выглядит примерно так.
Довольно хорошо… пока
Как только у вас появится история, обсудите для начала, что достаточно сделать, чтобы она просто хорошо работала. Пока не стоит думать о том, как вызвать у клиентов восхищение, хватит минимально рабочего состояния. Запишите характеристики, которые обеспечат состояние «достаточно хорошо», и в дальнейшем относитесь к ним как к отдельным небольшим историям.
Если рассмотреть в качестве примера, скажем, IMDb.com (the Internet movie database – интернет-база данных кинофильмов), мы можем обсудить историю «Просмотреть информацию о фильме». Представим себе экран, где можно увидеть разные подробности о фильме и, таким образом, принять решение, стоит ли его смотреть. Обсуждая этап «довольно хорошо», можно ограничиться следующими простыми вещами.
• Просмотреть базовую информацию: название, рейтинг, режиссер, жанр и т. д.
• Просмотреть постер фильма.
• Просмотреть трейлер.
Лучше
Затем спросим себя, что может сделать историю лучше. Продолжая рассматривать пример с кинофильмами, можно добавить такие пункты.
• Прочитать аннотацию к фильму.
• Прочитать рейтинги участников.
• Прочитать рейтинги в обзорах.
• Просмотреть список всех актеров фильма.
Идеально
Наконец, подумайте, что может сделать историю потрясающей. На этом этапе не бойтесь самых безумных идей. Помните: вы не пишете требования. Это просто варианты, которые будут рассмотрены вами совместно с командой. Зачастую в таких дискуссиях зарождаются самые блестящие идеи – то, что может сделать ваш продукт выделяющимся, но оказывается удивительно недорогим в реализации. Продолжая работу с примером, можно добавить следующее.
• Посмотреть альтернативные обзоры или видео об этом фильме.
• Почитать любопытные факты о фильме.
• Почитать новости о фильме.
• Почитать дискуссии об этом фильме и принять в них участие.
Как видите, прогрессия небольших историй может помочь развить историю «Просмотреть информацию о фильме» от простого состояния, когда мы можем лишь убедиться в его работоспособности, до возможностей, которые сделают эту историю поистине впечатляющей. Если бы я занимался этой функциональностью, то создал бы базовые вещи всего приложения, прежде чем двинуться к стадиям улучшения и доведения до идеала. Работая таким образом, я куда безопаснее чувствую себя, приближаясь к дедлайнам.
Когда обсуждения историй станут по-настоящему хорошими, а я знаю, что скоро так и будет, в конце семинара по историям вы должны получить набор историй верного размера, снабженный множеством дополнительной документации и различных моделей, а также критериями приемки, где будет описано, как вы собираетесь убедиться в том, что работа над историей успешно завершена. Иногда требуется несколько семинаров, дополненных несколькими внешними исследованиями, анализом данных и дизайнерской работой, прежде чем удастся прийти к соглашению, но это нормально. Огранка и полировка всегда требуют времени и терпения.
Рецепт планирования цикла разработки
В процессах Agile, таких как Scrum или экстремальное программирование, используется принцип ограничения времени разработки . Это значит, что каждый цикл разработки начинается с сессии планирования, а заканчивается оценкой сделанного. Во многих компаниях эти два вида совещаний – самые ненавистные из всех. Чаще всего они длинные и очень утомительные, и к тому времени, когда члены команды могут покинуть конференц-зал, они готовы согласиться с чем угодно, лишь бы выбраться на свободу. Очевидно, что качество составленных планов при таком подходе невысоко.
Но этот подход – не единственный из возможных.
Вот простой рецепт, который поможет вам избежать самых распространенных проблем.
Подготовка
Выберите истории, над которыми будете работать следующие один-два цикла . Если вы владелец продукта, периодически уточняйте у членов ключевой команды, работающей над продуктом, состояние функциональностей, находящихся в данное время в разработке. Выберите для добавления те истории, которые помогут приблизить эту работу к релизу.
Проведите предварительный семинар . Выделите время, чтобы члены ключевой команды продукта могли посовещаться между собой перед сессией планирования. Погрузитесь в детали, разделите на части большие истории, предусмотрите несколько вариантов. Перечитайте историю Мэта Кроппера из главы 7. Когда я общался с Мэтом, он возлагал самые большие надежды на серии коротких получасовых спонтанных семинаров по историям, на которых программисты и тестировщики готовились к планированию.
Пригласите всю команду , а также других людей, чья помощь может вам потребоваться в предстоящем цикле разработки.
Планирование
Начните с обсуждения стратегической цели предстоящего цикла. Вы выбрали несколько историй, над которыми собираетесь работать. Как именно эта группа историй будет способствовать прогрессу решения, которое вы планируете выпустить?
Просмотрите истории, которые планируете обсудить . Не следует слишком углубляться в детали – просто хорошо передайте общую картину. Вернитесь к истории Николы и Стива, рассказанной в этой главе. Посмотрите на фотографию, где Никола стоит на фоне стены: на ней очень много слов и картинок, с помощью которых члены команды легко могут представить себе общую картину. Очень разумный подход.
Дайте командам время на самостоятельное планирование . Помните: толпа не может сотрудничать. А специалистам, которые будут разрабатывать и тестировать программный продукт, необходимо продумать собственные рецепты создания историй – точно так же, как делала Сидни из главы 10. Дайте командам примерно час на то, чтобы они разбились на небольшие группы и хорошенько обдумали свои истории. Если вы владелец продукта, UI-дизайнер или бизнес-аналитик, оставайтесь где-то поблизости. Наблюдайте, если хотите. Будьте готовы ответить на вопросы, которые помогут им продвигаться быстрее.
Работая в маленькой группе, создайте план для каждой истории . Помните трех амиго, о которых мы говорили в главе 12? Возьмите их за образец при формировании групп. Затем как команда разработки решите, сколько историй могут быть успешно завершены в данном цикле разработки. Не забудьте принять во внимание праздники и отпуска. Однажды мне рассказывали историю, как замечательный план разработки провалился из-за Дня благодарения – как будто никто не знал о том, что приближается этот праздник!
План должны утвердить все . В конце выделенного промежутка времени, после того как команда составит свой план для каждой истории, нужно снова собраться вместе и поделиться своим планом с остальными. Не стоит подробно рассказывать обо всех деталях, это не слишком интересно даже вашим коллегам. Что им интересно, так это какие функциональности будут созданы вашей командой в конце цикла. Команда должна отнестись к плану и соглашениям очень серьезно, если хочет иметь репутацию надежной и ответственной.
Чтобы достичь соглашения, может потребоваться некоторое время , особенно если вся работа, которую нужно сделать, не умещается в заданное время разработки. К счастью, вы знаете несколько приемов разбиения историй, описанных ранее. Попробуйте также рассмотреть реализацию истории в состоянии «хорошо», а не «лучше». Это должно помочь уместить в итерацию или спринт все необходимое.
Отдыхаем! Все готово. В прошлом мы любили выполнять планирование днем, чтобы закончить этот процесс за какое-то время до конца рабочего дня, а затем отмечали это событие, расходясь по домам пораньше. На следующий день все приходили отдохнувшими и готовыми начать работу по плану, составленному накануне.
Используйте карту историй во время разработки
Используйте карту, чтобы у членов команды разработки выработалось одинаковое понимание. Я часто слышу от участников различных команд, работающих по процессу Agile, как сильно они любят помогать друг другу и какими продуктивными чувствуют себя, потому что каждую неделю или две видят и демонстрируют работающие программные продукты. Но потом они всегда говорят нечто вроде: «Я, кажется, утратил понимание общей картины. Все, что я вижу, – это маленькие части продукта, который мы создаем». Используйте карту, чтобы облегчить команде понимание продукта в целом или функциональности, над которой вы работаете. Нахождение тактических проектных решений и выполнение задач разработки будет куда эффективнее, если люди хорошо понимают контекст, в который должна встроиться их работа.
Используйте карту для визуализации прогресса
Начав разрабатывать свой продукт к предстоящему релизу, активно пользуйтесь картой: она представляет собой отличную визуальную панель, на которой хорошо видно, что вы уже построили, а что – еще нет.
Одни команды предпочитают убирать детализированные истории с карты после того, как работа над ними завершена. Таким образом, лишь взглянув на карту, можно узнать, что еще осталось сделать.
Другие, не изменяя структуру карты, используют фломастеры или цветные стикеры, чтобы помечать законченные истории. Отойдя назад и взглянув на карту, они легко отделяют то, что уже сделано, от того, что осталось сделать.
Используйте карту, чтобы определить следующие истории для разработки. Каждую неделю владельцы продукта должны оценить, насколько продвинулась работа, а затем принять решение, за что нужно взяться в следующую очередь. Когда карта визуализирует прогресс, ее намного проще просканировать взглядом и выявить области, которые требуют больше внимания. Примерно так работают художники. Отступив на шаг назад и окинув взглядом картину, они могут определить, в каком месте требуется нанести пару мазков.
Используйте простые карты во время семинаров по историям
В каждом цикле разработки вы определяете в карте истории, которые должны пойти в работу следующими. Вы приносите эти истории на заключительные, самые продуктивные обсуждения, проходящие во время семинара по историям.
Во время семинара вы можете применить визуализацию, построив самую простую карту. Возможно, она будет состоять всего из трех-четырех шагов, которые делает пользователь, работая с обсуждаемой сейчас функциональностью. Но размещение этих нескольких шагов в виде стикеров на стене наглядно проиллюстрирует последовательность и сделает дискуссию живее. Начав обсуждать критерии приемки, напишите их на стикерах и добавьте на эту мини-карту. В конце вы получите очень простую визуализацию, которая поддержит обсуждение, состоявшееся на семинаре.
Визуализация рабочего бэклога
Крис Гансен и Джейсон Канеш
Интернет навсегда изменил политику, что доказала избирательная кампания президента Обамы в 2008 году. Онлайн-стратегия Барака Обамы сыграла непосредственную и значительную роль в его продвижении и последующем избрании. Поэтому стратегия выборов 2012 года включала в себя обеспечение сервисов, которые поддерживали массовый сбор средств и традиционное движение снизу, при использовании технологий в качестве коэффициента силы, чтобы компенсировать огромное количество денег со стороны, вращающихся в предвыборной гонке. Мы использовали специальные инструменты, такие как Pivotal и Basecamp, для отслеживания своей работы по созданию личного кабинета кампании Обамы 2012 года, а для того, чтобы все остальные могли легко понять, что происходит, мы использовали стену, которую вскоре полностью заклеили стикерами. Вы можете удивиться, зачем мы тратили время на возню с этими дурацкими стикерами? А вот почему.
Так вышло, что в одном пространстве и над одной целью работали две совершенно разные культуры. Мы сидели в углу, выкрутив лампочку, чтобы работать в относительной темноте. Мы притащили собственные шумные клавиатуры. Мы носили гигантские наушники, чтобы заглушить шум новостей и интервью по кабельному телевидению, звонки и аплодисменты, которые проникали в пространство нашего офиса. Мы даже носили футболки метал-групп вместо официальных костюмов. Все люди, работавшие в предыдущих кампаниях, все эти ребята в наглухо застегнутых костюмах с галстуками имели традиционные взгляды на разработку программного обеспечения. «Мы описываем функции, которые нам нужны, а вы их для нас разрабатываете. Срок – вчера». Они не привыкли к постепенному предъявлению функций и итеративным изменениям или улучшениям, и они уж точно не будут искать оптимальные соотношения, чтобы получить нужные функции в тот момент, когда они могут дать наибольший эффект. Это предвыборная кампания! Нельзя сместить дату представления продукта, разве что указом конгресса! На следующий день после выборов все заканчивается независимо от того, успели мы или нет. Поэтому о том, чтобы они получили абсолютно все, чего хотели, и речи не шло.
Приступив к работе, мы использовали некий базовый подход к составлению карты, чтобы описать людей, использующих нашу систему, и самые различные их потребности. Мы могли затем организовать работу над релизами, разделив их по времени. Это вполне сработало бы, но для людей, проводящих кампанию, было бы сложно оставаться вовлеченными в процесс, пытаясь понять способы работы с системой людей, которые будут использовать ее позднее, более чем через год от сегодняшнего дня. Их головы были заняты тем, что они хотели видеть готовым сегодня . Они строили множество догадок о том, что волонтеры и группы лидеров будут делать. Это было неизбежно, особенно если мы меняли свои представления о том, как все это будет работать.
Через семь месяцев мы выпустили маленький, минимально жизнеспособный продукт – только то, чего достаточно было для работы наших пользователей в штате Айова. Именно тогда все изменилось. Первая реакция была резко отрицательной, так как мы выпустили совершенно не то, что представляли себе люди. Было пропущено немало важных вещей. Попадались баги. Нас забросали вопросами: «Почему вы не сделали все как надо с первого раза?» И хотя мы уверяли, что будем вносить улучшения и исправлять неполадки каждую неделю, никто не собирался нам верить до того, как увидит это своими глазами. Но по мере того, как мы воплощали свои обещания в жизнь, росло и доверие.
Именно здесь сыграла важную роль стена со стикерами. Мы использовали Pivotal Tracker и Basecamp, но все остальные люди не хотели пользоваться этими инструментами. Нужен был абсолютно прозрачный способ показать всем, над чем мы работаем и к чему вскоре придем. Наша стена с историями была организована слева направо по календарным неделям, а сверху вниз – по приоритету. Самым важным для нас было время. На стене висели огромные часы, показывавшие, сколько дней, часов, минут и секунд осталось до дня выборов. Все понимали, что некоторые элементы сейчас не очень важны, а некоторые станут более критичными по мере приближения дня выборов. Каждая идея на стене была отмечена своим цветом, соответствующим определенному виду деятельности, связанному с этой идеей, например работе с избирателями, построению команды, регистрации голосов и явке избирателей. На этой картинке много фиолетового потому, что это ранний этап работы и построение команды, соответствующее фиолетовому цвету, сейчас более важно, чем другие моменты, например явка избирателей.
Обычно элементы на доску мы добавляли совместно с людьми, управлявшими кампанией. Мы говорили о том, что уже было запланировано на эту неделю и какие у нас шансы закончить эту работу в течение недели. Мы говорили о реальных проблемах, от которых избавит эта функциональность. Вместе мы решали, насколько эта функциональность важна по сравнению с другими, уже имеющимися на стене. Когда приходило время начинать разработку, программист, ответственный за данную функциональность, работал напрямую с тем из наших партнеров, кто знал ее лучше всего. Они вместе продумывали все детали, что порой занимало довольно много времени. Иногда мы выделяли день на то, чтобы создать простые прототипы графического интерфейса.
Эта огромная стена со стикерами была ключевым моментом в создании моста между теми, кто разрабатывал программное обеспечение, и теми, кто должен был им пользоваться. Именно это им было нужно, чтобы визуализировать, что, как и когда происходит, а также активно участвовать в принятии решений.