12 методологий разработки ПО


Содержание

Гибкая методология разработки (Agile)

Описание гибкой методологии разработки

Гибкая методология разработки (от англ. — Agile software development) — манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework — каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как «гибкая методология разработки» не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют — фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. — Guide to the Business Process Management Common Body Of Knowledge]. Agile — Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

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

За счет того, что разработка программного обеспечения с применением гибкой методологии определяет серии коротких циклов (итераций), с длительностью 2-3 недели, достигается минимизация рисков т.к. по завершению каждой итерации Заказчик принимает результаты и выдает новые или корректирующие требования т.е. контролирует разработку и может на неё сразу влиять. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. Обычно одной итерации не достаточно для выпуска полноценного программного продукта, но при этом по окончании каждого этапа разработки должен появляться «осязаемый» продукт или часть функционала, которую можно посмотреть, потестировать и выдать дополнительные или корректирующие меры. На основе проделанной работы, после каждого этапа, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки программного обеспечения.

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

История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с «методом водопада» («waterfall»), т.к. на момент выхода манифеста, именно «метод водопада» являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:

  • Adaptive software development (ASD)
  • Crystal Clear
  • Dynamic Systems Development Method (DSDM)
  • Extreme Programming (XP)
  • Feature driven development (FDD)
  • Pragmatic Programming
  • Scrum

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

Agile-манифест разработки программного обеспечения:

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

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

  • Люди и взаимодействие важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

  1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
  2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
  3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
  4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
  5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
  6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
  7. Работающий продукт — основной показатель прогресса.
  8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
  9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
  10. Простота — искусство минимизации лишней работы — крайне необходима.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Критика Agile

Agile плохо описывает процессы управления требованиями, можно сказать, что такое понятие просто отсутствует т.к. гибкая методология разработки не подразумевает под собой долгосрочного планирования (планирование осуществляется на краткосрочную перспективу), как следствие пропущен шаг формирования плана развития продукта или другими словами дорожной карты продукта. Т.к. планирование краткосрочное (на ближайшую итерацию разработки), а Заказчик по окончанию каждой итерации принимает продукт и выставляет новые требования, сам продукт может поменяться в корни, а выставляемые новые требования зачастую противоречат структуре и архитектуре продукта уже поставляемого клиентам. По большому счету, в случае, если Заказчик не до конца понимает, что хочет увидеть в итоге (конечный продукт), а понимание приходит во время разработки (это случается в 90% случаев), процесс разработки превращается в формализованную и легализованную бюрократию т.е. продукт дорабатывается бесконечно, пока не кончаются деньги, или заказчик не переключается на другой продукт. Справедливости ради, необходимо заметить, что Заказчик знает на что идет и сам решает, платить за разработку продукта или нет, по большому счету команда разработчиков просто выполняет требования заказчика. Однако, реально, в работе это приводит к хаосу, срыву сроков и авралам, что порождает новые требования, которые меняют не в лучшую сторону продукт. Более того, снижается качество разрабатываемого продукта, т.к. Agile определяет подход к разработке, в рамках которого необходимо быстро тушить пожары, наиболее простым и быстрым способом. Код пишется не соблюдая требований платформы, на которой разрабатывается продукт, появляется множество обходных решений и дефектов, а такая конструкция не очень устойчива и не безопасна, растет негодование клиентов от частых сбоев в работе программного обеспечения. Бизнес на выходе получает потери, падает качество планирования.

Некоторые эксперты Agile ассоциируют больше с подходом по совершенствованию уже готового продукта, нежели разработки нового. Сторонников много у гибкой методологии разработки, ровно, как и противников. Последние в свое время даже выпустили Anti Agile Manifesto. Далее в ознакомительных целях, мы приводим содержание двух, наиболее популярных манифестов, противоречащих основному манифесу Agile:

Anti-Agile манифест (необходимо отметить, что данный anti-agile манифест на самом деле противоречит не самому Agile, а скорее одному из фреймворков, основанном на принципах Agile — Scrum т.к. в манифести используются термины именно из этого фреймворка):

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

  • эпики (epics) — это просто проекты
  • пользовательские истории (user stories) — это просто сценарии использования (use case)
  • спринты (sprints) — это просто работа
  • стенд апы (stand-ups) — это просто совещания
  • итерации (iterations) — это просто версии
  • бэклоги (backlogs) — это просто список дел
  • скорость команды (velocity) — это просто результаты
  • и эти задачи (tasks) — это реально, просто задачи

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

Разновидность методологий гибкой разработки

На основании ценностей и принципов, определенных в Agile Manifesto были сформированы следующие гибкие методологии разработки:

  • Agile Modeling (AM) — данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
  • Agile Unified Process (AUP) — унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
  • Agile Data Method (ADM) — набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
  • Dynamic Systems Development Method (DSDM) — итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений — Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
  • Essential Unified Process (EssUP) — подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
  • Extreme programming (XP) — идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
  • Feature driven development (FDD) — основное ограничение, которое накладывается в рамках данного подхода, это «каждая функция должна быть реализована не более, чем за две недели». Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
  • Getting Real (GR) — в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
  • OpenUP (OUP) — данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
  • lean software development — данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
  • Scrum — один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

Сравнение процессов разработки программного обеспечения по методологиям PMBOK и Agile

Рубрика: Информационные технологии

Дата публикации: 25.04.2020 2020-04-25

Статья просмотрена: 866 раз

Библиографическое описание:

Ревенко В. Г., Джабраилов Ш. В. Сравнение процессов разработки программного обеспечения по методологиям PMBOK и Agile // Молодой ученый. — 2020. — №17. — С. 33-37. — URL https://moluch.ru/archive/203/49684/ (дата обращения: 13.11.2020).

