Читать «Скрам (Гибкое управление продуктом и бизнесом)» онлайн - страница 40

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

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

Извлеченные уроки

Пример Service1st показывает, насколько бывает трудно в комплексном проекте выяснить все детали заранее. Взаимодействие двух продуктов было настолько сложным, комплексным и неопределенным, что задачи, запланированные менеджерами в начале цикла создания релиза, устаревали вскоре после их назначения исполнителям. Работа только началась, а проект почти сразу стал отставать от расписания.

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

Также команда не чувствовала прогресс, не могла определить, насколько близка к запланированному релизу. Но разве у нее были другие варианты? Только когда оставалось всего два месяца из шести и работа переходила в режим «тушения пожара», менеджеры понимали, что пора отказаться от первоначального плана и позволить участникам делать все необходимое для реализации максимально возможной функциональности. К сожалению, времени оставалось слишком мало, поэтому команде разработки приходилось работать сутки напролет, в том числе по ночам и выходным дням. Разработчикам постоянно не хватало времени для написания качественного кода и его отладки, поэтому релизы выпускались с дефектами, а клиенты не были так счастливы, как хотелось бы.