Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

Итеративно мыслите, чтобы добавлять новое.

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

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

Возможно, это немного взорвет ваш мозг, но я собираюсь объединить несколько метафор. Лично мне нравится аналогия между созданием программного обеспечения и шахматной партией. Сразу говорю: я небольшой мастер игры в шахматы и в общем умею только двигать фигуры, поэтому, если мои метафоры неверны, не стоит писать мне и поправлять. Независимо от размера продукта или функциональности я предпочитаю делить релизный бэклог на следующие три части.

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

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

Эндшпиль.Наведите на свою работу блеск. Сделайте ее приятной и эффективной в использовании. Поскольку сейчас вы можете протестировать продукт на реальных данных и в реальном масштабе, вы обязательно обнаружите возможности для улучшения, которые невозможно было заметить на стадии прототипа. На этом этапе также можете получить обратную связь от пользователей и внести необходимые изменения.

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

Именно так и поступили Майк с Аароном и вся команда разработчиков. Теперь вы поняли, почему они так рады?

В главе 3 Эрику пришлось много возиться, при этом он рисковал неверно определить продукт. Он прибегнул к стратегии выделения отдельных релизов, что позволило ему всякий раз показывать заказчикам весь продукт.

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

Возможно, при чтении главы 2 вы обратили внимание на один тонкий момент – Эрику понадобились два двухнедельных спринта, чтобы создать очередной минимально жизнеспособный продукт-эксперимент. Ему пришлось решать, какие функциональности необходимо включить в первый спринт, а какие – во второй. Для этого он использовал примерно такой же подход. Он и его команда обработали самые рискованные части в первую очередь, чтобы как можно скорее увидеть их в работе и, если понадобится, внести изменения по ходу разработки, прежде чем их увидят заказчики.