Файл: Гибкая модель разработки программного обеспечения Agile.pdf

Введение

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

Специфика проектов по разработке программных продуктов заключается в том, что результат разработки нематериален – это коллективные ментальные модели, записанные на языке программирования. Это приводит к тому, что большая часть проектов разработки программного обеспечения (ПО) завершается со срывами сроков, перерасходом бюджета, а часть проектов не завершается в принципе. Вышесказанное подтверждают исследования Standish Group, которые показали, что только 35 % проектов завершились в срок. Одной из главных задач, напрямую влияющих на эффективность разработки ПО, является выбор модели процесса разработки.

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

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

Целью курсовой работы является изучение гибкой модели разработки программного обеспечения Agile. На основе поставленной цели будут решены следующие задачи:

- рассмотрены теоретические основы гибкой модели разработки программного обеспечения Agile;

- проанализированы плюсы и минусы гибкой модели разработки программного обеспечения Agile;

- на примере методологии scrum рассмотрены решения по управлению Agile проектами.

Предмет курсовой работы – методы разработки ПО, объект – Agile.

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

Глава 1 Теоретические основы гибкой методологии разработки Agile

Понятие гибкой методологии разработки Agile

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

---

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

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

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

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

---

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

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

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

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

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

Принципы Agile изменяют представление о том, как надо разрабатывать программное обеспечение. Трансформируется сама парадигма^[3]: фокус смещается с ориентированности на процесс как на последовательность заранее продуманных руководством шагов на ориентированность на проектную команду, как на группу людей, способных самоорганизоваться и решать все проблемы самостоятельно. Это изменение носит совсем не формальный характер: оно требует от членов проектных команд совершить переворот в собственном сознании, отказаться от ориентированности на административно-командные методы управления и попытаться сформировать совершенно новые для них методы решения проблем.

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

---

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

Внедрение коллаборативного мышления требует особого мужества в организации, управляемой традиционными административными методами. Все менеджеры достигли своего положения благодаря тому, что знают, что такое личная ответственность и способны принимать правильные решения в одиночестве. Как теперь перебороть представление о том, что такое хорошо и что такое плохо и начать внедрять “демократию” в отдельно взятом проекте? Зачастую решения о внедрении Agile принимаются чисто административными методами – находится отсветственный, ему поручается команда. Стараясь быть эффективным, менеджер щедро раздает пинки и тычки, кровью выбивая из команды “мотивированность” на успех. Такая тактика не принесет ничего, кроме разочарования. Команда не умеет принимать решения самостоятельно – а значит и не несет за решение ответственность.

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

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

---

• 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. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

---