Работа с требованиями в Agile

Расскажу о работе с требованиями в Agile, про то, в каких сферах заказной разработки это применимо, посмотрим, как можно визуализировать требования в Agile.

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

Инструменты и принципы управления требованиями в гибких подходах

Agile часто ассоциируется со Scrum и Kanban, но когда мы сталкиваемся с разработкой больших продуктов, где много зависимых друг от друга задач, с применением гибких подходов возникают проблемы.

В основе Agile лежит командная работа – мы оптимизируем наши процессы в команде, чтобы работать в тесном взаимодействии друг с другом.

Требования – это всегда контрактование с кем-то: или команды с заказчиком, или внутреннее контрактование аналитики с разработкой.

Но чем больше деталей и нюансов описано в вашем ТЗ, тем больше костылей в своем продукте вы будете делать.

Вы детально проработали требования с заказчиком, зафиксировали их, и потом, когда вы начинаете их реализовывать, вы понимаете, что какие-то детали не получается реализовать так, как хотели изначально. Из-за этого приходится изобретать костыли, а это приводит к тому, что сроки затягиваются, и мы в итоге получаем не совсем тот продукт, на который рассчитывали вначале.

А когда мы переходим в Agile, этап контактирования аналитики с разработкой перестает быть важным, мы должны четко коммуницировать внутри команды.

При этом контрактирование с заказчиком никуда не девается, но в Agile-команде мы с заказчиком фиксируем общие требования и затем, работая итеративно, пытаемся уточнять требования по мере их возникновения.

Перечислю принципы работы с требованиями в Agile.

Коммуникация лицом к лицу – самый важный принцип. Это важно при взаимодействии как внутри команды, так и с заказчиком. Если заказчик не идет на контакт и не дает обратную связь – Agile-подход разваливается. Мы должны постоянно общаться с разработчиками и потребителями, чтобы непрерывно улучшать и модифицировать продукт. Если у вас коммуникация не выстроена, заказчик просто выслал ТЗ и на контакт не идет то классический инструментарий более эффективен – фиксируем требования, реализуем их, забираем деньги и разбегаемся.

От общего к частному – еще одна важная концепция. Работая с большим продуктом, мы понимаем, что какие-то кусочки продукта не можем уточнить до конца. Мы на каждом этапе собираем из понятных для нас кусочков MVP. И нам надо на старте определить, какие между этими кусочками есть взаимосвязи. Если вы не определите эти взаимосвязи, на этапе реализации столкнетесь с тем, что команда постоянно будет на чем-то завязана и не сможет с этим справиться – концепция поставки продукта по кусочкам перестанет работать. Поэтому на первом этапе сделайте овервью продукта – определите зависимости внутри команды и от внешних команд. А дальше – работайте с требованиями так же, как с разработкой: фиксируйте маленькие кусочки требований на каждом отрезке времени.

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

В команде появляется человек от бизнеса, который дает нам бизнес-контекст, говорит о том, что мы хотим получить, на какого пользователя мы ориентируемся. Если бизнес не знает бизнес-контекст – это странно, но такое тоже бывает, особенно если мы работаем с b2g (business-to-government).

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

Поскольку на коротких промежутках времени выявить взаимосвязи не получается, мы с помощью этого принципа можем выстроить общую картину на квартал.

Мы обрисовываем картину, делаем высокоуровневое планирование, фиксируем фичи и зависимости между ними. И дальше крупноблочно раскидываем, что сможем сделать внутри команды за квартал.

Визуализировать зависимости между командами помогает «доска зависимостей». С помощью этой доски удобно разбираться с зависимостями и блокерами в Agile-проектах.

Если хотите познакомиться с этим инструментом подробнее, концепция принципа планирования «набегающей волной» очень хорошо описана в методологии Scaled Agile Framework (или SAFe).

Рассмотрим, как визуализируются требования в Agile.

Есть совсем высокоуровневые требования от бизнеса – эпики. Мы общаемся на уровне бизнеса только этими понятиями. Мы не знаем, что он хочет. Он не понимает, что в его системе происходит, поэтому, условно, он говорит: «Я хочу, чтобы у меня ничего не болело». А потом эта просьба разбивается на детали: фичи и истории. Это – классическая схема, которую вы наверняка видели в имплементации инструментов Jira, Team Foundation Server и т.д.

Эпики, фичи и истории – это то, над чем работает Agile-команда вне зависимости от того, как она организована (работает по Scrum, Kanban или как-то по-другому).

Но здесь есть разделение:

• Epic – это работа с бизнесом.

• Feature – детализация и сбор обратной связи от бизнеса по конкретному кусочку (обычно, за период квартал).