Цель данной статьи — сравнить общий набор процессов управления проектами, как это определено в своде знаний Management Body of Knowledge (PMBOK) и в методологиях гибкой разработки Agile. PMBOK разработан и сконструирован вокруг пяти групп процессов управления (инициирование, планирование, выполнение, контроль и завершение) и девяти области знаний (управление, интеграция, управление знаниями, управление временем, управление качеством, затратами, персоналом, рисками, закупками). Методологии гибкой разработки и управления проектами основаны на следующих принципах: принимать изменения, сосредотачиваться на ценности клиента, предоставлять клиенту функционал после каждой итерации, обучение и самоорганизация команды.

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

Ключевые слова: управление проектами, риски проектов, методологии разработки PMBOK, методологии Agile, Scrum.

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

В результате большое число ИТ-проектов оканчиваются неудачей: примерно 95 % проектов имеют перерасход различных средств в среднем 60–160 %, а превышение сроков в среднем 30–200 %; более 30 % проектов прекращаются, не достигнув завершения. Использование методологий управления проектами позволяет более сбалансировано управлять жизнью ИТ-проекта, что существенно повышению шанс достижения ожидаемых результатов. [1]

Гибкие методологии пытаются преодолеть эти препятствия, изменив подход, используемый для разработки программного обеспечения и управления проектами. Кроме того, гибкая разработка позволяет пользователю продукта менять требования и выпускать части программного обеспечения с рабочим функционалом. Манифест для разработки Agile software был выпущен в феврале 2001 года и состоял из 17 программных процессов и методологии управления. С тех пор ряд методов разработки программного обеспечения стали использовать этот подход. Стали развиваться такие подходы: Extreme Programming (XP), Scrum, Feature-Driven Development (FDD), Adaptive Software Development (ASD) и другие.

Такие методы в основном создавались внутри корпораций экспертами по программным процессам в качестве попыток улучшить существующие процессы компании. Например, XP был создан Kent Beck во время работы над Chrysler Comprehensive проект расчета заработной платы и системы вознаграждений персонала. Результаты его работы были опубликованы в его книге «Extreme Programming Explained» [2].


С другой стороны, более традиционные методы управления проектами зависят от жизненного цикла разработки программного обеспечения: линейное развитие или водопад. Наряду с предсказуемостью они унаследовали детерминистский подход, основанный на разбивке задач. Свод знаний по управлению проектами (PMBOK) разработанный Институтом управления, является лучшим представителем этого подхода [3]. PMBOK формально состоит из 44 проектных процесса, описывающих деятельность на протяжении всего жизненного цикла проекта. Эти 44 процесса организованы в двух осях: пять групп процессов и девять областей знаний, которые будут кратко описаны далее.

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

Институт управления проектами

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

  1. Управление интеграцией проектов описывает процессы и действия, которые объединяют различные аспекты управления проектами.
  2. Управление проектом включает в себя процессы, которые отвечают за управление областью проекта.
  3. Управление временем проекта описывает процессы, связанные со своевременным завершением проекта.
  4. Управление стоимостью проекта, включается в себя процессы, касающиеся стоимости.
  5. Управление качеством проекта описывает процессы, связанные с обеспечением того, чтобы проект удовлетворял целям, для которых он был выполнен.
  6. Управление человеческими ресурсами проекта включает в себя все необходимые процессы для организации и управления командой проекта.
  7. Управление коммуникацией проекта описывает процессы, связанные с механизмами связи проекта, сбору, распространению, хранению и утилизации информации о проекте.
  8. Управление рисками проекта описывает процессы, связанные с управлением рисками.
  9. Управление закупками включает все процессы, связанные с приобретением продуктов и услуг, необходимых для завершения проекта.

Agile управление проектом

Целью манифеста Agile Software Development было «выявить лучшие способы разработки программного обеспечения, сделав это и помогать другим делать это». Принципы, на которых он основан, заключаются в следующем:

‒ Индивидуальное взаимодействие над процессами и инструментами.

‒ Рабочее программное обеспечение с полной документацией.

‒ Сотрудничество с клиентами и заключение контрактов.

‒ Реагирование на изменение в соответствии с планом.

Очевидно, манифест не является ориентированным на процессный подход. Как представлено во введении, существует много методов разработки программного обеспечения, которые можно назвать «гибкими». Однако в этой работе выбраны только некоторые из них в качестве наиболее представительных. Среди методов разработки были: Extreme Programming (XP), Scrum и Feature-Driven Development (FDD).

А. Extreme Programming

Экстремальное программирование или XP — это гибкий метод, который появился в проекте в Chrysler Corporation в конце 1990-х годов. Он был разработан Уордом Каннингемом, Кент Бек и Рон Джеффрис. Метод XP основан на четырех значениях:

‒ Связь, основанная на таких практиках, как модульное тестирование, парное программирование, оценка задачи.

Цукерберг рекомендует:  Заря импортозамещения

‒ Простота, всегда стремиться к простейшему решению.

‒ Обратная связь. Иметь конкретные знание о текуoем состоянии системы.

‒ Уметь, признавать недостатки в системе и предпринимать корректирующие действия.

Scrum подход для разработки новых продуктов, который был впервые представлен Takeuchi и Nonaka [4] после наблюдения за небольшими высокопроизводительными командами в разных компаниях. Scrum — это гибкий процесс разработки программного обеспечения, в котором проекты продвигаются через серию месячных итераций, называемых спринт.

Кроме того, серия спринтов в среднем от 6 до 9 может производить выпуск работающего продукта.

В начале проекта его требования заносятся в специальный список известный как Product backlog. Затем, в начале каждого спринта происходит совещание по планированию спринта, в ходе которого владелец продукта определяет приоритетные задачи. В течение каждого дня спринта проводятся ежедневные встречи для обсуждения вопросов проекта. Такие ежедневные собрания помогают значительно развитию команды и коммуникации. В конце спринта команда представляет функциональный продукт на обзор.

В. Feature Driven Development (FDD)

