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

Представьте себе, что вы Леонардо да Винчи и собираетесь написать картину, следуя той же стратегии, к которой традиционно прибегают большинство команд в мире разработки [11]. Вы можете начать работу с четким представлением о картине, по крайней мере вам так кажется. Вы разбиваете картину на несколько частей. Допустим, на эту работу отведено пять дней и каждый день вы рисуете по одной части. А к концу пятого дня – бах! – вы закончили! Что может быть проще?

Проблема лишь в том, что в реальности это не работает, по крайней мере для художников. Что-то создать таким образом можно, если предположить, что изначальное видение точно и правильно. Необходимо также, чтобы автор был высокопрофессионален и способен точно выделить части работы без визуального представления их в контексте. Если вы поступаете подобным образом при разработке программного обеспечения, это называется стратегией постоянного прироста (инкрементальной) . По сути, таким образом каменщик строит стену, и этот способ хорошо работает, если размеры всех кусочков одинаковы и хорошо определены – как у кирпичей.

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

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

Мне, к сожалению, не приходилось наблюдать за Леонардо, но, я полагаю, он делал что-то очень похожее.

Даже Леонардо да Винчи, вероятно, признал бы, что его первоначальное видение картины не было идеальным, а он кое-что понимал в рисовании. В первый день, как мне представляется, он рисовал эскиз композиции или, может быть, делал легкий набросок. Я уверен, что на этом этапе он вносил в композицию небольшие изменения: «Хм, кажется, здесь самое важное – ее улыбка. Надо убрать руку от губ. А эти горы на заднем плане… Кажется, они слишком высокие, недостает пространства».

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

«Работу над великим произведением искусства невозможно завершить – ее можно только прервать» (Леонардо да Винчи).

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

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

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

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