Аналитика: различия между версиями
Перейти к навигации
Перейти к поиску
Tsarev (обсуждение | вклад) (Новая страница: «= Definition of Ready и Definition of Done для системных аналитиков = <noinclude> {{DISPLAYTITLE:DoR и DoD для задач системного аналитика}} Категория:Системный анализ Категория:Управление задачами </noinclude> __TOC__ == Введение == '''Definition of Ready (DoR)''' и '''Definition of Done (DoD)''' — это критерии, которы...») |
Tsarev (обсуждение | вклад) Нет описания правки |
||
(не показаны 2 промежуточные версии этого же участника) | |||
Строка 16: | Строка 16: | ||
Перед взятием задачи в работу системный аналитик должен убедиться в наличии: | Перед взятием задачи в работу системный аналитик должен убедиться в наличии: | ||
* | * '''✓ Четкой цели''' задачи (проблема, требование или гипотеза) | ||
* | * '''✓ Определенных стейкхолдеров''' (кто заказчик, кто принимает решение) | ||
* | * '''✓ Исходных данных''' (документы, ссылки, примеры) | ||
* | * '''✓ Согласования с PO/тимлидом''' (нет конфликтов с другими задачами) | ||
* | * '''✓ Известных ограничений''' (сроки, бюджет, технические рамки) | ||
=== Идеальные критерии === | === Идеальные критерии === | ||
Дополнительные параметры для сложных задач: | Дополнительные параметры для сложных задач: | ||
* | * '''✎ Примеры аналогичных решений''' (как делали раньше или у конкурентов) | ||
* | * '''✎ Предварительный анализ''' (интервью с пользователями, данные аналитики) | ||
* | * '''✎ Критерии успеха''' (как поймем, что задача выполнена хорошо) | ||
* | * '''✎ Определенные риски''' (что может пойти не так) | ||
== Definition of Done (DoD) == | == Definition of Done (DoD) == | ||
Строка 34: | Строка 34: | ||
Для закрытия задачи достаточно: | Для закрытия задачи достаточно: | ||
* | * '''✓ Документированных требований''' (в СФЕРА) | ||
* | * '''✓ Первичной валидации''' (подтверждение от заказчика или PO) | ||
* | * '''✓ Передачи артефактов''' (разработчикам/тестировщикам) | ||
* | * '''✓ Отсутствия открытых вопросов''' | ||
=== Идеальные критерии === | === Идеальные критерии === | ||
Дополнительные параметры для полного завершения: | Дополнительные параметры для полного завершения: | ||
* | * '''✪ Требования по стандарту''' (Use Cases, User Stories, BPMN/UML) | ||
* | * '''✪ Приемочный тест''' (демо для стейкхолдеров) | ||
* | * '''✪ Обновленная документация''' (внутренняя и пользовательская) | ||
* | * '''✪ Ретроспективный разбор''' (улучшения на будущее) | ||
== Пример применения == | == Пример применения == | ||
Строка 60: | Строка 60: | ||
|- | |- | ||
| '''DoD''' || | | '''DoD''' || | ||
* Требования в | * Требования в СФЕРА | ||
* Подтверждение разработчика | * Подтверждение разработчика | ||
|| | || |
Текущая версия от 12:37, 26 марта 2025
Definition of Ready и Definition of Done для системных аналитиков[править]
Введение[править]
Definition of Ready (DoR) и Definition of Done (DoD) — это критерии, которые помогают системным аналитикам четко понимать, когда задачу можно брать в работу (DoR) и когда она считается завершенной (DoD). Данные определения особенно важны в Agile-командах для поддержания прозрачности процесса работы.
Definition of Ready (DoR)[править]
Минимальные критерии[править]
Перед взятием задачи в работу системный аналитик должен убедиться в наличии:
- ✓ Четкой цели задачи (проблема, требование или гипотеза)
- ✓ Определенных стейкхолдеров (кто заказчик, кто принимает решение)
- ✓ Исходных данных (документы, ссылки, примеры)
- ✓ Согласования с PO/тимлидом (нет конфликтов с другими задачами)
- ✓ Известных ограничений (сроки, бюджет, технические рамки)
Идеальные критерии[править]
Дополнительные параметры для сложных задач:
- ✎ Примеры аналогичных решений (как делали раньше или у конкурентов)
- ✎ Предварительный анализ (интервью с пользователями, данные аналитики)
- ✎ Критерии успеха (как поймем, что задача выполнена хорошо)
- ✎ Определенные риски (что может пойти не так)
Definition of Done (DoD)[править]
Минимальные критерии[править]
Для закрытия задачи достаточно:
- ✓ Документированных требований (в СФЕРА)
- ✓ Первичной валидации (подтверждение от заказчика или PO)
- ✓ Передачи артефактов (разработчикам/тестировщикам)
- ✓ Отсутствия открытых вопросов
Идеальные критерии[править]
Дополнительные параметры для полного завершения:
- ✪ Требования по стандарту (Use Cases, User Stories, BPMN/UML)
- ✪ Приемочный тест (демо для стейкхолдеров)
- ✪ Обновленная документация (внутренняя и пользовательская)
- ✪ Ретроспективный разбор (улучшения на будущее)
Пример применения[править]
Для User Story[править]
Этап | Минимальные критерии | Идеальные критерии |
---|---|---|
DoR |
|
|
DoD |
|
|
Когда какие критерии использовать[править]
- Минимальные DoR/DoD — для срочных задач или MVP
- Максимальные DoR/DoD — для:
- Сложных фич
- Регулируемых индустрий (финансы, медицина)
- Критически важных компонентов системы