в каждом спринте заключается в том, что вы попутно создаете дополнительную ценность для клиентов. Представьте, что вы выполнили 10 % проекта, но отправляете эту часть только в конце. Вы, таким образом, держите 10 % функций в заложниках, пока не будут выполнены остальные 90 % проекта. Но, разделяя работу и часто отправляя результат, вы можете сразу представить эти 10 % функций клиентам.
Аджайл-команды обычно разбивают сложные задачи на части, создавая бэклог заданий, подлежащих выполнению. Если инженеры занимаются реализацией бэклога заданий текущего спринта, то задача менеджера по продукту состоит в подготовке бэклога заданий следующего спринта, устраняя неясности и неопределенности. За пределами следующего спринта существует море заданий на разных стадиях определения, но по мере выполнения спринтов они становятся все более и более ясными. Самое главное, это не является недостатком аджайл. Принимайте решения как можно ближе к моменту их реализации, чтобы получить как можно больше информации. Подобный метод уменьшает объем ненужной работы.
Тесное сотрудничество между бизнесом и разработчиками
В большинстве аджайл-команд есть две роли: владелец продукта и команда разработчиков. В скрам добавляется еще и третья роль: скрам-мастер. Задача владельца продукта состоит в понимании и защите клиента, а также в подготовке «пользовательских историй», описывающих потребности пользователя. Пользовательские истории – это инструмент взаимодействия владельца продукта и команды разработчиков. Конечно, это может смахивать на перекладывание работы на других, но в хорошо функционирующей аджайл-команде владелец продукта тесно сотрудничает с разработчиками в процессе подготовки и постепенного улучшения пользовательских историй.
Смотрите на пользовательские истории как на описание работы, подлежащей выполнению с точки зрения клиента. Этим они отличаются от технических требований к продукту прошлых лет, которые больше концентрировались на том, что должна выполнять программа, а не на том, что нужно клиенту. Разница может показаться несущественной, но она важна. В хорошо функционирующей аджайл-команде создание пользовательской истории и ее обсуждение сконцентрированы больше на клиенте, а не на ПО.
Плохая пользовательская история описывает большую сложную систему, а хорошая – ограничена по объему. Это повышает предсказуемость и снижает возможность неверных интерпретаций или появления открытых вопросов. Вместе с тем хорошая пользовательская история содержит сквозное описание того, что собирается делать клиент, так что разработчик может прочувствовать и понять проблему клиента. Это позволяет разработчику принимать правильные решения и использовать свою интуицию, а не просто «делать то, что приказано».
Владелец продукта, как и следовало ожидать, – обычно менеджер по продукту. Он должен не ограждать команду разработчиков от клиентов, а помогать членам команды понять потребности клиента. Владелец продукта служит связующим звеном и поддерживает диалог между клиентами и командой. Хороший владелец продукта умеет правильно резюмировать проблему клиента, подлежащую решению, и, таким образом, представляет широкий круг клиентов.
Владелец продукта управляет бэклогом работ команды. Бэклог представляет собой очередность будущих заданий, которые постоянно уточняются владельцем продукта с целью создания максимальной потребительской ценности в каждом спринте и работы над пользовательскими историями с высокой степенью осуществимости и полезности для клиента. Если в пользовательской истории все еще много неопределенности в потребностях клиента или осуществимости, то владелец продукта должен сделать все, чтобы найти ответы на незакрытые вопросы. Эту часть процесса называют «причесывание бэклога», она является одной из важнейших обязанностей владельца продукта. В каждом спринте, если команда разработчиков сосредоточена в основном на выполнении требований пользовательских историй для данного спринта, то владелец продукта занимается уточнением набора пользовательских историй для следующего спринта. Хотя формирование бэклога лежит в основном на владельце продукта, наполнение историй техническими деталями происходит в тесном сотрудничестве с разработчиками и совершенно непохоже на перекладывание работы на других.
Если все это кажется сложным, то так оно и есть. К работе необходимо привлечь аджайл-коуча, который поможет команде внедрить хорошую аджайл-гигиену, в частности расчет пунктов истории и причесывание бэклога. Если команде с трудом удается представлять работоспособное ПО в каждом спринте, то коуч должен помочь команде определить, в чем проблема – в определении объема, в низкой производительности, в плохом сотрудничестве, в расплывчатости пользовательских историй или во всем вышеперечисленном. Если аджайл-коуч покажется роскошью, то он может работать сразу с несколькими командами. Я не буду детализировать роль коуча, скажу только, что она похожа на роль любого другого коуча – когда нужно помочь команде чему-то научиться, хороший коуч может быть бесценным.
Слишком много вопросов
Итак, если аджайл – это лучшая методология создания ПО, разработанная к настоящему моменту, то почему до сих пор так много неудовлетворительных результатов? Давайте рассмотрим ряд вопросов, которые могут возникать у руководителей при работе аджайл-команд.
Почему вы не знаете, когда продукт будет поставлен клиентам и с какими функциями?
Первое, что вызывает досаду у руководителей и менеджеров, – это неспособность технических команд придерживаться жестких сроков. На мой взгляд, в разработке ПО есть четыре аспекта: функции, сроки, качество продукта и его определенность. Вообще говоря, вы можете выбрать любые три из них, но вам не удастся получить одновременно все четыре. Вы можете с уверенностью создать набор функций к определенному сроку, но качество продукта может сильно пострадать, поскольку разработчики будут упрощать многое, чтобы уложиться в срок. Вы можете создать продукт к определенному сроку и с предсказуемым качеством, но в реальности вам придется для этого урезать функции продукта. Вы можете с высокой уверенностью получить известный набор функций с хорошим качеством, но не будете знать, сколько времени это займет. Или можно замахнуться на все три аспекта – функции, качество и сроки, что звучит здорово, но, скорее всего, при низкой уверенности.
Если вы, как руководитель, потребуете выполнения всех четырех аспектов, то вам придется угадывать, какой из них – ложный. Или вы можете получить реалистичные отчеты от подчиненных, которые расскажут вам, основываясь на фактах, что произойдет, по их мнению. Если у вас жесткий срок – крупная конференция пользователей или маркетинговая кампания, которую необходимо осуществить любой ценой, – то они скажут, чем следует пожертвовать. Или назовут вероятность выдерживания сроков, что редко бывает точным или внушающим оптимизм. Поэтому, скорее всего, они будут настаивать на соблюдении функциональности, определенности и сроков. На первый взгляд, именно этого и ждут руководители. Жертвой, однако, чаще всего становится качество продукта. Поначалу это может