Feature Driven Development (FDD) — это итеративный и инкрементный процесс разработки программного обеспечения. Методология FDD состоит из пяти этапов:

‒ Разработка общей модели.

‒ Создание списка функций.

‒ План по предметной области.

‒ Дизайн по набору функций.

‒ Создание по принципу.

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

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

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

Четвертым шагом является «Дизайн по набору функций». Цель этого шага — создать дизайн каждого набора функций. Модель проектирование включает в себя диаграммы последовательности UML.

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

Сравнение PMBOK и Agile методов

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

‒ PMBOK является исчерпывающим перечнем передовой практики в форме процессов, которые могу быть адаптированы к конкретным потребностям

‒ PMBOK хорошо известен и официально документирован по сравнение с представленным в этой работе гибкими методами. Результат этого сравнения представлен в таблице 1.

Сравнение методологий PMBOK иAgile

Методологии тестирования ПО. Какую выбрать?

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

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

Каскадная модель (Линейная последовательная модель жизненного цикла ПО)

Каскадная модель (Waterfall Model) является одной из наиболее старых моделей, которую можно применять не только для разработки или тестирования ПО, но также практически для любого другого проекта. Его базовым принципом является последовательный порядок выполнения задач. Это значит, что мы можем переходить к следующему шагу разработки или тестирования только после того, как предыдущий был успешно завершен. Эта модель подходит для небольших проектов и применима только в том случае, если все требования точно определены. Главными достоинствами этой методологии являются экономическая эффективность, простота использования и управления документацией.

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

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

Узнайте больше о каскадной модели из предыдущей статьи .

V-Model (Модель верификации и валидации)

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


Схема данной модели показывает принцип разделения задач на две части. Те, которые относятся к дизайну и разработке, размещены слева. Задачи, относящиеся к тестированию ПО, размещены справа:

Основные этапы этой методологии могут изменяться, однако обычно они включают следующие:

  • Этап определения требований. Приемочное тестирование относится к этому этапу. Его основная задача состоит в оценке готовности системы к финальному использованию
  • Этап, на котором происходит высокоуровневое проектирование, или High-Level Design (HDL). Этот этап относится к системному тестированию и включает оценку соблюдения требований к интегрированным системам
  • Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного тестирования, во время которой происходит проверка взаимодействий между различными компонентами системы
  • После этапа написания кода начинается другой важный шаг — юнит-тестирование. Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО корректно и соответствует требованиям

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

Инкрементная модель

Данная методология может быть описана, как мультикаскадная модель тестирования ПО. Рабочий процесс разделяется на некоторое количество циклов, каждый из которых также делится на модули. Каждая итерация добавляет определенный функционал к ПО. Инкремент состоит из трех циклов:

  1. дизайн и разработка
  2. тестирование
  3. реализация.

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

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

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

Спиральная модель

Спиральная модель это методология тестирования ПО, которая основана на инкрементном подходе и прототипировании. Она состоит из четырех этапов:

  1. Планирование
  2. Анализ рисков
  3. Разработка
  4. Оценка

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

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

Читайте подробнее o спиральной модели в предыдущем блог посте .

Agile

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

Узнайте больше об Agile (прим. — статья на английском языке) .

Экстремальное программирование (XP, Extreme Programming)

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

Главными достоинствами такой методологии являются постоянное тестирование и короткие релизы, что помогает обеспечить высокое качество кода.

Scrum

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

  • Участие в Scrum планировании
  • Поддержка в юнит-тестировании
  • Тестирование пользовательских историй
  • Сотрудничество с заказчиком и владельцем продукта для определения критериев приемлемости
  • Предоставление автоматического тестировании

Более того, участники QA-отдела должны присутствовать на всех ежедневных собраниях, как и другие члены команды, чтобы обсудить, что было протестировано и сделано вчера, что будет протестировано сегодня, а также общий прогресс тестирования.

В то же время принципы Agile методологии в Scrum к появлению специфических особенностей:

  • Оценка усилий, необходимых для каждой пользовательской истории является обязательной
  • Тестировщик должен быть внимательным к требованиям, поскольку они могут постоянно изменяться
  • Риск регрессии возрастает вместе с частыми изменениями в коде
  • Одновременность планирования и выполнения тестов
  • Недопонимание между членами команды в случае если требования заказчика не до конца ясны

Узнайте больше о методологии Scrum из предыдущей статьи .

Заключение

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

Если вам нужна помощь с разработкой программного обеспечения или тестированием, выделенная команда разработчиков и QA инженеров готова к работе.

Какие методологии разработки применяются в различных IT-компаниях — Tproger собирает рассказы представителей индустрии

Наш подписчик задал вопрос:

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

Мы передали его на рассмотрение нашим экспертам, а теперь делимся с вами полученными ответами.

Михаил Игонин , ведущий инженер, Дирекция по разработке программного обеспечения, «ПЕТЕР-СЕРВИС»

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

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

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

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

Василий Кораблев , директор практики бизнес-архитектуры в AT Consulting

Как компания мы очень адаптивны, поэтому на каждом проекте используем оптимальные методологии. Для «коробочных» внедрений, где есть отработанные схемы, это обычно референтные (эталонные) подходы, учитывающие специфику конкретного решения, например, Oracle AIM.


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

Процесс вывода продукта на рынок и его непрерывного совершенствования традиционно основан на цикле непрерывного совершенствования качества Деминга (циклическое повторение этапов Plan-Do-Check-Act), ускоренного Scrum, дизайн-мышления и других современных техниках.

Николай Добровольский , вице-президент Parallels

В разных проектах у нас используются различные подходы – где-то Agile с одно-двухнедельными спринтами, а где-то — почти что Waterfall с майлстоунами по несколько месяцев. За многие годы работы у нас сложилось ощущение, что чем больше проект и команда, работающая над ним, тем сложнее и менее эффективно стараться запихнуть разработку в agile-процесс. Да и не всегда это нужно.

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

