🪱Workflow разработки

Начало проекта

1-й день. Анализ высокоуровневых требований, выбор первых вариантов использования (например, 10% от всех), которые являются архитектурно-значимыми, сложными или важными для предметной области.

2-й день. Детальный анализ функциональных и нефункциональных требований выбранных вариантов использования.

3-й день. Планирование 1-й итерации.

Планирование итерации

1. Разбить выбранные варианты использования на более мелкие цели.

2. Более мелкие цели нужно разбить на мелкие задачи.

3. Начать итерацию.

Последовательность итерации (2 недели)

1-й день. Моделирование и проектирование, построение UML-диаграмм.

2-8 дни. Кодирование, рефакторинг и тестирование.

9-й день. Анализ новых требований.

10-й день. Планирование следующей итерации.

Советы по написанию вариантов использования

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

2. Описывать вариант использования лучше по принципу "чёрного ящика": что делает, но не как. Например: "Система регистрирует покупку", а не "Система записывает сведения о покупке в базу данных".

3. Нужно концентрироваться на целях и задачах пользователей и исполнителей, а не просто на функциях.

Распределение времени в типичном спринте

Параметры планирования спринта
Продолжительность спринта (рабочих дней)	10
Идеальное количество часов в сутки (время, потраченное на проект)	x 6
Общее идеальное количество часов на спринт для разработчика	= 60

Количество действий по скраму на спринт для разработчика	Часов
Разработка, включая тестирование	48
Дейли-скрам (стендапы)	2
Уточнение бэклога продукта (5%)	3
Планирование спринта	4
Обзор спринта	2
Ретроспектива спринта	1
Итого	60

Вертикальные срезы - предпочтительны

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

Критерии готовности задачи (истории)

1. Проходит обзор кода (в том числе, через чеклисты)

2. Проходит вспомогательные плагины (например, AssetCheck)

3. Проходит статический анализ кода

4. Проходит тестирование без ошибок

5. Проходит регрессионные тесты

6. Сборка без ошибок и предупреждений

Любая задача (история) включает тестирование

Тестирование - это неотъемлемая часть разработки, которая также включена в оценку усилий.

Критерии готовности задачи (истории) в бэклоге

1. Задача понята разработчиком достаточно хорошо, чтобы решить, можно ли её выполнить в течение спринта.

2. Задача оценена и её можно выполнить за один спринт.

3. Задача свободна от зависимостей, которые не позволят её реализовать в течение спринта.

4. Определены критерии приёмки задачи, то есть задача тестируема.

Карта историй

Карта историй состоит из трёх этапов:

1. Запишите основной функционал на стикерах и расположите их в порядке приоритета слева направо. Основной функционал состоит из функций, эпиков или крупных историй, тем, инициатив и прочих крупных требований.

2. Разложите эпики верхнего уровня на этапы и темы. Такая проработка не сместит приоритеты эпиков.

3. Разложите каждый этап или тему на истории и запишите их на стикерах. Разместите их под каждым этапом или темой в порядке приоритета.

Карта историй помогает определить общие рамки для релиза заблаговременно, а затем способствует постановке приоритетов и ведёт к пошаговому уточнению требований по мере хода работ.

Плагин Unreal Engine для тестирования

1. Проверка на наличие запрещённых символов в именовании ассетов

2. Проверка на соблюдение паттернов именования ассетов

3. Проверка на отсутствие пустых слотов для материалов у StaticMesh и SkeletalMesh

4. Проверка на использование в StaticMesh и SkeletalMesh только MaterialInstance

5. Проверка на правильность настроек у текстур (Compression Settings и sRGB)

6. Проверка на наличие префикса во всех исходных файлах

7. Проверка на наличие copyright в первой строке в каждом исходном файле (.h, .cpp) в формате:

   // Copyright Epic Games, Inc. All Rights Reserved.

8. Проверка на наличие #pragma once в каждом заголовочном файле на 3-й строке

9. Проверка на наличие пустой строки в конце каждого исходного файла (.h, .cpp)

10. Проверка на правильный порядок #include

11. Проверка на правильный порядок forward declarations

12. Проверка на использование неправильных типов (например, int)

13. Проверка на пустые файлы

14. Проверка на пустые директории