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

Scrum, Extreme Programming и другие модели Agile

На практике методология Agile может использоваться в нескольких интерпретациях. В проектах для заказчиков EPAM наиболее часто применяет:

 

• Scrum
• Extreme Programming
• Lean Software Development (LSD)
• Dynamic Systems Development Method (DSDM)
• Open Unified Process (OpenUP)
• Agile Project Management (APM)
• Microsoft Solutions Framework для Agile (MSF)

Обеспечить высокое качество при  реализации проектов и при этом уложиться  в сжатые сроки нам помогает:

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

Для контроля над распределением ресурсов и работой ИТ-команды используется информационная система EPAM Project Management Center. По мнению ряда экспертов, это одно из лучших решений в мире для поддержки методологий гибкой разработки программного обеспечения, в частности, Scrum.

 

Методология Scrum

 

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

Спринт — итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в резерве проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенном в резерв проекта.

В методологии Scrum всего три роли.

• Scrum Master
• Product Owner
• Team

Скрам Мастер (Scrum Master)

Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.

Основные обязанности Скрам Мастера таковы:

• Создает атмосферу доверия,
• Участвует в митингах в качестве фасилитатора
• Устраняет препятствия
• Делает проблемы и открытые вопросы видимыми
• Отвечает за соблюдение практик и процесса в команде

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.

ScrumMaster может также помогать Product Owner создавать Backlog для команды

Product Owner

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

Обязанности Product Owner таковы:

• Отвечает за формирование product vision
• Управляет ROI
• Управляет ожиданиями заказчиков и всех заинтересованных лиц
• Координирует и приоритизирует Product backlog
• Предоставляет понятные и тестируемые требования команде
• Взаимодействует с командой и заказчиком
• Отвечает за приемку кода в конце каждой итерации

Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда (Team)

В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.

Обязанности команды таковы:

• Отвечает за оценку элементов баклога
• Принимает решение по дизайну и имплементации
• Разрабатывает софт и предоставляет его заказчику
• Отслеживает собственный прогресс (вместе со Скрам Мастером).
• Отвечает за результат перед Product Owner

Размер  команды ограничивается размером группы людей, способных эффективно взаимодействовать  лицом к лицу. Типичные размер команды - 7 плюс минус 2.

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

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

Методология Extreme Programming – Экстремальное программирование

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

Цели XP

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

 

Принципы XP

Основными принципами являются:

1. Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.
2. Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.
3. Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.
4. Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
5. Достаточная степень смелости и желание идти на риск.

 

 

 

 

 

 

 

 

 

 

 

 

 

Вывод

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

 

1. http://www.kport.info/money/finlikbez/index.php?ELEMENT_ID=11485
2. http://ru.wikipedia.org/wiki/Гибкая_методология_разработки
3. http://www.epam-group.ru/strengths/methodology/agile.html
4. http://cmcons.com/articles/obshhie_stati_rup/rup_i_drugie_metodologii_razrabotki_po
5. http://www.digital-soft.ru/methodology.php