Как мы ведём требования к ПО: формализация

[Vadim_Ts]

Алексей, спасибо за статью! Было бы интересно посмотреть пример Vision, понять как он помогает или ограничивает системного аналитика в выборе технического решения. Так же понятно, фичу на саб-таски распиливает СА или кто-то другой ? За то, чтобы собрать саб-таски вместе и поставить фичу СА у вас отвечает ?

[alobzov]

Спасибо за вопросы! По пунктам:

1. В общих чертах наш Vision - это схема компонентов решения с описанием последовательности их взаимодействия, данных и протоколов плюс текстовое описание процесса. Схема выглядит приблизительно как в разделе "Архитектура ПО" в статье Мой краткий чек-лист по скилам системного аналитика.

2. Деление на саб-таски выполняется совместно членами команды разработки.

3. Обычно либо системный аналитик либо тестировщик занимаются выкаткой поставок в бой. Но могут быть вариации

[maxim_ge]

Схема выглядит приблизительно как в разделе "Архитектура ПО"

Подскажите, какое ПО используется для создания схем такого типа?

[alobzov]

Схемы такого типа обычно разрабатывают в MS Visio. Помимо него ещё используется Enterprise Architect. Там формат немного другой

[ViseMoD]

На основе Specs и UI команда разработки (DevTeam) выполняет декомпозицию User Stories на подзадачи (Sub-Tasks) для каждого члена команды.

Надеюсь, имеется в виду, что аналитик и дизайнер собираются вместе с командой разработки и обсуждают предложенный (возможный) вариант реализации - собирают обратную связь и, если требуется, уходят уточнять/дорабатывать артефакты?

[alobzov]

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

[a3aquB]

Нельзя ли отказаться от Word? И как у вас происходит трассировка между бизнес-требованиями и ФТ/НФТ?

[alobzov]

Отказаться от Word, безусловно, можно. Вопрос - зачем? Необходимо понять потребность.

В описанной модели трассировка выполняется на уровне задач в Jira:

1. Бизнес-требованию соответствует эпик.

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

3. Далее идут подзадачи для членов команды разработки. Что им требуется сделать для реализации пользовательской истории.

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

Таким образом, можно проследить цепочку от бизнес-требования до изменения в коде или даже документации, если вы ведёте её рядом с кодом. Мы, например, ведём. Я писал об этом в статье Как мы ведём документацию рядом с кодом.

[a3aquB]

Кажется, что word лишает возможностей трассировки на конкретное бизнес-требование или же избыточен, если у вас и так они в виде эпиков.

За ответ спасибо!

[maxim_ge]

Интересный опыт, однако ж, должен признаться, процесс выглядит как "водопад". Т.е. вот, есть пожелания бизнеса, анализируем их, получаем BRD, далее из BRD получаем Vision, ну и так далее по цепочке Анализ - Проектирование - Кодинг.

Опять же, PO не пишет и не приоретизирует истории, эта функция возложена на целую группу Product Team, "истории" нельзя сразу давать команде разработки, предварительно надо пройти еще одну проектную стадию и получить Specs.

Развитие технологий разработки ПО идет по спирали, Водопад -> Agile -> Водопад2.0 ? :)

[alobzov]

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