Скрам

Назначение конкретных задач исполнителям, назначение «счастливчиков» на задачи нескольких команд и, в особенности, водопадный процесс – все это приводило участников к ощущению изолированности и отсутствию реальной работы по созданию релиза в течение первых трех-четырех месяцев. В оставшиеся два месяца разработчики пытались компенсировать накопленное отставание.

Следующий релиз был запланирован на 7 апреля, в марте должна была бы состояться демонстрация пользователям. Шел конец октября: сотрудники уже сосредоточились на предстоящих праздниках[12], постепенно восстанавливались после кризиса при завершении последнего релиза. В то же время менеджеры уже всерьез переживали, хотя шестимесячный цикл подготовки нового релиза начался всего три недели назад. Успеем ли вовремя? Неужели сотрудникам снова придется трудиться в поте лица, постоянно перерабатывая в течение последних двух месяцев? Несмотря на сокращение цикла с года до полугода, никто не заметил каких-либо существенных изменений, поэтому все ожидали худшего.

Применение скрама

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

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

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

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

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

1. Вход в систему для инициирования кредита;

2. Запуск процесса инициирования кредита;

3. Унифицированный внешний вид продукта;

4. Унифицированная для обоих продуктов безопасность;

5. Бесшовное и масштабируемое исполнение процесса.