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

метки: Разработка, Методология, Модель, Заказчик, Команда, Изменение, Работа, Проект

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

Гибкие (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.

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

Разработка технологии процесса управления ООО Виктория

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

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

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

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

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

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 – Разделение рисков между заказчиком и командой

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