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

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

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

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

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

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

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

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

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

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

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

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

После составления списка я объяснил команде разработки концепцию трассирующей пули, представленную Эндрю Хантом и Дэвидом Томасом в книге «Программист-прагматик. Путь от подмастерья к мастеру» [13] Хант Э., Томас Д. Программист-прагматик. Путь от подмастерья к мастеру. – М.: Лори, 2009. – Прим. ред . . Концепция заключается в следующем: стреляя из автоматического оружия в темноте, трудно поразить цель, но каждая 50-я пуля оставляет видимый след, его можно использовать для корректировки прицела. Я попросил команду создать трассирующую функциональность, проходящую через все слои системы, чтобы проложить и показать путь для всех других функций. Такую функциональность, чтобы вход в систему и бизнес-процесс инициирования кредита частично или целиком задействовали оба продукта и отвечали всем перечисленным в бэклоге нефункциональным требованиям.

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

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