Скрам

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

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

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

Ситуация в Service1st

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

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

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

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

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

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

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