Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

Скрам обеспечивает определенную степень регулярности и предсказуемости в комплексной или хаотичной среде. Именно таким был проект Y2K, поэтому Джек решил применить скрам ко всем аспектам проекта, даже к действиям полевых инженеров на площадках клиентов. Джек синхронизировал релизы с 30-дневными спринтами: в конце каждого спринта Medcinsoft предоставляла клиентам новую рабочую версию программного обеспечения. Каждый спринт выпускался релиз, содержащий самые приоритетные элементы бэклога продукта и обнаруженные в процессе разработки критические ошибки. Однако Джек испытывал затруднения в своевременном получении точной информации о приоритетах клиентов, датах установки и критических исправлениях. Информацию о потребностях каждой компании-клиента предоставляли полевые инженеры поддержки, с которыми общались разные сотрудники организации-заказчика. Поэтому Джеку нужен был нормализующий фильтр и прием, позволяющий сделать эту информацию своевременной, предсказуемой и точной. Таким приемом стали ежедневные скрамы для клиентов, которым релиз Y2K от Medcinsoft требовался в течение трех месяцев, и еженедельные версии ежедневных скрамов для клиентов, дата релиза которых была позднее трех месяцев. На каждом событии ежедневного скрама клиент и полевые сотрудники службы поддержки Medcinsoft обсуждали текущее состояние и проблемы проекта. Они поддерживали в актуальном состоянии планируемую дату очередного релиза программного обеспечения Medcinsoft и упорядоченный по приоритету бэклог релиза клиента, содержащий список требуемых доработок, настроек, функциональных возможностей системы, оставшихся критических и высокоприоритетных дефектов (см. рис. 9.2). У каждого клиента был свой собственный бэклог продукта, эволюционирующий со временем.

Полевые инженеры агрегировали бэклоги клиентов в бэклоги Medcinsoft по районам, затем районные – в бэклоги по регионам (см. рис. 9.3), а региональные – в единый «бэклог службы поддержки Medcinsoft». При любом изменении бэклога клиента изменялась и соответствующая ему часть в бэклоге службы поддержки Medcinsoft. Затем этот комбинированный бэклог упорядочивался по приоритету, чтобы планировать работу среди всех клиентов. Руководители полевых инженеров использовали его, чтобы распределять персонал на местах для выполнения настроек и оказания помощи во внедрении, тестировании и тиражировании программного обеспечения.

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

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

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

Часть верхних элементов бэклога продукта в начале спринта могла выглядеть так:

■ дефект неправильной даты печати в заголовке отчета в модуле или отчете;

■ дефект отображения неправильного года на экранной форме в модуле демографических данных пациента;

■ модуль демографических данных пациента зависает при вводе 2010 года в поле даты;

■ новый подключаемый модуль от поставщика программного обеспечения для устранения проблемы с переносом даты;

■ ошибка в модуле демографических данных пациента: экранная форма изменения адреса не возвращается к корректной предыдущей странице;

■ клиент MediLife запрашивает релиз для внедрения (в настоящее время установлена версия 8.1);

■ клиент MedClinic запрашивает релиз для внедрения (в настоящее время установлена версия 7.2).

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

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