7️⃣ мировых методологий управления в разработке ПО

Не для кого не секрет, что в мире разработки программного обеспечения существуют понятные, четкие и структурно описанные процессы, которые сформировались за многолетний опыт разных IT команд и были описаны в единые стандарты - их называют методологиями.

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

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

Выбирая модель сотрудничества с IT-компанией, Заказчику стоит обратить внимание на то, какие возможности открывает тот или иной тип контракта.

Среди наиболее популярных моделей оплаты контракта на сегодняшний день:

• Time & Materials (оплача за фактически отработанные часы);
• Fixed Price (фиксированная цена).

В чем разница? - давайте уйдем пока в сторону, от вопроса самих методологий разработки и разберемся сначала с обеими моделями сотрудничества...

💵 Модель «Fixed Price»

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

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

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

Для каких проектов подойдет модель «Fixed Price»

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

Ключевые особенности работы по «Fixed Price»:

• фиксированный бюджет;
• фиксированный объем работ;
• фиксированные временные рамки;
• отсутствие возможности внести изменения или дополнения после подписания контракта;
• более высокие рейты на разработку;
• возможные компромиссы относительно качества продукта.

⏱️ Модель «Time & Materials»

Пусть вас не смущает слово «Время» в модели сотрудничества «Time & Materials» — это не означает, что вы просто оплачиваете время разработчиков. Контракт по T&M предполагает оплату по факту выполнения работ.

Если совсем подробно, вот как это работает:

1. Проект разбивается на задачи, каждую из которых команда оценивает отдельно, так что у вас есть возможность вносить любые дополнения в ходе работ;
2. Проектная группа оценивает первую задачу и предоставляет вам данные — сколько человеко-часов необходимо для ее реализации;
3. Умножаем человеко-часы на рейт(ы) разработчика(ов) и получаем стоимость задачи. Если вы согласны — приступаем;
4. Когда задача выполнена и вам предоставлен видимый результат — вы оплачиваете работу команды (оплата может происходить сразу после спринта, ежемесячно, раз в квартал и т.д. — как вам удобно)

Сотрудничая по модели «Time & Material», компания заинтересована в том, чтобы предоставить вам качественный результат за оптимальное время — это, в свою очередь, гарантирует дальнейшее успешное сотрудничество.

К недостаткам модели T&M можно отнести необходимость дополнительной коммуникации с компанией, хотя это может стать преимуществом — обсуждая детали, вы всегда понимаете на какой стадии находится ваш проект, куда он двигается и можете вносить улучшения или изменения прямо в ходе работ.

Еще несколько преимуществ модели «Time & Materials»:

• это гибкая модель оплаты, которая отлично совместима с принципами Agile;
• возможность быстро приступить к разработке — в отличие от Fixed Price, сотрудничая по T&M можно приступить к работе буквально сразу;
• прозрачные часовые ставки разработчиков позволяют заказчику контролировать задачи, сроки реализации и бюджет;
• возможность посмотреть результат работы на каждом этапе;
• Вы получаете решение, которое соответствует вашим ожиданиям.

А сейчас можно рассмотреть все методологии отдельно и расписать по ним плюсы и минусы каждого подхода.... Погнали ⤵️

1️⃣ Методология «Waterfall»

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

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

• системного анализа;
• анализа требований;
• проектирования;
• реализации;
• тестирования;
• внедрения и дальнейшего сопровождения.

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

➕ Плюсы

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

➖ Минусы

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

2️⃣ Методология «Agile»

Методология Agile — это популярный подход, в котором основное внимание уделяется гибкости, сотрудничеству и оптимизации процессов для реализации качественного проекта. Это итеративный подход, и приоритет в нем отдается обратной связи от владельца продукта и адаптации к изменяющимся требованиям.

Цикл разработки ПО по Agile-методологии можно разбить на 5️⃣ этапов:

• планирование;
• проектирование;
• разработка;
• тестирование;
• развертывание и обслуживание

Также стоит учесть 4️⃣ главных постулата Agile подхода:

• Agile — философия гибкого управления проектами и семейство методологий на её основе.
• Методология Agile предполагает, что команда проекта быстро адаптируется к изменениям в работе и новым вводным. Например, к новым требованиям заказчика или изменениям на рынке.
• В семейство Agile входит несколько методологий гибкого управления проектами. В России чаще всего используют Kanban и Scrum.
• Гибкие методологии лучше всего подходят для проектов, при работе над которыми требуется быстро реагировать на изменения и совершенствовать продукт в ходе его создания. В случаях, когда задачи проекта важно решать последовательно и строго по первоначальному плану, Agile не подойдёт.

На сегодняшний день существует около 10-12 разновидностей Agile подходов при разработке IT-продуктов... По базовым из них давайте пройдемся ⤵️

a) «SCRUM»

Обычно один спринт длится 2–4 недели. В конце каждого спринта команда поставляет готовую часть продукта — его «неидеальную» версию, которой уже можно пользоваться, — или дополнительные функции к ней. При этом в начале проекта нет представления о том, как будет выглядеть продукт в самом конце: требования могут меняться в ходе разработки.

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

1) Команда, или developers, — люди, которые создают продукт. Простыми словами — разработчики. Состав команды формируют отдельно для каждого проекта.

2) Скрам-мастер — менеджер, который направляет команду и решает проблемы, замедляющие рабочий процесс. Его задача — организовать работу так, чтобы каждый участник команды понимал потребности клиента и мог предлагать свои идеи. Также скрам-мастер организует общение клиента и команды на совместных мероприятиях.

3) Владелец продукта, или product owner, — человек, который отвечает за ценность продукта и за бэклог. Обычно это представитель заказчика. Он передаёт команде новые требования к продукту и следит, чтобы команда работала в нужном направлении.

3) Бэклог — список задач проекта, расположенных по приоритетности.

4) Scrum-митинг (дэйли или стендап) — ежедневный сбор команды примерно на 15 минут. За это время каждый участник команды отвечает на три вопроса:

• что он сделал с прошлой встречи;
• что планирует делать сегодня;
• что этому мешает.

В результате встречи становится понятно, всё ли идёт по плану, что нужно сделать, чтобы преодолеть препятствия.

➕Плюсы

• Легко адаптировать к нестабильным требованиям проекта, подходит для работы в динамичной среде.
• Продукт отвечает потребностям владельца благодаря его участию в проекте.
• Процесс работы становится прозрачным за счет регулярных встреч и видимого прогресса проекта. Это также упрощает общение между участниками.
• Частые тестирование и анализ помогают выявить и устранить ошибки на ранних этапах разработки.

➖ Минусы

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

b) «KANBAN»

Задачи проекта расставляют в виде карточек на доске, разлинованной на колонки. Эти колонки отражают этапы выполнения проекта. Участник команды берёт задачу, перемещает карточку по доске от одной колонки к другой, и вся команда видит актуальный статус этой задачи.

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

Обычно на канбан-досках минимум три колонки: «Выполнить», «В работе» и «Выполнено». Чаще всего к ним добавляют колонки для промежуточных этапов: «Бэклог», «На согласовании», «Тестирование» и так далее.

Традиционно канбан-доски представляли собой физические доски — например, магнитные или пробковые, — на которых крепили бумажные карточки. Позже появились онлайн-доски. Самые популярные из них — Trello, Jira, Asana.

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

Вместо этого работа над проектом организована как непрерывный поток задач. Когда участник команды заканчивает одну задачу, он идёт за другой, потом за следующей и так далее.

c) «LEAN»

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

Если убрать задачи и действия, не приносящие реальной пользы, члены команды достигают оптимальной эффективности. В данном случае к «ненужному» можно отнести дополнительные функции, избыточный код, неэффективные процессы и излишнюю бюрократию. Проект делится на небольшие задачи, которые можно закончить быстро. Это сокращает время работы и упрощает обратную связь.

➕Плюсы

• Бережливая разработка направлена на устранение лишних деталей и оптимизацию процессов. Это помогает повысить эффективность и снизить затраты ресурсов.
• Гарантирует, что результат работы соответствует потребностям и предпочтениям владельца продукта. Активный фидбек первых пользователей также повышает качество ПО.
• Бережливая разработка адаптируется к меняющимся требованиям пользователей и условиям рынка.
• Выполнение небольших задач и сдача проекта точно в срок позволяют ускорить запуск и сократить время выхода на рынок.

➖Минусы

• Как и с другими Agile-методологиями, с Lean-разработкой могут возникнуть проблемы с управлением нагрузкой, если нет строгого требования по объему работы.
• От владельца продукта потребуются регулярные правки и обратная связь, а это может оказаться сложной задачей.
• В очень больших проектах могут возникнуть трудности с полной реализацией принципов Lean-разработки.
• Подход основан на минимальном документировании, это может не подойти для отраслей или проектов, требующих подробной документации.

d) «EXTREME PROGRAMMING» (XP)

Экстремальное программирование — это тоже методология на базе Agile.
Для нее характерны: командная работа, общение и быстрый фидбек. XP считается одной из самых радикальных форм Agile и сильно отличается от других подходов.

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

➕Плюсы

• Проекты с использованием XP короткие — обычно они длятся всего несколько месяцев. Это связано с тем, что каждый этап сдается быстро.
• Подход обеспечивает предсказуемый и прозрачный процесс разработки.
• Команда работает сообща для достижения поставленных целей в сжатые сроки. Это позволяет наладить совместную работу и быстро адаптироваться к изменению требований.
• Большое внимание уделяется тестированию, экспертной оценке и проверке качества кода, что снижает риск ошибок.

➖Минусы

• Самое главное в экстремальном программировании — этап разработки (создание кода), он может перетянуть на себя все внимание. Из-за этого нередко страдает дизайн.
• Требует большого упорства, творческого подхода и нестандартного мышления, чтобы привести программу в соответствие с потребностями пользователей.
• Предполагается, что в начале проекта у владельца продукта нет четкого представления о результате.

e) «RAPID APPLICATION DEVELOPMENT» (RAD)

Быстрая разработка приложений — это итеративная методология, при использовании которой важно разработать продукт быстро и, если необходимо, создать несколько прототипов. Метод Rapid Application Development (RAD) основан на обратной связи от пользователей и совместной работе всех членов команды, что позволяет ускорить выполнение проекта и избежать проблем после запуска.

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

Еще есть метод разработки динамических систем (DSDM), основанный на принципах RAD. Методология ориентирована на быстрое и эффективное создание продуктов. Во многом она похожа на SCRUM и XP, поэтому мы не станем описывать ее подробно.

Вернемся к RAD. Ниже приведена блок-схема, показывающая, как применяется быстрая разработка приложений:

➕Плюсы

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

➖Минусы

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

f) «FEATURE DRIVEN DEVELOPMENT» (FDD)

Функционально-ориентированная разработка (Feature Driven Development) — это гибкая методология, также основанная на принципах Agile.
Она направлена на создание небольших функций или функциональных блоков. FDD — итеративная и инкрементальная (пошаговая) методология, и ее цель — быстро получить ощутимые результаты.

Есть 5 основных этапов разработки в рамках FDD:

• создание общей модели;
• формирование списка функций;
• планирование по функциям;
• дизайн по функциям;
• разработка по функциям

FDD предусматривает отчетность на всех этапах для отслеживания прогресса и фиксирования результатов. Обычно методология используется в крупномасштабных проектах. Работает FDD примерно следующим образом👇🏻

➕Плюсы

• Используя FDD, процесс разработки можно легко подстроить под требования владельца продукта. Методология позволяет быстро реагировать при изменении приоритетов.
• Функционально-ориентированная разработка делает упор на быстрое создание основных функций.
• Включает эффективные методы управления проектами, например, использование ограниченных по времени циклов разработки. Это позволяет обеспечить достижение поставленных целей.

➖Минусы

• Не очень хорошо подходит для небольших проектов и для проектов, в которых работает только один разработчик.
• В меньшей степени, чем другие Agile-подходы, ориентирована на непосредственное участие владельца продукта.
• Большая ответственность ложится на плечи главного программиста, который должен одновременно выполнять функции координатора, ведущего дизайнера и наставника для новых членов команды.