Михаил Вайсман , CEO Trinity Digital

Мы работаем с гибкими методологиями разработки (Agile). После постановки задачи проводим аналитику, создаем дизайн мобильного приложения. Далее разработка — ведется по двух-трехнедельным спринтам. В рамках спринта решаются задачи по разработке, дизайну, проводится тестирование. И, наконец, релиз! После релиза мы оказываем услуги по поддержке приложения и по продвижению, а также начинаем работу над новым функционалом и новыми версиями.

Дмитрий Коробченко , инженер в области машинного обучения NVidia

В компании NVIDIA представлен широкий спектр разнообразных активностей, касающихся разработки и исследований. Методология может варьироваться в зависимости от направления деятельности, команды или проекта. Однако большинство проектов по софтверной разработке подразумевает использование Agile и Continuous Integration.

Владислав Никитин , технический директор компании Itransition

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

  1. Выбор правильной методологии ведения проекта. Это могут быть различные варианты гибкой разработки, водопадная модель или же их комбинации. А учитывая, что заказчик хочет иметь возможность внесения изменений на всех этапах разработки и как можно раньше получать работоспособные версии систем, в том числе и масштаба Enterprise, все большую популярность приобретает подход Scaled Agile.
  1. Привлечение бизнес-аналитиков на всех этапах разработки для выяснения, спецификации, уточнения и, что важно, верификации требований. Это позволяет минимизировать риск искажения или неверной интерпретации требований на всем протяжении процесса разработки.
  1. Использование «унифицированной среды разработки» — совокупности специально подобранных и проинтегрированных между собой инструментов, необходимых для создания ПО (управление задачами, контроль версий, сервер непрерывной сборки, статические анализаторы кода для различных языков и т.д.), а также корпоративных практик и стандартов, которыми мы руководствуемся при разработке.
  1. Разделение тестирования и разработки — на всех наших проектах тестирование производится силами независимой команды, что позволяет предоставить нашим клиентам максимально объективную оценку качества системы.

Также мы активно используем автоматизацию тестирования и практики DevOps.

Евгений Арнаутов , исследователь в Департаменте машинного обучения Центра инноваций SAP

У нас в SAP на этапе постановки задачи все более широко используется методология Design thinking. На этапе создания продукта часто можно видеть варианты Agile, причем иногда совмещенные с Waterfall-подходом.

Андрей Моруга , директор управления программами компании Virtuozzo

На этот вопрос сложно ответить коротко — но чтобы дать хоть какое-то представление, давайте рассмотрим роли, которые существуют в нашей компании Virtuozzo и вовлечены в процесс разработки.

Все начинается с менеджера продукта и менеджера программ — эти две роли, часто объединённые в одном человеке, отвечают за вопросы «какие проблемы решает наш продукт, для каких пользователей и как он это делает». Менеджер программ, по сути, отвечает за ежедневную коммуникацию и представление точки зрения пользователя в команде разработчиков, а также за создание спецификаций на продукт и его компонентов. Рабочие инструменты менеджера программ — система документооборота (например, confluence), системы change management, bug tracking вроде Jira, средства телекоммуникаций (как webex), средства прототипирования и создания «скетчей» интерфейсов, средства для сбора информации о существующих версиях продукта и о том, как его используют живые пользователи. Менеджер программ также выступает заказчиком для следующей роли — дизайнера.

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

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

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

Тестировщики и QA — это люди, которые ответственны за тестирование продукта (ручное или автоматическое) и за внедрение и выполнение методик, повышающих качество продукта, за отмашку «продукт готов к релизу».

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

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

Сравнительный анализ методологий разработки программного обеспечения Текст научной статьи по специальности « Организация и управление»

Аннотация научной статьи по организации и управлению, автор научной работы — Геркушенко Георгий Геннадьевич, Ткаченко Александр Владимирович

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

Похожие темы научных работ по организации и управлению , автор научной работы — Геркушенко Георгий Геннадьевич, Ткаченко Александр Владимирович,

Текст научной работы на тему «Сравнительный анализ методологий разработки программного обеспечения»

Сравнительный анализ методологий разработки программного обеспечения Геркушенко Г. Г.1, Ткаченко А. В.2

1Геркушенко Георгий Геннадьевич / Gerkushenko Оеог%у Оеппа^еу1ек — кандидат технических

