Шаблон постановки
(полный)
Содержание
1
1.1
1.2
1.3
2
2.1
2.1.1
2.1.2
2.1.3
2.2
2.3
2.4
3
3.1
3.1.1
3.2
3.2.1
3.2.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
4
5
6
6.1
7
8
8.1
8.2
9
10
10.1
11
11.1
11.1.1
11.1.2
11.1.3
11.2
11.3
Постановка
Проблема
Цели
Критерии приемки
Концепция решения
Возможные архитектурные подходы
Проблема ...............................................................................................................
Открытые вопросы ...............................................................................................
Итоговое решение.................................................................................................
Пользовательская история
Схема работы
Модель поиска
Реализация
UI/UX
Web.........................................................................................................................
Front-end
Вводная ................................................................................................................
Компоненты .........................................................................................................
Back-end
Вводная ................................................................................................................
Бизнес-логика ......................................................................................................
Модель данных ....................................................................................................
API ........................................................................................................................
Миграция данных ................................................................................................
Права доступа
Безопасность
Аудит
Логирование
Интеграционный лог
Нагрузочное тестирование
Профиль нагрузки
Результаты
Договор / SLA взаимодействия с внешними сервисами
Пользовательская документация
Документация в системе
Организационные моменты
Процесс внедрения
До установки версии ..........................................................................................
Во время установки версии ...............................................................................
После установки версии ....................................................................................
Инфраструктура
Конфигурация БД / сервисов
Аналитик
→ Здесь и ниже заполняем участников процесса через символ "@", например
Сергей Родикевич. В том числе представителей ответственных за функционал
команды, если доработка затрагивает смеженные области.
UI/UX
→ Ответственный за визуальный дизайн в рамках этой постановки. Он должен
подтвердить, что прочитал постановку и согласен с описанным, проставив
галочку. Так же может потребоваться дизайнер от ответственной за
функционал команды, если доработка затрагивает смеженные области.
Front-end
→ Ответственный за разработку фронта в рамках этой постановки. Он должен
подтвердить, что прочитал постановку и согласен с описанным, проставив
галочку. Так же может потребоваться лидер frontend от ответственной за
функционал команды, если доработка затрагивает смеженные области.
Back-end
→ Ответственный за разработку бэка в рамках этой постановки. Он должен
подтвердить, что прочитал СТ и согласен с описанным, проставив галочку. Так
же может потребоваться лидер backend от ответственной за функционал
команды, если доработка затрагивает смеженные области.
QA
→ Ответственный за тестирование в рамках этой постановки. Он должен
подтвердить, что прочитал постановку и согласен с описанным, проставив
галочку. Так же может потребоваться тестировщик от ответственной за
функционал команды, если доработка затрагивает смеженные области.
Product owner
→ Владелец продукта вашей команды. Он должен подтвердить, что прочитал
постановку и согласен с описанным, проставив галочку. Так же может
потребоваться владелец продукта от ответственной за функционал команды,
если доработка затрагивает смеженные области.
Operations
→ Руководитель DevOps / Infrastructure. Он должен подтвердить, что прочитал
постановку (раздел "Организационные моменты") и согласен с описанным,
проставив галочку.
Tech-lead
→ Тот, кто согласует всю архитектуру решения. Он должен подтвердить, что
прочитал постановку и согласен с описанным, проставив галочку. Так же
может потребоваться техлид от ответственной за функционал команды, если
доработка затрагивает смеженные области.
Безопасность
→ Согласующий требования безопасности (использование и шифрование
персональных данных)
Статус
документа
ЧЕРНОВИК
РЕВЬЮ
аналитик работает на документом
аналитик согласует документ со всеми участниками процесса
СОГЛАСОВАНО
ВНЕДРЕНО
аналитик передал документ на реализацию
доработки попали в прод
Если в процессе оказалось, что доработки более неактуальны, необходимо
отправить статью в раздел "Архив"
JIRA
→ Ссылки на задачи через макрос "Jira Issue / Filter"
Ссылки
→ Если для них не нашлось места в теле документа
Справочная
документация
Методический глоссарий, технический глоссарий, правила именования и т.п.
Постановка
1
1.1
Проблема
→ Описание существующих проблем. Модель AS IS
1.2
Цели
→ Кому и какую бизнес-ценность принесёт доработка. Как будет выглядеть итоговый
результат
1.3
Критерии приемки
→ По каким признакам product owner определит, что доработка выполнена / не выполнена
2
Концепция решения
→ Простым языком описываем что будет сделано по задаче. Модель TO BE
2.1
Возможные архитектурные подходы
2.1.1 Проблема
→ В любом представлении, если есть из чего выбирать. Например в виде таблицы
Описание решения
Плюсы
Минусы
1
2.1.2 Открытые вопросы
→ Что не имеет явного решения и нужно особенно внимательно продумать
2.1.3 Итоговое решение
→ Какой вариант был выбран (возможно с дополнениями)
2.2
Пользовательская история
→ Описываем что будет происходить и в каком порядке
2.3
Схема работы
→ Принципиальная схема в любом виде, например UML
2.4
Модель поиска
→ Описываем по каким полям и как будет искать, нужен ли Elasticsearch или достаточно
поиска по БД
3
Реализация
3.1
UI/UX
→ Ссылка на каталог с макетами
3.1.1 Web
3.1.1.1 Название макета
→ Скриншот макета
3.2
Front-end
3.2.1 Вводная
→ Описываем в общих чертах что нужно сделать front-end разработчику
3.2.2 Компоненты
3.2.2.1 Наименование экрана
→ Путь до экрана и для какой роли нужна доработка
Наименование Тип Состояние
компонента
по
Uikit
умолчанию
1 поле для
примера
3.3
поле пусто
ввода
Требования к данными
Поведение Требует
доработку в
Uikit
нельзя указывать больше 10
не даст ввести Да/Нет
букв русского алфавита, можно латинскую
оставить пустым
букву
Back-end
3.3.1 Вводная
→ Описываем в общих чертах что нужно сделать back-end разработчику
3.3.2 Бизнес-логика
→ Здесь можно описать манипуляции с данными до укладки в БД или перед ответом на
фронт
3.3.2.1 a. Возможные ошибки
Тип
проверки
1 Бизнесправило или
ограничение
модели
Описание
Идентификатор Текст
Тип
ошибки
сообщения ошибки
В каких
Например код
случаях
ошибки
ошибка может
происходить
3.3.3 Модель данных
3.3.3.1 PostgreSQL
→ Здесь пишем про DDL
Уникальные индексы
Поисковые индексы
3.3.3.2 Java
→ Здесь описываем enum и какие-либо константы
3.3.4 API
или шаблон системная /
сообщения не
системная /
отдельная
проверка
3.3.4.1 REST
name
url
method
1 Получить /api/v1/donuts/entitle POST
именной
пончик
request
{
"donutTitle":
string,
"userId":
number
}
Code Block 1
структура запроса
response
desc
{
"success":
boolean,
"data": {
"donutId":
number,
"donutTitle":
string,
"userId":
number
},
"error": {
"id":
string,
"code":
string,
"title":
string,
"stackTrace":
string
}
}
Code Block 2
структура ответа
3.3.4.2 GraphQL
→ Здесь описываем mutation и query
3.3.5 Миграция данных
3.3.5.1 PostgreSQL
→ Если миграция не требуется, то необходимо явно указать, что миграция не требуется.
Уникальные индексы
Поисковые индексы
4
Права доступа
permission id
desc
functional roles
roles
default value
1 наименование описание каким
каким базовым включено ли по
функциональным ролям
умолчанию для роли
ролям присвоено присвоено
или нужно выдавать
отдельно
facade method
наименования
метода в
фасадном классе
→ Описание прав, которые покрывают доработку. К каким ролям / функциональным
ролям принадлежит доработка.
5
Безопасность
→ Сертификаты. Шифрование. Гриф секретности данных
→ Работа с персональными данными (хранение, получение, аудит)
6
Аудит
→ Любая активность пользователя должна фиксироваться в аудите.
→ Описание должно содержать типы событий аудита, к каким объектам эти события
относятся и какой текст сообщения используется.
6.1 Логирование
→ Необходимо описать уровень логирования:
•
INFO — логирование ошибок, предупреждений и сообщений;
•
WARN — логирование ошибок и предупреждений;
•
ERROR — логирование всех ошибок;
•
DEBUG, TRACE - отладка.
7
Интеграционный лог
→ В случае взаимодействия между системами, необходимо вести журнал обмена
сообщениями между системами.
8
Нагрузочное тестирование
8.1
Профиль нагрузки
→ Включая генерацию тестовых данных, сценарий и удаление тестовых данных
наименование метода
частота вызова
размер сообщения
результат
1
8.2
9
Результаты
Договор / SLA взаимодействия с внешними сервисами
→ Необходимо зафиксировать размеры сообщений, частоту вызовов, время/период
недоступности обоих сервисов, длительность обработки вызовов, другие ограничения на
вызов API, время жизни старого API/поддержка обратной совместимости
10
Пользовательская документация
10.1 Документация в системе
→ Достаточно ссылки на задачу в JIRA, если необходимо изменить или разработать
пользовательскую документацию
11
Организационные моменты
11.1 Процесс внедрения
11.1.1 До установки версии
→ Что нужно проверить и сделать до внедрения, со ссылками на задачи JIRA
11.1.2 Во время установки версии
→ Что нужно проверить и сделать во время внедрения, со ссылками на задачи в JIRA
11.1.3 После установки версии
→ Что нужно проверить и сделать после внедрения, со ссылками на задачи в JIRA
11.2 Инфраструктура
→ Например, новые кластера / БД / схемы / пользователи / сервисы
11.3
Конфигурация БД / сервисов
→ Что нужно изменить или добавить
