Совмещение Waterfall и Agile в Timetta

Обновлено: 09.11.2026

Timetta позволяет сочетать календарное и финансовое планирование проекта с гибкой организацией работы команды. Для этого важно определить, какая структура задаёт рамки проекта, как команда декомпозирует работу и где учитываются затраты.

ТерминыТермины

Waterfall, или водопадная модель, предполагает последовательное прохождение этапов и существенную проработку состава работ до исполнения. До запуска проекта оценивают сроки, стоимость и потребность в ресурсах, затем контролируют выполнение согласованного плана и управляют его изменениями.

Для такого планирования используют, например, Microsoft Project и Oracle Primavera P6. Они поддерживают календарно-сетевой график, зависимости и ресурсное планирование. Сами инструменты не ограничены только водопадной моделью.

Agile, или гибкий подход, предполагает уточнение решений по мере получения результата и обратной связи. Планирование здесь тоже необходимо: есть цели, приоритеты, планы релизов и ближайших итераций. Детали последующих работ уточняются постепенно. Это соответствует принципам Agile-манифеста. Знакомые инструменты такого подхода — Jira и Azure Boards.

Таким образом, различается прежде всего способ управления неопределённостью и изменениями, а не наличие или отсутствие плана.

В Timetta используются три связанных понятия:

Элемент ИСР — часть структуры проекта. Задача — единица работы со статусом, исполнителем и оценкой. Наличие сроков и вложенности само по себе не определяет, какой из этих инструментов нужен: граница проходит по назначению структуры.

У задачи может быть один непосредственный родитель и несколько дочерних задач. Связей с другими задачами может быть несколько. Связь «блокирует» не назначает родителя, не переносит затраты и сама по себе не создаёт зависимость в календарно-сетевом графике ИСР. Подробнее — Связи задач.

Управление проектами по водопадной моделиУправление проектами по водопадной модели

Основой управления становится ИСР проекта. Руководитель декомпозирует проект до глубины, необходимой для планирования и контроля: количество уровней ИСР не ограничивается двумя или тремя. В этой структуре определяют сроки, зависимости, потребность в ресурсах и бюджет.

Задачи можно использовать для повседневной работы команды: например, вести Kanban-доску с поручениями и привязывать их к соответствующим работам ИСР. Можно обойтись и без задач, учитывая время непосредственно на ИСР.

В этой модели обычно достаточно эпиков и обычных задач. Создавать параллельную управленческую иерархию из инициатив и других уровней выше эпика не рекомендуется: команде придётся поддерживать две конкурирующие структуры одного проекта.

По той же причине обычно не нужны родители задач из других проектов. Совместное управление несколькими проектами лучше организовывать через программы и портфели. Зависимости между задачами разных команд при необходимости задаются отдельно.

Руководитель контролирует проект по ИСР. Режим «План» в представлении задач помогает увидеть, как оперативная работа соотносится с этой структурой, но не заменяет полноценный план проекта.

Управление проектами по гибкой моделиУправление проектами по гибкой модели

Подробную ИСР можно не строить. Проект становится прежде всего контейнером для задач команды, сохраняя роль единицы финансового и ресурсного учёта. Технически корневой элемент ИСР остаётся: к нему относятся задачи и затраты, если более подробная структура не нужна.

Основой организации работы становится иерархия задач. В привычной модели Jira различают три уровня:

• Уровень 1 — эпик.
• Уровень 0 — задача, история, ошибка и другие типы основной работы команды.
• Уровень −1 — подзадача.

Дополнительные уровни выше эпика настраиваются средствами планирования, если это поддерживает используемая конфигурация Jira.

В Timetta можно организовать работу как «Эпик → Задача / История / Ошибка» и расширить иерархию собственными типами. Чек-лист внутри задачи не является отдельным уровнем иерархии и не равнозначен подзадаче Jira: его элементы не имеют самостоятельной карточки задачи и собственного процесса прохождения статусов.

Зачем нужны уровни выше эпикаЗачем нужны уровни выше эпика

Инициатива или другой верхний тип объединяет несколько эпиков ради общего результата. Это полезно, когда результат достигается несколькими командами или не укладывается в один эпик. Такой уровень нужен для согласования цели и контроля её достижения; он не становится автоматически этапом ИСР с собственным бюджетом.