• Story – работа с командами внутри спринтов, обычно не более двух недель. Это короткое описание небольшого компонента и желаемой функциональности понятным пользователю языком. Даже по Story мы собираем обратную связь с заказчика.

Формируем высокоуровневые требования

Если вы будете детально расписывать требования заказчика текстом – команды это читать не будут и после двух-трех страниц текста начнут разработку.

Заказчик тоже не любит читать большие требования – он попросит: «Лучше покажите мне на картинке, как это будет, а детали мне не важны – я вам доверяю».

Для наглядного формулирования требований от заказчиков есть специальные инструменты, например Impact Mapping.

В начале построения Impact Mapping мы формируем цель – зачем нам нужен проект или продукт?

После этого смотрим, где наши зависимости – с кем мы будем взаимодействовать внутри создания ценности (с нашими заказчиками и стейкхолдерами), и с кем мы будем взаимодействовать во внешней среде (сюда относятся в том числе наши антистейкхолдеры – наши конкуренты и вредители)

Смотрим, как стейкхолдеры и антистейкхолдеры будут влиять на создание нашего продукта;

И прописываем конкретные действия, которые мы будем предпринимать, чтобы поддержать полезные влияния и минимизировать вредные.

Формируем Story

После того, как мы вместе с заказчиком обрисовали «вид сверху» о том, как это все работает, мы спускаемся вниз, на уровень декомпозиции – формируем истории (Story) для команды.

Здесь тоже есть инструменты, которые помогают нам декомпозировать историю от бизнеса к тому, что мы будем делать спринтами, каденциями и т.п.

Самый простой инструмент – User story mapping, где мы идем от пользователя.

У нас есть пользователь, мы описываем последовательность действий, которые нужно сделать, чтобы пользователь достиг своей цели.

В качестве примера возьмем публикацию сториз в Инстаграм: пользователю нужно войти в профиль, создать историю, загрузить фото и так далее.

Декомпозицию делаем совместно с командой, но с привлечением точечных стейкхолдеров, которые могли бы подтвердить или поправить то, как команда видит задачу.

Дальше говорим о том, как поддержать историю технически – по каждому действию расписываем детали технической реализации, как мы достигнем эту ценность.. Например, вход мы можем организовать с помощью OpenID, логина Facebook, Twitter и т.д. Расписываем каждый такой вариант и приоритезируем.

Первый подход к декомпозиции от бизнеса к конкретным историям – что мы будем делать на короткой итерации. У нас есть:

• цель пользователя;

• задачи пользователя – «хребет»;

• MVP – «ходячий скелет», минимальные потребности, которые мы закрываем и по которым можем собрать обратную связь, нам нужно убедиться, что этот «скелет» начал «ходить».

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

Мы обрисовали овервью, сделали маленький прототип и дальше на него «матрешкой» начинаем наслаивать нашу функциональность. Если у вас продукт такого рода, вам подходит итеративная инкрементальная разработка по гибким подходам.

Вот так это выглядит в жизни:

• есть пользователь;

• есть его потребности;

• по каждой потребности команда детально расписывает требования.

Команда собирается вместе и клеит стикеры на доску. С приходом онлайн-инструментов сделать это можно удаленно: например, с помощью Miro или Mural, где мы можем очень быстро командой раскидать эти блоки.

Классический подход работы с требованиями – работаем через документы:

• согласуем с заказчиком бизнес-концепцию,

• бизнес-аналитик с системным аналитиком собирает бизнес-требования и системные требования.

Очень много документов, есть высокая вероятность ошибиться на каждом этапе, есть вероятность, что какие-то документы придется пересогласовывать – это сложно и долго. Проще всего собрать их в одном месте и проработать видение, а потом детали.

Когда мы работаем со Story – продуктовая команда встречается с заказчиком и набрасывает пользовательскую историю, идею того, что хочет получить заказчик.

• для кого этого нужно;

• что конкретно нужно;

• зачем это нужно.

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

Далее фиксируем договоренности, критерии приемки, критерии готовности: все мысли и замечания о том, как мы будем принимать продукт, когда будем считать его готовым.

В работе с маленькими описаниями есть три составляющих: Card, Conversation и Confirmation.

• сначала мы описываем концепцию – Card;

• Обсуждаем ее – Conversation;

• Описываем детали – Confirmation.

Эта модель называется 3Cs, когда мы от обсуждений плавно переходим к реализации.

На слайде показан пример:

• менеджер парковки хочет получать уведомления;

• детализируем, как он хочет получать уведомления;

• а затем описываем критерии приемки.

Как выглядит концепция коммуникации? Как выглядит Story?

