Мелкие ставки. Великую идею нельзя выдумать, но можно открыть

Интересно, что основатели метода гибкой разработки изначально позаимствовали ее основной элемент из японского сборника статей о промышленности. Джеф Сазерленд, создатель Scrum-метода[23], рассказывает, что они взяли его название из статьи, напечатанной в журнале Harvard Business Review за 1986 год. Ее авторы Хиротака Такеучи и Икуджиро Нонака описывали лучшие методики, применяемые для разработки новых продуктов в таких компаниях, как Honda, Canon и Fuji. Как вспоминает Сазерленд, «мы посмотрели, каким образом они формировали свою команду, и собрали группу разработчиков таким же образом».

Такеучи и Нонака сравнили способ формирования команды в японских компаниях с тем, как ведут себя регбисты во время матча, перемещаясь по полю во время схватки за мяч и пасуя его вперед и назад нужному игроку в каждом отдельном промежутке игры. Во время игры в регби игроки должны творчески подходить к атаке в соответствии с конкретной ситуацией на поле. Очень похоже работали и команды исполнителей в японских компаниях – они были многофункциональны, самостоятельными в своих действиях и не сильно зависели от решений топ-менеджеров, самоорганизовывались и учились по мере продвижения к достижению цели. Вместо того чтобы скрупулезно планировать весь процесс создания новых продуктов и распределять полный объем работ между исполнителями, как это делали в компаниях вроде General Motors, новые венчурные команды сотрудников в компании Honda объединяли дизайнеров, инженеров, менеджеров по продажам и производству. Эти команды не расформировывались до полного завершения разработки. Их цель состояла в том, чтобы добиться максимальной скорости и гибкости, в то время как руководство оговаривало условия или осуществляло то, что сами авторы называли мягким контролем, вроде введения контрольных этапов. Такеучи и Нонака сравнили такой процесс с использованием игроков в регби с определенными достоинствами в каждом новом промежутке игры.

Но традиционно для разработки программного обеспечения способы решения задач планировались заранее, были продуманы и детализированы еще до начала работы над проектом. Это часто называют методом водопада. Так, если компания Microsoft собирается заняться разработкой новой версии Windows методом водопада, стоящие перед ней задачи совмещаются с требованиями к дизайну и формулируются заранее. Вместо того чтобы использовать небольшие команды разработчиков, перед которыми ставятся задачи и определяются методы их решения, руководство «водопадными» процессами осуществляется сверху вниз, когда старшие сотрудники распределяют и контролируют весь процесс. Этот процесс и называется водопадом, потому что начинается с определенных требований к программе, далее «стекает» непосредственно к ее проектированию, а затем уже разработчики начинают заниматься внедрением, тестированием и инсталляцией. Список требований часто представляет собой документ в сотню страниц, а задания перечисляются в последовательности, от одной фазе к другой в виде диаграмм Ганта[24], где конкретные задания и время на их исполнение отображаются в виде столбиков.

Стандартный метод водопада во многом обязан своему возникновению Министерству обороны США. В 1980-е годы это ведомство финансировало до 60 процентов всех проектов по разработке программного обеспечения и требовало от своих подрядчиков соблюдения этого метода. Принимая во внимание влиятельность Министерства обороны, остальные разработчики программного обеспечения в стране приняли метод на вооружение.

У метода водопада есть свои достоинства, в том числе визуальная наглядность и высокая степень контроля над процессом (это ясно видно на диаграммах Ганта), но есть и несколько крупных недостатков. В первую очередь это стремление руководства учесть все возможные функции программы, которые с его точки зрения могут быть востребованы пользователями. Известно выражение Стива Джобса: «Люди не могут знать, что им нужно, пока они это не увидят». Неудивительно, что многие функции программ, созданных при разработке методом водопада, никогда не используются. Другой недостаток метода в том, что ко времени, когда компания Microsoft или подобная ей заканчивает проект, длившийся один или два года, мир уже успевает поменяться. Новые проблемы возникают постоянно. Приоритет управления сверху вниз при использовании метода водопада, когда мелкие изменения требований к продукту или к его дизайну не отражаются на ходе работы над ним в течение месяцев или даже лет, стал еще большей проблемой из-за развития Интернета и ускоряющегося технического прогресса. Все это способствовало росту популярности методов гибкой разработки программного обеспечения.