Нарушайте правила

Более 70% заказной разработки ПО в Европе и США и до 30% в России выполняется с использованием методологии Scrum, но, несмотря на ряд преимуществ по сравнению с «водопадной» моделью разработки, лишь четыре из десяти Scrum-проектов завершаются успешно. Почему? Компаниям, предоставляющим услуги заказной разработки, необходимо соблюдать основополагающее правило скорых (agile) методов — максимально привлекать к проекту представителя заказчика.

Как и другие гибкие технологии, Scrum позволяет сделать процесс разработки программного обеспечения упорядоченным и прозрачным для всех заинтересованных сторон. В Scrum отсутствует излишний формализм, а основное внимание уделено общей продуктивности команды, максимальному конечному соответствию разрабатываемого продукта реальным, часто меняющимся во времени, бизнес-задачам клиента. Это предполагает постоянную периодическую демонстрацию заказчику промежуточных версий продукта, пусть и с минимальным приращением функциональности. Разработка производится одинаковыми небольшими, от двух до четырех недель, промежутками времени — итерациями («спринтами»). К концу каждого спринта программисты вместе демонстрируют представителю клиента текущую версию, сверяют как качество системы, так и правильность реализации требований и при необходимости корректируют дальнейший ход разработки. Эта методика позволяет на ранних этапах выявлять и устранять отклонения от желаемого результата и таким образом минимизировать временные и финансовые потери, что отличается от традиционного «принципа водопада», согласно которому вся система сдается заказчику одновременно, в самом конце проекта.

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

Однако на практике заказчик из-за высокой загрузки часто не в состоянии уделять разработчикам достаточно времени — многим командам знакома ситуация, когда программисты могут работать в течение нескольких месяцев, но заказчик лишь в конце проекта находит возможность посмотреть на результаты и понять, что они не соответствуют его ожиданиям. Как избежать срыва проекта? Можно ли выполнить заказную разработку в соответствии со Scrum, но без постоянного активного вовлечения заказчика? При правильной организации работы сама команда разработчиков способна успешно выполнять значительную часть функций, отводимых заказчику.

Сочиняйте новые роли

Классический Scrum предусматривает три роли: «Владелец продукта» (Product Owner), «Scrum-мастер» и «Команда разработчиков» (Scrum Team). В успешном Scrum-проекте «Владелец продукта» проводит с командой до 100% времени, а если стопроцентная вовлеченность невозможна, то разработчикам следует ввести дополнительное действующее лицо, способное перехватить большую часть функций Product Owner, но при этом более доступное команде. В нашей компании новая роль получила название Proxy Product Owner (PPO) — полномочный представитель владельца продукта.

Роль PPO может исполнить Scrum-мастер или Test Lead (руководитель группы тестировщиков либо ведущий инженер по тестированию). PPO «засылается» к заказчику как можно раньше, в идеале — на этапе бизнес-планирования проекта, когда в обсуждении продукта принимают участие все заинтересованные лица со стороны клиента. PPO досконально изучает все требования и пожелания заказчика, что позволит ему формулировать, уточнять и ранжировать требования к продукту, составлять приемочные тесты для конкретного спринта, а также тестировать продукт в течение итерации от лица заказчика. Фактически он становится доверенным и приближенным представителем клиента, все время находящимся с ним на связи. При этом PPO постоянно доступен команде и в состоянии ответить на любой вопрос разработчиков.

Одна из главных характеристик Scrum-проекта — прозрачность, обеспечить которую позволяет грамотно составленная система отчетности. Если «Владелец продукта» присутствует на проекте только в дни демонстраций промежуточных версий (то есть один раз за итерацию), то правильно сформированная отчетность станет для заказчика надежной «приборной панелью проекта», способной предоставить всю ключевую информацию по объему проделанной работы.

Зачастую не имеет смысла перегружать отчеты для менеджеров на стороне клиента такими техническими показателями, как цикломатическая сложность кода, коэффициент тестового покрытия и т. п. Хотя сбор и анализ этих показателей чрезвычайно полезны для управления качеством продукта, любого заказчика интересуют в первую очередь два вопроса: успевает ли команда сделать продукт в срок и укладывается ли она при этом в бюджет. Метрики для заказчика должны быть визуализированы и содержать такие показатели, как динамика проекта (скорость реализации требуемого объема функциональности), бюджетное управление (расход средств в рамках проекта), плотность дефектов и т. п. Обновляемость отчетов должна составлять от одного дня до одной итерации. Оперативные и достоверные данные позволяют «Владельцу продукта» отслеживать реальный ход проекта, положительные и негативные тенденции, вносить коррективы в текущую ситуацию и делать прогнозы. Например, проектные метрики позволяют оценить текущую степень готовности продукта и отслеживать скорость реализации запланированного на спринт объема функционала: если разработка идет быстрее плана, команда, по согласованию с заказчиком, может добавить в бэклог (журнал) спринта (Sprint Backlog) новые задачи. Несмотря на то что классический Scrum запрещает изменять список задач в течение спринта, зачем тормозить процесс? Однако нужно отметить, что серьезные отклонения от плана (как положительные, так и отрицательные) могут сигнализировать о неточности процедуры оценки или о появлении непредвиденных технических трудностей. В любом случае наглядная демонстрация показателей проекта позволит вовремя скорректировать и приблизить к реальности ожидания, связанные с графиком движения проекта (рис.1).