Если вы зайдете в любой инструмент контроля требований, например, в Jira, вы увидите, что у каждой задачи есть обязательные атрибуты:

• название – без него непонятно, о чем эта задача;

• шаблон контекста – можно задавать контекст в формате User Story или Job Story, мы это сейчас тоже сегодня разберем;

• критерии приемки – на слайде они описаны в виде Gherkin (Given/When/Then);

• приоритет;

• оценка.

Разберемся, как формировать контент, какие есть типы формирования контента

Есть два известных шаблона Story: Job Story и User Story.

Оба шаблона применяются, любой из них помогает в коммуникации и в финализации ваших требований.

Классический формат шаблона User Story выглядит так:

Как <Роль>
Я хочу <Действие>
Для того чтобы <Цель>

И есть формат Job Story

Когда <ситуация>
Я хочу <мотивация>
Чтобы <результат>

Оба шаблона содержат результат или цель – что мы хотим получить в результате реализации той или иной функциональности. И здесь мы на стадии сбора требований уже начинаем собирать обратную связь с заказчика – правильно ли мы его поняли.

В этих шаблонах есть два различия.

• в шаблоне User Story мы больше фокусируемся на роли, описываем роль и персону, которая будет работать с нами;

• в шаблоне Job Story мы описываем ситуации и то, что мы с этой ситуацией хотим сделать или что хочет сделать пользователь, и где мы ему должны помочь.

Эти моменты мы формулируем на этапе взаимодействия с заказчиком. Мы выравниваем понимание заказчика с пониманием того, что нужно сделать команде.

Формируем критерии приемки

В конце работы с историей мы формируем для нее критерии приемки. Здесь есть известный шаблон: Given, When, Then.

• мы описываем, что у нас дано – начальная история;

• когда, в каких случаях возникают какие-то действия;

• что мы получаем в результате реализации.

Возьмем пример со светофором.

• Дано: горит красный сигнал светофора

• Когда проходит определенное количество времени

• Что мы должны сделать? – переключить сигнал светофора на желтый.

Наши действия – это и есть механизм переключения между красным и желтым.

Непрерывные исследования

Agile – это не только работа в команде, но и непрерывный процесс исследования и коммуникации. Мы постоянно работаем с заказчиком, с потребителями, с командой – коммуницируем со всеми ролями, вовлеченными в процесс создания продукта.

Многие, кто начинает применять Agile, об этом забывают – они считают, что в Agile у команды просто есть бэклог с требованиями от заказчика, и команде эти требования нужно реализовать. Это не совсем так.

Agile подталкивает к трем следующим активностям:

• мы должны непрерывно подготавливать требования, взаимодействуя с заказчиком (непрерывное исследование);

• непрерывно реализовывать эти требования (непрерывная реализация);

• непрерывно выпускать этот процесс вовне (непрерывный выпуск).

У нас появляется процесс непрерывных исследований, который помогает нам выстроить картинку того, что хочет заказчик. Если требование не соответствует действительности – его убирают.

Основная концепция Agile в том, что мы наряду с непрерывной реализацией ценности непрерывно работаем над уточнением требований, постоянно взаимодействуем с заказчиком, ищем узкие места, делаем все, чтобы на выходе требования были понятны нашим исполнителям.

Вот так этот цикл исследований выглядит в Agile – у нас появляется цикл работы с требованиями до попадания в разработку:

• появляется гипотеза;

• происходит коллаборация с менеджментом;

• уточнение у архитектора;

• выявление зависимостей с командами;

• и потом синхронизация в процессе реализации.

Например, диаграмма Ганта – это один из способов применения того, как мы эту фичу будем реализовывать совместно с другими нашими подразделениями.

Вопросы

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

Да, Agile – это недешевая технология, нужно собрать команду вместе, выделить ее на 100% для реализации работы с заказчиком – недешевая история на старте.

Но если вы хотите сделать что-то на коленке, вам не нужна Agile-команда, вы можете взять одного разработчика. У меня был проект, когда я даже без разработки, с помощью одного тестировщика выпустил первый MVP. У нас в компании было достаточно технологий, и он из этих технологий собрал прототип. Интересно, что этот прототип после сборки продали 4-м заказчикам. Когда мы провалидировали спрос, что это интересно и действительно требуется на рынке, мы начали масштабировать эту историю. Поэтому мы идем от потребности.

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

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

Тогда, по сути, в Agile не важна технология, а важна слаженность команды? А классические технологии позволяют неслаженной команде получить хоть какой-то результат?

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

