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

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

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

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

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

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

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

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

Практические методы, основанные на эмпиризме

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

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

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

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

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

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

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

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