Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 163

3. Планируя стратегию разработки, обязательно обсуждайте риски, вызванные предположениями о том, что понравится пользователям и закрепится в их работе, а также риски, связанные с технической реализацией. Разбивайте камни, нацеливаясь на изучение, создавайте то, что вам нужно в первую очередь, чтобы узнать как можно больше.

4. Планируя следующий цикл разработки, проведите финальные, самые качественные обсуждения, чтобы точно решить, что вы создаете, и прийти к соглашениям, как будете проверять готовность программного продукта. Каждое из этих соглашений позволяет разбить историю на еще более мелкие истории так, чтобы каждый из них соответствовал хотя бы одному соглашению.

Очевидно, что если вы попытаетесь провести все четыре обсуждения за одну встречу, это займет очень много времени и будет слишком утомительно. Для того чтобы рассмотреть все необходимые аспекты, потребуется очень много людей. А из моих предыдущих предупреждений и из собственного опыта вы наверняка знаете, что большая группа людей не может работать эффективно, по крайней мере не все присутствующие в одной комнате одновременно. Именно поэтому мы разбиваем истории постепенно, проводя довольно много отдельных обсуждений.

Обратная сборка разбитых камней

В игре «Астероиды» нужна была большая осторожность, чтобы случайно не расстрелять не те астероиды, которые нужно, потому что, однажды разбив, вы не сможете собрать их вновь. А вот однажды разделенные истории собрать заново можно.

Чтобы избежать переполнения бэклога множеством маленьких историй, возьмите группу историй, объединенных одной темой, и запишите все их названия на одной карточке в виде маркированного списка. Дайте им одно общее название и озаглавьте так свою новую карточку. Вуаля – у вас снова есть одна большая история.

Если вдуматься, это просто фантастика. Карточка с написанным на ней названием делает осязаемой и управляемой любую витающую в воздухе идею. Идеи гораздо более податливы, чем камни или горы документов. Иногда мы забываем, что другое название разработки программного обеспечения – труд, основанный на знаниях. Если мы в самом деле забываем это и слишком увлекаемся документами и процессами, наша работа становится чем-то скучным и бюрократичным. А когда я общаюсь с людьми, управляющими огромными бэклогами, сплошь заполненными маленькими историями, то чувствую, что они просто задыхаются от бюрократии.

Объединяйте маленькие истории, чтобы очистить бэклог

Я часто работаю с командами разработки продуктов, бэклоги которых заполнены сотнями элементов. И разумеется, в этом случае чаще всего звучит жалоба на большие сложности с расстановкой приоритетов. Когда я заглядываю в их бэклоги, то часто вижу, что они переполнены множеством маленьких историй. Обсуждение каждого из них и вынесение решения о приоритете может занять долгие часы, а то и дни. Но необходимости в этом нет.