Если вы возьмете хорошего менеджера, который имел опыт, вы получите хороший результат. Так же, как если вы возьмете плохого Agile-коуча или плохого Скрам-мастера, который прочитал только книжку и никогда это не применял, низкая вероятность, что вы соберете хорошую команду. Здесь все зависит от ваших потребностей, от ваших ресурсов, от того, что вы хотите получить в конце.

Так же, как и постановка задач. Если я знаю, что я хочу получить мост, знаю, как он выглядит, знаю, какую цель он будет преследовать – тут не важно, работаете ли вы Agile-командой или классическим проектным управлением. Здесь важны компетенции, с которыми вы будете это делать, потому что задача понятна.

А если мы идем дальше и попадаем в запутанную ситуацию, когда потребитель не понимает задачу, тогда нам нужно подстраиваться под эти истории. Тогда как раз накладные расходы на написание требований в классическом подходе – очень большие. И чтобы их сократить, мы собираем Dream Team или группу, которая может работать слаженно и подстраиваться под изменяющийся мир.

Но я согласен, что классные крутые команды, которым «море по колено», могут успешно сделать проект с любой технологией.

Единственное, что Agile помогает вырастить сильную команду. В Agile есть принципы Inspect и Adapt, которые помогают даже в слабой команде.

В конце каждого отрезка времени мы команду спрашиваем: «Почему вы здесь «не добежали»? Почему у вас здесь что-то «просаживается»?». И мы пытаемся научить эту команду работать более эффективно.

Если вы цикл Шухарта-Деминга (цикл PDCA) применяете внутри команды, она учится и развивается. Это основной принцип Agile – мы должны постоянно модифицировать свои методы, инструментарий и скилы. Т.е. если вы в этом направлении двигаетесь, можно сказать, что вы уже удовлетворяете принципам и ценностям Agile, даже если вы не называете это Agile.

В PMBoK тоже есть итеративный подход – это тот же цикл Шухарта-Деминга, только дольше по времени. PMBoK не предлагает все сразу спланировать и идти по водопаду, он предлагает вносить коррективы по итогам работы и перепланировать в рамках исполнения тоже. Но в Agile цикл гораздо более короткий, обучение гораздо более эффективное, и команда может расти гораздо быстрее.

Согласны ли вы, что «Водопад» очень часто – средство прикрытия «пятой точки»? Процесс Waterfall направлен не на решение проблемы, а на соблюдение процесса.

Да, именно так. Но не всегда. Действительно, Waterfall был создан, чтобы сформировать некие правила игры и показать прозрачность работы над проектом или продуктом. Он был предназначен для прозрачности. Но, к сожалению, многие менеджеры интерпретируют это так: есть требования, я по ним делаю. Если вы работаете с госзакупками – это очень частый пример, когда в ТЗ прописано какое-то условие, и пока оно не будет выполнено, заказчик проект не примет.

Но даже в классическом проектном управлении для фиксации требований есть инструменты, которые позволяют изменять ТЗ в процессе работы. Например, в b2g у нас есть ФЗ, по которому мы контрактуемся, но в то же время многие заказчики хотят работать по Agile. Поэтому, несмотря на то, что у нас на этапе контрактования были зафиксированы определенный Scope и четкая описанная архитектура, мы в процессе разработки для нашего ТЗ выпускаем допсоглашения.

С какими проблемами можно столкнуться, если работать с User Story или с Job Story?

Я очень много работаю с продуктовыми менеджерами – я их постоянно учу. И в процессе обучения я их постоянно заставляю перекладывать свои дорожные карты в формат User Story или Job Story. И каждый раз для них самая большая проблема – сформулировать цель (в User Story) или результат (в Job Story).

Почему-то мы этот момент очень часто упускаем. Запускаем Agile-команду, пишем, что надо сделать вот это, а для чего – забываем. Через какое-то время команда начинает сбавлять скорость, мотивация теряется, мы становимся молотилками маленьких фич и не понимаем, зачем это делать.

Не упускайте на старте фиксировать от заказчика и показывать команде цель вашей работы. Это – подводный камень, который нужно увидеть на старте.

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

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

Бизнесу очень трудно объяснить, что не нужно диктовать команде, как делать, это должна решать команда сама. Но убедить не всегда получается. Бизнес начинает говорить ИТ-шными терминами: «Сделайте Push-уведомление о событии». Начинаешь разбираться, оказывается, что там не нужно Push-уведомление. И таких вещей очень много. Это – та лазейка или баг, которая существует при переходе от классического управления к управлению требованиями в Agile. В идеале должно быть так: бизнес говорит, что хочет делать, а команда говорит, как она может помочь, поддержать эту потребность.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Сбор требований и составление ТЗ: современные подходы в управлении проектами".