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

1) как провести пилотное исследование этого нового метода разработки программного обеспечения;

2) какую информацию вы сможете обрести в ходе этого исследования;

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

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

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

1) сформируйте команду;

2) подумайте, что бы вы хотели создать;

3) закончите маленький кусочек работы полностью;

4) оцените, что бы вы хотели сделать следующим;

5) определите, что может быть улучшено, и улучшите это;

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

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

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

Вот как выглядит процесс.

1. Сформируйте команду. Соберите всех менеджеров по продажам вместе, обсудите, как идут дела в компании, проведите обзор конкурентов, информируйте продавцов обо всех новых продуктах компании.

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

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

4. Обдумайте, что бы вы хотели сделать следующим. Обновите каналы сбыта и сфокусируйте усилия на следующем месяце.

5. Продолжайте делать и оценивать. Повторяйте эти шаги каждый месяц.

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

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

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

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

Вице-президент должен был инвестировать только лишь в первую фазу проекта 500 тысяч долларов – приличные деньги всего лишь за описание требований того, что он хотел. Цена разработки самого приложения была неизвестна, но можно было предположить, что она будет в разы выше первоначальных затрат. Ему следовало предоставить предложения своему начальнику в комитете финансов и в IT (для планирования). Никто не хотел рисковать такими средствами без полной уверенности в успехе продукта.

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

Чтобы получить одобрение пилотного проекта, он приготовил презентацию, с которой направился к руководству, менеджерам своего отдела и в IT-отдел. Он обсудил с ними, что именно хотел бы сделать. Первый слайд презентации устанавливал цель пилотного проекта: определить, будет ли это приложение для смартфона хорошей инвестицией для организации. Он показал, как приложение встраивается в бизнес-стратегии организации, и бегло описал суть эмпирического процесса разработки – как это работает и почему он хочет его попробовать. Затем шло описание всего проекта. Он рассказал, что результатом пилотного проекта может стать работающее приложение, которое в дальнейшем можно совершенствовать. Полная стоимость приложения может быть экстраполирована на основании данных трехмесячного пилотного проекта. Также вице-президент и вся организация получат шанс понять, подходит ли эмпирический процесс для их компании.

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

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

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

1. Понимает, как создать программное обеспечение, используя технологии, необходимые для пилотного проекта.

2. Имеет все необходимые навыки для разработки законченного фрагмента приложения.

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

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

5. Участник должен быть увлечен проектом.

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

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

2. Флипчарты и лекционные доски в рабочем пространстве могут помочь членам команды визуализировать возможности и найти идеи. Пространство должно обеспечивать место для работы и хранения инструментов на всем протяжении создания пилотного проекта.

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

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

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

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

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

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

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

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

Рассредоточенная команда в Iron Mountain. Iron Mountain Digital – это компания по хранению и управлению данными стоимостью 3,1 миллиарда долларов. Она предоставляет услуги по внеофисному хранению резервных цифровых данных с помощью продукта LiveVault. В 2006 году продукт LiveVault испытывал трудности. Новая версия программного обеспечения не выходила более 12 месяцев. Отдельные люди в LiveVault читали об эмпирическом методе разработки программного обеспечения Scrum, но по-прежнему использовали старые методы. Не зная этих трудностей, маркетинговое крыло компании Iron Mountain заключило контракт с Microsoft в июне 2007 года. Microsoft обеспечивала своих пользователей программным обеспечением, постоянно создающим резервные копии. Резервные копии создавались на локальном сервере, и в Microsoft хотели предложить внеофисное хранение резервных данных в LiveVault в качестве альтернативы.

Как менеджер по продукции компании Пол Луппино заключил соглашение с Microsoft на выпуск нового релиза LiveVault. Контракт предполагал, что Microsoft начнет обеспечивать своих клиентов внеофисным хранением резервных данных к февралю 2008 года. Компания Iron Mountain предложила Полу стать менеджером по разработке этого продукта. Трудиться над ним предстояло в течение шести месяцев.

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

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

Все испытывали трудности из-за физической дистанции между командами разработчиков. Видеоконференции были дорогими, Skype работал недостаточно хорошо, и расходы на переезды также очень высоки. Каждый участник координировал свою работу во время ежедневных совещаний (используя дорогостоящие видеоконференции, электронную почту и инструменты социальных сетей), связывающих разработчиков из Iron Mountain в Массачусетсе, разработчиков Microsoft в Индии и менеджеров Microsoft по продуктам в Вашингтоне, чтобы оценивать прогресс в разработке и вносить изменения в дальнейшие планы.

Все менеджеры проверяли прогресс в создании инкремента каждые 30 дней. Сначала люди, находясь в разных местах, изучали законченный инкремент и затем в формате телеконференции обсуждали прогресс и проблемы, а также планировали объем работы для следующей итерации. Обучающие курсы помогли каждому стать более организованным. Пол обновил рабочее пространство в Iron Mountain, чтобы команда разработки стала более продуктивной и эффективной. Потери от нескоординированной работы, которую приходилось переделывать, были устранены. Потери от ручного тестирования, которое можно делать автоматически, также были устранены. Высшее руководство Iron Mountain решило развивать LiveVault. Новая маркетинговая программа и усилия по продвижению были запущены. Еще три релиза выпустили в течение следующих шести месяцев.

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

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

1. Может ли команда разработки создать приложение в рамках существующей технологии?

2. Можно ли приложение эффективно подключать к функционалу портала без использования интерфейса интернет-портала?

3. Как должно выглядеть это приложение?

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

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

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

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

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

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

Примечание: сотрудники IT-отдела постоянно приходили в офис команды разработки с различными просьбами и мешали команде. Менеджер проекта попросил их всех уйти и решать свои проблемы где-нибудь в другом месте.

Даже то, что, казалось бы, вызывает незначительную задержку, может снизить общую эффективность команды более чем на 50 %. Вице-президент знал, что висит на крючке у руководства, желающего проверить эффективность эмпирического процесса, и не хотел все испортить из-за того, что его сотрудников отвлекают.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот вам еще один пример. Вице-президент компании РТС по разработке программного обеспечения Сильвин Муссад работал непосредственно с Джейн Вачутка. В его подчинении находилось более 300 девелоперов ПО. Он и его менеджеры изначально считали, что необходимо распределить процесс разработки среди 50 команд. Они так и поступили и создали лучшие команды, которые только смогли. Но при этом команды оказались не очень продуктивными.

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

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

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

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

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