# Об Agile В 2001 году семнадцать консультантов собрались на горнолыжном курорте в штате Юта, США, чтобы обсудить методы разработки программного обеспечения. Результатом их встречи стал документ под названием "Agile Manifesto". Манифест включил в себя 12 принципов, но широко известны в основном только четыре «ценности»: • Люди и взаимодействие важнее процессов и инструментов • Работающий продукт важнее исчерпывающей документации • Сотрудничество с заказчиком важнее согласования условий контракта • Готовность к изменениям важнее следования первоначальному плану Эти принципы задали новый тон для разработки программного обеспечения, представив Agile как более эффективный и прогрессивный подход по сравнению с устаревшими методами. Однако на практике оказалось, что большинство этих принципов слишком расплывчаты, чтобы их можно было применить непосредственно к разработке ПО. О техниках Agile написано множество книг, а тысячи людей прошли соответствующую сертификацию, обучая других, как «правильно» работать по Agile. И если у вас не получается — значит, вы просто не делаете Agile как надо. При этом, несмотря на широкое распространение, нет очевидных доказательств того, что Agile действительно работает. Его популярность объясняется тем, что метод Waterfall — где все планируется заранее и строится по плану — работает только в тех случаях, когда четко известно, что нужно создать, заранее. В стартапах, где разрабатывается что-то концептуально новое, это едва ли возможно. **Тайна Канбан-доски** В 2003 году Мэри и Том Поппендик опубликовали книгу *Lean Software Development: An Agile Toolkit*. Эта книга была первой попыткой применить методы, взятые с японских заводов Toyota, к разработке ПО. Судя по тому, как много команд разработчиков используют Канбан-доски в наше время, эта идея оказалась успешной. Но действительно ли принцип автомобильного конвейера подходит для создания ПО? Не совсем понятно, почему Мэри и Том решили, что этот метод будет работать для ПО. Toyota использовала Канбан для производства одинаковых автомобилей из одинаковых запчастей. На линии сборки могут быть сотни рабочих станций, каждая из которых выполняет одну четко определенную, бесконечно повторяемую операцию. Когда машина покидает завод, ответственность за нее уже не лежит на сборщиках — они переходят к следующему автомобилю. Процесс сборки — это транзакция, где завершенный автомобиль является конечным продуктом, и операция на каждой станции сборки не зависит от других. Например, покрасочная линия не заботится о том, как устанавливается аудиосистема, а установка колес не зависит от качества сидений. С программным обеспечением это не работает. Разработка ПО — это не транзакционный процесс. Новый код пишется поверх уже существующего, слой за слоем, и постоянно меняется. Спорные решения, принятые в начале разработки, могут повлиять на весь проект. Создание ПО больше похоже на создание бесконечно растущего небоскреба или на рост растения. **Code ownership против менталитета тикетов** Когда автомобиль выходит с конвейера, его ремонтом его занимаются в сервисных центрах, а не на сборочной линии. Точно так же, когда задача на Канбан-доске помечена как «Сделано», она исчезает в небытие, и вам придется пользоваться поиском, чтобы ее найти. Это будет сложно и для ваших коллег, а если они все-таки найдут задачу, как они поймут, актуальна ли информация или она была заменена другой? С Канбан-доской у разработчиков нет особого стимула думать за пределами текущих задач. Нашли дефект после релиза? Отлично, просто создадим еще один тикет — новый способ показать свою продуктивность. Разработчики, которые быстро создают не самый качественный код, часто выигрывают в Agile, а их коллеги тратят время на исправления и рефакторинг. Связь между ошибками и стремлением к скорости работы часто игнорируется. «Если это не в Jira, этого не было» — такой подход не способствует улучшению качества кода или долгосрочному планированию. Он ставит на первое место скорость выполнения задач и различные метрики, которые редко оказываются полезными. Люди, не обладающие техническими знаниями, не могут точно оценить качество кода или увидеть ухудшение его состояния, пока не станет слишком поздно. Именно поэтому переписывание ПО с нуля по-прежнему является частой историей в индустрии. Технические лидеры часто говорят о «code ownership», но на самом деле они пытаются решить проблему равнодушия к качеству продукта. Немало разработчиков не смотрят дальше плохо написанных требований и не сталкиваются с последствиями своих ошибок. Их задача — исправить свои ошибки, но они не учатся на них. В то время как более опытные разработчики вынуждены идти на компромиссы в конце спринта, что приводит к разочарованию и выгоранию. Agile и Канбан-доска не оправдали себя в разработке ПО. Agile пытался объединить эвристический подход и программирование, но это оказалось неудачным экспериментом. Поэтому мы создали итеративно-функциональный метод — системный подход к управлению продуктами в области разработки ПО. # ИФ Метод

