Перейти к основному содержимому

Чек-лист самопроверки

Руководителю Аналитику Техническому писателю

Чек-лист самопроверки

  1. Чётко ли определена цель проекта и зафиксирована в виде SMART-цели?
  2. Стабильны ли требования, или ожидается их частое изменение?
  3. Есть ли юридические или нормативные ограничения, требующие фиксации объёма работ до начала разработки?
  4. Утверждено ли техническое задание (ТЗ) до старта реализации?
  5. Возможны ли изменения в ТЗ без формального перезаключения контракта?
  6. Используется ли линейная модель (Waterfall), где этапы строго последовательны?
  7. Есть ли чёткое разделение на фазы: анализ → проектирование → кодирование → тестирование → внедрение?
  8. Проводится ли тестирование только после завершения всей разработки?
  9. Является ли приёмка продукта единовременным событием в конце проекта?
  10. Используется ли Gantt-диаграмма или MS Project для детального планирования всех задач заранее?
  11. Применяется ли Agile как философия: фокус на ценности, сотрудничество, адаптация?
  12. Разделена ли работа на короткие итерации (спринты)?
  13. Есть ли у команды Product Owner, отвечающий за приоритезацию бэклога?
  14. Проводятся ли ежедневные 15-минутные встречи (Daily Scrum)?
  15. Есть ли Sprint Planning, Sprint Review и Sprint Retrospective?
  16. Демонстрируется ли работающий инкремент каждые 1–4 недели?
  17. Используется ли продуктовый бэклог как динамический список задач?
  18. Меняются ли приоритеты в бэклоге между итерациями на основе обратной связи?
  19. Применяется ли относительная оценка задач (Story Points), а не человеко-часы?
  20. Используется ли Planning Poker или аналогичный метод оценки?
  21. Визуализируются ли задачи на Kanban-доске (To Do / In Progress / Done)?
  22. Установлены ли ограничения на количество задач в работе (WIP)?
  23. Измеряется ли время цикла (Cycle Time) для анализа потока?
  24. Проводятся ли регулярные встречи по пополнению бэклога и анализу потока?
  25. Может ли новая задача быть добавлена в работу в любой момент?
  26. Используется ли гибридная модель (например, Water-Scrum-Fall)?
  27. Сохраняется ли формальная приёмка по ГОСТ даже при итеративной разработке?
  28. Проходит ли каждый инкремент независимую экспертизу и согласование?
  29. Автоматизированы ли сборка, тестирование и деплой (CI/CD)?
  30. Запускаются ли автоматические тесты при каждом коммите в репозиторий?
  31. Используется ли TDD (Test-Driven Development) или BDD?
  32. Есть ли культура рефакторинга и управления техническим долгом?
  33. Участвует ли заказчик в процессе на постоянной основе (не только на старте и в конце)?
  34. Может ли заказчик изменить приоритеты без бюрократических процедур?
  35. Формулируются ли требования в виде пользовательских историй?
  36. Определены ли критерии приёмки (Definition of Done) для каждой задачи?
  37. Используются ли Jira, Trello или аналоги для управления задачами?
  38. Ведётся ли документация в Confluence или Notion как живой артефакт?
  39. Есть ли чёткое распределение ролей: кто отвечает за ценность, процесс, реализацию?
  40. Проводятся ли ретроспективы для анализа и улучшения процесса?
  41. Анализируются ли причины срывов сроков системно, а не как личные ошибки?
  42. Поддерживает ли архитектура системы частые изменения (модульность, контракты, тесты)?
  43. Используется ли эволюционный дизайн вместо big design up front?
  44. Учитывается ли технический долг в планировании спринтов?
  45. Есть ли метрики: Velocity, Cycle Time, Lead Time, частота релизов?
  46. Поставляется ли новая версия чаще одного раза в квартал?
  47. Возможен ли деплой в production несколько раз в день?
  48. Собирается ли обратная связь от пользователей после каждого релиза?
  49. Используются ли данные из production (логи, метрики) для планирования следующих итераций?
  50. Соответствует ли выбранная методология реальному поведению команды — или это лишь «Agile в названии»?

Освоение главы0%