Компания Medcinsoft использовала скрам для управления проектом Y2K, целями которого были адаптация продуктов Medcinsoft к датам после 31 декабря 1999 года, установка обновлений программного обеспечения более чем в 350 крупных организациях здравоохранения, обучение персонала больниц, стабилизация установленного обновления до 1 октября 1999 года. Программное обеспечение Medcinsoft автоматизирует административные документы организаций здравоохранения, включая регистрацию пациентов, выписки, выставление счетов на оплату, страхование, ведение медицинских карт, учет задолженностей клиентов. Неудача такого программного обеспечения имела бы катастрофические последствия для этих организаций и обслуживаемого ими населения. До начала использования скрама компания Medcinsoft для управления проектами применяла диаграммы Ганта, но они оказались крайне неуместными. Клиенты были недовольны: релизы часто задерживались на несколько месяцев, имели пугающее количество ошибок и не содержали ожидаемых функций.

Проект Y2K был комплексным и требовал масштабирования в нескольких измерениях одновременно. Необходимо было координировать работу более 300 разработчиков, определив приоритеты задач по реализации нового функционала различных продуктов, устранению «ошибки 2000 года» и исправлению дефектов. Более 400 полевых сотрудников поддержки нуждались в приоритизации и координации их работы и взаимодействия с клиентами Medcinsoft. Более 600 сотрудников из 350 организаций-клиентов нуждались в возможности сообщать в Medcinsoft о планах и изменениях в них. Клиенты работали с разными версиями программного обеспечения Medcinsoft, доработанными и настроенными под их конкретные потребности. У каждого клиента был свой уникальный график обновления используемых им систем, в том числе и обновления программного обеспечения Medcinsoft по проблеме Y2K. У клиентов также были уникальные расписания тестирования устанавливаемых систем и обновлений. Проще говоря, графики установки и тестирования и уровни знаний и навыков клиентов Medcinsoft существенно различались.

Скрам уже применялся успешно в одном из проектов Medcinsoft, поэтому руководство спросило менеджера проекта Y2K Джека Харта, сможет ли он использовать скрам для исправления ситуации. Самыми большими проблемами, стоящими перед Джеком, были сложность координации выполняемой работы и изменчивость сроков в разных частях этой работы. Для адекватной координации ему нужна была точная и своевременная информация. Нерегулярная информация о планах клиентов часто оказывалась противоречивой, а информация о статусе релизов – недостоверной. Задержки в предоставлении релизов достигали нескольких недель. Клиенты и полевые инженеры поддержки общались друг с другом неэффективно или не общались вообще.

У каждого клиента было собственное расписание тестирования программного обеспечения Medcinsoft, привязанное к тестированию других программных пакетов. Эти планы, в свою очередь, были связаны с планами по обучению персонала и тиражированию систем. Завершить все работы по каждой системе нужно было до начала 2000 года. Medcinsoft должна была не только своевременно предоставить каждому клиенту новый релиз, но и иметь возможность изменить дату поставки, если у клиента возникли бы какие-либо изменения в графике. Каждый релиз Medcinsoft должен был быть готовым к поставке: все известные работы по устранению проблемы Y2K произведены, программное обеспечение полностью протестировано, все критические и высокоприоритетные ошибки исправлены, а все оставшиеся дефекты задокументированы. Все уникальные доработки, произведенные для клиента, необходимо было повторить в новой версии. Далее релиз должен был быть установлен на площадке заказчика, а все предыдущие настройки восстановлены полевым инженером Medcinsoft. Наконец, прописав значения параметров интерфейсов взаимодействия, обновленную версию системы Medcinsoft нужно было интегрировать с другими используемыми клиентом системами.

Перечисленных проблем было предостаточно, но список трудностей Джека на этом не заканчивался. Несмотря на то что ранее проводились обширные и внимательные поиски недочетов по проблеме Y2K в соответствии с отраслевыми и внутриорганизационными рекомендациями, новые дефекты Y2K все еще регулярно обнаруживались. Кроме того, Medcinsoft планировала добавить в релиз Y2K новую функциональность веб-доступа, а ошибки, возникающие при ее реализации, оказались трудными для обнаружения. По мере устранения новых дефектов часто создавались другие – регрессионные дефекты. Некоторые части программного обеспечения были очень древними. Написавшие код разработчики уже не работали в компании и не могли внести исправления Y2K или хотя бы помочь советом, поэтому сегодняшним разработчикам приходилось параллельно изучать и обновлять код. При этом базовое программное обеспечение было велико согласно почти любым стандартам, оно оценивалось в 2500 функциональных единиц. Особенности управления программным обеспечением со стороны клиентов Medcinsoft дополнительно осложняли ситуацию. Многие компании никогда не проводили столь массивную модернизацию своих систем и не были готовы к этому. У неожиданно большого числа клиентов не было ни тестовых сред, ни понятных отлаженных процессов проверки новых релизов.

Скрам обеспечивает определенную степень регулярности и предсказуемости в комплексной или хаотичной среде. Именно таким был проект 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 новой функциональности веб-доступа использовались те же механизмы масштабирования. Проект начался с довольно интенсивных спринтов по проектированию системы. Результатом каждого спринта была и рабочая пользовательская функциональность, и все более детализированная архитектура системы, не допускающая ситуаций, при которых разные команды спотыкались бы друг о друга.

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

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

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

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