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

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

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

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

Члены команды могут применять новые для них методы работы

Самоорганизация

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

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

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

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

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

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

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

Кросс-функциональность

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