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