Скрам - читать онлайн книгу. Автор: Кен Швабер cтр.№ 16

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

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

■ как ограничение по времени помогает постичь «искусство возможностей» и избежать перфекционизма;

■ как инкрементальная поставка продукта помогает повысить уровень инженерных практик;

■ как наделения полномочиями и самоорганизация помогают развить креативность и повысить удовлетворенность сотрудников.

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

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

Третья фирма – научно-исследовательская организация Lapsec, которая проверяет реалистичность идей программных приложений для правительства США. После событий 11 сентября компании было поручено быстро разработать новую систему для анализа информации о потенциальных террористических угрозах. Этот проект требовал объединения нескольких технологий, включая одну новую и непроверенную. Она называлась «слияние данных» (data fusion) и представляла собой усовершенствованную форму глубинного анализа данных (data mining).

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

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

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

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

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

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

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

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

Следующий релиз был запланирован на 7 апреля, в марте должна была бы состояться демонстрация пользователям. Шел конец октября: сотрудники уже сосредоточились на предстоящих праздниках ^[12], постепенно восстанавливались после кризиса при завершении последнего релиза. В то же время менеджеры уже всерьез переживали, хотя шестимесячный цикл подготовки нового релиза начался всего три недели назад. Успеем ли вовремя? Неужели сотрудникам снова придется трудиться в поте лица, постоянно перерабатывая в течение последних двух месяцев? Несмотря на сокращение цикла с года до полугода, никто не заметил каких-либо существенных изменений, поэтому все ожидали худшего.