Экран активных итераций

**Итеративно-функциональный метод** — это способ итеративного управления разработкой ПО, не имеющий отношения к Agile или Waterfall. У этого метода нет философии, принципов или ценностей, только алгоритм, который отражает процесс разработки ПО, происходящий в реальности — программисты, тестировщики, дизайнеры и продуктовые менеджеры параллельно работают над различными итерациями разнообразного функционала ПО. Метод включает в себя три основные понятия: очередь итераций, итерация функции и сама функция продукта. Эта триада представлена на двух экранах, между которыми можно переключаться. Первый экран, т.н. **экран активных итераций**, отображает очереди активных итераций для каждого разработчика в виде колонок. Каждая карточка итерации функции, в отличие от карточки на канбан-доске, остаётся на своём месте. Второй экран, называемый **Карта продукта**, представляет собой все когда-либо созданные функции продукта за всю его историю. Он выполняет ту же роль для продуктовых спецификаций, как кодовая база (codebase) для кода. Когда итерация функции завершается (все её стадии помечены как завершённые), она исчезает с экрана активных итераций и доступна только на Карте продукта. #### Стадии итераций Каждый человек, имеющий отношение к разработке, знает, как работает канбан-доска: вы создаёте задачу, перетаскиваете её из одной колонки в другую и иногда переназначаете её на другого человека. Это бесконечный процесс: перетащил — отпустил, перетащил — отпустил. Если ваша команда больше пяти человек и вы используете Agile практики, то на каждом стендапе продуктовый менеджер может бесконечно прокручивать Канбан-доску, пытаясь найти нужные задачи, распределённые по разным колонкам и разным людям. ИФ Метод не имеет такой проблемы. Изменения статусов происходят не путём перетаскивания или переназначения задач, а одним кликом на индикаторе стадии. Один клик — и статус меняется на мигающий зелёный, показывая, что задача в процессе. Ещё один клик — она становится полностью зелёной, что означает «готово». Третий клик ставит желтый статус «блокировано», а четвертый возвращает его в исходное (пустое) состояние. На данный момент стадии имеют глобальное значение для всего рабочего пространства и устанавливаются при его создании. Можно настроить до пяти стадий. Это эквивалентно 15 колонкам канбан-доски, что даёт уровень детализации, фактически недостижимый с помощью традиционного Канбана. Представьте себе Канбан-доску с 15 колонками — будет полный хаос. В ИФ Методе каждая стадия имеет 4 статуса: не начато, в процессе, готово и заблокировано. Все названия стадий можно редактировать, хотя мы рекомендуем оставить название последней как «Готово для пользователей». #### Готово для пользователей vs. Определение готовности (Definition of Done) В некоторых организациях есть чёткое «Определение готовности» (DoD), при выполнении требований которого карточка задачи уходит с доски в небытие. ИФ Метод предлагает использовать формулировку «Готово для пользователей», не определяя строгих шагов. Если продукт готов для пользователей и вам не стыдно за то, что они увидят, этого вполне достаточно — больше уточнений не нужно. Но что происходит с итерацией функции, которая «готова для пользователей»? В отличие от задач на канбан-доске, которые исчезают в пустоту, итерации функций переходят в **Карту продукта**. # Карта продукта

Карта продукта с шестью функциями

