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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  И НАУКИ, МОЛОДЕЖИ И СПОРТА УКРАИНЫ

Донецкий  национальный технический университет

Институт информатики и искусственного интеллекта

 

Д050103.1.01.09/344.ЛР Кафедра Программное обеспечение 
интеллектуальных систем

 

 

 

 

 

 

 

 

 

 

 

РЕФЕРАТ

по дисциплине «Профессиональная практика программной инженерии»

Тема: «Гибкие методологии разработки ПО»

 

 

 

 

Выполнил:  ст. гр. ПОC-О9в

___________Безносов А.ю.

    (дата, подпись)

Проверили:

_________ст.пр. Золотухина О.А.

(дата, подпись)

 

 

 

 

 

 

 

 

 

 

 

 

 

Донецк – 2012

 

Список условных обозначений, сокращений и терминов

 

• Adaptive Software Development (ADS) - Адаптивная разработка программного обеспечения;
• Agile Project Management (APM) – Agile управление проектами;
• Dynamic Systems Development Method (DSDM) – Метод динамическое развитие систем;
• Extreme Programming (XP) – Экстримальное программирование;
• Feature-Driven Development (FDD) – Разработка, управляемая функциональностью ;
• Lean Software Development (LSD) – Бережливая разработка программного обеспечения ;
• Microsoft Solutions Framework для Agile (MSF) – методология разработки программного обеспечения, предложенная корпорацией Microsoft ;
• Open Unified Process (OpenUP) – экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла. 
• Pragmatic Programming (PP) – методология гибкой разработки
• Scrum – методология гибкой разработки

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Когда начинаешь интересоваться какие сейчас популярны методологии программирования, то очень быстро натыкаешься на очень красивое, но не понятное слово Agile

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

что такое Agile и с чем его едят.  

Agile  - это только концептуальный каркас. Своего рода абстрактный класс, от которого вы можете наследовать свой рабочий процесс и выбрать: вы хотите работать по Extreme programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Или по нескольким сразу (SCRUM и Extreme programming прекрасно сочетаются ). Или же у вас непреодолимое желание создать свою методику, но все равно у вас есть шанс быть Agile командой (рис.1). 

 

 

Рис.1  –  Схема методологии  Agile

 

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

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

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

 

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

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

 

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

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

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

В чем суть Аgile и чем хороши эти методологии?

 

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

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

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

Такие методологии имеют  ряд преимуществ, основными из которых  являются:

 

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

 

Рассмотрим эти пункты подробнее:

 

1. Хорошая реакция  на изменения

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

 

 

2. Agile уделяет много внимания качественной обратной связи

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

 

 

Рис.2 – Взаимоотношение  заказчик-разработчик

 

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

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

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

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

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

 

3. Agile обеспечивают предсказуемость

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

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

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

Например, если мы имеем следующие  исходные данные: 
Объем работ = 1000 единиц, 
Производительность команды = 50 единиц за итерацию, 
Цена итерации (сумма ставок каждого из ее членов) = 100$. 
То в итоге мы получаем: (1000/50)*100=2000$. 
Это означает, что изменение объема работ на 50 пунктов влечет за собой изменение стоимости конечного продукта на 100 у.е.

 

 

Рис.3 – Команда разработчиков

 

4. Agile позволяют использовать самоорганизацию для мотивации команды

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

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

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

 

5. Agile подразумевают разделение рисков между заказчиком и командой

Сейчас наиболее распространёнными  видами взаимодействия с заказчиком является заключение контрактов с фиксированной  ценой (fixed-price контракты) или контрактов «Время и материалы» (time & material).

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

Вторая схема контракта – time & material, суть которого в том, что заказчик оплачивает фактическую работу.

 

 

Рис.4 –  Разделение рисков между заказчиком и командой

 

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