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

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

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

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

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

Таблица 2.1. Бэклог требований для организации бизнес-операций

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

Во-первых, мы должны удостовериться, что наша идея осуществима. Сможем ли мы в течение 30 или меньше дней создать то, что будет полезным и оправдает дальнейшую работу над программным обеспечением?

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

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

Давайте сформулируем определения для того, что мы описали.

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

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

Инкремент (приращение). Это частица целого, которая увеличивается со временем. Функциональный результат итерации в процессе разработки называется инкрементом. Приращение создается повторение за повторением, пока мы не получим полезную систему.

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

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

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

На разработку системы, соответствующей нашим требованиям и видению, может потребоваться несколько или огромное количество итераций. Время каждой из них определено, то есть мы всегда можем выделить и использовать полную итерацию без изменения ее длины. Каждая итерация создает инкремент потенциально полезного программного обеспечения (рис. 2.1). Функционал становится законченным, нет необходимости что-то доделывать. Результат предыдущей итерации используется как стартовая точка для следующей.

Рис. 2.1. Одна итерация производит один прозрачный инкремент

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

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

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

Иногда одной итерации достаточно, чтобы разработать то, чем уже можно пользоваться, пока мы направляем команду разработчиков развивать более широкий функционал. Мы можем встраивать больше производительности и функционала итерация за итерацией, так как у нас есть преимущество более полного использования. Каждый инкремент накладывается на предыдущие. Когда результат работы команды разработки признается правильным, мы выпускаем релиз программного обеспечения, и им начинают пользоваться. Рисунок 2.2 иллюстрирует несколько итераций.

Рис. 2.2. Несколько итераций создают инкремент дополнительной функциональности

Мы придумали эмпирический процесс разработки программного обеспечения и выбираем, что делать дальше в конце каждой итерации, держа в уме нашу цель и рассматривая, что уже было разработано. Мы можем экстраполировать вероятную стоимость и срок поставки продукта, чтобы решить, хотим ли мы продолжать. Мы называем это итеративно-инкрементальным процессом, и это основа Scrum. Мы описали, как это работает и почему это может называться «программное обеспечение за 30 дней». Теперь давайте посмотрим, решает ли данный процесс проблемы, которые мы нашли в каскадном, или предиктивном, процессе.

Решает ли наше эмпирическое решение проблемы каскадного метода? Давайте оценим новый процесс в болевых точках, обнаруженных в каскадном методе.

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

Проблема 2 каскадного процесса: срыв графиков релизов. Наш график разработки не может сдвинуться более чем на 30 дней, так как это максимальная длительность одной итерации. Мы выпускаем накопленные инкременты, когда достигаем даты релиза. Мы не выделяем итераций для построения малозначительного функционала, что позволяет выпускать законченную систему гораздо раньше, чем обычно. При использовании традиционного метода разработки программного обеспечения только менее 50 % функционала используется часто. Мы не разрабатываем этот функционал.

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

Проблема 4 каскадного процесса: планирование занимает слишком много времени и выполняется неправильно. Начальное планирование сводится к постановке цели и определению наиболее ценных функциональных возможностей, производительности и особенностей, необходимых для ее достижения. Затем определяются ориентировочная стоимость и срок разработки. Планирование до первой итерации, как правило, занимает 20 % времени от того, что обычно мы привыкли тратить на планирование для каскадного, или предиктивного, метода. Мы планируем детальные требования для каждой итерации только непосредственно перед ее началом. Это планирование перед итерацией называется «точно в срок», и в него могут включаться требования, возникающие во время проверки предыдущей итерации, и адаптироваться лучшие требования для следующей.

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

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

Проблема 7 каскадного процесса: авралы наносят моральный вред. Процесс стабилизации программного обеспечения перед выпуском исключен, как и работа в выходные и сверхурочная работа.

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

Работой можно управлять, используя всего три переменные. Первая (А) – это требования, функциональные возможности, которые предоставит планируемое программное обеспечение. Вторая переменная (В) – время, которое теперь мы измеряем в блоках по 30 дней. Третья переменная (С) – законченная работа, которая измеряется в пригодных к применению функциональных возможностях или в количестве требований и функциональных возможностей, выполненных в каждый из 30-дневных периодов и совокупно.

Таким образом, можно создать график для управления проектом.

1. Бэклог требований по оси Y, или вертикальной оси. Работа по выполнению каждого требования разбита по размеру. Давайте предположим, что у нас есть пять требований. Каждое требует выполнения 2, 3, 5, 3 и 8 блоков работы. Они создают объем работы по оси Y из 21 блока. Блоки расположены в порядке, в котором вы хотите превращать их в пригодные к использованию функциональные возможности. Давайте, скажем, порядок сверху вниз будет 2, 3, 5, 3 и 8.