Один из принципов Agile — «работающее ПО важнее подробной документации» — возможно, стал причиной того, что внутренняя документация современных программных продуктов стала слабым звеном (если она вообще существует). Однако трудно поспорить с тем, что внутренняя документация необходима, особенно в сложных, устаревших системах, которые обслуживают множество клиентов, включают кастомизированные части и в целом сложны в поддержке. Так почему же поддержка документации вызывает такие трудности? Основная причина — двойная работа. Карточки на Канбан-доске и внутренняя документация существуют в разных жанрах. Карточки представляют собой пользовательские истории, подзадачи, баги и иногда эпики. Внутренняя же документация, как правило, представлена в свободной форме и существует в виде цельных документов, без какой-либо разбивки, удобной для оценки в "стори поинтах". Разработка часто включает в себя изменения в спецификациях в процессе, что делает их сложными для поиска и обновления всей связанной с ними документации. Проблема в том, что как только документация устаревает, её использование может быть даже опасным, не говоря уже о том, что она становится бесполезной. Как говорят, "\[TOOL\_NAME] — это место, где документация умирает." При отсутствии должной поддержки иногда полезнее просто её удалить. С помощью Карты продукта вы можете просматривать все функции вашего продукта на одном экране. Кликнув на функцию, вы сможете последовательно просмотреть все итерации этой функции с момента её создания, с указанием программистов, ответственных за каждую итерацию. Этот подход значительно облегчает работу новым членам команды или разработчикам, которые не знакомы с какой-либо функцией — они могут изучить итерации, узнать её историю и понять, к кому обратиться с вопросами. Тикеты Канбана, как правило, существуют отдельно друг от друга, и установить точную взаимосвязь между ними практически невозможно. Также можно отправить итерацию функции обратно на экран активных итераций из Карты продукта, сняв зелёные индикаторы стадии в списке итераций. Это возвращает итерацию к разработчикам, которые изначально ею занимались. # Функция Многие инструменты управления проектами, такие как Jira, изначально были разработаны как трекеры дефектов — интерактивные таблицы для отслеживания ошибок, в то время как требования к продукту создавались в виде длинных документов по принципу Waterfall. Канбан-доски были добавлены позднее под влиянием последователей Agile, вдохновленных автомобильными конвейерами на заводах Тойота (TPS – Toyota Production System). ИФ Метод полностью меняет эту логику. Он был задуман не как способ трекинга ошибок, а как инструмент для создания продукта. Каждая карточка представляет собой итерацию функции, и любые дефекты — под именем "технического урона" — создаются непосредственно в той итерации, где они были допущены. В отличие от Канбан карточек, которые часто воспринимаются как что-то одноразовое, итерации функций в ИФ методе рассчитаны на постоянное использование в качестве документации. Подход "Shape Up" Джейсона Фрида (Jason Fried) и DHH подчеркивает важность письменных навыков в командах разработчиков. ИФ Метод также развивает этот навык: команда должна поддерживать актуальность спецификаций продукта и технический контекст так же тщательно, как поддерживать код в стабильном, расширяемом и читаемом состоянии. # Итерация функции

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

