Другие находящиеся в комнате могут наблюдать за ними и слушать, но не говорить. Они – вне аквариума.
Если кто-то находящийся вне аквариума хочет принять участие, он может «нырнуть». Но когда один человек заходит извне, кто-то изнутри должен «вынырнуть».
Таким образом обсуждение остается компактным и продуктивным, все информированы и включены в процесс. Кроме того, это хороший способ обучения: новички включаются в процесс, не замедляя его скорости.
Важность компактности
Помните обсуждение торта и капкейков из главы 10? Сейчас как раз настало время разбить наши торты на капкейки наименьшего размера из возможных. Именно сейчас, когда присутствуют разработчики, тестировщики и другие специалисты, непосредственно участвующие в создании программного продукта, можно по-настоящему взяться за разделение истории на части.
Надеюсь, вы знаете, что корень слова software (программное обеспечение), soft, означает «мягкий». Это значение не ограничивается тем, что мы подразумеваем, говоря о губках или булочках. Лучше подойдет ассоциация с большим документом или книгой. Если бы вы писали книгу, как стараюсь делать сейчас я, вы бы не пытались сделать все за один раз. Вы бы написали, допустим, главу в один присест. Я, например, пишу за раз одну главу, а Питер, опытный и доброжелательный редактор, с которым я сотрудничаю, просматривает ее, делая необходимые предложения и поправки.
Но это не значит, что глава готова. До этого еще далеко.
Мне нужно вернуться к ней снова и подумать, где в тексте должны быть иллюстрации. Я должен решить, стоит ли добавить сноски, ссылки, объяснения терминов из глоссария или элементы указателя. Затем другие редакторы издательства проходятся по всем главам, внося финальные правки. Получается, что я разделяю работу, делая ее итерационно, и таким образом вижу, как книга постепенно обретает форму.
Сейчас вы читаете главу «Огранка, полировка, разработка». Если так, то, видимо, это значит, что мой тортик успешно испекся. Если бы я решил позаботиться о финальных критериях приемки, то, наверное, сформулировал бы такие.
• Материал понятен мне и лично проверен мной.
• Материал понятен моим редакторам и отредактирован ими.
• Книга снабжена иллюстрациями, которые облегчат читателям понимание материала и визуализируют ключевые моменты.
• Книга снабжена предметным указателем, с помощью которого читатели легко могут найти объяснение термина в соответствующей главе.
• Книга снабжена глоссарием, который читатели могут использовать, чтобы уточнить определения терминов, встречающихся в данной главе.
Это немаленькое количество работы. Даже сейчас, печатая первый, черновой вариант критериев, я понимаю, что предстоит сделать еще очень много. Но я не собираюсь закончить все это до перехода к следующей главе, потому что мне хотелось бы сначала увидеть книгу целиком. Поэтому я разбиваю работу на капкейки – маленькие законченные фрагменты, не готовые к публикациям, но поддерживающие мою уверенность в том, что я двигаюсь в правильном направлении, работая над книгой.
Я разделил бы работу над книгой на следующие истории.
• Огранка, полировка и создание первого чернового текста.
• Огранка, полировка и создание второго чернового текста.
• Огранка, полировка и создание текста с иллюстрациями.
• Огранка, полировка и создание текста с учтенными замечаниями и поправками.
• Огранка, полировка и создание текста с предметным указателем.
• Огранка, полировка и создание текста с глоссарием.
• Огранка, полировка и создание окончательной версии текста.
Для каждого из этих этапов я могу создать полноценную историю, в которой описано, что представляет собой этап, а также перечислены шаги, которые я (с помощью Питера в части редактирования) должен проделать, чтобы получить в конце этапа текст со всеми запланированными улучшениями и поправками. Как вы можете видеть, по мере завершения каждого этапа глава становится все более проработанной и приближается к состоянию готовности. Теоретически вы вполне могли бы прочитать и даже найти небесполезной первую версию, которая появилась после завершения первого этапа. Но я не хочу ее никому показывать, и вряд ли она бы вам очень понравилась.
Поскольку я уверен, что вы хорошо знаете свое дело, думаю, вы заметили, что этот список маленьких компактных историй во многом очень похож на критерии приемки для этой главы. В этом и заключается суть. Именно обсуждение критериев приемки должно подсказать нам, на какие меньшие части лучше всего разбить работу, чтобы их удобно было создавать и контролировать по ходу дела.
Очень важно контролировать работу постоянно, чтобы можно было оценить ее и при необходимости скорректировать курс. Вот здесь, например, вы могли бы прочитать очень неудачный пример, который я изначально вставил в это место. Но этого не произойдет, потому что, написав текст, я позже перечитал его и удалил этот пример.
При традиционном подходе к разработке программного обеспечения работу по контролю и удалению неудачных фрагментов непременно объяснили бы плохими требованиями. Но после того, как вы надели плащ и шляпу рыцаря Agile, эта работа становится обучением и итеративным улучшением.
Одна из моих любимых и очень простых техник окончательного разбиения историй – игра «Хорошо – лучше – идеально». Чтобы играть в нее, нужны большая история и пачка стикеров. Результат игры выглядит примерно так.
Довольно хорошо… пока
Как только у вас появится история, обсудите для начала, что достаточно сделать, чтобы она просто хорошо работала. Пока не стоит думать о том, как вызвать у клиентов восхищение, хватит минимально рабочего состояния. Запишите характеристики, которые обеспечат состояние «достаточно хорошо», и в дальнейшем относитесь к ним как к отдельным небольшим историям.
Если рассмотреть в качестве примера, скажем, IMDb.com (the Internet movie database – интернет-база данных кинофильмов), мы можем обсудить историю «Просмотреть информацию о фильме». Представим себе экран, где можно увидеть разные подробности о фильме и, таким образом, принять решение, стоит ли его смотреть. Обсуждая этап «довольно хорошо», можно ограничиться следующими простыми вещами.
• Просмотреть базовую информацию: название, рейтинг, режиссер, жанр и т. д.
• Просмотреть постер фильма.
• Просмотреть трейлер.
Лучше
Затем спросим себя, что может сделать историю лучше. Продолжая рассматривать пример с кинофильмами, можно добавить такие пункты.
• Прочитать аннотацию к фильму.
• Прочитать рейтинги участников.
• Прочитать рейтинги в обзорах.
• Просмотреть список всех актеров фильма.
Идеально
Наконец, подумайте, что может сделать историю потрясающей. На этом этапе не бойтесь самых безумных идей. Помните: вы не пишете требования. Это просто варианты, которые будут рассмотрены вами совместно с командой. Зачастую в таких дискуссиях зарождаются самые блестящие идеи – то, что может сделать ваш продукт выделяющимся, но оказывается удивительно недорогим в реализации. Продолжая работу с примером, можно добавить следующее.
• Посмотреть альтернативные обзоры или видео об этом фильме.
• Почитать любопытные факты о фильме.
• Почитать новости о фильме.
• Почитать дискуссии об этом фильме и принять в них участие.
Как видите, прогрессия небольших историй может помочь развить историю «Просмотреть информацию о фильме» от простого состояния, когда мы можем лишь убедиться в его работоспособности, до возможностей, которые сделают эту историю поистине впечатляющей. Если бы я занимался этой функциональностью, то создал бы базовые вещи всего приложения, прежде чем двинуться к стадиям улучшения и доведения до идеала. Работая таким образом, я куда безопаснее чувствую себя, приближаясь к дедлайнам.
Когда обсуждения историй станут по-настоящему хорошими, а я знаю, что скоро так и будет, в конце семинара по историям вы должны получить набор историй верного размера, снабженный множеством дополнительной документации и различных моделей, а также критериями приемки, где будет описано, как вы собираетесь убедиться в том, что работа над историей успешно завершена. Иногда требуется несколько семинаров, дополненных несколькими внешними исследованиями, анализом данных и дизайнерской работой, прежде чем удастся прийти к соглашению, но это нормально. Огранка и полировка всегда требуют времени и терпения.
В процессах Agile, таких как Scrum или экстремальное программирование, используется принцип ограничения времени разработки. Это значит, что каждый цикл разработки начинается с сессии планирования, а заканчивается оценкой сделанного. Во многих компаниях эти два вида совещаний – самые ненавистные из всех. Чаще всего они длинные и очень утомительные, и к тому времени, когда члены команды могут покинуть конференц-зал, они готовы согласиться с чем угодно, лишь бы выбраться на свободу. Очевидно, что качество составленных планов при таком подходе невысоко.
Но этот подход – не единственный из возможных.
Вот простой рецепт, который поможет вам избежать самых распространенных проблем.
Подготовка
Выберите истории, над которыми будете работать следующие один-два цикла. Если вы владелец продукта, периодически уточняйте у членов ключевой команды, работающей над продуктом, состояние функциональностей, находящихся в данное время в разработке. Выберите для добавления те истории, которые помогут приблизить эту работу к релизу.
Проведите предварительный семинар. Выделите время, чтобы члены ключевой команды продукта могли посовещаться между собой перед сессией планирования. Погрузитесь в детали, разделите на части большие истории, предусмотрите несколько вариантов. Пе