2. Время отложим по горизонтальной оси Х. Блоки по 30 дней, что составляет протяженность одной итерации.

3. Мы предполагаем, основываясь на предыдущем опыте, что команда разработки выполняет по пять блоков работы за каждую итерацию. Реальную производительность команды разработки выясним, когда начнем работу, а пока это всего лишь прогноз вчерашней погоды. Итак, мы предполагаем, что 20 блоков работы будут закончены за первые четыре итерации и последний фрагмент будет выполнен в течение пятой итерации.

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

5. Команда разработки создала 3, 5 и 5 блоков функциональных возможностей в первые три периода времени. Получившийся график показан на рис. 2.3.

Рис. 2.3. Диаграмма сгорания работы

План, или прогноз, в начале работы показывает, что вы начали с 21 блока работы.

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

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

Эмпиризм обеспечивает ряд факторов.

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

2. Контроль. Если информация показывает, что окончание работы может быть позднее, чем необходимо, вы можете уменьшить объем требований и количество оставшихся функциональных возможностей, которые необходимо доделать. К примеру, в конце второй итерации, с оставшимися 13 блоками работы для выполнения требований, вы можете уменьшить количество оставшихся блоков до десяти. Если команда разработки продолжит выполнять по пять блоков работы за итерацию в течение последующих двух итераций, функционал будет полностью закончен к концу четвертой итерации.

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

4. Управление рисками. Команда разработки закончила только два блока работы в каждой из первых трех итераций. В конце третьей прогноз показал, что окончание разработки не случится ранее середины десятой итерации. Если начальный бюджет был 100 тысяч долларов, новый прогноз предполагает перерасход средств на 150 тысяч. Если возврат инвестиций в размере 250 тысяч долларов невозможен, то проект можно отменить уже после третьей итерации.

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

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

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

Действия команд напоминали им игру в регби, поэтому они назвали этот стиль управления разработкой проекта Scrum – так в регби называется момент возобновления игры после того, как мяч вышел за пределы поля.

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

Уважение к личности сотрудника. В некоторых компаниях к сотрудникам относятся как к детям, их мнение не учитывается, им просто указывают, что именно делать в каждый момент в течение дня. Для того чтобы люди были вдохновлены и вовлечены в свою работу, следует создать атмосферу содействия, когда с сотрудниками обращаются с уважением и восхищением. Scrum призван обеспечить такую обстановку. Мы были не первые, кто решил применять идеи и практические методы, используемые в Scrum. Большинство из них представляют собой передовые методы в индустрии. Тем не менее Джефф действительно сосредоточен на аспекте «люди» в среде разработки программного обеспечения Scrum.

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

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

Взаимное развитие. Совместно размещенные кросс-функциональные команды воспитывают в своих участниках стремление к высокой производительности, качеству и креативность. Члены команды работают совместно, и границы между сферами деятельности начинают размываться. На самом деле некоторые компании требуют от каждого члена команды знаний по двум специализациям (например, программирование более чем на одном языке плюс навыки тестировщика) и в двух областях (например, дизайн и маркетинг). Интенсивное взаимодействие индивидуальностей начинает задавать пульс, или темп команды.

Пересекающиеся фазы разработки. Избегая линейной последовательности в работе, команда способна поглощать «вибрацию» или «шум», создаваемый препятствиями в процессе разработки. Когда образуется «узкое горлышко», команда не приходит к внезапной остановке, но решает проблему. Пересекающиеся фазы избавляют от традиционного понятия разделения труда. Такой подход не только обеспечивает скорость и гибкость, но и способствует разделению ответственности, поощряет сотрудничество, стимулирует вовлеченность и обязательность, а также чувствительность к рыночным условиям. Недостаток в данном случае – необходимость управления интенсивным процессом, который требует прозрачности, взаимодействия, напряжения и даже конфликта.

Многоуровневое и мультифункциональное обучение. Обучение в команде идет в разных направлениях. В 3М, например, инженерам рекомендуется использовать 15 % своего рабочего времени, чтобы заниматься своей мечтой. Если команда работает с компанией Honda, ее члены могут быть отправлены в Европу, чтобы «осмотреться и понять, что там происходит». Идея в том, что обучение часто происходит в необычных местах и необычным способом и, самое главное, инициируется сотрудниками и поощряется и направляется руководством.

