К середине недели Леонардо уже нанес на картину большую часть форм и красок, но все еще мог вносить изменения и делал это. К концу недели, видя, что не укладывается в назначенный срок, Леонардо прикладывает все усилия к проработке деталей картины. Некоторые до сих пор гадают, почему у Моны Лизы нет бровей: это осознанное решение художника или ему просто не хватило времени проработать эту особенность?
«Работу над великим произведением искусства невозможно завершить – ее можно только прервать» (Леонардо да Винчи).
Эту цитату приписывают Леонардо да Винчи. Фраза означает, что мы можем продолжать добавлять и улучшать что-то бесконечно, но в какой-то момент все-таки придется прерваться и выпустить наше произведение в мир. И если Леонардо и множество других великих художников могут служить для нас примерами, мы – люди, которые смотрят на их работы, – даже не догадываемся, что работа была прервана. Для нас она выглядит завершенной.
Итерации и прирост
Любой художник или писатель работает именно так. Люди, которые совмещают чтение утренней газеты и просмотр вечерних новостей, по сути, следуют этому принципу. Люди, играющие в театре, следуют этому принципу. Каждому, кто должен выпустить какой-то продукт в точные сроки и приобретает знания по ходу дела, без сомнения, знакома такая стратегия.
Итеративно мыслите, чтобы верно оценивать, и вносите изменения в то, что вы уже сделали.
В области разработки программного обеспечения термин «итерация» имеет два значения. С точки зрения процесса он означает повторение одних и тех же действий снова и снова. Вот почему отрезок времени, в течение которого идет разработка, в методологии Agile часто называют итерацией. Но, используя этот термин в отношении программного обеспечения, которое вы уже создали, вы подразумеваете его оценку и изменение. Часто необходимость внести изменения во что-то уже существующее выглядит как провал: если бы требования были прописаны лучше или границы проекта не расширялись постоянно, то люди, принимающие решения, что и как программировать, не ошибались бы и ничего исправлять бы не пришлось. Но, как мы знаем, на самом деле исправления – всего лишь неизбежный результат увеличения знаний.
Итеративно мыслите, чтобы добавлять новое.
К сожалению, завязнуть в водовороте итераций очень легко, поэтому держите в поле зрения календарь и продолжайте постепенно внедрять новое. Художники совершенствуют свою работу, не только добавляя в картину какие-то ранее отсутствующие детали, но и прорабатывая то, что уже написано.
Вы можете следовать тому же принципу при разработке программного обеспечения, для начала создав простую версию функциональности без каких-либо деталей. Можете рассматривать ее как набросок, эскиз. Некоторое время поработав с этой простой версией, можно ее усовершенствовать – добавить дополнительные функции. Еще через некоторое время она развивается настолько, что работу можно считать законченной – она соответствует вашему первоначальному видению. А если вы все делали правильно, то, возможно, результат работы будет отличаться от изначального замысла в лучшую сторону, ведь идея получает развитие, потому что по ходу работы вы узнаете и понимаете много нового.
Дебют, миттельшпиль, эндшпиль
Возможно, это немного взорвет ваш мозг, но я собираюсь объединить несколько метафор. Лично мне нравится аналогия между созданием программного обеспечения и шахматной партией. Сразу говорю: я небольшой мастер игры в шахматы и в общем умею только двигать фигуры, поэтому, если мои метафоры неверны, не стоит писать мне и поправлять. Независимо от размера продукта или функциональности я предпочитаю делить релизный бэклог на следующие три части.
Дебют. Сфокусируйтесь на самых необходимых функциях или пользовательских шагах, которые затрагивают весь продукт. Сфокусируйтесь на самых трудных или рискованных частях работы. Отложите различные варианты действий пользователей. Отложите замысловатые бизнес-правила, которые понадобятся вам позднее, перед релизом. Создайте только то, что необходимо для базовой работы продукта от начала до конца.
Миттельшпиль. Дополняйте и прорабатывайте функции. Добавьте код, поддерживающий различные варианты действий, которые может выполнить пользователь. Реализуйте строгие бизнес-правила. Если вы хорошо поработали на стадии дебюта, то можете начать тестировать основной процесс продукта на соответствие требованиям производительности, масштабирования нагрузки и удобства использования – все это показатели качества, которые нелегко обеспечить. Обязательно отслеживать их постоянно.
Эндшпиль. Наведите на свою работу блеск. Сделайте ее приятной и эффективной в использовании. Поскольку сейчас вы можете протестировать продукт на реальных данных и в реальном масштабе, вы обязательно обнаружите возможности для улучшения, которые невозможно было заметить на стадии прототипа. На этом этапе также можете получить обратную связь от пользователей и внести необходимые изменения.
Разделите стратегию разработки прямо на карте
Если вы определились, что именно войдет в первый жизнеспособный релиз, который можно показать заказчикам и пользователям, вместе с командой начните работу, чтобы разделить истории этого релиза на части, которые войдут в дебют, миттельшпиль и эндшпиль. Никто не сумеет оценить риски и благоприятные возможности для исследований лучше людей, которые создают продукт, кроме того, они будут ощущать большую заинтересованность в выполнении плана, который составлен с их участием.
Именно так и поступили Майк с Аароном и вся команда разработчиков. Теперь вы поняли, почему они так рады?
На самом деле суть в рисках
В главе 3 Эрику пришлось много возиться, при этом он рисковал неверно определить продукт. Он прибегнул к стратегии выделения отдельных релизов, что позволило ему всякий раз показывать заказчикам весь продукт.
В этой главе Аарон и Майк сконцентрировались на технических рисках – факторах, которые могли нарушить график разработки или непредсказуемо увеличить затраты. Они не демонстрировали результаты своей работы пользователям и заказчикам в конце каждого цикла, так как это никак не помогло бы снизить риск, но очень строго и придирчиво рассматривали их самостоятельно и с помощью команды, а затем использовали то, что удавалось узнать, для безопасной разработки продукта.
Возможно, при чтении главы 2 вы обратили внимание на один тонкий момент – Эрику понадобились два двухнедельных спринта, чтобы создать очередной минимально жизнеспособный продукт-эксперимент. Ему пришлось решать, какие функциональности необходимо включить в первый спринт, а какие – во второй. Для этого он использовал примерно такой же подход. Он и его команда обработали самые рискованные части в первую очередь, чтобы как можно скорее увидеть их в работе и, если понадобится, внести изменения по ходу разработки, прежде чем их увидят заказчики.
Что теперь?
Вы познакомились с несколькими отличными примерами создания и применения карт для различных целей. Но карты можно использовать и для других задач – мы рассмотрим их в следующих главах. Прежде чем идти дальше, хочу продемонстрировать вам свою любимую хитрость, которую я применяю при обучении других использованию карт. Уверяю: стоит вам ее освоить – и вы прямо сейчас сможете создавать карты на экспертном уровне.
Встретимся в главе 5.
Глава 5. На самом деле вы уже всё умеете!
Если вы думаете, что создание карты историй – это сложный, загадочный или в каком-нибудь еще смысле трудный процесс, то разрешите мне прямо сейчас доказать, что это не так. На самом деле у вас уже сейчас есть все, чтобы разобраться в базовых понятиях, необходимых для создания карты. Давайте прямо сейчас рассмотрим пример, взятый из обычной жизни. А чтобы было интереснее, возьмем его из вашей жизни. По ходу дела я познакомлю вас с самыми важными понятиями процесса составления карт, суть которых вы уже понимаете.
Приготовьте пачку стикеров, ручку – и начнем. Не спешите, приступим, когда у вас будет достаточно времени. Я подожду.
Готовы?
1. Запишите свою историю по одному шагу за раз
Закройте глаза и вернитесь к моменту пробуждения сегодня утром. Вы же проснулись сегодня утром, правда? Что вы сделали прежде всего? А сейчас откройте глаза и запишите это действие на стикере. Я тоже сделаю это: мое первое действие сегодня утром было «Переключил будильник», что я и написал на бумажке. Не слишком интересно, правда? Хотя бывают дни, когда мне приходится переключать будильник два или три раза.
А сейчас оторвите этот стикер и приклейте его на стол перед собой. Затем подумайте о следующей вещи, которую вы сделали. Вспомнили? Теперь запишите ее на следующем стикере и приклейте его, поместив справа от предыдущего. Продолжайте в том же духе. На моих следующих стикерах написано: «Выключил будильник» и «Поплелся в ванную».
Продолжайте записывать свои действия на бумажках, пока не доберетесь до выхода из дома на работу или куда-то еще, куда вы собирались сегодня. Я обычно заканчиваю на «Подошел к машине» и перехожу к пути на работу. Думаю, вам понадобится не больше трех-четырех минут, чтобы написать все эти стикеры.
Задачи – это то, что мы делаем
Посмотрите на то, что у вас получилось. Вы заметили, что все или почти все стикеры начинаются с глагола? Короткие глагольные фразы, вроде «почистил зубы» или «принял душ» – это задачи, или попросту действия, необходимые для достижения какой-то цели. Когда мы описываем задачи людей, использующих наше ПО и выполняющих по порядку какие-то действия, чтобы достичь определенной цели, мы называем их пользовательскими задачами. Это самое важное понятие в создании хорошей карты историй, не говоря уже о написании и изложении хороших историй. Вы убедитесь, что почти все стикеры в картах историй содержат короткие глагольные фразы, обозначающие действия, которые делают люди при использовании вашего ПО.
А сейчас остановимся на минуту – подумайте, было ли это сложно? Я попросил вас записать то, что вы делали, и задачи легко возникли у вас в голове. Не правда ли, хорошо, что самое важное в процессе происходит так естественно?
Поэтому не стоит бояться слова «задача». Если вы менеджер проекта, то должны знать, что проектные планы полностью состоят из задач. Если вы когда-либо использовали истории в разработке Agile, то знаете, что планирование включает в себя написание большого количества задач на разработку и тестирование. Если же вы не менеджер и не программист, то будьте осторожны, употребляя слово «задача»: другие люди могут понимать под ним то, что привычно для них, как в примерах, приведенных ранее, и могут сказать, что вы ошибаетесь.
Пользовательские задачи – основной строительный материал для карты историй.
А сейчас посчитайте, сколько задач вы записали.
Большинство людей в этом упражнении записывают от 15 до 25 задач. Если вы записали больше, это поразительно. Если меньше – что ж, можно позавидовать простоте вашей жизни, я бы тоже хотел собираться по утрам так быстро. Но, может быть, вам стоит еще раз посмотреть на свой список и проверить, не пропустили ли вы чего.
Мои задачи отличаются от ваших
Думаю, для вас не станет новостью то, что люди отличаются друг от друга. Эти различия хорошо заметны в способах, которые люди выбирают, чтобы чего-то добиться.
Например, многие достаточно мотивированы и дисциплинированны, чтобы каждое утро делать зарядку. Если у вас есть хоть один стикер, связанный с физкультурой, жму вам руку! Я все еще работаю над собой в этом смысле.
У других людей больше утренних обязанностей по сравнению с вами из-за условий, в которых они живут. Например, если у вас есть дети, могу поспорить, что вы записали несколько задач, которые людям бездетным и в голову не придут. Если есть собака, то, должно быть, найдется задача-другая, связанная с заботой о животном.
Не забывайте об этом, думая о людях, которые будут использовать ваше ПО. Они могут работать с приложением, имея различные цели. Они могут применять его в разных обстоятельствах, из-за чего им приходится учитывать интересы других людей или процессов.
Я ориентирован на детали
Как правило, выполняя это упражнение, некоторые люди записывают больше деталей, чем другие. Вместо краткого «Приготовил завтрак» они могут написать нечто вроде «Положил хлеб в тостер», «Налил сок в стакан» или, если это моя жена, «Добавила в смузи кале[12]», что создает некоторые проблемы в наших отношениях.
Задачи похожи на камни. Если вы возьмете большой камень и стукнете по нему молотком, он разобьется на кучку осколков, но эти осколки – такие же камни. То же самое происходит с задачами. Я не сумею определить, достаточно ли камень велик, чтобы считать его валуном, или достаточно мал, чтобы считать его галькой, но способ отличить крупные задачи от мелких существует.
Мой друг Алистер Коберн описал концепцию целевых уровней в книге «Написание эффективных пользовательских ситуаций» (Cockburn Alistair, Writing Effective Use Cases, издательство Addison-Wesley Professional). Не волнуйтесь, расписывать пользовательские ситуации мы сейчас не будем – это просто концепция, очень полезная при обсуждении поведения людей.
Алистер пользуется метафорой уровней высоты: уровень моря находится в середине, а все остальное – выше или ниже его. Задача на уровне моря – это то, что мы собираемся сделать, прежде чем намеренно остановимся и перейдем к чему-то еще. В ваших задачах наверняка есть «Принял душ». Это и есть задача на уровне моря – вы же не выключаете воду, думая: «Этот душ, похоже, затягивается, пойду-ка я выпью чашечку кофе, а потом закончу мыться». Алистер называет такие вещи задачами функционального уровня и помечает их значком океанской волны. Но я их называю просто задачами.
Задача «Принять душ» может быть разбита на множество маленьких подзадач вроде «Настроить температуру воды» или «Вымыть голову», а также, как у моей жены, чего-нибудь включающего надраивание мочалкой из люфы. Помните, что люди разные, и вы заметите различия в их поведении, касающиеся того, как они подходят к решению задач. Алистер помечает такие вещи маленькой рыбкой, потому что они находятся ниже уровня моря.
И наконец, мы переходим к ряду задач итогового уровня. Принять душ, побриться, почистить зубы и все остальное, что вы проделываете по утрам, поднявшись с постели, в конце концов сводятся к одной задаче-итогу. Я не уверен, как точно сформулировать ее название. «Стать чистым»? «Утренняя гигиена»? Мне не очень нравится слово «гигиена». Не будем его использовать.