2Ткаченко Александр Владимирович / Тка^епко А1ек$ап& У1аШш1гоу(Л — студент

кафедра системы автоматизированного проектирования и поискового конструирования, факультет электроники и вычислительной техники, Волгоградский государственный технический университет, г. Волгоград

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

Цукерберг рекомендует:  Ruby три must-read книги, по мнению разработчиков

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

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

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

Название Автор Предметная область

Методология PMI Международный некоммерческий институт управления проектами Не привязана к предметной области


Методология IPMA Международная ассоциация управления проектами Не привязана к предметной области

Методология PRINCE2 Центральное компьютерное и телекоммуникационное агентство Великобритании В настоящий момент не привязана к предметной области (исходно ориентирована на ИТ-проекты)

Методология MSF Корпорация Майкрософт Ориентирована на разработку ПО

Методология RUP Корпорация Rational Software Ориентирована на разработку ПО

Группа методологий Agile Альянс agile (глобальная некоммерческая организация) Ориентированы на разработку ПО

Набор моделей CMMI Университет Карнеги-Мелона Ориентированы на разработку ПО

Методология ASAP Корпорация SAP AG Ориентированы на разработку ПО

Разберем более подробно некоторые из них.

1. Методология PMI, сформулированная в виде стандарта PMBoK [3], базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBoK отражает существенную коррекцию методологии в сторону интерактивных методик.

Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK фиксирует части Свода знаний по управлению проектами, который обычно считается хорошей практикой.

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

• Группы процессов согласно PMBOK:

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

• Группа процессов планирования. Процессы, требуемые для определения общего содержания проекта, уточнения целей и определения последовательности действий, требуемых для достижения целей проекта.

• Группа процессов исполнения. Процессы, применяемые для выполнения работ, определенных в плане управления проектом, для удовлетворения спецификаций проекта.

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

• Группа процессов завершения. Процессы, выполняемые для завершения всех действий в рамках всех групп процессов и формального завершения проекта или фазы.

Области знаний PMBOK:

2. PRojects IN Controlled Environments 2 (PRINCE2) [1] представляет собой структурированный метод управления проектами, одобренный правительством Великобритании в качестве стандарта управления проектами в социальной сфере. Методология PRINCE2 включает в себя подходы к менеджменту, контролю и организации проектов.

Методология описывается «сверху — вниз». От абстрактных уровней, к конкретному их наполнению.

Состоит из трех важных компонентов (Планирование, управление изменениями и управление качеством).

Весь процесс состоит из стадий, подстадий и связей.

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

3. Microsoft Solutions Framework (MSF) [2] — методология разработки программного обеспечения, опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

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

Процесс MSF ориентирован на «вехи» (milestones). Вехи — ключевые точки процесса разработки, которые характеризуют достижение какого-либо существенного результата.

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

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

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

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

Модель выделяет семь последовательных этапов проектного управления:

Тестирование и отладка

Эксплуатация и сопровождение

Рис. i. Каскадная модель (waterfall)

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

Рис. 2. Спиральная модель

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

Модель процессов MSF объединяет в себе упорядоченность каскадной модели с гибкостью спиральной.

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

Поскольку выработка единого видения проекта и следование ему настолько важны, MSF выделяет для этих целей отдельную фазу (этап) разработки — «Выработка концепции».

Проявляйте гибкость — будьте готовы к переменам. В противоположность каскадной модели MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управления.

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

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

Поощряйте свободное общение. Исторически многие организации строили свою работу по принципу need-to-know, то есть сведения к минимуму информированности сотрудников.

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

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

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

Не бывает лучшей методологии — выбор зависит от типа проекта и конкретных обстоятельств.

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


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

Для минимизации рисков большого проекта лучше использовать PRINCE2. Данная методология определяет организацию, управление и контроль над исполнением проектов.

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

1. Методология PRINCE 2. [Электронный ресурс]: URL: http://www.12manage.com/m ethods_ccta_prince2_ru.html (дата обращения: 17.02.2020).

2. Обзор Microsoft Solutions Framework (MSF) [Электронный ресурс]: Microsoft Developer Network. URL: msdn.microsoft.com/ru-ru/library/jj161047.aspx (дата обращения: 17.02.2020).

3. Свод знаний по управлению проектами (Руководство PMBOK®). Американский национальный стандарт / Пятый выпуск. — Институт управления проектами, Inc. 2013 — 614 стр.

Как разработать “проект-огонь” с методологией Agile?

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

Что такое Agile?

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

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

Термин впервые употребили в 2001 году в США в штате Юта во время собрания 17 разработчиков, которые обсуждали свои идеи и программные подходы. Совокупность ценностей и принципов, предложенных ими, легла в основу Манифеста гибкой методологии разработки.

Что такое методология Agile в разработке программного обеспечения? 12 принципов Манифеста методологии

Как пользоваться Agile?

Цикл разработки состоит из 6 гибких этапов. Некоторые из них могут протекать параллельно. На словах распределение этапов может показаться непростым, поэтому процесс Agile-разработки визуализируют, используя, например, диаграммы Ганта.

6 этапов Agile-разработки:

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

Что такое гибкая методология разработки?

Инструменты Agile сконцентрированы на гибкости и усовершенствовании. Здесь мы объединили несколько основных преимуществ методологии Agile.

Как это работает? 6 ключевых преимуществ Agile для менеджеров проектов:

  1. Приспособиться к изменениям в ходе реализации проекта с более короткими циклами планирования не составляет труда. Вы всегда можете уточнить и изменить приоритеты по отстающим вопросам. Также позволить команде вносить изменения в проект.
  2. Конечная цель может быть невидимой. Методология Agile может быть полезна для проектов с неопределенными конечными целями.
  3. Высокое качество и быстрые стандарты доставки. Из-за разбивки проекта на итерации, команды могут быть сфокусированы на разработке и тестировании.
  4. Сильное взаимодействие команды. Методология обеспечивает прямое взаимодействие. Люди могут работать вместе и совместно брать на себя ответственность.
  5. Клиенты могут работать в тесном сотрудничестве с командой. Они могут внести свой реальный вклад и оказать воздействие на продукт.
  6. Постоянное улучшение. Проекты на основе метода Agile подразумевают обратную связь от пользователей и членов команды.

5 главных недостатков метода

Гибкость методологии довольно высока, но иногда происходят некоторые заминки. Вот некоторые недостатки гибкого метода программной разработки:

  1. Процесс планирования может быть менее конкретным. Иногда бывает трудно определить конкретную дату поставки. Некоторые элементы, запланированные к реализации, могут не быть завершены в срок. Это происходит потому, что менеджеры часто вносят изменения приоритетов при решении текущих задач.
  2. Команда должна знать все детали и факты. Как правило, команды Agile-проектов небольшие, и их участники должны быть «подкованы» в разных областях.
  3. Время для развития. Успешное Agile-движение происходит тогда, когда команда полностью посвящена проекту.
  4. Команды часто забывают о документации. Лучше всего найти баланс между бумажными вопросами и личными встречами.
  5. Конечный продукт может сильно отличаться от того, что было изначально задумано. Вы можете добавлять новые итерации, поскольку метод подразумевает гибкость.


Основные обязанности менеджера Agile-проектов:

  • Поддержание всех активностей и ценностей в проектной команде.
  • Устранение помех и препятствий.
  • Проведение и модерирование всех совещаний.
  • Обсуждая путей преодоления препятствий.
  • Работа с приоритетами, усиление отстающих вопросов в рамках процессов.
  • Мотивирование. Руководители проектов должны быть основными мотиваторами для своих команд.

Сравнение гибких методологий

Вы можете попробовать разные инструменты управления проектами в рамках Agile-движения. Перечислим некоторые из них:

Список методов Agile:

XP (Extreme Programming)

Extreme Programming представляет собой специфический метод разработки программного обеспечения, который предназначен для повышения оперативности и качества обслуживания для развития потребностей клиентов. Он выступает за частые «выпуски» в коротких циклах разработки.

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

FDD (Feature driven development)

FDD (разработка, управляемая функциональностью) — итеративный и постепенный процесс разработки программного обеспечения, который включает в себя лучшие практики отрасли в единую методологию. Процесс имеет 5 ключевых активностей: разработка базовой модели, построение списка функций, дизайн по функциям, план на основе функций и построение с помощью функций.

ASD (Adaptive system development)

Согласно методу адаптивного развития системы, проекты всегда должны быть в состоянии постоянной адаптации. ASD система состоит из 3 повторяющихся серий: предполагать, сотрудничать и учиться.

Kanban

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

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

Crystal Clear

Crystal Clear – еще один пример методологии Agile. Он чаще всего используется командами из 6- 8 разработчиков. Crystal Clear преимущественно сфокусирован на людях, а не на процессах.

У метода свои сильные стороны: фокусировка, личная безопасность, легкий доступ к опытным пользователям и автоматизированным тестам.

Scrum

Scrum лучше всего отражает функции Agile-управления. Спринты длятся 1-2 недели и позволяют командам поставлять программное обеспечение на регулярной основе.

Scrum-разработка: участники процесса

В управлении проектами с помощью Scrum обязанности распределены между владельцем продукта, Scrum-мастером и командой.

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

5 ресурсов для работы с Agile-проектами

Одна из классических систем для решения задач и управления проектами онлайн. Задачи в JIRA состоят из названия, типа, темы, приоритетности, содержания и компонентов.

Сервис предлагает управленцам множество конфигурации и решений непрофильных задач, таких как управление рисками, автоматизации рекрутинга и др.

HP Agile Manager

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

GanttPRO

Сервис, основанный на использовании онлайн диаграмм Ганта, помогает создавать объемные проектные планы за короткое время и позволяет качественно руководить ими. Менеджеры могут делиться полученными графиками и экспортировать их в отчеты, бизнес-планы и презентации.

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

Basecamp

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

Менеджеры выбирают этот сервис для работы с Agile-проектами за простой и понятный интерфейс, возможность создавать собственные дополнения, доступность для преподавателей и студентов.

Bipulse


Сервис для планирования и управления проектами позволяет предсказывать сроки завершения проекта на основе Agile-метрик, рассчитывать календарное расписание критической цепи, интегрироваться с популярными трекерами задач и многое другое.

Пример работы с проектом в JIRA:

Пример работы с проектом в GanttPRO:

А вы использовали методологию Agile в своей работе?

Что вы можете сказать о результатах вашего проекта?

Получился ли тот самый “огонь”?!

Методология Agile. Матерь драконов или всех гибких методологий

История Agile начинается с публикации в 2001 году «Манифеста гибкой разработки ПО», состоящего из 12 принципов. Конечно, отдельные положения Agile-подхода появились появлялись и до этого, но только этот документ систематизировал и изложил их в достаточной для использования мере. Каждый год под манифестом подписываются новые компании, IT-специалисты и проектные менеджеры. Появляются новые методы и модификации гибкой системы разработки.

Что такое Agile Methodology (гибкая методология)?

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

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

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

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

Методы присутствующие в Agile:

Scrum

Своему термину «Scrum» обязан регби, в котором это слово означает метод командной игры в виде построения трех линий каждым из соперников и попытке захватить мяч. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность каждого участника схватки и четкое понимание цели.

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал кейс внедрения Scrum на основе полученного опыта.

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

Джефф Сазерленд, автор книги «Scrum. Революционный метод управления проектами» выделил 8 шагов по использованию методики:

  1. Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
  2. Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
  3. Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
  4. Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
  5. Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
  6. Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
  7. Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
  8. Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.
Ретроспектива в Agile

В скрам есть 4 ключевых элемента:

  • Product Backlog — список требований по проекту
  • Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
  • Sprint Goal — цель спринта
  • Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте.

eXtreme Programming (XP)

Разработчик методики, Кент Бек, создал метод экстремального программирования, цель которого — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки.

Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

  1. кодирование — согласно единым в команде стандартам оформления;
  2. тестирование — тесты пишутся самими программистами до написания кода, который будут тестировать;

  3. планирование — как финального билда, так и отдельных итераций. Последнее проходит в среднем раз в две недели.
  4. слушание — как разработчиков, так и клиента, в ходе которого исчезают неясности, определяются требования и ценности.

Crystal Methodologies

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.

Crystal-проекты должны соответствовать 3 основным показателям:

  1. быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
  2. совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
  3. «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Dynamic Software Development Method (DSDM)

Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.

Особая роль отводится участия конечного потребителя (пользователя) в процессе разработки. Помимо этого принципа, к базовым относятся:

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

В начале команда изучает реальность разработки приложения и область применения. Дальше работа делится на три взаимосвязанных цикла:

  1. цикл функциональной модели — создание аналитической документации и прототипов.
  2. цикл проектирования и конструирования — приведение системы в рабочее состояние.
  3. цикл реализации — развертывание системы.

Feature Driven Development (FDD)

Методология, которая появилась даже раньше, чем «Манифест гибкой разработки ПО«.

Цукерберг рекомендует:  Asp net - С# для мобильной разработки

Хоть в FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:

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

Feature Driven Development состоит из таких цикличных этапов:

  1. Создание общей модели — видение проекта на основе предварительных данных.
  2. Разработка списка свойств — аналог product backlog в методике скрам.
  3. Планирование по свойствам — оценка сложности свойств каждым членом команды.
  4. По каждому свойству — технический дизайн и реализация — финальная стадия, по окончанию которой свойство уходит в продукт и цикл повторяется.

Lean Software Development

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.

В набор входят следующие 7 принципов:

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

  5. усиление команды — один из принципов «Манифеста. » гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
  6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
  7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Разновидность методологий гибкой разработки

Agile Modeling (AM)

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

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

Agile Unified Process (AUP)

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

  • Ваша команда знает, что делает;
  • Простота превыше всего.
  • Соответствие принципам гибкой методологии разработки.
  • Сфокусированность на ценных для проекта активностях.
  • Независимость в выборе инструментов.
  • Индивидуальная настройка AUP под нужды конкретного проекта.

Agile Data Method (ADM)

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

Суть Agile Data Method определяется шестью положениями:

  1. Данные — основа создания любого приложения.
  2. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
  3. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
  4. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
  5. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
  6. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP)

Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

  • сценарий использования — описание поведения системы.
  • итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
  • командные практики — направленные на сплочение команды и повышение её эффективности.
  • процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Getting Real (GR)

Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.

