Макеев А. А. AGILE – ГИБКИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Друк

УДК: 004.057.5+004.053

 

AGILE – ГИБКИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Макеев А. А.

Национальный технический университет Украины «Киевский политехнический институт», Киев, Украина

 

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

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

 

Макєєв О. О. Agile – гнучка методологія розробки програмного забезпечення / Національний технічний університет України «Київський політехнічний інститут», Київ, Україна

Висвітлюються основні питання концепції гнучкої методології розробки програмного забезпечення, а саме: проблеми організації процесу розробки ПЗ, основні принципи методології, застосування практик, заснованих на методології, основні проблеми переходу на дану методологію.

Ключові слова: гнучка методологія, програмне забезпечення, керування проектом

 

Makieiev O. O. Agile – flexible software development methodology / The National Technical University of Ukraine “Kyiv Polytechnic Institute”, Kyiv, Ukraine

The article highlights the concept of agile software development as a philosophy and a methodology; namely, organizing the software development process, the methodology’s key points, the use of methodology-based practices, major issues and benefits around agile transition.

Key words: agile methodology, software, project management

 

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

Среди общераспространенных проблем процесса разработки программного обеспечения встречаются следующие:

1. Изменение требований непосредственно в процессе разработки.

2. Нечеткое распределение ответственности за выполняемую работу и ее результат.

3. Наличие непрерывного потока мелких, «быстрых», наваливающихся требований, отвлекающих разработчиков и менеджеров от основного направления работ.

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

Для решения задачи успешной организации процесса разработки ПО была создана гибкая методология разработки ПО.

Гибкая методология разработки (англ. Agile software development) – это набор принципов и правил, в рамках которого осуществляется разработка ПО.

Методология Agile – это семейство процессов разработки, а не единственный подход к разработке программного обеспечения. Ценности и принципы Agile методологии закреплены в документе ‘Agile Manifesto’. Agile не включает конкретных практик, а определяет ценности и принципы, которыми руководствуются успешные команды.

Agile Manifesto разработан и принят 11–13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах штата Юта, США. Манифест подписали представители следующих методологий:

• Extreme programming

• Scrum

• DSDM

• Adaptive Software Development

• Crystal Clear

• Feature-Driven Development

• Pragmatic Programming

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

ние, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недоста-

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

Основным результатом работы по agile-методологии является работающий программный продукт. Расценивая именно работающий программный продукт в качестве единственного показателя работы команды проекта за конечный период времени, создатели концепции agile сформулировали следующие ценности и принципы методологии. Ценности Agile-методологии:

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

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

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

• реакция на изменения важнее, чем следование плану.

Принципы Agile-методологии:

• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;

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

• частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);

• тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

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

• рекомендуемый метод передачи информации – личный разговор (лицом к лицу);

• работающее ПО – лучший измеритель прогресса;

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

• постоянное внимание на улучшение технического мастерства и удобный дизайн;

• простота – искусство НЕ делать лишней работы;

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

• постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся обстоятельствам.

Основные проблемы перехода на гибкие методологии:

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

2. Построение «системы», не обладающей необходимой гибкостью. Отсутствие опыта работы по новой методологии ведёт к тому, что новый процесс внедряется по инструкциям, буква к букве, что ведёт к негибкости и бюрократизации.

3. Начало внедрения не с «основ». При переходе на новые методологии руководство преследует конкретные выгоды, которые должна обеспечить методология: высокая производительность, качество и т.п. При этом некоторые практики нового процесса более очевидно ведут к этим выгодам, а некоторые – совсем не очевидно. В связи с этим возникает соблазн внедрить сначала более «выгодные» практики, а потом уже остальные. При этом не учитывается, что некоторые практики являются базовыми по отношению к другим, и внедрение вторых без первых невозможно.

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

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

 

Литература:

1. Томас Д., Хансон Д. Agile Web Development with Rails. 2007. с. 17–64.

2. Кон M. Succeeding with Agile: Software Development Using Scrum. 2008. с. 53–81.

3. Scrum: [Электронный ресурс] – Режим доступу: http://en.wikipedia.org/wiki/SCRUM (дата обращения: 23.05.2014)

4. Agile: [Electronic resource] – Режим доступу: http://www.unn.ru/pages/issues/vestnik/99999999_West_2011_3(2)/36.pdf

 

References:

1. Thomas D., Hansson D. H. Agile Web Development with Rails. 2007. P. 17–64.

2. Cohn M. Succeeding with Agile: Software Development Using Scrum. 2008. P. 53–81.

3. Scrum: [Electronic resource] - Rezhim dostupu: http://en.wikipedia.org/wiki/SCRUM

4. Agile: [Electronic resource] - Rezhim dostupu: http://www.unn.ru/pages/issues/vestnik/99999999_West_2011_3(2)/36.pdf

Tags: