Методология управления agile реферат

Обновлено: 03.07.2024

В статье рассматриваются пять ключевых принципов и основные характеристики методов Agile. Выделяются основные этапы с описанием стандартных задач и рекомендациями при первом применении технологии. Гибкое управление отличается от классического подхода, поэтому в работе приведено их аналитическое сравнение их ценностей, подходов к анализу гипотез, принципы планирования, менеджмент проекта, реакции на изменения, метрики, методики и область применения. Множество успешных проектов увенчались успехом только благодаря тому, что команды, работающие над ними, были достаточно гибкими, способными реагировать на внешние изменения и применять гибкие технологии. В связи с тем, что главное препятствие к внедрению и масштабированию Agile связано с трудностями изменения организационной культуры, в статье описываются наиболее часто встречающиеся ошибки при внедрении технологии гибкого управления Agile, которые имеют существенное влияние на результаты деятельности команды. Обосновывается актуальность применения гибких методов и приводятся статистические данные об использовании её в российских организациях. Для обоснования эффективности методов Agile приведен опыт работы над проектами Сбербанка, предоставлены результаты деятельности их работы после внедрения Аgile технологий.

3. Джефф Сазерленд Scrum. Революционный метод управления проектами. М.: Манн Иванов и Фербер, 2016. 272 с.

Введение

Управление проектами включает в себя множество подходов и инструментов. Управление проектами происходит комплексно по этапам жизненного цикла проекта и фазам менеджмента. Области проектного управления включают финансовые, кадровые, структурные сферы деятельности организации. А для того, чтобы все эти сферы были широко и правильно охвачены, команде, работающей над проектом, необходимо правильно распределить свои обязанности, чему и способствует методология Agile manifesto.

Цель исследования – обосновать необходимость использования гибких технологий в современных условиях ведения бизнеса на основе анализа отличий и преимуществ подхода Agile manifesto.

Материал и методы исследования

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

Результаты исследования и их обсуждение

Agile – семейство процессов разработки, а не единственный подход в разработке проектов. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. Гибкая методология Agile имеет основу, наделенную рядом характеристик, представленных на рисунке 2.[1]

Следует понимать, в чем состоит ключевое отличие классического проектного управления от гибкого (табл. 1).

Agile методология предполагает использование смарт объектов: электронные таблицы, в которые можно вносить изменения в режиме реального времени и оповещать об этом свою команду моментально, сетки, календари, диаграмма Гантта [2].

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

Видим, что в Agial методологии успешно сочетаются принципы тайм-менеджмента, бережливого производства и т. д.

Рис. 1. Основные принципы Agile

Рис. 2. Основные характеристики методологии Agile manifesto

Сравнение методологии классического управления проектами и гибкого управления проектами

Классическое проектное управление

Гибкое управление проектами

Ценность устанавливается в конце проектной деятельности

Постановка ценности осуществляется во время реализации проекта.

До старта проекта

В ходе исполнения проектов для его улучшения

Детальное, до конца, с использованием метода критического пути.

Эмпирическое, основывающееся на предыдущем опыте.

Управление командой без внутренней иерархии.

Реакция на изменения

Негативная, так как ожидаются проблемы и дополнительная работа.

Изменения воспринимаются как часть процесса работы.

Процент реализации, отклонение от плана, Метод освоенного объема, прогнозная дата завершения проекта

Диаграмма сгорания задач, Накопительная диаграмма реализованных функций, Дата выхода на рынок

Отраслевые стандарты и практики (PMBoK, PRINCE2).

Верхнеуровневые фреймворки (например, Скрам). Большое количество отдельных практик (ежедневное собрание, спринт и другие)

Применяется, когда окончательный продукт и требуемые ценности до концы определены, работы и границы проекта определены.

Продукт, процесс и границы проекта еще до конца не определены.

Agile методология – подход, предполагающий присутствие всех, кто занимается разработкой определенного проекта. При этом каждый специалист выполняет свою работу. Agile методология дает возможность увидеть, что всех участников процесса объединяет одна цель – создание качественного проекта для своего потребителя. Множество успешных проектов увенчались успехом только благодаря тому, что команды, работающие над ними, были достаточно гибкими, способными реагировать на внешние изменения и менять свои планы.

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

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

Этапы реализации Agile-проекта

стандартных задач этапа

при первом применении

Появление инициатора изменений

Желание внедрить подходы. Готовность выступать в роли инициатора. Инициатор должен получить знания.

Определение круга пользователей

Выбрать проект, в котором есть возможность быстро выиграть. Чтобы доказать команде полезность такого подхода.

Определить владельца продукта. Выбрать фреймворк для внедрения. Выяснить потребности для выбранного проекта.

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

Анализ законодательства, политики и потребностей для бизнеса.

Написание пользовательской истории

Определение целей и рисков