GR — сборная солянка из десятка инструментов гибкой разработки, которые используются для минимизации:

  • возможностей
  • опций и настроек
  • структуры компании
  • встреч
  • обещаний.

Необычная концепция не получила широкого распространения, хотя отдельные элементы используют другие методики.

OpenUP (OUP)

Независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:

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

Практики реализуются на основе четырех принципов:

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

Agile показатели

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

Для большинства проектов хватит 4 направлений метрик:

  1. Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
  2. Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта;
  3. Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
  4. Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам.

Нет единственно верной или нужной вашему проекту метрики.

Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

Разрушители мифов: Agile

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

Миф № 1: Agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

Миф № 2: Agile против документации.

Гибкая методология разработки не против документации, она против документации как самоцели. А вот при выборе документации как средства коммуникации Agile действительно отдаёт приоритет живому общению.

Миф № 3: Agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

Миф № 4: Agile требует много переделывания (re-work).

В гибкой методологии разработки ПО переделывание проявляется в двух формах: переделывание требований (пользователи понимают, что им действительно нужно) и программного обеспечения (команды разработчиков находят улучшенные способы написать и спроектировать приложение). Но с этим приходится сталкиваться и в других методиках! Более того, для уменьшения негативного влияния rework и нужна итерационная модель, которая является особенностью Agile.

