Гибкие технологии управления agile scrum реферат

Обновлено: 02.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: определение и краткая история

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

На основе этого в 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 может стать в этом деле верным помощником.

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

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

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

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 - это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (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 направлены на повышение качества программного продукта.

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

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

Автор Анна Вичугова

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

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта [1]. Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы [2]. Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Гибкость против жесткости: Agile vs Waterfall

В отличие классического Project Management (PM), когда проект жестко регламентирован заранее установленными требованиями (контрактами), Agile предполагает быстроту реагирования, а также гибкую адаптацию к внешним и внутренним изменениям. Это достигается с помощью итеративной разработки продукта и эффективного межличностного общения. В водопадной (каскадной) модели PM, которая считалась стандартом де-факто, проект состоит из функциональных задач, где каждая последующая работа четко регламентирована и начинается строго после окончания предыдущей, например, тестирование начнется только после того, как написан весь код. Жесткая определенность и обилие регламентирующей документации обусловливают длину производственного цикла. При этом продукт считается готовым лишь после выполнения всех этапов [3].

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

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах Agile Manifesto [1]:

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

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

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

Недостатки Agile являются прямым следствием его достоинств:

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

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания (meetings, митинги), мотивирует и поддерживает команду.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно. Иначе – необходимо решать проблему: искать, где и почему возникли задержки и чью работу надо оптимизировать [4].

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Где, как и кем используется Agile

Сегодня эджайл применяется не только в управлении ИТ-проектами, а используется как эффективная практика организации труда небольших групп и творческих команд вместе с либеральными и демократическими методами менеджмента [1]. В частности, одной крупной телеком-компании благодаря внедрению Agile-практик в процессы кросс-функциональное взаимодействия всего за 3 месяца удалось достичь следующих результатов [6]:

рост от продажи устройств на 45%;
сокращение сроков запуска рекламных кампаний в 2 раза;
рост плановой ежемесячной выручки от разработки продуктов на 20%;
в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений [7]. Подобным опытом делится Райффайзен-Банк [8] и Сбербанк [9]. Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам [10]. Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях [11]. В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах [12].

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