Пользовательские истории. Искусство гибкой разработки ПО - [31]
Итерации и прирост
Любой художник или писатель работает именно так. Люди, которые совмещают чтение утренней газеты и просмотр вечерних новостей, по сути, следуют этому принципу. Люди, играющие в театре, следуют этому принципу. Каждому, кто должен выпустить какой-то продукт в точные сроки и приобретает знания по ходу дела, без сомнения, знакома такая стратегия.
Итеративно мыслите, чтобы верно оценивать, и вносите изменения в то, что вы уже сделали.
В области разработки программного обеспечения термин «итерация» имеет два значения. С точки зрения процесса он означает повторение одних и тех же действий снова и снова. Вот почему отрезок времени, в течение которого идет разработка, в методологии Agile часто называют итерацией. Но, используя этот термин в отношении программного обеспечения, которое вы уже создали, вы подразумеваете его оценку и изменение. Часто необходимость внести изменения во что-то уже существующее выглядит как провал: если бы требования были прописаны лучше или границы проекта не расширялись постоянно, то люди, принимающие решения, что и как программировать, не ошибались бы и ничего исправлять бы не пришлось. Но, как мы знаем, на самом деле исправления – всего лишь неизбежный результат увеличения знаний.
Итеративно мыслите, чтобы добавлять новое.
К сожалению, завязнуть в водовороте итераций очень легко, поэтому держите в поле зрения календарь и продолжайте постепенно внедрять новое. Художники совершенствуют свою работу, не только добавляя в картину какие-то ранее отсутствующие детали, но и прорабатывая то, что уже написано.
Вы можете следовать тому же принципу при разработке программного обеспечения, для начала создав простую версию функциональности без каких-либо деталей. Можете рассматривать ее как набросок, эскиз. Некоторое время поработав с этой простой версией, можно ее усовершенствовать – добавить дополнительные функции. Еще через некоторое время она развивается настолько, что работу можно считать законченной – она соответствует вашему первоначальному видению. А если вы все делали правильно, то, возможно, результат работы будет отличаться от изначального замысла в лучшую сторону, ведь идея получает развитие, потому что по ходу работы вы узнаете и понимаете много нового.
Дебют, миттельшпиль, эндшпиль
Возможно, это немного взорвет ваш мозг, но я собираюсь объединить несколько метафор. Лично мне нравится аналогия между созданием программного обеспечения и шахматной партией. Сразу говорю: я небольшой мастер игры в шахматы и в общем умею только двигать фигуры, поэтому, если мои метафоры неверны, не стоит писать мне и поправлять. Независимо от размера продукта или функциональности я предпочитаю делить релизный бэклог на следующие три части.
Дебют. Сфокусируйтесь на самых необходимых функциях или пользовательских шагах, которые затрагивают весь продукт. Сфокусируйтесь на самых трудных или рискованных частях работы. Отложите различные варианты действий пользователей. Отложите замысловатые бизнес-правила, которые понадобятся вам позднее, перед релизом. Создайте только то, что необходимо для базовой работы продукта от начала до конца.
Миттельшпиль. Дополняйте и прорабатывайте функции. Добавьте код, поддерживающий различные варианты действий, которые может выполнить пользователь. Реализуйте строгие бизнес-правила. Если вы хорошо поработали на стадии дебюта, то можете начать тестировать основной процесс продукта на соответствие требованиям производительности, масштабирования нагрузки и удобства использования – все это показатели качества, которые нелегко обеспечить. Обязательно отслеживать их постоянно.
Эндшпиль. Наведите на свою работу блеск. Сделайте ее приятной и эффективной в использовании. Поскольку сейчас вы можете протестировать продукт на реальных данных и в реальном масштабе, вы обязательно обнаружите возможности для улучшения, которые невозможно было заметить на стадии прототипа. На этом этапе также можете получить обратную связь от пользователей и внести необходимые изменения.
Разделите стратегию разработки прямо на карте
Если вы определились, что именно войдет в первый жизнеспособный релиз, который можно показать заказчикам и пользователям, вместе с командой начните работу, чтобы разделить истории этого релиза на части, которые войдут в дебют, миттельшпиль и эндшпиль. Никто не сумеет оценить риски и благоприятные возможности для исследований лучше людей, которые создают продукт, кроме того, они будут ощущать большую заинтересованность в выполнении плана, который составлен с их участием.
Именно так и поступили Майк с Аароном и вся команда разработчиков. Теперь вы поняли, почему они так рады?
На самом деле суть в рисках
В главе 3 Эрику пришлось много возиться, при этом он рисковал неверно определить продукт. Он прибегнул к стратегии выделения отдельных релизов, что позволило ему всякий раз показывать заказчикам весь продукт.
В этой главе Аарон и Майк сконцентрировались на технических рисках – факторах, которые могли нарушить график разработки или непредсказуемо увеличить затраты. Они не демонстрировали результаты своей работы пользователям и заказчикам в конце каждого цикла, так как это никак не помогло бы снизить риск, но очень строго и придирчиво рассматривали их самостоятельно и с помощью команды, а затем использовали то, что удавалось узнать, для безопасной разработки продукта.
