Skip to content
Микешин Сергей edited this page Dec 17, 2020 · 19 revisions

Назначение и способы применения методологий RUP, Agile, XP, Scrum в разработке программных средств

Выполнил Микешин Сергей, ИДБ-17-05

Проверила Торхова Анастасия, ИДБ-17-05

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

Адаптивные (гибкие) методологии нацелены на преодоление ожидаемой неполноты требований и их постоянного изменения.

Рассмотрим некоторые из них.

RUP

Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

Основные характеристики:

  1. Разработка требований. Для описания требований в RUP используются прецеденты использования (use cases). Каждый прецедент использования – это описание сценариев взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. Все функциональные требования должны быть представлены в виде прецедентов использования.

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

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

none

В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline):

  • Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.
  • Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.
  • Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.
  • Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.
  • Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
  • Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.
  • Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (Change requests).
  • Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.
  • Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

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

Agile

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. К гибким методологиям относят экстремальное программирование, DSDM, Scrum, FDD, BDD и др.

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

Практически все аgile-команды сконцентрированы в одном офисе (bullpen). Офис включает product owner – заказчика, который и определяет требования к продукту. В качестве заказчика может выступать бизнес-аналитик, менеджер проекта или клиент. Кроме того, в офис могут входить и дизайнеры интерфейса, тестировщики, технические писатели. То есть методы Agile направлены в первую очередь на непосредственное общение.

Методы Agile были разработаны еще в начале 2000-х как альтернатива малоэффективным традиционным IT методам. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.

Основные идеи:

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

Принципы Agile:

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

Главные преимущества Agile:

  • Качество web-продукта – вовлечение заказчика в процесс каждой итерации дает возможность корректировать процесс, что неизменно повышает качество.
  • Высокая скорость разработки – итерация длится не более 3-х недель, к концу этого срока обязательно есть результат.
  • Минимизация рисков – крупный проект дает возможность заказчику оплатить несколько итераций и в ходе работы понять, что он вовремя получит именно то, что хочет и за приемлемую цену. Водопадные модели (с применением спецификаций и технических заданий) таких возможностей не дают.

XP

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

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

Основными принципы XP:

  1. Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) являются начальной информацией, на основании которой создается модуль. ПИ пишутся самими пользователями, которые в XP являются частью команды.
  2. Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком.
  3. Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков).
  4. Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
  5. Достаточная степень смелости и желание идти на риск.

Обычно XP характеризуют набором из 12 приемов (практик), которые могут быть объединены в четыре группы:

1. Короткий цикл обратной связи (Fine-scale feedback)

  • Разработка через тестирование (Test-driven development)
  • Игра в планирование (Planning game) — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming) — предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.

2. Непрерывный, а не пакетный процесс

  • Непрерывная интеграция (Continuous integration) — интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
  • Рефакторинг (Design improvement, Refactoring) — подразумевается, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.
  • Частые небольшие релизы (Small releases) — версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени.

3. Понимание, разделяемое всеми

  • Простота (Simple design) — в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Проектирование должно выполняться небольшими этапами. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи.
  • Метафора системы (System metaphor) — разработчикам необходимо проводить анализ архитектуры программного обеспечения для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.
  • Коллективное владение кодом (Collective code ownership) – означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.
  • Стандарт кодирования (Coding standard or Coding conventions) — необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек.

4. Социальная защищённость программиста (Programmer welfare)

  • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

none

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

Scrum

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

Роли, которые участвуют в процессе:

  1. Scrum Мастер (Scrum Master)
  2. Владелец продукта (Product Owner)
  3. Команда (Team)

Scrum Мастер – самая важная роль в методологии. Scrum Мастер отвечает за успех Scrum в проекте. Эту роль в проекте играет менеджер проекта или лидер команды (Team Leader). Scrum Мастер отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. Scrum Мастер может также помогать заказчику создавать список задач для команды.

Основные обязанности Scrum Мастера:

  • создает атмосферу доверия;
  • участвует в митингах в качестве фасилитатора – человека, обеспечивающего успешную групповую коммуникацию;
  • устраняет препятствия;
  • делает проблемы и открытые вопросы видимыми;
  • отвечает за соблюдение практик и процесса в команде.

Владелец продукта (Product Owner) – это человек, отвечающий за разработку продукта. Обычно представитель заказчика для заказной разработки. Владелец продукта – это единая точка принятия окончательных решений для команды в проекте, поэтому это всегда один человек, а не группа.

Команда (Team) – в методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Владельцем продукта. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Команда в Scrum кроссфункциональна: в нее входят люди с различными навыками – разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды.

none

В основе лежат короткие ежедневные встречи – Scrum и циклические 30-дневные встречи, называемые спринтом. Результатом спринта является готовый продукт, который можно передавать заказчику. Короткие спринты обеспечивают быструю обратную связь проектной команды с заказчиком. Заказчик получает возможность гибко управлять системой, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в список имеющихся на данный момент бизнес-требований и технических требований к системе (Product Backlog), приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий спринт. В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Цель спринта должна быть фиксированной. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте.

Ссылки на источники:

https://portal.tpu.ru/SHARED/i/IGSAVENKO/academic/Tab/Tab3/trpo_lections_230100_2014.pdf

https://qaevolution.ru/metodologiya-menedzhment/xp/

https://worksection.com/blog/agile.html#:~:text=%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F%20Agile.-,%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D1%8C%20%D0%B4%D1%80%D0%B0%D0%BA%D0%BE%D0%BD%D0%BE%D0%B2%20%D0%B8%D0%BB%D0%B8%20%D0%B2%D1%81%D0%B5%D1%85%20%D0%B3%D0%B8%D0%B1%D0%BA%D0%B8%D1%85%20%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B9,%C2%BB%2C%20%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D1%89%D0%B5%D0%B3%D0%BE%20%D0%B8%D0%B7%2012%20%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF%D0%BE%D0%B2.

Clone this wiki locally