Мы хотим создавать такое программное обеспечение, которое приносит пользу, нравится потребителям и вызывает у них желание заботиться о нем. Мы хотим, чтобы наше ПО работало эффективно и было создано максимально хорошо, так как тратим слишком много времени на споры о дизайне, архитектуре и технологиях. Все это действительно волнует команду. Сделать жизнь пользователей лучше – вот наиболее прямой путь, которым мы поставляем ценность. А это и есть настоящая, честная, вдохновляющая цель.
Этот принцип находится в верхней части списка принципов Agile-манифеста. Обратите внимание на слова, которые мы выделили.
Наш главный приоритет – удовлетворение заказчика посредством ранней и непрерывной поставки ценного программного обеспечения.
Причина, по которой это считается приоритетной задачей, в том, что поставка ценности пользователям – наиболее эффективный способ мотивации команд и движущая сила хорошего планирования спринта.
Начинать с бэклога – это значит начинать с пользователей
Почему мы планируем поставку специализированных функций в спринте, вместо того чтобы двигаться дальше? Потому что работали как команда, чтобы выяснить, какие функции наши пользователи считают наиболее ценными. Именно поэтому владелец продукта так важен – его задача понять потребности пользователей и своевременно информировать о них команду.
Будьте реалистичны в оценке того, что вы можете поставить заказчику
Многих менеджеров посещает безумная идея, что если не подбадривать разработчиков, то они будут бездельничать, выполнять минимум работы и устанавливать длинные сроки. Однако для большинства команд это неверно. Просто в реальности разработчики слишком большие оптимисты. Именно поэтому мы знаем немало проектов, которые завершились с опозданием, и почти не видели случаев, когда они заканчиваются раньше времени. Не пытайтесь втиснуть в спринт слишком много функций. (В конце концов, пользователи должны всего лишь дождаться следующего спринта, чтобы получить рабочее программное обеспечение, которое включает в себя очередной набор функций.) Хороший scrum-мастер помогает команде оценить работу и понять, чем можно заниматься, а чем нет.
Измените план, если это необходимо
Используйте преимущество ежедневных scrum-митингов, чтобы выяснить, действительно ли команда собирается закончить разработку тех функций, которые были запланированы в спринте. Когда необходимо изменить план, команда делает это. Если становится понятно, что не удастся закончить все работы в бэклоге спринта, то команда должна перенести некоторые из них (начиная с наименее значимых) из бэклога спринта обратно в продуктовый бэклог. Scrum-мастер обязан убедиться в том, что все члены команды понимают суть изменений. Пользователи, привыкшие видеть работающее программное обеспечение, меньше нервничают, не дождавшись во время обзора спринта ожидаемых функций, если владелец продукта предварительно их к этому подготовил.
Заставьте всех говорить о ценности
В успешных scrum-командах, как правило, многие понимают, что на самом деле нужно пользователям и что для них ценно. Единственный верный способ добиться этого – сделать так, чтобы каждый член команды понимал, что именно он будет делать для пользователей. Как это облегчит их жизнь? Что позволит им делать то, что раньше было невозможно? Все это действительно важно для agile-разработчиков. Чем больше вы обсуждаете это, тем лучше будет программный продукт.
Scrum одновременно инкрементальный и итеративный. Инкрементальный – потому что работа разбита на последовательные этапы, а итеративный – потому что команда адаптирует каждый новый спринт к изменениям, которые происходят во время проекта.
Когда успешные scrum-команды говорят, что они мотивированы поставлять ценность, они имеют в виду, что их важнейшая цель – создание программного обеспечения, которое улучшает жизнь пользователей.
Работа владельца продукта заключается в том, чтобы сохранить в команде мотивацию создавать ценность, помогая им понимать пользователей, разбираться в том, что они делают и для чего нужно ПО.
Роджер – руководитель команды, пытающийся использовать Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде
Акт IV. Собака ловит автомобиль
С тех пор как Роджер и Ави принесли Эрику новости о том, что стали называть «встречей со стейкхолдерами из ада», они не могли понять, почему он полон оптимизма. Несколько дней спустя все трое отправились после работы в соседний ресторан, чтобы все обсудить.
Эрик спросил: «Как вы думаете, почему все эти менеджеры по работе с клиентами были расстроены?»
У Роджера и Ави не нашлось ответа. Роджер заговорил о том, как команда старалась стать более гибкой, что в его понимании означало возможность приспосабливаться к потоку запросов на добавление новых функций и создание новой продукции каждый раз, когда это необходимо. Ави чувствовал, что потратил много усилий, чтобы «присоединиться» к команде и передать ей массу великолепных идей, высказанных менеджерами по работе с клиентами. Они оба ощущали, что предоставили заинтересованным сторонам именно то, что те просили. «Посмотри, я получил письма, в которых каждый из них просит именно то, что мы им предоставили, – сказал Ави. – Что же их могло огорчить?»
Эрик объяснил, почему он как agile-тренер доволен увиденным, хотя проект столкнулся с неприятностями. Он сказал, что раньше они были похожи на гигантское круизное судно, которому нужно проплыть много миль, чтобы сделать поворот. Теперь же они больше напоминают флот, состоящий из тесно взаимодействующих между собой быстроходных катеров. Пришлось больше общаться, но зато они могут разворачиваться на месте. А еще Ави избежал потрясений и появления некоторого антагонизма между ним и командой, он смог стать ее настоящим членом и успешным связующим звеном между командой и ее пользователями.
Помогая команде в организации эффективных ежедневных scrum-митингов, Роджер уполномочил ее самостоятельно организовывать свою работу согласно меняющимся приоритетам. Но появилась новая проблема, и Эрик объяснил, что это случается со многими командами, преодолевшими первый этап на пути к самоорганизации. Такая команда теперь имеет право эффективно менять направление деятельности. А входящий в состав команды владелец продукта может определять это направление.
Эрик предложил хорошую аналогию: «Вы когда-нибудь видели пожарную команду, которая учится тушить пожар при помощи пожарного шланга? Вам со стороны кажется, будто они просто целятся в огонь. Но они потратили недели или месяцы, пока не научились эффективно двигаться и общаться друг с другом, чтобы действовать согласованно. Раньше ваша команда была как садовый шланг, а теперь как пожарный.
Как мне поступить с зависимостями между задачами в моем плане проекта?
Точно так же, как и сейчас, – вы говорите об этом команде и выясняете ее мнение.
Для командно-административного менеджера проекта, использующего планирование в стиле «вначале детальные требования» и создающего большие диаграммы Ганта, это очень часто возникающий вопрос.
Идея самоорганизующейся команды, где каждый участник решает вопрос о своей следующей задаче перед началом работы, звучит нереально. Часто это происходит потому, что менеджер проекта тратит много усилий на выявление всех зависимостей между задачами. Учебники на тему «Управление проектами» (в том числе те, которые написали мы!) содержат разделы, объясняющие различные типы зависимостей (финиш-старт, старт-старт и т. д.) и то, как их определить и записать при планировании проекта. Так что нет смысла спрашивать, как именно анализ зависимостей проявляется в самоорганизующихся командах.
Почему руководителям проектов необходимы эти зависимости в начале проекта? Потому что они нужны для определения проектной деятельности, разделения задач на части, распределения их последовательности, выбора ресурсов и построения графика проекта. Упорядочить все это можно только одним способом: определив зависимости между отдельными задачами.
Предположим, что, пока член команды работает над задачей в общих чертах, он обнаруживает, что она зависит от другой задачи. Какой ужас! Теперь следующие задачи в плане будут сдвинуты назад, потому что принятая ранее последовательность задач не учитывала эту скрытую зависимость. Это приводит к каскадным задержкам – одной из самых распространенных причин изменения проектных планов. Еще хуже, если команда имеет фиксированный срок. Тогда руководитель проекта должен сделать трудный выбор и провести сложные переговоры о сокращении масштабов в конце проекта. Неудивительно, что менеджеры проектов зацикливаются на зависимостях! Этот сценарий до поры неизвестных зависимостей – распространенное явление, он превращает хорошо продуманные планы в хаос. Казалось бы, полный анализ может дать руководителю ложное чувство безопасности благодаря уверенности, что команда берет на себя просчитанные риски, – и привести к задержкам, которые, как обычно, случаются в самый неподходящий момент. Команда также испытывает ложное чувство безопасности, потому что тратит много времени на размышления о зависимостях, после того как план рассмотрен и распределен по командам.
Самоорганизующиеся команды также выявляют эти связи, но делают это гораздо лучше. Разница в том, что они имеют дело с зависимостями в последний ответственный момент, когда у них гораздо больше информации о задачах и они способны выполнять более полный анализ.
Все это хорошо в теории, но будет ли это ра