Каждая итерация функции имеет название, последовательный римский номер и индикаторы стадий, за статус которых ответственен лидер итерации. Также она включает сектора лидера, других разработчиков и лист технического урона (если таковой был зафиксирован). Мы настоятельно рекомендуем избегать использования критериев (Acceptance criteria) в формате "Given-When-Then" и вместо этого использовать простой повествовательный формат для спецификаций. Если вы используете внешние ресурсы, такие как инструменты OpenAPI (Swagger и т. д.) или инструменты дизайна (Figma), мы настоятельно рекомендуем документировать только информацию и требования, которые не могут быть напрямую взяты из этих документов. В противном случае изменения в этих ресурсах сделают текстовое содержание итерации функции устаревшим. Для всех спецификаций очень важно иметь единственный источник правды (single source of truth). Используйте принцип бритвы Оккама. Написание сектора итерации для разработчика — это не только обязанность продуктового менеджера или бизнес-аналитика. Разработчики контролируют свои сектора итерации, и мы рекомендуем им включать туда технические детали о компромиссах (trade-offs), сложных исправлениях и технических решениях. Сектор итерации разработчика — это не просто описание технических требований, за которые он ответственен; это живой документ, результат взаимодействия между продуктовой и инженерной командами. Он отражает не только то, что ожидается от разработки, но и документирует процесс технической реализации и его результат. В ИФ Методе классический вопрос Kanban — "Должен ли это быть отдельный тикет?" — просто отпадает. Вся информация распределяется по секторам разработчиков. Лидер итерации принимает решение о том, как разделить итерацию функции на сектора. # Лидер итерации У каждой итерации функции есть лидер – программист, который несет ответственность за её выполнение. Только этот человек имеет право завершить стадию разработки итерации и отвечает за работу других разработчиков, задействованных в итерации. В интерфейсе платформы это визуально отображается тем, что индикаторы стадий расположены только на карточке лидера итерации. Смысл в том, что другим членам команды не нужно знать статус подзадач итерации; им важно только одно — когда код будет готов для пользователей. Всё остальное не имеет значения для внешних стейкхолдеров и решается внутри команды разработчиков. Лидер итерации также отвечает за распределение спецификации функции на сектора разработчиков. Мы рекомендуем использовать принцип "обратной Дженги" ("reversed Jenga"): после определения архитектурного контракта разработчики выбирают самые удалённые части функции, которые можно разрабатывать независимо, чтобы как можно дольше избегать конфликтов слияния (merge conflicts). Первая часть, обычно описывающая общую структуру файлов и интерфейсы, как правило, выполняется лидером итерации незадолго до того, как другие разработчики начнут свою работу. Лидер итерации несёт полную ответственность за выполнение задачи и также имеет решающий голос в любых спорах по техническим вопросам или архитектуре реализации. # Технический урон Термин «технический долг» существует так же долго, как и сама разработка программного обеспечения. Согласно Википедии, это подразумеваемая стоимость будущих изменений кода, возникающая, когда решение делается с акцентом на удобство или скорость, а не на долгосрочную архитектуру. Со временем этот долг накапливает «проценты», которые необходимо «погашать». Мы считаем, что негативное влияние этой аналогии на современную разработку ПО огромно. Финансовый долг — это обыденность для большинства людей: ипотека, кредитные карты, автокредиты. Идея накопления процентов выглядит вполне нормальной, особенно при низких процентных ставках. Доступ к долговым инструментам воспринимается как отличный способ быстрее достичь желаемого. Технический долг имеет совсем другую сущность. Разработчики нередко увольняются из-за огромного технического долга. Не редкость, когда люди увольняются в первый день, увидев ужасающее состояние кодовой базы. Согласно последнему опросу Stack Overflow, технический долг — это главная проблема для разработчиков, которую назвали 63% опрошенных. Технический долг лишает разработчиков морального удовлетворения от работы, значительно усугубляя уровень стресса. Переписывание всего кода из-за неустранимого технического долга стало нормой в индустрии. Само словосочетание "технический долг" не отражает настоящую природу происходящего. Убедить бизнес в необходимости инвестиций в решение проблем с техническим долгом чрезвычайно сложно, потому что его реальное влияние останется скрытым до тех пор, пока не будет слишком поздно. Вот почему ИФ Метод вводит новый термин — «технический урон». Он охватывает всё, что мешает созданию безупречного и бесперебойного опыта и для пользователей (user experience), и для разработчиков (developer experience). Понятие включает дефекты, нечитаемый или запутанный код, неправильные конфигурации и сломанные шаблоны разработки — всё это является техническим уроном. Изменение терминологии имеет серьёзные последствия для повседневной разработки. В Канбане баги всегда имеют приоритет над рефакторингом некачественного кода, и часто последний вообще не получает должного внимания, оставаясь глубоко в бэклоге. Трудно обосновать бизнесу необходимость переписать код, который «просто работает», даже если это «спагетти-код», склонный к неочевидным багам. Понятие технического урона уравнивает баги и некачественный код, а также неправильные конфигурации, проблемы DevOps и SecOps, влияющие на продукт. #### Баги — это антиработа Канбан доски часто способствуют низкокачественной разработке, так как они отображают «пользовательские истории» (user stories) — фактическую работу — и баги одинаково, что создаёт ложное представление о том, что они равны по своей важности для продукта. Однако баги — это не работа, это антиработа. Это дополнительная нагрузка, вызванная ошибками в коде, пропущенными шагами в цикле разработки, недостаточным тестированием и неправильными решениями конкретных людей. Разработка ПО — это уникальная профессия, где людям платят деньги за исправление их собственных ошибок зачастую без каких-либо последствий. Непосредственные причины большинства багов остаются скрытыми от инженеров и продуктовых менеджеров, в то время как каждый из этих дефектов должен служить учебным материалом для разработчиков, чтобы дать им понять, почему проблемы возникли и как избежать их в будущем. Также дополнительный стресс вызывает ситуация, когда другие разработчики систематически исправляют ошибки в коде, которые допустил кто-то другой. ИФ Метод не использует отдельные карточки для дефектов. Вместо этого платформа создает отдельный сектор технического урона в каждой итерации функции. Это значит, что каждый дефект должен быть создан в той итерации функции, в ходе выполнения которой этот дефект был допущен. Кто-то может сказать, что это приведет к токсичной атмосфере и поиску виноватых. ИФ Метод считает это встроенной радикальной прямотой (radical candour). Метод подразумевает, что профессионалы будут брать ответственность за качество своей работы. #### Капля дегтя в бочке меда Технические лидеры часто подчеркивают важность найма лучших инженеров, горящих своим делом и ответственных за свою работу. Что они на самом деле имеют в виду — так это избегание людей с противоположными качествами. Причины низкой производительности могут быть различными — проблемы с техническими навыками, лень, недостаточное внимание к деталям — но влияние некачественного найма может быть разрушительным со временем. Один человек, который пишет низкокачественный, дефективный, неподдерживаемый или нерасширяемый код, может сделать разработку невыносимой для всей команды, особенно если этот человек повлиял на ранние архитектурные решения. Позже уже не будет достаточно времени, чтобы исправить некачественный фундамент. Именно поэтому стартапы на ранних стадиях часто вынуждены переписывать свои продукты после получения финансирования. Они изначально нанимают дешевых разработчиков, пишущих низкокачественный код, а затем профессиональные разработчики не в силах его поддерживать или расширять. ИФ Метод, с его обязательной связкой дефектов и итераций функций, визуально показывает источник низкокачественной работы. Если инженеры сталкиваются с трудностями и не хотят повышать свой уровень и учиться, их нужно увольнять как можно быстрее. Канбан облегчает скрытие низкокачественной работы и упрощает имитацию бурной деятельности за счет создания бесконечного количества карточек задач, не связанных друг с другом. В конечном итоге деградация кода достигает точки невозврата, люди уходят, а новые менеджеры объявляют, что весь код нужно переписать, что ведет к огромным затратам для бизнеса. Канбан создаёт идеальные условия для «смерти от тысячи бумажных порезов». #### Информационные бункера — это технический урон Ещё один немаловажный аспект технического ущерба связан не только с багами или нечитаемым кодом — это избыточно усложненный код и создание "информационных бункеров" (knowledge silos). Это случается, когда только один разработчик может работать над определённой частью кодовой базы, потому что никто другой не знает контекста и / или код слишком сложен для понимания. Иногда это происходит без злого умысла, но довольно часто люди накапливают знания и не делятся ими, переусложняют решения, чтобы другие не могли легко вносить изменения, и так становятся незаменимыми — иногда в целях защиты от увольнения. ИФ Метод отображает все итерации для функции со всеми секторами разработчиков, что позволяет легко увидеть, кто работал над большинством итераций. Мы рекомендуем назначать разных разработчиков на последующие итерации, чтобы люди не застаивались на определённых участках, не забывали контекст других функций и регулярно пересматривали код друг друга. Код ревью очень важен, но непосредственная работа с кодом другого разработчика даёт наилучший контекст. Инженеры и менеджеры по продукту не должны недооценивать опасность информационных бункеров. Когда человек, накопивший знания, увольняется, продукт рискует значительно замедлить своё развитие и начать накапливать дефекты из-за недостатка контекста у оставшихся разработчиков. В худшем случае, этот участок придётся переписывать полностью. # Облачная и коробочная версии Платформа ИФ Метода существует в облачной и коробочной версиях. Облачная версия доступна по адресу [app.ifmethod.ru](https://app.ifmethod.ru) и развернута в московском кластере Яндекс Облака, что делает платформу очень быстрой – большинство API запросов выполняется менее чем за 50 миллисекунд, если вы находитесь в московском регионе. Коробочная, она же self-hosted или on-premise, версия создана для самостоятельного разворачивания пользователем на своем сервере или облаке. Мы рекомендуем использовать коробочную версию, поскольку она дает максимальный контроль над данными и жизнеспособностью системы. Облачная версия подойдет тем, кто не хочет дополнительных расходов на собственную инфраструктуру и временных затрат на ее обслуживание. Для полноценной работы с любой из версий понадобится лицензионный ключ. Его вы можете приобрести, написав письмо на . Ключ выдается на срок от 3 до 12 месяцев и не имеет ограничений по количеству пользователей. Без ключа вы можете работать с платформой только в демо-режиме, в котором есть лимит на один продукт и только 6 функций в нем. Если вы выбрали облачную версию, можете пропустить следующую страницу и перейти к странице "Создание рабочего пространства". # Установка коробочной версии ### 1. Создание виртуальной машины и получение внешнего IP адреса Необходимо создать новую виртуальную машину.
Можно выбрать минимальную, самую дешевую конфигурацию, для простоты доступа рекомендуем выбрать OS Login.
Нажмите "Создать ВМ" и через несколько секунд в списке виртуальных машин вы увидите новую ВМ. На данном этапе нам нужен внешний IP адрес, нам нужно скопировать его и перейти в панель управления DNS зоной домена, на котором вы хотите разместить платформу. В нашем случае это REG.ru.
### 2. Обновление DNS зоны домена Нам нужно будет создать две записи типа А, для фронтенд приложения и бекенд сервера соответственно.
Обновление серверов DNS может занять 10-15 минут, можно за это время выпить чая. Сайт поможет вам определить, когда можно переходить к следующему этапу. ### 3. Установка платформы на виртуальную машину В настройках виртуальной машины найдите команду для доступа через SSH.
Залогиньтесь на виртуальную машину через SSH и поменяйте юзера на root командой `sudo su`. Теперь нам нужно скачать и запустить скрипт для установки платформы. Скрипт запустится только из под пользователя root. Скопируйте и последовательно введите следующие команды: ``` curl -fsSL https://raw.githubusercontent.com/aerlinn13/ifmethod-helm-charts/refs/heads/main/setup_docker.sh -o setup_docker.sh ``` ``` chmod +x ./setup_docker.sh ``` ``` ./setup_docker.sh ``` Изначально скрипт установит Docker и Docker Compose, затем последовательно задаст вам ряд вопросов. 1. App domain (URL фронтенд приложения): в нашем случае это mirror.ifmethod.ru. 2. Api domain (URL бекенд сервера): в нашем случае это mirror-api.ifmethod.ru. 3. Image tag (версия платформы): последняя версия на текущий момент это 4.25.3. 4. Ваш адрес электронной почты для самоподписываемых SSL сертификатов. После ответа на все вопросы скрипт скачает необходимые образы, запустит NGINX сервер, запросит SSL сертификаты, перезагрузит образы уже с SSL сертификатами. После завершения работы скрипта платформа будет доступна по указанному ранее адресу. # Создание рабочего пространства ### Шаг 1. Название рабочего пространства
После первой авторизации вы увидите экран, на котором сможете ввести название вашей компании. ### Шаг 2. Лицензионный ключ
На втором шаге необходимо ввести лицензионный ключ, который вы можете приобрести, написав нам на . ### Шаг 3. Настройка стадий
Следующий экран предназначен для настройки стадий, которые каждая итерация функции должна пройти, прежде чем стать выполненной. В ИФ Методе нет предварительных этапов разработки или «Определения готовности» (Definition of Ready). Стадия разработки всегда идет первой, и ее название и позиция не могут быть изменены. Остальные этапы можно переименовывать и изменять их порядок. По умолчанию форма включает QA и "Готово для пользователей" вместо «Definition of Done», а также позволяет добавить до двух дополнительных стадий. Это могут быть Ревью кода или любые другие стадии, подходящие для вашего продукта. Стадии изначально настраиваются при создании рабочего пространства, а после этого могут быть отредактированы через настройки. # Управление пользователями

Вот что вы увидите после того, как настроите стадии.

В ИФ Методе нет концепции «досок», вместо этого есть продукты. На экране вы видите "The Product" в верхнем левом углу. Это название вашего первого продукта, которое вы можете позже изменить. Сообщение на экране гласит, что очереди разработчиков пусты. В ИФ Методе есть две категории пользователей: разработчики и все остальные. Только разработчики могут быть назначены на разработку итераций фич. При нажатии Ctrl + J (Command + J) откроется список команд.
Когда вы впервые создаете рабочее пространство, ваше имя в аккаунте не отображается. Чтобы установить его, используйте выпадающее меню «Действия» рядом с вашим пользователем в таблице.
После этого вы можете добавить других пользователей в команду. Обратите внимание, что сейчас платформа не имеет интеграции с почтовым сервером, поэтому при создании пользователя вам будет однократно показан его пароль, который вам необходимо будет передать пользователю по защищенным каналам связи. По этой же причине пользователь не сможет самостоятельно сбросить пароль. Вы, как администратор, сможете получить новый пароль и таким же образом передать ему. Если Вы, как единственный администратор, забыли свой собственный пароль, то пишите на . # Управление продуктами Как только все необходимые пользователи и разработчики будут добавлены в рабочее пространство, вы можете перейти на вкладку «Продукты». Как вы уже знаете, в ИФ Методе нет концепции доски, как в Канбане, вместо этого используются продукты. Обычно одна команда работает над одним продуктом, который включает в себя одну или несколько кодовых баз.
Вкладка «Продукты» состоит из двух основных элементов. Первый — это выбор продукта. В отличие от Jira, где на главном экране есть выбор доски, в ИФ Методе этот выбор скрыт в настройках, поскольку большинство пользователей практически никогда не используют его — они обычно работают над своим продуктом и не нуждаются в постоянном переключении на другие. Второй элемент — это лист продуктов. Здесь вы можете переименовать продукт и добавлять или удалять пользователей и разработчиков из продуктов. В данный момент мы рекомендуем не удалять разработчиков из продукта, так как эта функция еще в разработке. Однако добавлять их можно без ограничений. Любой пользователь или разработчик может быть добавлен в любое количество продуктов. Вы также можете создавать неограниченное количество продуктов. # Управление функциями продукта Если вы предпочитаете русскоязычный интерфейс, переключиться можно во вкладке Interface.
Нажав Сtrl + J, вы откроете меню команд и сможете выбрать «Добавить функцию». Затем появится собственно экран функции, пока пустой.
Создание функции заключается в добавлении ее имени и определении базовой, первой итерации. Мы рекомендуем оставить название "Основа" для начальной итерации каждой функции.
Обратите внимание, что каждая итерация функции, включая базовую, должна иметь лидера итерации. На этом экране лидер итерации обозначен золотой звездочкой рядом с именем разработчика. Лидера итерации можно менять в любое время по мере необходимости.
Вот как выглядит экран активных итераций после создания функции. Вы видите, что итерация появляется в обоих очередях разработчиков, но только у лидера итерации есть индикаторы стадии и иконка технического урона в виде красного сердца. Это указывает на то, что лидер итерации полностью отвечает за разработку функции и отчетность перед внешними стейкхолдерами, в то время как остальные разработчики отчитываются непосредственно перед лидером итерации. Когда вы наводите на карточку итерации, синим цветом подсвечиваются все карточки одной и тоже итерации, что дает вам знать обо всех разработчиках, занятых в этой итерации. ### Карта продукта
Экраны активных итераций и карты продукта можно легко переключать между собой с помощью иконки в нижнем левом углу экрана. Карта продукта отображает все функции, которые когда-либо были созданы в рамках выбранного продукта. При клике на функцию вы попадаете на тот же экран функции, который доступен с экрана активных итераций. Этот экран функции, доступный с обеих главных экранов, позволяет добавлять последующие итерации к функции. Сейчас мы добавим новую итерацию под названием «Apple Pay» к функции P2P Payments.
Вторая итерация будет назначена Данилу Чернышеву и Владимиру Набокову, при этом Данил будет лидером итерации. Также необходимо будет назначить ответственных за оставшиеся стадии, которые в этом рабочем пространстве включают QA и финальную стадию «Готово для пользователей».
Поскольку мы создали функцию из карты продукта, мы остались на этом экране. Как видите, карточка P2P Payments теперь имеет римскую цифру «II» и зеленый индикатор, показывающий, что у этой функции есть активная итерация. Давайте вернемся на экран активных итераций, используя кнопку в нижнем левом углу экрана.
Как видите, Данил является лидером итерации для второй итерации функции P2P Payments.
Только карточка лида итерации имеет индикаторы статуса стадий. В этом рабочем пространстве три стадии: «Разработка», «QA» и «Готово для пользователей». Статус каждой стадии может быть одним из четырех: пустой (работа не начата), в процессе (мигающий зеленый), блокировано (желтый) и выполнено (немигающий зеленый). Этот подход дает гораздо большую детализацию по сравнению с типичной Канбан-доской. Например, давайте взглянем на этот скриншот.
Это означает, что стадия разработки была завершена, в то время как QA и «Готово для пользователей» были заблокированы, отменены или не завершены. Поскольку техническая ошибка (красное сердце) не была добавлена, скорее всего, причиной этого являются внешние факторы. Вот еще один пример ниже.
Это означает, что стадия разработки завершена (сплошной зеленый), QA находится в процессе (мигающий зеленый), а проверка стадии «Готово для пользователей» еще не была начата. Если у вас есть вопросы, отправьте нам письмо на , и мы поможем. Теперь перейдем к последнему разделу, где мы объясним, как управлять техническими проблемами с помощью ИФ Метода. # Управление техническим уроном Технический урон — это новый термин, который был создан и в настоящее время используется исключительно в ИФ Методе. Он включает в себя все, что мешает пользовательскому и инженерному опыту. Это включает в себя дефекты, нечитаемый или запутанный код, чрезмерную сложность, сломанные шаблоны програмированния, неправильные конфигурации, проблемы с инфраструктурой. В сущности, это все, что мешает команде быстро и устойчиво разрабатывать высококачественное ПО, не создавая дополнительного технического урона. Процесс учета технического урона в ИФ Методе отличается от того, к чему вы могли бы привыкнуть с Канбан-доской. Обычно вы создаете тикет о баге и помещаете его в текущий спринт или бэклог, чтобы кто-то взял его позже. Однако в ИФ Методе весь технический урон должен быть зарегистрирован в конкретной итерации функции, где они изначально возникли. Это означает, что разработчику сначала необходимо провести исследование, чтобы определить, когда и где был допущен дефект. Эта связь позволяет всем участникам процесса разработки видеть, сколько технического урона накопила конкретная итерация функции. Теперь посмотрим на интерфейс и добавим технический урон. Допустим, Данил Чернышев закончил разработку итерации функции «Apple Pay», которую мы подтвердили на предыдущем экране, и Владимир начал процесс QA. Он обнаружил несколько багов и хочет добавить их в итерацию, чтобы Данил мог их исправить.
На скриншоте выше видно, что первая стадия, Разработка, завершена (сплошной зеленый), в то время как QA не прошла (сплошной желтый). Теперь Владимир, ответственный за QA, нажимает кнопку с красным сердечком, чтобы открыть сторону технического урона.
Чтобы вернуться назад, нужно снова нажать на кнопку с сердцем, но так как мы хотим добавить технический урон, мы нажимаем вместо этого «Создать тех. урон», и открывается текстовое окно.
На данный момент мы можем вводить только текст (скриншоты и видео планируются в будущем).
Здесь можно добавить новый технический урон, пометить его как устраненный, а если есть несколько активных единиц урона, можно использовать кнопки со стрелками, чтобы перемещаться между ними. Существует способ увидеть весь технический урон итерации сразу. Если мы вернем карточку на «светлую сторону» и кликнем по ней, чтобы открыть экран функции, мы увидим черный сектор под названием «Технический урон». Клик по этому сектору отобразит полный список технического урона. На данный момент ИФ Метод поддерживает только добавление и завершение технических повреждений; нет возможности их удалять или добавлять прямо из экрана функции, но это будет добавлено в функционал платформы в будущем.
Карточка итерации также изменится. Вместо красного сердца появится иконка гаечного ключа с цифрой, отображающей количество активных технических повреждений.
Что делать, если дефект найден в итерации функции, которая уже была полностью завершена? Как только разработчик подтверждает источник технического урона, он меняет статус всех стадий этой итерации, включая разработку, на желтый, что означает, что эти стадии необходимо пройти повторно. Например, если Данил находит дефект, который был допущен в первой итерации P2P Payments, уже отправленной в прод, он меняет все стадии на желтый. Итерация затем снова появляется на экране активных итераций и по умолчанию отображается в очередях тех разработчиков, которые участвовали в ее разработке, чтобы они могли ее исправить. Не является обязательным — но рекомендуется — чтобы разработчики исправляли технический урон, который они сами нанесли. Также можно назначить другого разработчика и сделать его ведущим этой итерации для решения проблемы. Другой сценарий возникает, когда вы только начали использовать ИФ Метод, и функция еще не создана, но нужно зарегистрировать технический урон для этой функции. В этом случае можно просто создать пустую функцию и зарегистрировать технический ущерб в ее первой итерации ("Основа").