# Рабочий процесс

## Боль и проблемы

В подпунктах — мини-решения.

* Планирование ад
* Задачи неверно декомпозированы
* Нехватка системного анализа (технического)
* Разрыв в терминологии (живём в разных мирах)
* Нет прозрачности (не у всех прикрыта жопа (убрать? изменить?)
* Для того чтобы прикрыть всех — нужен прозрачный процесс
* Любая задача должна выполняться системно: от начала до конца и задействовать весь цикл: никаких мелких вбросов
* У аналитиков нет раннего доступа к разработке
* tech-review
* Процесс многим не понятен
* Дизайн оторван от реальности
* Не продуманная архитектура (косвенный аргумент)

## Решение

* Этапы фичи, задачи, стори — Jira Workflow
* idea
* biz analysis
* design
* system analysis
* tech review
* ready for dev (to do)
* dev (in progress)
* ready for qa
* qa
* done
* ready for doc
* doc
* autotest*
* close

### Описание этапов

#### Idea

Исполнитель: владелец продукта
Что делает: описывает боль потребителя
Пример: Боль. Пользователи не понимают, как устроена система комментирования.

#### Biz analysis

Исполнитель: бизнес аналитик
Что делает: описывает проблему потребителя
Пример: Проблема. В системе комментирования используются синонимы, которые вводят пользователей в заблуждения. Нужно ограничить термины до: обсуждения, сообщения. Убрать термины: ветка, ответ, комментарий.

#### Design

Исполнитель: дизайнер
Что делает: прикладывает макеты к задаче в трёх состояниях
Пример: Макеты.fig
Дополнительно: желательно кликабельный прототип, который демонстрирует весь процесс взаимодействия с функционалом

#### System analysis

Исполнитель: системный аналитик
Что делает: описывает техническое решение проблемы с учётом макетов
Пример: Решение. 1) В sidebar переименовать вкладку «Комментарии» в «Обсуждения». 2) Во вкладке «Обсуждения», переименовать подписи «ответы» в «сообщения». 3) Внутри «обсуждения» на форме для создания сообщения, переименовать кнопку «Комментировать» на «Отправить».

#### Tech-review

Исполнитель: разработчик и тестировщик
Что делает: приводит постановку к реальности, принимает задачу
Пример: Задачу приняли к планированию: Вася Фронт, Миша Бэк, Петя Куа

#### Ready for Dev (to do)

Исполнитель: разработчик и тестировщик
Что делает: оценивают задачу
Пример: оценка: 2sp

#### Dev (in progress)*

Исполнитель: разработчик
Что делает: реализовывает задачу
Пример:
* [decisions-ui/pull-requests/607](https://bitbucket.vtb.cloud/projects/DS/repos/decisions-ui/pull-requests/607)
* [document-dictionary-api/pull-requests/20](https://bitbucket.vtb.cloud/projects/DS/repos/document-dictionary-api/pull-requests/20)

#### Ready for QA*

Исполнитель: QA
Что делает: берет реализацию на проверку

#### QA*

Исполнитель: QA
Что делает: проверяет реализацию, заводит баги, возвращает на доработку, переводит в статус «Ready for Doc»

#### Ready for Doc

Исполнитель: тех-писатель
Что делает: приступает к описанию реализованного функционала

#### Doc

Исполнитель: тех-писатель
Что делает: описывает реализованный функционал, как сопровождающую документацию к ПО
Пример: [ссылка на документацию в Confluence](https://confluence.vtb.cloud/pages/viewpage.action?pageId=14517333)

#### Done

Исполнитель: владелец продукта
Что делает: демонстрирует пользователям, подтверждает выполнение задачи — переводит в статус «Close»

#### Close

Исполнитель: владелец продукта
Что делает: использует в отчетах

### Итоговый вид задачи

#### Боль

Пользователи не понимают, как устроена система комментирования.

#### Проблема

В системе комментирования используются синонимы, которые вводят пользователей в заблуждения. Нужно ограничить термины до: обсуждения, сообщения. Убрать термины: ветка, ответ, комментарий.

#### Макеты

Макеты.fig

#### Решение

1) В sidebar переименовать вкладку «Комментарии» в «Обсуждения».
2) Во вкладке «Обсуждения», переименовать подписи «ответы» в «сообщения».
3) Внутри «обсуждения» на форме для создания сообщения, переименовать кнопку «Комментировать» на «Отправить».

