Скрам

Команды разработки были сгруппированы по функциональности, например СОЗ (счета клиентов, оплата по выставленным счетам, задолженность клиентов), РАСП (ведение расписаний) и т. д. (см. рис. 9.4). На планировании спринта Джуди помогала каждой команде разработки выбрать элементы бэклога продукта, соответствующие ее функциональной области. Участники команды работали в Medcinsoft достаточно долго, поэтому выбор исполнителей не вызывал вопросов. Если задач для полной загрузки команды было недостаточно, то команда во время этого спринта работала над проектом Y2K только часть своего времени, а оставшуюся часть – над другими проектами. Джек использовал такой подход, чтобы обеспечить четкое разделение работы, поскольку над элементами бэклога продукта Y2K могли одновременно работать до 20 команд по 10 участников в каждой. Среди этих команд находились функциональные команды, команды сборки системы, команды обнаружения дефектов Y2K, команды тестирования и команды релизов.

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

Исправление ошибок

Обнаруживаемые ошибки вносились в систему отслеживания дефектов. Одни ошибки команда тестирования находила при регрессионной проверке создаваемого инкремента продукта. Другие были ошибками Y2K и выявлялись в ходе их постоянного поиска для снижения возможных последствий неправильной работы программного обеспечения в связи с этой проблемой. Третья группа ошибок возникала при установке и тестировании релизов Y2K на площадках заказчиков. Изначально Medcinsoft намеревалась исправить все ошибки и дефекты вплоть до финальной версии релиза Y2K, запланированной к выпуску 1 октября 1999 года. Но такой план был отвергнут клиентами. Они хотели как можно скорее обезопасить себя, «задраив люки» задолго до начала 2000 года. Чтобы успеть в более сжатые сроки и повысить целостность каждого релиза, Джуди анализировала новые дефекты перед ежедневным скрамом, а затем добавляла все критические и высокоприоритетные ошибки в бэклоги спринтов различных команд, работавших над этим релизом. Этим действием Джуди явно нарушала правило скрама, согласно которому никакая внешняя работа не может добавляться в спринт команды после его начала. Тем не менее другая практика скрама – «руководствуйся здравым смыслом» – одержала верх, поскольку поставка новых релизов без незамедлительного устранения дефектов просто впустую потратила бы время клиентов и спровоцировала бы дополнительные проблемы.

Джек установил скрам-командам следующие правила для управления своим временем и работой, сказав, что задачи Y2K имеют наивысший приоритет. Если они выделили только 50 % своего времени на задачи спринта, а оставшиеся 50 % времени работали над другими вещами, то о последних можно забыть, пока не будут исправлены все ошибки и дефекты Y2K. Если команда разработки была загружена задачами Y2K на 100 %, то участники команды должны пойти в остальные команды и пригласить других инженеров помочь устранить все ошибки Y2K до последней.

Извлеченные уроки

Компания Medcinsoft успешно обошла комплексные отмели проекта Y2K и удовлетворила потребности своих клиентов за счет постоянной инспекции, анализа, выработки решений и адаптации. Многие из участвующих в этом проекте команд не разрабатывали программное обеспечение; они тестировали его, устанавливали его, координировали деятельность. И тем не менее все они использовали механизмы инспекции и адаптации скрама, чтобы оставаться в курсе любых изменений.

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

Выводы