Вы находитесь на странице: 1из 3

ТЕМА 9.

ГИБКИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ


ПРОЕКТАМИ

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

Здравствуйте, студенты РАНХиГС! Меня зовут Константин Негачев, и я стану вашим наставником
на пути изучения такого интересного и очень полезного направления, как гибкие методологии
разработки. Знания, полученные в рамках нашего курса, помогут вам ускорить процесс решения
поставленных задач, а также усовершенствовать тайм-менеджемент практически в любой сфере
жизнедеятельности и работы.

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

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

Итак, начнем. Наверняка многие из вас слышали такие слова, как Agile, Waterfall, Scrum, Kanban,
XP. Возможно, кто-то из вас даже применял их в каких-либо проектах.

1. Agile (от англ. — гибкий, поворотливый) — система идей и принципов гибкого управления
проектами.

Ключевой принцип — разработка через короткие итерации (циклы), в конце каждого из которых
заказчик или пользователь получает рабочий код или продукт.

Существует и альтернативная методика под названием Waterfall. Это методика управления


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

Методика Agile появилась в США. За ее созданием стоит группа американских IT-специалистов,


которые разработали «Манифест гибкой разработки программного обеспечения (англ. Agile
Manifesto)» — документ, содержащий описание гибкой разработки программного обеспечения,
разработанный в феврале 2001 г. в США.

Ключевые идеи, определяющие характер гибкой методики разработки:


1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.

Agile стал основой для целого ряда гибких методик, среди которых самыми популярными стали
Scrum, Kanban, экстремальное программирование (XP), Lean.

1
Кратко эти методики можно описать так:

Scrum — методология гибкой разработки на основе Agile, в основе которой лежит спринт — отрезок
от 1 до 4 недель, по окончании которого должна быть получена рабочая версия продукта.

Lean — метод, в основе которого лежит философия постоянного совершенствования на всех


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

Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится


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

Преимуществами методики Agile являются:


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

Недостатки методики Agile:


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

2. Waterfall (водопадная система разработки) — прохождение процесса разбито на стадии,


переход к следующей только после завершения предыдущей.

Методика была создана Уинстоном Уокером Ройсом, директором Lockheed Software Technology
Center, одним из родоначальников разработки программного обеспечения.

В его работе «Managing the development of large software systems» описаны 6 стадий разработки
продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с
разработчиками программного обеспечения:
1. Системные и программные требования закрепляются в документе требований к
продукту.
2. Анализ воплощается в моделях, схемах и бизнес-правилах.
3. Дизайн — разрабатывается не только интерфейс и внешний вид программного
обеспечения, но и его внутренняя структурная логика.
4. Кодинг — написание кода программы и интеграция программного обеспечения.

2
5. Тестирование — тестировщики проверяют продукт, указывая сведения о дефектах. В
случае ошибок происходит их исправление.
6. Операции — адаптация продукта под разные операционные системы, регулярное
обновление функционала, техническая поддержка.

Преимуществами методики Waterfall:


• Понятная и простая структура процесса разработки.
• Удобная отчетность — детальная документация проекта позволяет отследить различные
показатели.
• Стабильность задач — задачи остаются неизменными на протяжении всего процесса.
• Оценка стоимости и сроков сдачи проекта — сроки выпуска готового продукта и его
итоговая стоимость могут быть просчитаны до момента запуска разработки.

Недостатки методики Waterfall:


• Лишенный гибкости процесс — так, если проект требует больше временных и
финансовых ресурсов, возможно, пострадает этап тестирования. В среднем стоимость
исправления багов после выпуска продукта выше в среднем в 20 раз, чем во время
полноценного многоэтапного тестирования в процессе разработки.
• «Стойкость» к изменениям — жесткий каркас из этапов разработки и условие
предоставления только готового продукта определяют невозможность вносить
изменения во время разработки.
• Инерционность — на первых стадиях прогноз временных и финансовых трат может
измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат,
изменения функционала или концепции до выпуска готового продукта невозможно.
• Повышенный риск — классическая система тестирования подразумевает отдельно
тестирование каждого из компонентов проекта, в том числе, во взаимодействии с
другими. При использовании Waterfall происходит тестирование готового продукта.

Некоторые недостатки были исправлены в модификациях Waterfall:

Сашими — модель с наслаивающимися друг на друга этапами, которые перекрываются один


другим во времени.

Waterfall с субпроектами — модель работы с тремя крупными блоками: концептуализация,


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

Модель снижения риска — разделение проекта на мини-проекты.

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

Гибкая модель может применяться для IT-компаний, стартапов, проектов в инновационных сферах.
Каскадная модель — в строительных проектах или проектах, где ключевым ограничителем
является срок реализации проекта, а не финансы.