Читать «Скрам (Гибкое управление продуктом и бизнесом)» онлайн - страница 37
Кен Швабер
Длительность цикла разработки новой версии программного обеспечения в Service1st составляла 12 месяцев. Последние два месяца каждого цикла всегда были похожи на тушение пожара. После каждого такого «выталкивания» нового релиза в боевую среду сотрудники были выжаты, а ПО оказывалось нестабильным. Чтобы избавиться от переработок и повысить качество релизов, руководство компании решило равномернее распределить интенсивность усилий по более короткому отрезку времени в шесть месяцев.
Вице-президент по разработке провел для меня экскурсию по рабочим местам программистов. Было тихо, спокойно и безлюдно: только каждый четвертый кабинет или сектор был кем-то занят. Сначала я подумал, что еще слишком рано и люди просто не приехали. Потом увидел, что уже 9:00 часов, и предположил, что недавно прошла волна увольнений и ряды поредели. Но нет, Service1st – успешная и растущая компания-разработчик, за 20 лет работы не было никаких сокращений персонала.
Вице-президент объяснил мне ситуацию: компания только что закончила шестимесячный цикл разработки, последний релиз вышел три недели назад, и персонал еще не восстановился после сверхусилий. Чтобы выпустить релиз вовремя, последние два месяца команды работали до позднего вечера и по выходным. Такой режим плохо сказывался не только на сотрудниках Service1st, но и на клиентах: из-за безумных темпов разработки последние версии каждого релиза были полны ошибок. Вице-президент сказал, что хочет внедрить скрам, чтобы впредь не вынуждать своих сотрудников идти на такие жертвы и повысить качество программного обеспечения Service1st.
Какой процесс разработки стоял за этим безумием? Почему сотрудники подразделения разработки были настолько перегружены? В начале цикла разработки очередного релиза менеджеры проектов совместно с маркетологами создавали подробные планы работ по реализации нового функционала. Список функциональных требований составлялся из клиентских запросов в службу поддержки, критичных дефектов, требований по повышению производительности и функциональных возможностей систем конкурентов. После утверждения плана любые корректировки производились по формальной процедуре контроля изменений.
Планы оформлялись в виде диаграмм Ганта с подробным выравниванием ресурсов. Каждая задача была разделена на множество технических подзадач, сильно зависящих друг от друга. Таким образом, любой, кто работал с одним набором функций, вряд ли взаимодействовал с кем-то, работающим с другим набором функций. Единственными людьми, не изолированными от остальных, были счастливчики, работающие в нескольких командах. Сотрудники подразделения разработки получали задачи и выполняли только их до момента готовности всего релиза.
