28. Преимущества и область применения гибких методологий

Преимущества применения Agile

• частые релизы — требования не успевают устаревать, частью функционала уже можно пользоваться;

• фиксированная длина итераций — можно предсказывать скорость работы команды с учетом рисков;

• команда сама оценивает задачи — оценки реалистичны, команда мотивирована выполнить свои обязательства;

• команда самоуправляемая — 10 голов учтут больше чем одна очень умная;

• в конце каждой итерации процесс работы оценивается и вносятся улучшения;

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

Область применения Agile

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

Agile может негативно сказаться на эффективности:

• в проектах, которые являются инфраструктурными и имеют очень сложный процесс поддержки;

• в проектах, где подтверждение технического задания требует очень длительного формального цикла;

• если нет обратной связи с конечным пользователем системы или нет возможности у команды провести экспертизу в предметной области;

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

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

• Agile Modeling

• Agile Unified Process

• Agile Data Method

• DSDM

• Essential Unified Process (EssUP).

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

• Feature driven development

• Getting Real

• OpenUP

• Scrum

• Бережливая разработка программного обеспечения (англ. lean software development) использует подходы из концепции бережливого производства.

29. Экстремальное программирование: понятие, базис xp

Экстремальное программирование (англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения.

Основная идея ХР — устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов* и реляционных баз данных. Таким образом ХР - это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и весьма приятный способ разработки программного обеспечения, предусматривающий низкий уровень риска.

Базис ХР образуют перечисленные ниже двенадцать методов могут быть объединены в четыре группы:

• короткий цикл обратной связи;

• непрерывный, а не пакетный процесс;

• понимание, разделяемое всеми;

• социальная защищенность программиста.

Методы XP-процесса:

1. Игра планирования (Planning game) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок.

2. Частая смена версий (Small releases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

3. Метафора (Metaphor) — вся разработка проводится на основе том, как работает вся система.

4. Простое проектирование (Simple design) — проектирование выполняется настолько просто, насколько это возможно в данный момент.

5. Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций.

6. Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.

7. Парное программирование (Pair programming) — весь код пишется двумя программистами, работающими на одном компьютере.

8. Коллективное владение кодом (Collective ownership) — разработчик может улучшать в любое время любой код системы.

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

10. 40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.

11. Локальный заказчик (On-site customer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.

12. Стандарты кодирования (Coding standards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.