В примере с корпоративным ПО и отдельно выделенной командой мобильного приложения структура может выглядеть так:

Инициатива «Единый доступ к сервисам» — проект «Корпоративное ПО»
+-- Эпик «Серверная авторизация» — проект «Корпоративное ПО»
|   +-- Задачи серверной команды
+-- Эпик «Вход в мобильном приложении» — проект «Мобильное приложение»
    +-- Задачи мобильной команды

Руководитель инициативы контролирует общий результат по верхней задаче, команды — свои эпики и задачи. Финансы при этом остаются в собственных проектах: межпроектная иерархия не создаёт общий бюджет.

Для таких структур предназначен режим «План». Доска и бэклог показывают задачи уровня 0 и ниже. Эпики — уровень 1 — и более высокие уровни, например инициативы, в рабочий список задач доски и бэклога не входят. Их декомпозицию и общий прогресс отслеживают в «Плане».

Типы и допустимые уровни иерархии настраивает администратор. Родителя выбирают с непосредственно предыдущего уровня; пропускать настроенные уровни нельзя. Межпроектное назначение должно быть разрешено для типа родителя и учитывать права доступа. По умолчанию такие назначения выключены. Подробнее — Иерархия задач.

Управление проектами по гибридной моделиУправление проектами по гибридной модели

Проектному офису до запуска проекта нужны оценка сроков, стоимость и план ресурсов. Команда при этом может уточнять решения итерациями, работать со спринтами или Kanban. Гибридная модель связывает эти два способа управления.

Вариант 1. ИСР и иерархия задач ведутся отдельноВариант 1. ИСР и иерархия задач ведутся отдельно

Руководитель ведёт ИСР, а команда самостоятельно организует задачи. Каждая задача в любом случае привязана к элементу ИСР своего проекта, но правильный выбор этой работы требует внимательности. Дочерние задачи наследуют работу родителя в пределах проекта; это упрощает привязку, но не исправляет ошибку при выборе работы для всей ветки.

Если самостоятельные ветки оставить на корневом элементе, часы и себестоимость будут собраны по проекту, но детализация по этапам потеряется.

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

Такую организацию работы не рекомендуется выбирать как основной подход, хотя на практике она встречается. Если две структуры ведутся отдельно, необходимо явно назначить ответственного за их соответствие и регулярно проверять привязку задач к ИСР.

Вариант 2. Выбранные уровни ИСР представлены задачамиВариант 2. Выбранные уровни ИСР представлены задачами

В настройках задач конкретного проекта задаётся соответствие для первого и, при необходимости, второго уровня ИСР. Корневой элемент проекта в эту нумерацию не входит.

Это пример настройки, а не универсальное значение типов. Можно ограничиться одним уровнем, например сопоставить первый уровень ИСР с эпиками.

ИСР проекта                         Представление для команды
Проект
+-- Личный кабинет           <-->   Инициатива «Личный кабинет»
    +-- Авторизация          <-->   Эпик «Авторизация»
                                    +-- История «Вход по коду»
                                    +-- Задача «Настроить отправку»
                                    +-- Ошибка «Не приходит код»

Каждая пара «элемент ИСР ↔ задача» относится к одному объёму работ. Правила такой модели:

• При создании элемента сопоставленного уровня система создаёт одну связанную задачу нужного типа. Вручную создавать задачи зарезервированного типа в этом проекте нельзя.
• Название и плановые даты задаются через ИСР. В задаче они доступны для просмотра; дедлайн соответствует окончанию работы ИСР. Изменения согласованного плана выполняет руководитель.
• Связанные задачи повторяют структуру соответствующих элементов ИСР. Команда декомпозирует их обычными задачами, планирует спринты и управляет исполнением.
• Обычные дочерние задачи получают работу ИСР через связанную родительскую задачу. Отдельно выбирать им другую работу ИСР в этом режиме нельзя.
• Для автоматически созданных представителей действует особое правило: инициатива относится к своему элементу первого уровня, а вложенный эпик — к своему элементу второго уровня. Эпик не наследует работу инициативы. Для обычных дочерних задач действует наследование работы от родителя.
• Бюджеты и ресурсы планируются в ИСР. Связанная задача не создаёт второй бюджет, а её трудозатраты учитываются один раз. Статус исполнения задачи и приёмка результата руководителем остаются разными управленческими действиями.

Для такого проекта команда должна работать внутри созданной структуры. Неразобранные задачи следует явно показывать как требующие привязки. Межпроектных родителей лучше избегать: они размывают границу между согласованным планом проекта и его исполнением.

ИСР можно продолжать глубже второго уровня, но автоматические представители у этих элементов в данной схеме не создаются. Факт по задачам эпика собирается на связанном с ним уровне. Если необходим учёт по более глубоким работам, время следует относить непосредственно на эти работы либо использовать первый вариант с отдельными ветками задач.

В представлении «План» элемент ИСР и его связанная задача показываются одной строкой, объединяющей плановые показатели и сведения об исполнении. Ниже располагаются задачи команды.

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

Общие правила принадлежности и учётаОбщие правила принадлежности и учёта

Следующие правила определяют принадлежность задач и место учёта затрат. При включённом сопоставлении типов задач с ИСР закреплённая связь с элементом ИСР имеет приоритет перед обычным наследованием.

Как задача получает элемент ИСРКак задача получает элемент ИСР

Каждая задача принадлежит одному проекту и одному элементу ИСР этого проекта. На один элемент ИСР может приходиться несколько задач.

При изменении работы родителя новое значение распространяется по его обычным дочерним задачам в пределах одного проекта. Автоматически созданная по ИСР задача сохраняет собственную закреплённую работу; её обычные потомки наследуют именно эту работу. На межпроектной связи распространение останавливается, даже если ниже снова встретится задача исходного проекта.

При включённом сопоставлении типов с ИСР работа обычной задачи определяется её положением в связанной ветке; вручную выбрать другую работу нельзя. Без сопоставления ручное изменение допускается, если у задачи нет родителя в том же проекте, есть необходимые права и отсутствуют списания времени, включая черновики. Перенос задачи в другой проект — отдельная операция со своими проверками.

Экономика и фактическое времяЭкономика и фактическое время

Экономика планируется и контролируется по проекту и его ИСР: здесь сопоставляются ресурсы, бюджеты, план, факт и прогноз. При гибкой модели без подробной ИСР этот контроль остаётся на уровне проекта.

Время можно учитывать через задачу или непосредственно на работе ИСР. При списании через задачу используются её собственные проект и работа. Задача сохраняется как дополнительная аналитическая детализация.

6 часов на задачу «Разработать API»
    -> работа ИСР «Серверная часть»
    -> факт и себестоимость проекта «Бэк»

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

Прогресс и Story PointsПрогресс и Story Points

Статусы, количество выполненных задач и Story Points (SP) помогают оценивать исполнение. SP выражают относительный объём или сложность работы; это не часы и не деньги.

По родительской задаче можно видеть показатели доступных пользователю потомков, в том числе из нескольких проектов. Оценивать один и тот же объём одновременно на нескольких уровнях следует осторожно: при суммировании это может завышать итог.

Аналитика по задачам помогает разобраться, куда ушло время. Но завершение половины SP не означает расходование половины бюджета, а финансовые показатели инициативы нельзя получить простым переносом в неё затрат всех дочерних проектов.

Для чего нужен режим «План»Для чего нужен режим «План»

«План» — представление существующих задач в структуре и на временной шкале. Оно помогает видеть состав результата и его связь с ИСР. Само включение этого режима не создаёт календарно-сетевой график и не включает автоматическое сопоставление ИСР с типами задач.

Даты обычной задачи могут определяться её спринтом и работой ИСР; для окончания также используется собственный дедлайн задачи. Для задач, созданных по сопоставлению с ИСР, плановые даты задаются связанной работой проекта. Поэтому даты на шкале не следует воспринимать как независимо заданные начало и окончание каждой задачи.

Два способа построения структурыДва способа построения структуры

В варианте с ИСР связанные элементы и автоматически созданные задачи образуют общие строки. Для обычных задач вложенность родителя и ребёнка сохраняется, если они относятся к одному проекту и элементу ИСР. При другой принадлежности ребёнок остаётся под своей работой ИСР, а межпроектная иерархия не переносит его под чужой проект.

Оба способа используют одну выборку задач. «План» задач не обязан показывать всю ИСР, включая работы без выбранных задач. Для полного календарного и ресурсного планирования используется структура самого проекта.

Как собрать несколько проектов в одном представленииКак собрать несколько проектов в одном представлении