Рис. 1. Примеры проектных метрик

Творчески планируйте время спринта

В традиционном Scrum-проекте каждый спринт содержит несколько этапов: первый день — планирование спринта; последний день — демонстрация готовой версии продукта заказчику; промежуток между первым и последним днем занимает разработка. Параллельно с разработкой ведется тестирование (в рамках Agile-методологий тестирование не выделяется в отдельный этап после разработки, а рассматривается как органическая часть процесса создания ПО). Такая плотность спринта ускоряет процесс разработки, но иногда может негативно сказаться на качестве продукта. Это происходит в тех случаях, когда к концу спринта в коде накапливается определенное количество неисправленных ошибок. Если не следить за этим накапливающимся долгом, то к концу проекта он может произвести эффект снежного кома и запуск системы в эксплуатацию может оказаться под угрозой.

Как ни парадоксально, но с целью увеличения продуктивности проекта имеет смысл пожертвовать одним днем разработки в течение итерации и потратить его на стабилизацию и улучшение уже написанного кода. Для этого идеально подходит предпоследний день спринта (рис. 2).

Рис. 2. Составляющие классического и реформированного спринта

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

Компания First Line Software

Компания специализируется на заказных ИТ-решениях, разработка которых ведется в Санкт-Петербурге, Нижнем Новгороде и Москве. Клиентами компании, выполнившей на данный момент около 200 проектов, являются крупные российские и зарубежные организации и государственные предприятия. Более 90% проектов выполняются на базе Scrum-методологии. First Line Software первой в мире выполнила крупномасштабный глобально распределенный Scrum-проект, а в 2012 году получила сертификат зрелости Scrum-процессов от компании Scrum, основанной Джеффом Сазерлендом.

Пример проекта

В 2010 году First Line Software была привлечена к участию в проекте для крупнейшего медиахолдинга Европы, издающего более 100 газет и журналов. Заказчик планировал построить единую систему управления веб-контентом для онлайн-версий всех входящих в холдинг изданий, а затем осуществить перевод на новую платформу (созданную на основе CMS-системы EPiServer) сайтов всех этих изданий, сохраняя при этом полноту уникального контента и структуру URL-адресов. Программа была рассчитана на два года. Для ее реализации потребовалось задействовать более 150 разработчиков и тестировщиков. В качестве подрядчиков были приглашены две аутсорсинговые ИТ-компании и консультативное ИТ-агентство.

С целью увеличения производительности и сокращения сроков работ First Line Software предложила использовать территориально распределенный Scrum-процесс. Для управления каждым из проектов, выполняемых разработчиками First Line Software, были выделены два консультанта: Product Owner и менеджер проекта (Project Manager, PM). Первый исполнял классические функции владельца продукта в Scrum, а второй должен был отвечать за административное управление проектом, отслеживание бюджета и управление ресурсами команды (рабочий день программистов, добавление новых программистов, предоставление отпусков и сверхурочных и пр.). Несмотря на то что в Scrum не существует роли PM, заказчик просил ее ввести.

Практически с первого спринта стало ясно, что Product Owner не всегда доступен всем участникам команды, поэтому в проект была введена роль PPO, который постоянно находился в контакте с владельцем продукта, собирая информацию для написания бэклога и ответов на вопросы разработчиков. Через некоторое время PPO достиг такого уровня компетенции в бизнес-вопросах заказчика, что руководители программы на стороне клиента приняли решение упразднить отдельную позицию Product Owner и перенести эту роль на сторону First Line (см. рисунок).

 

Состав участников проекта до и после введения роли PPO

 

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

В целом программа по внедрению новой платформы для управления онлайн-ресурсами медиахолдинга была успешно реализована: более 60 интернет-изданий (некоторые из них имеют до 7 млн уникальных посетителей в неделю) были перенесены на новую CMS-платформу, их редакторские коллективы получили расширенную функциональность, а доходы от онлайн-рекламы выросли за счет повышения качества интернет-изданий и оптимизации таргетирования рекламных объявлений на основе анализа предпочтений посетителей сайтов. Кроме того, новая стандартная платформа управления контентом позволила более чем в пять раз снизить трудозатраты на техническую поддержку интернет-ресурсов по сравнению с тем, что было до реализации проекта.

Сергей Юрасов (sergey.yurasov@firstlinesoftware.com) — руководитель центра разработки First Line Software (Нижний Новгород).