Итерация функции

Карточка итерации функции

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

Мы настоятельно рекомендуем избегать использования критериев (Acceptance criteria) в формате "Given-When-Then" и вместо этого использовать простой повествовательный формат для спецификаций. Если вы используете внешние ресурсы, такие как инструменты OpenAPI (Swagger и т. д.) или инструменты дизайна (Figma), мы настоятельно рекомендуем документировать только информацию и требования, которые не могут быть напрямую взяты из этих документов. В противном случае изменения в этих ресурсах сделают текстовое содержание итерации функции устаревшим. Для всех спецификаций очень важно иметь единственный источник правды (single source of truth). Используйте принцип бритвы Оккама.

Написание сектора итерации для разработчика — это не только обязанность продуктового менеджера или бизнес-аналитика. Разработчики контролируют свои сектора итерации, и мы рекомендуем им включать туда технические детали о компромиссах (trade-offs), сложных исправлениях и технических решениях.

Сектор итерации разработчика — это не просто описание технических требований, за которые он ответственен; это живой документ, результат взаимодействия между продуктовой и инженерной командами. Он отражает не только то, что ожидается от разработки, но и документирует процесс технической реализации и его результат.

В ИФ Методе классический вопрос Kanban — "Должен ли это быть отдельный тикет?" — просто отпадает. Вся информация распределяется по секторам разработчиков. Лидер итерации принимает решение о том, как разделить итерацию функции на сектора.