Плюсы и минусы использования Agile

Плюсы:

  1. вовлечение стейкхолдеров — у команды появляется больше возможностей понять желания клиента. А ранняя и частая доставка ПО усиливает доверие стейкхолдеров к проектной команде и еще глубже вовлекает в проект.
  2. ранняя и предсказуемая доставка — модель разработки через итерации (короткие промежутки от 1 до 6 недель) дает гибкость, ускоряет выпуск релиза продукта.
  3. фокусирование на бизнес-ценности — коллаборация с клиентом обеспечивает понимание командой того, как сделать продукт максимально ценным для потребителя.
  4. непрекращающееся улучшение качества — тестирование во время каждой итерации, деление финального билда на отдельные куски рабочего кода позволяют улучшать и справляться с ошибками ПО до выхода финального продукта.

Минусы:

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

Приложения

Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.

Если ваш бизнес относится к маркетинг и рекламным, дизайнерским, seo или digital агентствам , то saas-сервис Worksection можно применить для работы всей команды целиком. Нас рекомендуют COXO Digital, Royal ® Advertising и Prozorro.

Вот пара лайфхаков, чтобы настроить Agile в Worksection:

  1. настройте метки и статусы, которые необходимы для работы именно вашей компании.
    Статусы могут быть такими: в работе, проверка, выполнено, требует доработки, критично, фича, оплатить.
    Метки часто выглядят как: верстка, тестирование, продакшен, концепт, код.
  2. создайте проект-беклог и проект-спринг.
  3. создавайте задачи и предварительные чеклисты, скетчи и прочее в беклоге.
  4. на мит-апах определяйте задачи на спринг и переносите их из беклога в спринт.
  5. используйте гостевой доступ клиентов к задачам, чтобы всегда иметь согласованные и актуальные комментарии по проекту.
  6. отмечайте ответственных в задачах, чтобы каждый коллега знал зону своей ответственности и чувствовал причастность к результату спринта.

Вердикт

С гибкой методологией разработки программного обеспечения небольшие проектные команды добиваются максимальной эффективности. Agile реализуется через другие гибкие методы: Scrum, XP, Lean и т.п.

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

12 методологий разработки ПО

Цель: пассивный доход 100 тыс. руб. в мес.

Также в блоге: изучаем и разрабатываем что-то новое, делимся опытом.

Новый язык программирования, для разработки сайтов и приложений, подробнее.

Sitev.ru
Социальная сеть программистов, дизайнеров, предпринимателей . и обычных пользователей Sitev.ru/post
Блог программиста, аналог Хабра C++ фреймворк
Комплекс кроссплатформенных библиотек для разработки веб, мобайл, десктоп-приложений, игр. Sitev C++ CMS
Быстрая, надежная, масштабируемая CMS для разработки сайтов на C++ полный список задач.

Основные методологий разработки

Разработка ПО (программных продуктов) знает несколько основных методологий разработки.

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых методология разработки. Аж в 1970 году некий Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель». Каскадная модель состоит из следующих фаз:

  1. Определение требований
  2. Проектирование
  3. Реализация (кодирование)
  4. Тестирование
  5. Поддержка

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

2. V-модель (разработка через тестирование)

Основной принцип V-образной модели: детализация проекта возрастает при движении слева направо, с течением времени. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы.

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

