Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся.
Всё то же самое применимо и в Agile, но там есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов.

В чём проблема - она во всём.
Если работу быстро развивающегося сервиса поддерживают две и более команды разработки, то ни одной из них не подойдут ни продуктовые требования, ни бизнес-требования, ни требования к сумме ИТ-систем.
Очень часто им не подойдут даже требования к их отдельной системе, выделенной из окружения. Так как тим-лидов и менеджеров проекта ломает писать по 50 тикетов в неделю и заниматься координацией между всеми, кого нужно координировать.

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

Понимание качественных требований при переходе из длинных итерациий в короткие меняется. Полнота и непротиворечивость теряют свои позиции, зато становятся важны нужность, эффективность и прослеживаемость.
Уходят задачи заложить верный бюджет и сроки, а потом доказать заказчику, что всё сделано. Возникает задача удержать в балансе это "ведро с гайками", чтобы система собралась в единое целое и заработала уже в этой итерации, принося пользу. А еще важно уберечь команды от лишних действий (но главное - лишнего кода), не работающих на итоговую цель.

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

Я покажу быстрые, грязные и дешевые инструменты визуализации, выявления и анализа требований для таких ситуаций.
Среди них:
- Бизнес канвас
- Карты и эскизы процессов
- Двумерный мапинг историй
- Карты влияния (Impact mapping)
- Изображение системного ландшафта и архитектуры в стиле 4Context
- CQRS и другие паттерны, дополняющие и заменяющие CRUD+
- Сценарии или диаграммы взаимодействия для систем и компонентов

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

На своем опыте построения и запуска команд разработки я расскажу об основных заблуждениях, связанных с аналитикой и проработкой требований в гибких подходах. Расскажу о проблемах встраивания аналитики в agile-команду (ограничиваясь фреймворком Scrum) и о возможных способах решения этих проблем.

Тезисно история выглядит следующим образом:

1. Работающий продукт важнее... (Откуда взялся миф о том, что в аджайле нет аналитики и аналитиков, и что с этим мифом делать)
2. Здесь вас не стояло... (Роль и место аналитика в командной работе. Как не построить водопад внутри гибкой разработки)
3. Проработка как риск-менеджмент... (Работа с требованиями в парадигме потока создания ценности. Взаимосвязь между глубиной проработки и толерантностью к рискам).
4. Все только начинается... (аналитика зависимостей, связь проработки требований с архитектурой решений и еще несколько областей где рассказанная история имеет ограниченное применение и не отвечает в полной мере на все вопросы)

Язык подачи доклада: Русский

Тип презентации: Секционный доклад (40 мин)

Уровень аудитории: Начинающий

Тема: Узнать неизвестное или как восстанавливать требования для мобильных приложений

Аннотация

Я - аналитик, который работает в компании, занимающейся заказной разработкой мобильных приложений. На проекте, котором я работаю, при старте не было никакой документации по приложению, и все требования приходилось восстанавливать практически с нуля. В своём докладе я расскажу, как мы восстанавливали требования и какой результат у нас на текущий момент. Также расскажу про некоторые лайфхаки при восстановлении требований, которыми мы пользовались.

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

План доклада:

1. Что было в начале проекта, какие артефакты у нас были.
2. Как восстанавливали требования.
3. Что делали, если требования восстановить не получалось.
4. Лайфхаки.

В докладе будет обзор использования ГОСТ-ов 2.105, 34.603, 34.602.

Многие считают ГОСТ-ы полной ерундой. Пусть считают.

Я вот не умею пилотировать вертолет. Значит я должен считать, что они не могут летать? Что это полная ерунда? Но они летают. Это очень неожиданно. А ничего, что пилотированию надо учить? И без этого они не летают. А еще их надо заправлять топливом. Внезапно, без этого они тоже не летают.

С ГОСТ-ами ровно тоже самое. Это великолепные инструменты. Просто их использованию надо учить. И тогда они позволят вам "летать". Например, они позволяют резко повысить точность расчета продолжительности проекта, точность расчета бюджета проекта. Допустить меньше переделок после выхода в эксплуатацию, уменьшить стресс и переработки проектной команды. И, наконец, уменьшить число мата со стороны заказчика.

Сказка? Вовсе нет. Просто кроме UML, BPML, ER и прочего аналитик должен еще знать и владеть правилами оформления текста и создания структуры аналитической документации. Это резко снижает риск что нибудь пропусть.

Кто-то спросит, а какже юзерстори? Коллеги, юзерстори это про ПО. А ГОСТ-ы это про системы. Совершенно другой зверь. Это как болонка рядом с кавказкой овчаркой. И никто вам не мешает использовать юзерстори как один из разделов ТЗ по 34.602. А 2.105 резко снижает вариации в большом коллективе. "Все дело в уменьшении вариаций" говорил великий Деминг.

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