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

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

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

■ при необходимости определить и внедрить среду разработки для поддержки распределенных команд.

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

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

Эти подходы оказались полезными при масштабировании проекта «Год 2000» (Y2K) [23] Многие программы, созданные в 1980-х и 1990-х годах, использовали в дате двузначную запись года, предполагая, что первые две цифры – 19. Таким образом, дата 01.03.19 означала бы 1 марта 1919 года. Это могло привести к драматическим ошибкам алгоритмов. . В конце 1990-х годов почти каждая организация пыталась добиться, чтобы ее программное обеспечение поддерживало даты позднее 1999 года и не создавало проблем на заре XXI века. В следующем разделе я расскажу, как одна компания успешно применила подходы к масштабированию скрама в крупном проекте, направленном на обновление программного обеспечения для Y2K, и помогла клиентам обновить версию системы.

Компания 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 функциональных единиц [24] Мера оценки количества бизнес-функциональности, которую информационная система предоставляет пользователю. Впервые предложена Аланом Альбрехтом в IBM в 1979 г. Для каждого функционального требования пользователя определяется количество элементов, относящихся к каждой из пяти категорий: ввод, вывод, запрос, внутреннее хранение, внешний интерфейс. Суммарная сложность функции оценивается в «функциональных единицах». . Особенности управления программным обеспечением со стороны клиентов Medcinsoft дополнительно осложняли ситуацию. Многие компании никогда не проводили столь массивную модернизацию своих систем и не были готовы к этому. У неожиданно большого числа клиентов не было ни тестовых сред, ни понятных отлаженных процессов проверки новых релизов.