Итеративно‑функциональный метод и одноименная платформа создается в России с 2024 года. Agile был создан как ответ на косность Waterfall. ИФ Метод, в свою очередь, как ответ на фактическую импотенцию Agile практик и превращение его в своеобразную религию. Единственное сходство двух подходов — это итеративность, которая не является оригинальной идеей Agile. ИФ Метод строится на трех главных понятиях — итерации функции (фичи), самой функции и очередях итераций. ИФ Метод не признает никакой философии, ценностей или принципов — это маркетинговая чушь, которую используют, чтобы продать вам книги, курсы и консультационные услуги. ИФ Метод не использует канбан‑доски, имея оригинальный способ визуализации работы. По каким причинам ИФ Метод может быть удобнее и выгоднее для разработчиков, продуктовых менеджеров и высших руководителей? Для разработчиков:

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

Нет оценки в стори‑поинтах. Автомобильный конвейер не имеет ничего общего с разработкой программного обеспечения, но на конвейере единицы должны быть разделены по какому‑то принципу. Для этого используют концепт стори поинтов, придуманных Роном Джеффрисом, подписантом Манифеста и автором экстремального программирования. В 2019 году в этой статье он извинился за свое изобретение и посоветовал не использовать стори поинты, потому что они «мусор» (waste).

Отдельная документация больше не нужна.Другой концепт экстремального программирования Рона Джеффриса, знаменитые User Stories, исторически привел к тому, что людям нужно делать двойную работу, сначала писать user story в жанре As a User, I want X, so Y, а потом еще писать документацию о том же самом, но уже в жанре нормального повествования. С учетом того, что требования нередко меняются в ходе работы, обновлять и тикеты, и документацию — это двойная работа, на которую ни у кого нет времени. Итерации в ИФ Методе пишутся в простом повествовательном стиле и сами служат документацией.

Технический урон вместо технического долга. На эту тему будет отдельная статья, но ИФ Метод оперирует новым термином — технический урон, который включает в себя не только дефекты, но и некачественный / нечитаемый / неподдерживаемый код, мисконфигурации и все, что мешает не только customer experience, но и developer experience. Забавный факт — после того, как я рассказал известному аджилисту Аллану Холубу (Allan Holub) о концепции технического урона, он «придумал» новый термин — technical malfeasance («техническое злодеяние»).

Для продуктовых менеджеров

Нет необходимости в user story. Больше не нужно писать портянки текста с acceptance criteria. По принципу single source of truth (один источник правды), если информация может быть получена из дизайн‑документа (макет, блок‑схема, OpenAPI референс), то дублировать ее не нужно. Поэтому продуктовые менеджеры и аналитики могут сконцентрироваться на продуктовых исследованиях и экспериментам вместо бесконечного написания тикетов.

Четкая структура ответственности. За каждой итерацией функции закреплен лид, который отвечает за качество и своевременность работы всех разработчиков, занятых в этой итерации. Нет необходимости опрашивать всех на общем статус‑митинге, достаточно взаимодействовать с лидом итерации.

Прозрачность качества работы. Каждый дефект должен быть привязан к итерации функции, в которой он был допущен. В отличие от канбана, где любой дефект внешне равноценен user story, ИФ Метод подчеркивает, что главная работа программиста — это разработка фич, а дефекты — это анти‑работа, и нужно стремиться к тому, чтобы этой анти‑работы было все меньше.