3. Итеративная методология разработка

Ройс, который придумал каскадную модель, сам использовал итеративную модель разработки.

Итеративный подход (от английского iteration — повторение) — это выполнение работ одновременно с анализом полученных результатов и корректировкой предыдущих этапов работы. При этом подходе проект проходит повторяющийся цикл PDCA: Планирование — Реализация — Проверка — Корректировка (англ. Plan-Do-Check-Act).

Примером реализации итеративного подхода, например, является методология разработки Rational Unified Process.

4. Инкрементная модель

Инкрементная методология разработки ПО также, как и итеративная методология, основана на цикле PDCA. В чём же отличие между ними? ПО можно вводить в эксплуатацию по частям (а микросхемы, например, нельзя), а значит, разрабатывать и поставлять его заказчику также можно постепенно. На этом основана инкрементная модель. Мы дробим продукт на относительно независимые части, которые разрабатываем и вводим в эксплуатацию по отдельности.

Отличие инкрементной модели от итеративной представлено на рисунке ниже:

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

Примером реализации инкрементальной модели является технология RAD (от английского Rapid Application Development — быстрая разработка приложений).

5. Agile — гибкая методология разработки

Agile — это серия подходов к разработке программного обеспечения, а не единственный подход, и определяется Agile Manifesto.

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

  1. Люди и взаимодействие важнее процессов и инструментов
  2. Работающий продукт важнее исчерпывающей документации
  3. Сотрудничество с заказчиком важнее согласования условий контракта
  4. Готовность к изменениям важнее следования первоначальному плану

Методологии, которые поддерживают идей Agile Manifesto:

Agile Modeling — эффективное моделирование и документирование (не охватывает программирование и тестирование), Agile Unified Process — упрощенная версия Rational Unified Process, DSDM — основан на концепции RAD, представляет собой итеративный и инкрементный подход, придаёт особое значение участию в процессе потребителя, Extreme Programming (XP) — экстремальное программирование, OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения на базе Rational Unified Process, Scrum — акцент на качественном контроле процесса разработки, Бережливая разработка ПО — методология разработки, использующая методы концепции бережливого производства.

На какой методологии разработки ПО остановиться? Думаю каждый должен для себя решить это сам. Например, я для себя решил составить свою собственную методологию, выбрав из каждой наилучшие практики!

ТОП-4 Методологии управления проектами

26 Мар 2015

Как известно, каждый проект – это уникальное мероприятие, не поддающееся стандартизации. Однако процессы управления проектами поддаются стандартизации и документы, которые формализуют эти процессы, получили название методологий управления проектами. Причем некоторые методологии управления проектами применимы для всех типов проектов в разных областях. Другие же, напротив, подходят только для управления конкретными типами проекта. Так, для сферы дорожного строительства наиболее подходящей будет одна проектная методология, в то время как для проекта по разработке программного обеспечения – другая. Рассмотрим ниже наиболее часто применяемые методологии управления проектами.

Традиционная (Каскадная) методология управления проектами

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

  1. Определение требований
  2. Проектирование
  3. Реализация (строительство, производство…)
  4. Внедрение
  5. Тестирование и отладка
  6. Установка
  7. Эксплуатация и сопровождение

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

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

Методология управления проектами PRINCE2

PRINCE2 (Projects in Controlled Environments) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология, которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков). Методология PRINCE2 базируется на семи принципах, семи темах и семи процессах. Принципы являются центральным элементом методологии: если хотя бы один из них не выполняется, то нельзя говорить о том, что проект выполняется в рамках PRINCE2.

  1. Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
  2. Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
  3. Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
  4. Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
  5. Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
  6. Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
  7. Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска

Аспекты представляют собой направления проектного управления, на которые следует обращать внимание в течение длительности всего проекта.

Аспекты методологии управления проектами PRINCE2 :

  1. Обоснование проекта: какую ценность проект принесёт организации?
  2. Организация: каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
  3. Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить
  4. Планы: шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
  5. Риски: каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
  6. Изменение: как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
  7. Прогресс: реализуемость проекта, выполнение планов и дальнейшее развитие проекта

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

PRINCE2 подразумевает следующие процессы управления проектом:

  1. запуск проекта
  2. руководство проектом
  3. инициация проекта
  4. контроль этапов
  5. управление созданием продукта
  6. управление границами этапов
  7. закрытие проекта

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

Гибкая методология управления проектом (Agile Project Management)

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

В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

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

Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.

Методология быстрой разработки приложений (Rapid Application Development — RAD)

Быстрая разработка приложений (RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:

  • Планирование
  • Пользовательское проектирование
  • Быстрое конструирование
  • Переключение

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

Рекомендации:

  • Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды
  • Если вы работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства, выбирайте каскадную модель
  • Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте Agile методологию
  • Используйте методологию быстрой разработки приложений для небольших IT проектов с сжатыми сроками
  • Если вам необходимо минимизировать риски и требуются структурированный подход в исполнении крупного или среднего масштаба проекта, выбирайте PRINCE2
  • Не бойтесь использовать другие, менее популярные методологии, если они в большей степени подходят к вашему проекту

Сравнение методологий разработки ПО?

Рекомендую вам почитать Мартина Фаулера и Кента Бека. У них на эту тему много интересного написано.

Agile — это гибкие методологии в принципе. Остальное (XP, Scrum, Kanban) это уже методологии.
Вас никто не заставляет выбирать что-то одно и жестко этому следовать, на то они и гибкие, чтобы быть гибкими. Можете успешно комбинировать Канбан и ХП. Можете следовать лишь некоторым принципам, которые вас устраивают. Как из конструктора набираете то, что вас устраивает — и работаете.

Единственное на что стоит обращать внимание — это команда разработчиков. Команда должна быть готова к этому. Если этого не будет — методологии вас не спасут. Колхоз дело добровольное и заставить никого не получится.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих