Общие принципы разработки ПО - NikolayPlakhotniy/DMS GitHub Wiki

Введение

Разработка ведется в примерном соответствии с методологией SCRUM. Длина спринта - 2 недели.

User Story

User Story - это описание части функционала, сформированное на «простом» языке без технических подробностей. Описание формируется Product Owner и PO Support с непосредственным участием бизнес-аналитиков.
User Story формируется «от лица пользователя» и должна описывать пользователя, что пользователь хочет и почему / для чего. Качественно описанная User Story должна быть:

"I" ndependent – может быть реализована независимо от других user stories
"N" egotiable – описывает «что и почему», а не конкретные интерфейсы или логику приложения
"V" aluable – реализация улучшает продукт по сравнению с предыдущим релизом
"E" stimable – можно оценить с приемлемой точностью
"S" mall – трудоёмкость реализации не превышает половины velocity команды
"T" estable – есть понимание того, как будет протестировано

Для каждого User Story фиксируется:

Краткое описание по принципу «кто и что»
Приоритет
Принадлежность к бизнес / функциональной области (epic)
Цель – «почему / для чего». Для чего нужна User Story, более детальная информация с упоминанием бизнес-потребности, желательно зафиксировать, что изменится / улучшится, если эта user story будет реализована
Роли – системные роли, которым будет предоставлен доступ к функционалу
Критерии приёмки – набор критериев, по которым тестировщики и пользователи будут проверять выполнение задачи
Дополнительная информация, упомянутая в описании: формулы, правила, схемы…
Оценка трудоёмкости (story points)

Definition of Ready

User Story готова для принятия в работу (Backlog Refinement, Sprint Planning) при выполнении следующих условий:

Описание User Story закончено, приложена вся дополнительная информация
Указаны полные критерии приёмки для каждой из платформ
Зафиксирован дизайн или ключевые соглашения по дизайну интерфейса
Зафиксированы возможные последующие расширения функционала (если есть)
Определены зависимости от других User Stories
Оценка трудоёмкости не превышает половины velocity команды (для sprint planning)
Определён приоритет (для sprint planning)

Definition of Done

User Story реализована если:

Соблюдены критерии приёмки, зафиксированные в определении User Story
Команда тестирования успешно завершила функциональные тесты
Соблюдены нефункциональные требования, если есть
Для User Story нет зафиксированных незакрытых багов

Backlog

Список User Stories или иных задач, необходимых и достаточных для завершения проекта или выпуска релиза, которые известны команде в данный момент времени. Backlog служит единственным местом хранения знаний о требованиях к продукту и единственным источником задач для команды разработки.
Как только становится известно о новых / изменённых / уточнённых требованиях, информация об этом заносится в backlog. На регулярной основе из backlog удаляются задачи, которые, по какой-либо причине, перестали быть необходимыми для завершения проекта или выпуска релиза. Удаление считается перенос User Story в статус "Canceled".

Product Backlog Refinement (Grooming)

Backlog refinement проводится до начала разработки и периодически в процессе разработки для того, чтобы:

Содержимое Backlog отражало текущее понимание конечной цели разработки
User Stories были присвоены приоритеты, которые позволят определить последовательность работы
Описание User Stories соответствовало Definition of Ready

**Основные активности в ходе Grooming: **

Доописание User Stories
Удаление тех User Stories, которые больше не нужны для достижения цели проекта / выпуска релиза.
Определение / корректировка приоритетов User Stories
Определение / корректировка оценок трудоёмкости User Stories
Декомпозиция User Stories в тех случаях, когда трудоёмкость превышает половину velocity команды

Статусы User Stories

TO DO - при создании User Story она попадает в этот статус вне зависимости от полноты описания – необработанный Backlog.
COMPOSING – в этот статус User Story переводит бизнес аналитик (PO Support), когда начинает работу над задачей. В рамках этого статуса описываются цели, роли и критерии приёмки для User Story. На данном этапе User Story назначается на бизнес-аналитика, который отвечает за ее ведение вплоть до статуса Backlog.
REVIEW – User Story в этом статусе указывает на то, что она готова к утверждению с Product Owner. Необходимо утверждение описание User Story бизнесом для того, чтобы она попала на оценку команде разработки.
GROOMING - указывает на то, что User Story утверждена и готова к обсуждению с командой разработки и оценке трудоёмкости.
Backlog - все требования по User Story описаны и утверждены, по User Story проставлена оценка. Так же User Story в этом статусе указывает на то, что соблюдены все условия Definition of Ready. На данном этапе задача назначается на Product Owner.
Sprint Backlog - User Story запланирована к реализации в рамках текущего Sprint, но еще не взята в работу разработчиками.
Development - User Story находится в работе у одного из разработчиков. На данном этапе она уже назначается на конкретного разработчика.
Ready for sprint demo - User Story соответствует Definition of Done и готова к демонстрации Product Owner. На данном этапе задача еще раз назначается на Product Owner.
Done - Функционал продемонстрирован Product Owner и утвержден.
Blocked - По какой-либо причине User Story не может быть реализована. При переводе задачи в этот статус, необходимо указывать причины такого перевода.
Canceled - По какой-либо причине реализация запланированной ранее User Story отменяется.

Описание процесса

Бизнес аналитик или PO создаёт User Story, и назначает его на конкретного аналитика.
Как только User Story готов для проработки, бизнес аналитик переводит User Story в статус Composing. User Story прорабатывается до необходимой детализации.
Когда объем и детализация зафиксированной информации достаточны для обсуждения с командой разработки и оценки трудоёмкости бизнес аналитик переводит User Story в статус REVIEW.
Как только в статусе REVIEW накапливается 5-10 задач, проводится встреча, на которой Product Owner совместно с бизнес аналитиком утверждает User Story и определяет относительный приоритет. Утверждённые User Stories переводятся в статус GROOMING.
Как только в статусе GROOMING накапливается 5-10 задач, команда разработки совместно с бизнес аналитиком и (не обязательно) PO уточняют требования и дают оценку трудоёмкости задачи. Если информации недостаточно, или оценка трудоёмкости превышает половину velocity команды разработки, описание User Story уточняется, проводится декомпозиция. При необходимости, User Story возвращается на REVIEW.
User Stories, для которых соблюдён Definition of Ready переводятся в статус Backlog. Аналитик переводит задачу на PO.
В ходе Sprint Planning команда разработки совместно с PO определяет Backlog начинающегося спринта. Запланированные на спринт задачи переводятся в статус Sprint Backlog.
Программисты разбирают задачи из Sprint Backlog, переводя их в статус Development и назначая их на себя.
После завершения разработки и тестирования, программисты не меняя статуса User Story переводят ее на аналитика, который вносит корректировки в документацию.
После того как в документацию внесены все необходимые корректировки, аналитик переводит User Story в статус Ready for Sprint Demo.
После проведения Sprint demo и согласования User Story с PO, она переводится в статус Done.
В любой момент (до статуса Done), User Stry может быть переведена в статусы Blocked и Canceled, в случае возникновения такой необходимости.