Ниже описаны правила и средства взаимодействия между CSI и внешними разработчиками.

Внешней команде разработчиков со стороны CSI выделяется Product Owner (далее - PO или владелец продукта).
PO предоставляет команде разработки пользовательские истории или функциональные сценарии.
Назначает процесс работы (Scrum, Kanban), сроки выполнения задач, размеры итераций.
PO принимает выполненные работы, принимает решение об их готовности, завершённости.

Пользовательские истории / функциональные сценарии

Пользовательские истории (user stories) должны содержать:

понятное описание требуемого функционала;
сценарии использования (use cases), по которым выполняется демонстрация, приёмка выполненной работы и написание автоматизированных функциональных тестов;
нефункциональные требования

Команда разработки приступает к выполнению задач, только после полного понимания пользовательской истории / функциональных сценариев.
Необходимые ответы на вопросы и уточнения могут вноситься перед началом выполнения работ.
Пользовательские истории ведутся в Jira.

Jira

CSI может предоставить внешним разработчикам доступ к Jira на время выполнения работ.
В этом случае разработчики, тестировщики своевременно меняют статус работ в Jira (ToDo, In progress, Test, Ready и т.п.)

Размещение документации в Confluence

CSI может предоставить внешним разработчикам доступ к Confluence на время выполнения работ.
При необходимости документирования готового функционала - публикуются статьи в соответствующем пространстве Confluence.

Jenkins

Запуск сборок, статического анализа кода, unit и функциональных тестов происходит в Jenkins на стороне CSI
При подготовке к разработке DevOps команда CSI подготавливает необходимые ресурсы и создает заготовки Jenkinsfile (файлы с описанием процесса сборки и тестирования продукта).
Изменение Jenkinsfile может производиться аутсорс-разработчиками или DevOps на стороне CSI (обговаривается при старте проекта)

Инфраструктура для тестовых и демонстрационных стендов может быть предоставлена CSI по требованию.
Требования к инфраструктуре определяются на этапе согласования проекта.

GitHub

CSI предоставляет разработчикам доступ в приватный репозиторий, мастер ветка защищается от push.
Попадание в мастер ветку происходит только через pull request.
CSI готовит шаблон требований к pull request в репозитории.
Пример шаблона:

### Задача
[Ссылка на задачу]()

### Краткое описание задачи

### Качество
- [ ] Тестовые сценарии
- [ ] Unit-тесты
- [ ] Функциональные тесты - [Ссылка на прогон]()
- [ ] Статический анализ
- [ ] Документация в Confluence
- [ ] Проверка нефункциональных требований
### Приёмка
- [ ] Принято CSI

Наименование веток и комментарии к комитам должны содержать краткий код пользовательской истории.
Это необходимо для интеграции Jira и GitHub, например из пользовательской истории можно перейти к pull request и посмотреть изменения в коде.

Code style

Codestyle manifest

API Set10 ◾️ Правила и средства взаимодействия между CSI и внешними разработчиками