Тонкий контроль. Несмотря на то что команда разработки предоставлена сама себе, она работает не бесконтрольно. Акцент делается на самоконтроле и достаточном количестве контрольных точек, которые устанавливаются для предотвращения нестабильности, неопределенности и хаоса. Контроль со стороны равного и «контроль с любовью» – основы тонкого контроля. Динамическое движение возникает только в окружении, заботливо созданном руководством. Командные лидеры тщательно отбираются, а в самой команде иногда происходит замена участников, чтобы создать правильную динамику и уверенность, что люди смогут ужиться и работать вместе. В команде должен быть набор общих ценностей, а стимулы должны быть основаны на командной работе. При этом следует допускать возможность ошибок.

Передача знаний. Чтобы компания была успешной на рынке, выстраданные знания, накопленные внутри нее, должны быть доступны во всей компании, которая нуждается в новых командах с опытными людьми. Успешные мероприятия в рамках одного проекта распространяются внутри компании как стандартная практика. В то же время разучиться так же важно, как и научиться. Рынок меняется быстро, старые трюки могут больше не работать. Управление предъявляет новые требования, которые явно не могут быть удовлетворены старыми методами ведения дел.

Мы обнаружили, что некоторые практические методы также улучшают разработку программного обеспечения.

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

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

Состав команды. Команды более продуктивны, если имеют один и тот же состав участников. Продукты более надежны, когда команда имеет все кросс-функциональные навыки, сосредоточенные на работе. Изменение состава команды часто временно снижает ее производительность

Несмотря на то что предиктивный, или каскадный, процесс испытывает трудности, многие организации продолжают пытаться заставить его работать. Мы встретились в 2005 году с СТО и персоналом компании розничной торговли Marks and Spenser из Великобритании, чтобы обсудить эмпиризм и Scrum. Компания только что модернизировала весь процесс развития, приобретя в PricewaterhouseCoopers (PWC), интернациональной консалтинговой компании, набор методологий, инструментов, обучения и услуг по внедрению. Подход PWC был предиктивным, или каскадным.

Но CTO Marks and Spenser хотел понять эмпиризм. Когда мы объяснили ему процесс, он заметно разволновался, прервал нас и сказал, что его компания тоже использует эмпиризм. Всякий раз, когда один из их больших проектов по разработке, основанный на подходе PWC, попадает в беду, они его останавливают и затем применяют другой подход, чтобы вернуть процесс на правильный путь или закончить. Он сказал, что это их «туз в рукаве», имея в виду трюк, который позволяет компании выходить из трудных ситуаций.

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

Поскольку наш мир становится все более сложным, для организаций и бизнеса открывается все больше перспектив. Мечта каждого предпринимателя и бизнесмена с душой предпринимателя – воспользоваться преимуществом новой возможности, выяснить, какая будет цена и какие риски нужно предвидеть. Если риски приемлемы, предприниматель захочет продолжить шаг за шагом, настолько быстро, как только можно, чтобы воспользоваться открывающимися возможностями. Тем не менее, как бы мы ни хотели контролировать риски, все может быстро выйти из-под контроля. Здесь очень желательны смелая осторожность и осторожная смелость. Мы называем способность брать преимущество от появляющихся возможностей гибкостью. Мы можем развернуться на месте, немедленно развить смелые инициативы и начать управлять рисками. Мы можем заставить наших конкурентов рыдать по утрам и мы можем радовать наших новых клиентов. Гибкость – это способность пользоваться возможностями или бороться с трудностями с расчетными рисками. Сегодня это наиболее значимое конкурентное преимущество. Мы создаем это преимущество и контролируем риски, ограничивая все наши проекты сроком в 30 дней или меньше. В этом случае мы можем пробовать идеи и без сожаления от них отказываться. Уже на ранней стадии нам понятно, что они, к примеру, слишком дорогостоящие или нереальные. И мы останавливаемся до того, как потратим слишком много денег.

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

Менее рискованно, с большим контролем и быстрее вы можете получить первый результат в течение 30 дней и затем совершенствовать его.

Эмпирический процесс разработки программного обеспечения, использующий итеративно-инкрементальные методы, с нами уже более чем 20 лет. Используя его, вы можете создать плотный контроль над рисками с помощью ограниченных по времени инкрементов программного обеспечения. Это обеспечивает прозрачность путем доставки законченного, готового к использованию прироста полезного функционала каждые 30 дней (или в меньший срок), так что потери могут быть сведены к минимуму. Это обеспечивает скорость и гибкость настройки приложения для более полного удовлетворения возникающих потребностей и тем самым значительно увеличивает применимость. Мы больше не беспокоимся, что наши требования не будут выполнены. Мы больше не волнуемся, что бюджет увеличится. Мы больше не должны зависеть от абстрактных представлений о динамике проекта, таких как диаграммы Ганта или прототипы. Мы точно знаем, где мы находимся с точки зрения ценности продукта и графика, по крайней мере каждые 30 дней.