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

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

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

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

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

Расположенная в Филадельфии компания Primavera, которой сейчас владеет Oracle, создает программное обеспечение для управления проектами, основанными на предиктивном процессе. Учредители понимали иронию: использовать эмпирический процесс разработки программного обеспечения для создания своих предиктивных (прогнозируемых) инструментов. Тем не менее, чтобы решить свои проблемы, они должны были к нему прибегнуть.

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

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

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

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

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