Вместе с командой начать работать, чтобы участники команды могли набраться опыта.

Сформировать бэклог продукта.

Продолжать работать над формированием команды.

Определить метрики эффективности.

Заниматься управлением изменениями.

Начинание пользовательских историй

Тестирование их на пользователях

Улучшение продукта по результатам тестирования с участием пользователей на основании пользовательских историй.

Получить обратную связь от заказчика.

Внести необходимые улучшения.

Проверить соответствие метрикам эффективности.

Прохождение проверки на доступность

Улучшение продукта, основанное на обратной связи от пользователей, аналитике, дальнейшем исследовании пользователей.

Отладить систему обучения.

Продолжать менять культуру организации.

Заниматься постоянным улучшением продукта.

Связать эффективность деятельности команды с оплатой труда.

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

4. Вертикальная система управления тормозит применение гибких технологий. Часто получается так, что руководители концентрируют свое внимание на процессах Agile и забывают о необходимости реструктуризации управляющего звена организации. Это требует немало усилий, так как она касается субординации между сотрудниками и планов персонала касательного дальнейшего карьерного роста, но является обязательным этапом. В Agile не должна применяться привычная иерархия подчинения, в ней предусмотрена слаженная работа сети команд с постоянным обучением и совместным принятием решений.

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

6. Отсутствие четких временных ограничений регулярных встреч для обсуждения хода реализации проектов. Платформой управления проектной деятельностью в методологии Agile зачастую является Scrum, одним из ключевых принципов которого считается проведение ежедневных совещаний, занимающих не более 15 минут. Это позволяет устранить необходимость в проведении собраний традиционного формата. Но, к сожалению, не всегда удается сразу же избавиться от сложившихся привычек, и Scrum-встречи превращаются в совещания по всем имеющимся проблемам, растягиваясь на продолжительное время. Такие встречи подразумевают рассмотрение хода спринта и составление плана рабочей деятельности на следующий день. Данным принцип оглашается руководителем, он же следит за его исполнением.

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

9. Внедрить методологию Agile и не продолжать совершенствоваться. Agile подразумевает регулярную оптимизацию, а не единичный проект. Переход на основы Scrum еще не предполагает результативность каждого спринта. Внедрение данных технологий обязует к их постоянному совершенствованию для достижения желаемых результатов [4].

Рис. 3. Популярность Agile-подходов

На сегодняшний день Agile применяется во множестве существующих компаний. Из западных лидеров это: Facebook, Amazon, Apple, Google, Netflix, Uber и Airbnb. Они уже долгое время успешно функционируют на рынке и добиваются внушительных результатов, что подтверждает эффективность действующей методологии Agile.

Российские организации в последнее время тоже активно применяют Agile. На рисунке 3 представлена популярность Agile-подходов. Доминирующим является Scrum, который считается самым удобным, так как представляет собой конкретный набор правил для работы самоорганизующейся команды. В Российской Федерации доля Scrum составляет 54%, при этом чем популярнее становится Agile, тем выше процент использующих его компаний. Относительно 2018 года замечено резкое увеличение организаций, использующих Kanban – приток возрос в 2 раза [7].

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

Результатами их трансформации стали:

• Сокращение среднего времени вывода продукта на рынок более чем в 7 раз;

• Рост количества поставок год к году в 2 раза;

• Увеличение количества продуктовых внедрений в 4 раза;

• Повышение мотивации, ответственности и вовлеченности персонала.

На сегодняшний день 30 000 работников Сбербанка трудятся в 3 000 продуктовых команд. Методология Agile позволила масштабировать свои форматы и во время пандемии 2020 года: от 10 000 до 70 000 сотрудников в течение года перешли на удаленный режим, продолжая обеспечивать бесперебойное обслуживание потребителей. Тем самым ответственность и скорость принятия решений в организации существенно возрастает и приносит наибольший эффект [5].

Выводы

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

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

Вложенные файлы: 1 файл

реферат(Agile).docx

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ, МОЛОДЕЖИ И СПОРТА УКРАИНЫ

Донецкий национальный технический университет

Институт информатики и искусственного интеллекта

Д050103.1.01.09/344.ЛР Кафедра Программное обеспечение
интеллектуальных систем

Выполнил: ст. гр. ПОC-О9в

_________ст.пр. Золотухина О.А.

Список условных обозначений, сокращений и терминов

Adaptive Software Development (ADS) - Адаптивная разработка программного обеспечения;
Agile Project Management (APM) – Agile управление проектами;
Dynamic Systems Development Method (DSDM) – Метод динамическое развитие систем;
Extreme Programming (XP) – Экстримальное программирование;
Feature-Driven Development (FDD) – Разработка, управляемая функциональностью ;
Lean Software Development (LSD) – Бережливая разработка программного обеспечения ;
Microsoft Solutions Framework для Agile (MSF) – методология разработки программного обеспечения, предложенная корпорацией Microsoft ;
Open Unified Process (OpenUP) – экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла.
Pragmatic Programming (PP) – методология гибкой разработки
Scrum – методология гибкой разработки

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

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

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

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

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

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