Представление внутри проекта ограничивает исходную выборку этим проектом. Для общей структуры создайте представление задач без привязки к одному проекту:

1. Задайте название, например «План корпоративного сервиса».
2. Включите в фильтр все нужные проекты и работы, а не только верхнюю инициативу.
3. Включите режим «План».
4. Предоставьте участникам доступ к представлению.
5. Добавьте представление в нужную группу навигации.

Представление не создаёт копий задач и не переносит их между проектами. Доступ к представлению не заменяет права на сами задачи. Подробнее — Представления.

Как читать отфильтрованный планКак читать отфильтрованный план

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

Недоступные задачи не раскрываются. Если родитель недоступен, доступная дочерняя задача остаётся в представлении.

Диапазоны дат контекстных строк строятся по текущей выборке и не меняют исходные сроки ИСР. Сводка в карточке родителя охватывает доступных потомков независимо от фильтра представления, поэтому может отличаться от показателей выбранной части в «Плане».

Интеграция с JiraИнтеграция с Jira

Интеграция может использоваться и просто для загрузки задач и времени. Здесь рассматривается гибридный сценарий: Timetta задаёт плановую структуру проекта, Jira используется для детализации и исполнения.

Подобное разделение применяется в других решениях. Например, TPG PSLink передаёт пакеты работ из Microsoft PPM в Jira как версии, эпики или задачи и возвращает сведения об исполнении. В SKIDATA фактические часы из Jira используются для управления проектами в Microsoft PPM.

Для этого сценария настраиваются два направления обмена: передача согласованной структуры из Timetta в Jira и загрузка задач, прогресса и времени из Jira в Timetta. Состав обмена согласуется для используемой редакции Jira и конфигурации проектов.

Настройка соответствийНастройка соответствий

В двух системах необходимо согласовать смысл типов и допустимые родительские связи. Полностью одинаковые названия и идентификаторы не обязательны: важно, чтобы, например, инициатива и эпик соответствовали нужным уровням и сохранялась структура результата. Отдельно согласуется представление подзадач Jira: автоматически считать их элементами чек-листа Timetta нельзя.

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

У Jira Cloud есть особенность team-managed проектов: их типы и настройки локальны проекту. Поэтому одинаковое название типа в двух проектах не гарантирует одинаковую сущность; сопоставление должно учитывать проект и идентификатор типа. Если нужные уровни недоступны в конкретной конфигурации Jira, одной настройки соответствий недостаточно.

Кто управляет структуройКто управляет структурой

Элементы согласованной структуры создаются через ИСР в Timetta. На стороне Jira для соответствующих типов необходимо отдельно организовать ограничения создания и изменения плановых полей — настройками, средствами автоматизации и правилами работы. Timetta не может считать эти ограничения действующими только потому, что включена интеграция.

Ранее существующие задачи зарезервированных типов нужно связать с элементами ИСР. Вновь обнаруженный несопоставленный объект такого типа требует разбора: он не должен молча создавать дубликат или менять согласованный план.

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

Как проходит работаКак проходит работа

1. Проектный офис создаёт проект в Timetta. В отдельном сценарии заготовка проекта может формироваться из выбранного типа верхней задачи Jira.
2. Руководитель строит ИСР, оценивает сроки, стоимость и ресурсы.
3. Для сопоставленных элементов система создаёт связанные задачи в Timetta и, при включённом обмене, соответствующие задачи в Jira.
4. Команда декомпозирует их в Jira, выполняет работу и регистрирует время.
5. Импорт возвращает задачи, изменения исполнения и записи времени в Timetta. Факт относится к нужным проектам и работам ИСР.

Timetta: проект -> ИСР -> связанные инициативы и эпики
                                      |
                                      v
Jira:                 эпики -> задачи -> выполнение и время
                                      |
                                      v
Timetta:                  прогресс и факт по проекту и ИСР

Импорт должен охватывать все задачи и записи времени в согласованной области обмена, с учётом прав и периода загрузки. Это включает время на эпиках и других верхних задачах, а не только на задачах нижнего уровня. Если запись нельзя однозначно отнести к работе ИСР, она требует разбора, а не незаметного отбрасывания.

Повторная синхронизация обновляет связанные объекты и записи времени, не создавая дубликатов. Один и тот же факт не должен повторно учитываться как прямое списание на ИСР и как списание через импортированную задачу.