#### Задачу приняли к планированию

* Вася Фронт
* Миша Бэк
* Петя Куа

#### Pull requests
* [documents-structure/pull-requests/1](https://bitbucket.vtb.cloud/projects/DS/repos/documents-structure/pull-requests/1)
* [decisions-ui/pull-requests/607](https://bitbucket.vtb.cloud/projects/DS/repos/decisions-ui/pull-requests/607)
* [document-dictionary-api/pull-requests/20](https://bitbucket.vtb.cloud/projects/DS/repos/document-dictionary-api/pull-requests/20)

#### Bugs
* [DC3-1235](https://jira.vtb.cloud/browse/DC3-1235)

#### Документация в Confluence
* [Режим комментирования](https://confluence.vtb.cloud/pages/viewpage.action?pageId=14517333)

#### Статус задачи
Close

## Новые проблемы — ответы

* Нам некогда этим заниматься?
* Всегда будет некогда
* К этому можно идти поэтапно, определив цель — этот документ
* Нужно не поломать текущий процесс — сделать не хуже
* Этот документ описывает целевой процесс взаимодействия внутри команды, к которому нужно идти поэтапно. Никто не собирается внедрять всё сразу.

## Мнения на которых основан этот документ

### Группа 1

#### Данил Камышов, Андрей Едунов, Илья Заволокин, Валерий Сотников

* Постановка задачи понятна разработчику, тестировщику перед планированием
* Задачи должны быть оформлены в Jira, не в Confluence
* В Confluence — тех-документация (сопроводительная)

#### Максим Гранкин

* Оценка задач в абсолютном времени (− Валера)
* Ранний доступ к разработке

### Группа 2

#### Александр Дуринов

* Вообще нет процесса разработки (+ Валера)
* Нет системы оценки: риски, объективная тех оценка по работе (+ Алексей, − Валера)
* Ожидание сходится
* Нужно менять PBR (+ Алексей, Илья, Дима)

#### Алексей Орлов

* Нет разделения бизнес и системной аналитики (+ Саша)
* Мало общения между анализом и разработкой (+ Саша)
* Тестирование и анализ должны вместе сценарии (+ Илья, Дима)
* Нет обратной связи от реальных пользователей (+ Евгений)
* Не поломать хоть както работающий процесс (+ Валера, Кирилл)

#### Илья Заволокин

* Нет стандарта описания задач (+ Кирилл, Алексей)
* Хочу системное описание задач (+ Кирилл, Дима, Алексей)

#### Дмитрий Луков

* Не должно быть договоренностей в комментах (+ Алексей)
* Холивар на планировании не допустим → DoR

#### Евгений Егоров

* Реализация задачи продиктована продактом (+ Алексей)

### Группа 3

#### Антон Фролов

* Документация в Конфлюенсе, постановки в Джире
* Нужно ready for dev (tech-review)

#### Владимир Соловьев, Никита Уткин

* Аналитики не должны писать тех-реализацию без обсуждения с разработкой
* На встречах по тех-реализации должны быть только заинтересованные люди

#### Владимир Соловьев

* Этапы рабочего процесса должны быть опциональны
* Лучше «done → ready for doc → doc → autotest → close», чтобы не писать документацию и авто-тесты без валидации задачи PO (+ Валера)

#### Андрей Викулов

* Постановка задачи в конфл (− Валера, Антон)
* Не нужно тратить отдельно время на PBR, всё делать на плане

### Группа КОД

#### Ирина Галкина

* многие этапы лишние, их будут прокликивать
* поддержка приверженности к процессу

#### Стас Широков

* Сложно понять на какой стадии задача
* Нет привязки задач в Джире к релизам
* У багов должны быть указаны в каком релизе был обнаружен и на каком стенде
* Нжуно использовать линки relatesTo, blocksBy

## Концепции

### Боль > проблема > решение

idea > biz > sys