Основополагающие принципы Agile-манифеста

Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
Работающий продукт — основной показатель прогресса.
Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.

В чем суть А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, суть которого в том, что заказчик оплачивает фактическую работу.

Рис.4 – Разделение рисков между заказчиком и командой

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

31 июля 2019

Agile: методологии управления проектами

Agile – это термин, который объединяет ряд способов реализации проектов, основанных на гибком, неформализованном подходе. В статье разберем основные принципы Agile и дадим рекомендации по применению инструментов гибких методологий.

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

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

Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.

Agile противопоставляют в основном классическому менеджменту проектов, а не методологиям разработки программного обеспечения.

Как возник Agile

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

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

Но в конце 70-х годов особенности метода последовательной разработки стали ее недостатками: отсутствие гибкости в ответ на изменение условий; жесткость в отношении этапов проекта; зарегламентированность / бюрократия – все это мешало разработке массового программного обеспечения. Особенно в условиях растущей конкуренции, когда вопросы скорости предоставления готового продукта, оптимизации затрат на единицу выпуска выходили на первый план.

Гибкие методы появлялись органично в ответ на условия конкуренции:

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

В Agile акцент делается на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента.

О принципах Agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой - процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

На примере калькулятора для анализа проекта:

по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.

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

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

Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:

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

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

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

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

Приходилось ли вам когда-нибудь заниматься проектами или хотя бы принимать участие в проектной работе? Если да, то наверняка вы заметили, что наладить работу команды может быть достаточно сложно. И даже если она налажена, есть риск, что все усилия окажутся напрасными, ведь требования к необходимому результату часто меняются.

Метод Agile: определение и краткая история

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

Люди и их взаимодействие важнее, чем процессы и инструменты
Рабочее ПО важнее, чем документация
Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
Готовность к внесению изменений важнее, чем первоначальный план

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

Постигая Agile, в дополнение к обзору идей и правил обязательно ознакомьтесь с этим небольшим видео, где специалист по проектному управлению, консультант и бизнес-тренер Алексей Таченков рассказывает об основах системы.

Чтобы реально осуществить на практике вышеизложенные идеи и принципы, необходимо придерживаться нескольких правил. Только тогда Agile-менеджмент проекта может быть эффективен.

Ключевые моменты в применении Agile

Agile-методология основывается, в первую очередь, на визуальном контроле. Чаще всего участники проекта, работая над достижением результата, пользуются специальными цветными карточками. Один цвет сигнализирует о завершении планирования какого-то элемента конечного продукта, другой – о завершении его разработки, третий – о готовности и т.п. Визуальный контроль позволяет команде иметь наглядное представление о текущем состоянии процесса и гарантирует одинаковое видение проекта всеми ее членами.

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

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

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

Еще одним важным моментом Agile-методологии является разделение всего объема проекта на несколько более мелких составных частей. Такой подход многократно упрощает процесс разработки, а отдельные группы команды могут фокусироваться каждая на своей конкретной задаче.

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

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

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

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

Что я делал вчера?
Чем я буду занят сегодня?
Что мешает мне работать?

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

Четко обозначается значение проекта
В процессе реализации активно участвует клиент
Общий объем работ выполняется пошагово
Ориентироваться следует на конкретный результат
Численность одной рабочей группы: от 7 до 9 человек

В настоящее время проект-менеджмент с поддержкой Аджайл по большей части распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на вооружение множеством компаний и государственных структур.

Эти и многие другие организации используют в работе самые разные методы управления проектами, основанные на Agile. И поговорить об этих методах не менее важно, чем о самой методологии.

Плюсы и минусы Agile

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

В первую очередь стоит отметить, что Agile-управление очень гибкое. Если, например, традиционная методология указывает на конкретные этапы работы, то Эджайл легко подстраивается под потребителя конечного продукта и требования заказчика.

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

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

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

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

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

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

Внедрение Agile

Примеров внедрения Эджайл в работу компаний есть достаточно много. И практически все они говорят, что оно требует целого комплекса важных мероприятий.

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

Как мы и сказали, для внедрения Agile необходима команда профессионалов. Все ее члены должны знать базовые идеи и принципы методологии и уметь их применять. Если в компании нет таких людей, сотрудников нужно обучить. Руководство компании, решившей перейти к использованию Аджайл, также должно четко понимать, готова ли организация к изменениям, можно ли применять систему к своим проектам и т.д. Чаще всего, чтобы ответить на эти вопросы, приходится обращаться к специалистам по Agile.

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

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

Заключение

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

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

Читайте также: