Разработка ПО - подходы и фреймворки
Структура и методология сегодня являются одними из наиболее часто используемых терминов в индустрии разработки программного обеспечения. Однако, несмотря на некоторые существенные различия между ними, многие специалисты по разработке программного обеспечения используют эти термины как синонимы. Итак, прежде чем мы перейдем к описанию наиболее популярных подходов к разработке программного обеспечения, давайте изучим важные различия между методологией разработки программного обеспечения и средой разработки программного обеспечения.
Что такое методология разработки программного обеспечения?
Методология — это документированный набор соглашений, которым следует ваша команда для систематического решения проблем разработки программного обеспечения. Это набор принципов, инструментов, практик и заранее определенных правил разработки программного обеспечения, которые можно использовать для управления вашими процессами последовательным, последовательным, подотчетным и повторяемым образом. Методология — это комбинация двух ключевых вещей: методов, которые вы выбрали для достижения своих целей разработки программного обеспечения, и логики, лежащей в основе этих методов. Методологии являются строгими и предусматривают четко определенные шаги, которые необходимо предпринять, в том числе, почему и как эти шаги должны быть выполнены.
Что такое фреймворк разработки программного обеспечения?
Фрейворк разработки программного обеспечения предоставляет структурированный подход к решению проблем, на основе которого вы можете построить процесс разработки программного обеспечения. Он обеспечивает логическую структуру для классификации и организации сложной работы и структурных компонентов, необходимых для реализации модели, оставляя при этом место для включения других практик и инструментов. Хотя некоторые структуры являются жесткими, подавляющее большинство из них очень снисходительны на протяжении всего жизненного цикла разработки программного обеспечения. Они предоставляют много возможностей для творчества и могут быть легко адаптированы для решения конкретной задачи.
Короче говоря, методология предлагает строгий, систематический подход к решению проблемы, тогда как структура обеспечивает скелетную структуру, вокруг которой вы можете построить процесс разработки программного обеспечения.
Agile
Agile (она же - гибкая методология разработки программного обеспечения) — это больше, чем просто методология, структура или набор практик. Это сложный итеративный подход к управлению проектами и разработке программного обеспечения, который представляет собой целый комплекс структур и практик, основанных на ценностях и принципах, выраженных в Манифесте гибкой разработки программного обеспечения и лежащих в его основе Двенадцати принципах гибкого программного обеспечения.
Гибкий подход помогает командам разработчиков программного обеспечения сосредоточиться на выполнении работы небольшими, но ощутимыми шагами, достигаемыми посредством постоянной оценки требований, планов и результатов. Это обеспечивает большую гибкость в реагировании на изменения по сравнению с традиционными подходами, такими как «Водопад», который заранее планирует каждую мелочь. Такая гибкость помогает вашей команде найти своевременное решение каждой возникающей проблемы и определить правильные действия с учетом вашего конкретного контекста.
Еще одна важная вещь, которая отличает Agile от других подходов, — это ориентация на эффективное сотрудничество между самоорганизующимися межфункциональными командами внутри вашего проекта. Это означает, что члены вашей проектной команды не обязательно должны иметь определенные роли, а скорее должны обладать необходимым набором навыков. Это также означает, что члены вашей команды имеют возможность самостоятельно выяснить, как они собираются решать определенную проблему.
Agile — это методология разработки программного обеспечения, основанная на идее итеративной разработки. В отличие от подхода «Водопад», который является линейным и последовательным, Agile основан на выполнении работы небольшими шагами. Это позволяет команде разрабатывать продукт быстрее, с большей гибкостью и меньшим количеством проблем с качеством, которые остаются незамеченными.
Термин «гибкая разработка программного обеспечения» существует с 2001 года, когда его придумали 17 инженеров, искавших более эффективный способ создания программного обеспечения. Методология Agile основана на 12 принципах, определенных в Манифесте Agile, и 4 ключевых ценностях:
- Люди и взаимодействия имеют большее значение, чем процессы и инструменты.
- Функциональное программное обеспечение важнее обширной документации.
- Сотрудничество с клиентами заслуживает большего внимания, чем переговоры по контракту.
- Agile — это скорее реагирование на изменения, чем следование плану.
В первые дни своего существования, 20 лет назад, принципы и ценности Agile были в основном применимы к индустрии разработки программного обеспечения. Однако с тех пор все больше отраслей и предприятий осознали преимущества итеративной разработки. Вот почему инженерия, здравоохранение, маркетинг и даже военные проекты теперь используют одни и те же принципы для достижения более высокой адаптируемости, скорости разработки и качества продукции.
Цикл разработки по agile
Согласно методологии Agile жизненный цикл разработки программного обеспечения делится на шесть этапов:
- Этап концепции, на котором владелец продукта определяет масштаб проекта, его продолжительность и стоимость, а также приоритет данного конкретного проекта по отношению к другим текущим проектам.
- Начальный этап, на котором владелец продукта собирает команду с учетом ее наличия и соответствующего опыта. На этом этапе команда может приступить к разработке продукта.
- Этап итерации, на котором разработчики работают вместе с дизайнерами, чтобы убедиться, что все элементы и функции дизайна присутствуют в продукте. Этот этап также известен как этап строительства и обычно является самым продолжительным этапом в SDLC.
- Этап выпуска, на котором команда готовится выпустить продукт на рынок после тщательного периода тестирования и при необходимости вносит изменения в код.
- Этап сопровождения, на котором продукт доступен для всех и не требуется никаких серьезных итераций. Команда может решать проблемы с продуктом, обновлять существующие функции и добавлять новые функции по мере необходимости.
- Стадия вывода из эксплуатации, на которой завершается жизненный цикл текущего продукта и команда прекращает его поддержку. Это может произойти из-за того, что продукт больше не нужен или из-за альтернативного продукта, который заменит старый.
Самые популярные Agile-методологии
«Гибкая разработка программного обеспечения» — это общий термин, объединяющий несколько методов и методологий. Некоторые из них более известны, чем другие, но именно эти методологии наиболее широко используются в современной разработке программного обеспечения:
- Скрам (Scrum)
- Канбан
- Бережливая разработка программного обеспечения (Lean Software Development (LSD))
- Функционально-ориентированная разработка (Feature Driven Development (FDD))
- Адаптивная разработка программного обеспечения (Adaptive Software Development (ASD))
- Динамический метод разработки программного обеспечения (Dynamic Systems Development Method)
- Экстремальное программирование (eXtreme Programming (XP))
Здесь важно помнить, что выбор методологии проекта не высечен на камне. Может существовать более одной методологии, принципы которой соответствуют тем, которые вы используете. Существует бесчисленное множество команд, которые успешно сочетают аспекты двух или более Agile-методологий в своих интересах, и при внимательном подходе каждый может сделать то же самое.
Преимущества Agile-методологии
- Сосредоточьтесь на качестве
Методология Agile фокусируется на двух важных аспектах качества: восприятии клиентов и ценности для бизнеса. Объединив эти две вещи и используя их в качестве ориентира на каждом этапе проекта разработки, Agile-команда может достичь более высокого качества продукта. - Лучшая адаптируемость
Спринтерский характер жизненного цикла гибкой разработки программного обеспечения означает, что команда может вносить изменения в продукт именно тогда, когда это необходимо. Команда будет собирать обратную связь не после завершения проекта, а пока он активно работает, и внедрять изменения исходя из того, что действительно нужно клиентам. - Своевременная доставка
Одним из принципов Agile-подхода является разделение процесса разработки ПО на спринты длительностью от 1 до 4 недель. Зная точно, как долго продлится следующий спринт и что он, как ожидается, добавит в продукт, вы сможете более точно спланировать график тестирования или выпуска. - Предсказуемые затраты
Поскольку процесс разработки программного продукта по методологии Agile разбит на спринты, а стоимость каждого спринта обсуждается до его начала, клиент имеет четкое представление об общей стоимости проекта. Более того, клиент может принимать более обоснованные решения, когда дело доходит до масштабирования проекта или добавления новых функций, исходя из предполагаемого бюджета. - Снижение рисков
Жизненный цикл гибкой разработки программного обеспечения дает вам возможность протестировать ваш программный продукт несколько раз, пока он еще находится в разработке, а не тестировать только после того, как продукт будет завершен. В результате потенциальные проблемы обнаруживаются и решаются на ранней стадии, а риски, связанные с качеством продукта, уменьшаются. - Участие заинтересованных сторон
Согласно методологии Agile, заинтересованные стороны или клиенты команды разработчиков не являются какими-то внешними наблюдателями, которые существуют для того, чтобы рассказать, какой проект им нужен, а затем просто собрать готовый продукт. Заинтересованные стороны активно участвуют в каждом этапе проекта и могут четко донести свое видение до команды, что приводит к меньшему количеству случаев, когда команде приходится начинать все сначала или вносить существенные изменения в продукт.
Роли в Agile-команде
Есть два признака настоящей Agile-команды: она небольшая (до 10 человек) и у каждого члена команды есть четко определённая роль. Вот самые важные роли в каждом Agile-проекте:
- Стейкхолдер (заинтересованное лицо) — человек, не принимающий активного участия в процессе разработки, но заинтересованный в успешном исходе проекта. Заинтересованной стороной может быть кто угодно — от конечного пользователя до инвестора проекта.
- Владелец продукта (product owner) — человек, который курирует разработку продукта, его удобство использования и технические характеристики.
- Менеджер проекта (project manager) — в Scrum-проекте его также можно назвать Scrum Master; направляет рабочий процесс и выступает посредником между командой и клиентом.
- Архитектор ПО (software architect) и/или системный аналитик (system analyst) — высококвалифицированный специалист, который создает архитектуру программного продукта и следит за тем, чтобы он обладал всеми необходимыми функциями.
- Разработчик ПО (software developer) — человек или подгруппа, которые непосредственно занимаются разработкой продукта и пишут код согласно требованиям проекта и выбранным технологиям.
- Инженер по обеспечению качества (QA engineer) — тестировщик программного обеспечения или группа тестировщиков, ответственных за тщательную проверку каждой итерации программного продукта на наличие ошибок, узких мест, проблем с производительностью и лазеек в безопасности.
- UI/UX-дизайнер — человек или подгруппа, которые занимаются визуальной привлекательностью продукта и следят за тем, чтобы его интерфейс был привлекательным и простым в навигации для конечного пользователя.
- Бизнес-аналитик (business analyst) — специалист, который анализирует рынок и ценность продукта, гарантируя, что он имеет конкурентное преимущество и может приносить прибыль после его выпуска.
Часто из-за специфики проекта или небольшого размера команды в Agile-команде представлены не все роли. В других случаях один член команды может отвечать за несколько ролей — конечно, если такая многозадачность не мешает прогрессу проекта.