Двум талантливым архитекторам, Аманде и Саре, вручают по листу бумаги и ручке. Их задача - спроектировать для клиента 2-х этажный дом. Первоначальные требования расплывчаты. Они начинают с того, что кладут ручку на бумагу, чтобы нарисовать дом в соответствии с известными требованиями. Оба архитектора завершают свои первые проекты примерно за 15 минут.
На этом этапе Аманда и Сара представляют свои рисунки клиенту. Клиент просматривает свои проекты и отвечает на них отзывами, которые оба архитектора тщательно фиксируют как изменения первоначальных требований.
В унисон оба архитектора просят новый лист бумаги, поскольку теперь им обоим необходимо создать новые чертежи, соответствующие обновленным требованиям. Аманде дают чистый лист бумаги, и она сразу же начинает набрасывать свой измененный дизайн.
Саре, однако, предлагается открыть билет, чтобы запросить новый лист бумаги у группы операций с письменными материалами (WMOT). WMOT обработает ее запрос и ответит в течение 90 минут SLA новым листом бумаги.
Упражнение продолжается, Аманда обсуждает с клиентом свой последний проект каждые 15 минут или около того. Сара нервно сидит, ожидая, пока WMOT доставит новый лист бумаги, чтобы она могла создать следующую итерацию своего дизайна.
Хотя приведенная выше сцена явно надумана, она, к сожалению, хорошо знакома многим разработчикам программного обеспечения сегодня.
Как и в случае с архитектурой, разработка программного обеспечения - это не упражнение по сборке продукта из набора деталей и набора инструкций. И архитектура, и разработка программного обеспечения - это творческие процессы, требующие в равной степени воображения, инженерных основ и опыта.
Воображение требуется, потому что клиенту крайне сложно четко определить, какой продукт ему нужен. Как правило, у клиента есть видение высокого уровня, но многие детали этого видения могут быть обнаружены только на пути к конечному продукту.
Инженерные основы необходимы, потому что новые шаблоны и конструкции требуют, чтобы архитектор и разработчик понимали лежащие в основе компоненты, чтобы создать надежную структуру. Прихоти клиента должны сдерживаться реалиями бетона, дерева и исходного кода.
Опыт чрезвычайно важен, поскольку сочетание воображения и инженерии часто приводит к ситуациям, когда только мудрость, полученная в результате множества проб и ошибок, может эффективно направлять решения. Архитектор и разработчик программного обеспечения - настоящие эксперты, они уже были во многих путешествиях раньше; где это может быть первым для клиента.
Если вы согласны, то разработка программного обеспечения - это смесь воображения, творчества и инженерии; Вышеупомянутый сценарий можно использовать как аналог для типичного жизненного цикла разработки программного обеспечения. Клиент предоставляет требования, разработчик разрабатывает решение, клиент проверяет дизайн, клиент меняет требования, промывает и повторяет.
Надеюсь, вы также согласны с тем, что Аманда имеет значительное преимущество перед Сарой, поскольку Аманда может очень быстро взаимодействовать с клиентом, чтобы гарантировать, что каждая деталь ее дизайна была учтена и точно соответствовала развивающемуся видению ее клиента.
Целью приведенного выше сценария является раскрытие сути итерации до очень очевидного и важного аспекта любого творческого начинания. При этом ни провидец, ни создатель не знакомы с деталями конечного продукта. Они должны работать вместе, чтобы воплотить в жизнь конечный продукт.
Вариант разработки программного обеспечения, описанный выше, реализуется в компаниях по всему миру. Некоторые компании позволяют своим командам разработчиков программного обеспечения быстро выполнять итерации, а многие - нет.
Многие проблемы, такие как проектирование дома для конкретного клиента или реализация программного приложения, имеют множество жизнеспособных решений. Каждое из этих решений можно сравнить друг с другом и оценить их достоинства. Чтобы найти эти решения, нужны эксперименты. Итерация * есть * эксперимент.
Чтобы переходить от одного решения к другому, требуется воображение. Инженерные основы гарантируют, что решение является структурно прочным и безопасным. Опыт помогает определить, достаточно ли хорошее текущее решение или его можно улучшить, приложив немного больше усилий.
Даже если Аманда и Сара были одинаково креативны, продемонстрировали одинаковую инженерную строгость и имели сопоставимый опыт, ясно, что способность Аманды повторять и экспериментировать позволяет ей прийти к лучшему решению, чем Сара.
Учтите также, что общее время, затрачиваемое на завершение дизайна, у Аманды и Сары одинаково. Обоим архитекторам был задан одинаковый набор ограничений, но один явно имеет преимущество перед другим просто за счет более быстрой итерации.
Я бы сказал, что для многих творческих начинаний общее количество итераций более важно, чем общее выделенное время. Команда, которая выполняет итерацию 15 раз в месяц, очень часто создает лучший продукт, чем аналогичная команда, которая тратит на разработку 6 месяцев, но встречается с клиентом только один раз для обратной связи.
Точно так же команда, выполняющая 15 итераций в течение одного месяца, создаст продукт, который, вероятно, удовлетворит клиента примерно так же, как команда, выполняющая 15 итераций в течение всего года.
Команды разработчиков программного обеспечения, которые могут втиснуть больше итераций за то же время, скорее всего, добьются лучших результатов.
Вероятно, это основная причина того, что малые, бережливые и необремененные предприятиям невероятно успешно внедрять новое программное обеспечение и поддерживать его актуальность с течением времени. В то время как разработка программного обеспечения, происходящая во многих крупных компаниях, обычно тормозится плохо интегрированными командами, раздутыми процессами и неполными или неадекватными цепочками инструментов.
Таким образом, ключевой метрикой для любого бизнеса, пытающегося создать программное обеспечение, от небольшого стартапа до большого уважаемого предприятия, должна быть скорость, с которой их команды разработчиков программного обеспечения повторяют итерацию от дизайна до обратной связи. Если команда не может надежно и уверенно внести изменения в течение нескольких дней или часов, те, кто финансирует разработку, должны быть очень обеспокоены.
Бизнес, который зависит от доходов от программных продуктов, должен вкладывать время, ресурсы и инструменты, чтобы обеспечить быструю итерацию. Это вложение, которое принесет дивиденды не только клиенту, но и разработчику программного обеспечения. Просто спросите Сару!
