Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

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

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

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

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

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

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

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

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

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

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

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