Заказать звонок
Москва, Пресненская набережная, 12
Корзина 0
Войти
PMJournal.ru - управление проектами
Портал для профессионалов в управлении проектами
Услуги
Книги
Онлайн-курсы
Кейсы
Статьи
Новости
Обзоры
Тренинги
Работа
Персоны
Мероприятия
Ещё
    PMJournal.ru - управление проектами
    Услуги
    Книги
    Онлайн-курсы
    Кейсы
    Статьи
    Новости
    Обзоры
    Тренинги
    Работа
    Персоны
    Мероприятия
    Ещё
      0
      PMJournal.ru - управление проектами
      0
      • Услуги
      • Книги
      • Онлайн-курсы
      • Кейсы
      • Статьи
      • Новости
      • Обзоры
      • Тренинги
      • Работа
      • Персоны
      • Мероприятия
      • Личный кабинет
      • Корзина0
      Будьте на связи
      Москва, Пресненская набережная, 12
      info@pmjournal.ru
      • Facebook
      • Вконтакте
      • Twitter
      • Instagram
      • Telegram

      Agile/Scrum для начинающих

      • Главная
      • Блог
      • Кейсы
      • Agile/Scrum для начинающих
      // Кейсы
      Автор: PM Angel

      Что такое гибкая методология?


      Что такое Agile и Scrum?

      Что такое Agile?

      В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

      Agile Manifest

      Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

      • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
      • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
      • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
      • изменения в проекте приветствуются и быстро включаются в работу.

      В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

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

      Мы следуем таким принципам: 

      1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. 

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

      3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 

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

      5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 

      6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. 

      7. Работающий продукт — основной показатель прогресса. 

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

      9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 

      10.Простота — искусство минимизации лишней работы — крайне необходима.

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

      12.Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

      Краткое видео о том, что такое Scrum (english):


      Что такое Scrum?

      Scrum – это одна из нескольких методологий гибкой разработки ПО:
      • Scrum
      • Lean
      • Feature Driving Development
      • Extreme Programming
      Scrum процесс на одном листе:

      Scrum Agile process

      Scrum – это спортивный термин, который пришел к нам из регби, и представляет собой фигуру, которую образуют игроки перед началом игры.

      Scrum Rugby

      Артефакты в Scrum

      В скрам используется всего четыре артефакта:

      • Product Backlog
      • Sprint Backlog
      • Sprint Goal
      • Sprint Burndown Chart

      Product backlog:

      • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
      • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
      • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
      • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

      На скриншоте ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3 (Project Backlog в JIRA):

      Project Backlog JIRA

      Sprint backlog:

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

      Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

      Kanban Доска в Спринте

      Sprint Goal

      • это краткое описание того, ради чего выполняется данный спринт.
      • цель на спринт помогает команде принимать обоснованные решения.

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

      Sprint Burndown Chart

      • дословно “диаграмма сгорания”
      • в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
      • диаграмма обновляется каждый раз, когда завершается какая-либо задача.

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

      Burndown диаграмма в Jira

      Роли в Scrum

      В скрам используется всего три роли:

      • Product Owner
      • Scrum Master
      • Team.

      Роль Product Owner

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

      Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

      В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

      Роль Scrum Master

      • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
      • организует работу команды и обеспечивает её всем необходимым
      • защищает команду, несёт ответственность за её эффективность
      • только один человек.

      Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организует работу команды проекта, но не вмешивается в её работу.

      • Скрам мастер не назначает людей на задачи – это делает сама команда;
      • Мастер не заставляет людей делать работу – это ответственность команды;
      • Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

      Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

      Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

      Team (команда проекта)

      • кросс-функциональная
      • взаимозаменяемая
      • самоорганизующаяся
      • с фиксированным составом (в ходе спринта)
      • 4-10 человек.

      Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

      Команда НЕ принимает решений:

      • какие требования являются приоритетными – это делает Product Owner.

      Ритуалы (процессы в Scrum)

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

      Ритуалы в скрам это:

      • Sprint Planning Meeting
      • Daily Meeting
      • Sprint Review
      • Retrospective

      Sprint Planning Meeting (встреча по планированию спринта)

      • выполняется всей командой перед началом спринта
      • команда выбирает требования из Product Backlog и формирует Sprint Backlog
      • если требуется учесть взаимосвязи между операциями, то это делается здесь
      • команда декомпозирует требования на задачи (tasks)
      • каждая задача проходит оценку в трудозатратах или универсальных единицах
      • во время встречи Product Owner отвечает на вопросы команды.

      Встреча, которая проводится перед началом каждого спринта. Структура встречи:

      • представление и пояснение Product Owner’ом списка требований
      • вопросы со стороны команды
      • /рекомендуется перерыв/
      • декомпозиция требований на задачи (tasks)
      • оценка задач по методу Planning Poker.

      Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

      Daily Meeting (ежедневная встреча команды).

      Из названия понятно, что встреча проводится ежедневно. Основные принципы:

      • проходит ежедневно и только в одно и то же время;
      • встреча проходит только стоя;
      • поэтому длительность встречи не более 15 минут;
      • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

      Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

      Kanban Board во время спринта

      Sprint Review – сдача спринта Product Owner

      По завершению каждого спринта команда обязана провести демонстрацию полученного результат. Ценность этого ритуала я поясню отдельно.

      Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

      Структура встречи:

      • команда зачитывает требования из Sprint Backlog
      • по каждому критерию приемки происходит демонстрация полученных результатов
      • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
      • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

      На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

      Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

      Retrospective

      Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

      • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
      • какие проблемы мешают команде выполнять взятые на себя обязательства?
      • как улучшить взаимодействие с Product Owner’ом?
      • какие ошибки совершает команда и почему.

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

      Почему появился Agile?

      Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

      1. Заказчик не может сформировать четкие требования к ПО;
      2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
      3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

      #1 Заказчик не может сформировать четкие требования к ПО

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

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

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

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

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

      #2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

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

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

      #3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

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

      При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

      Резюме

      Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile – это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

      Автор: PM Angel
      Понравилось Понравилось Не понравилось Не понравилось

      Теги
      Agile Scrum
      Поделиться
      Назад к списку
      • Комментарии
      • Facebook
      • Вконтакте
      Загрузка комментариев...
      Категории
      • Кейсы40
      • Бизнес статьи35
      • Новости13
      • Обзоры38
      • Проект "Бизнес-эволюция"0
      • Тренинги4
      • Работа9
      • Персоны64
      • Мероприятия4
      Это интересно
      • О снежном коме плохого управленческого опыта
        О снежном коме плохого управленческого опыта
      • Кейс внедрения гибридного управления проектами с применением ИТ-платформы
        Кейс внедрения гибридного управления проектами с применением ИТ-платформы
      • PM-хаки
        PM-хаки
      • Договороспособность
        Договороспособность
      • Одиннадцать ошибок управления проектами на примере трансатлантического яхтенного перехода
        Одиннадцать ошибок управления проектами на примере трансатлантического яхтенного перехода
      • О принципе разумной фильтрации
        О принципе разумной фильтрации
      • Чек-лист для начинающих спасателей чужих проектов
        Чек-лист для начинающих спасателей чужих проектов
      • О технике отказа
        О технике отказа
      • Суперменеджеры
        Суперменеджеры
      • Синдром раздраженной секретарши
        Синдром раздраженной секретарши
      • ЧЕРНАЯ КНИГА СКРАМ
        ЧЕРНАЯ КНИГА СКРАМ
      • "Вредные" советы по управлению проектами
        "Вредные" советы по управлению проектами
      • Мифы и реалии о многозадачности
        Мифы и реалии о многозадачности
      • Казнить, нельзя помиловать
        Казнить, нельзя помиловать
      • Управление разработкой в проектах по созданию сложных программных систем
        Управление разработкой в проектах по созданию сложных программных систем
      • Тренинги по управлению проектами
        Тренинги по управлению проектами
      • Делегирование, не, не слышали. Хочешь что-то сделать хорошо - сделай сам
        Делегирование, не, не слышали. Хочешь что-то сделать хорошо - сделай сам
      • Чужие приоритеты
        Чужие приоритеты
      • Игра в качество и трудности воспитания менеджеров
        Игра в качество и трудности воспитания менеджеров
      • Про современных бизнес мотиваторов
        Про современных бизнес мотиваторов
      Облако тегов
      50 проектов Agile Gartner IPMA jira Kanban M&A MS Project opm3 PDCA PM PMBOK PMBOK7 PMI PMP PRINCE2 Project Manager RUP Scrum waterfall web-разработка ZohoProjects анти КСУП Боль веб-сервис внедрение информационной системы управления проектами внедрение корпоративной системы управления проектами внедрение проектной методололгии жизненный цикл проекта зачем нужно проектное управление информационная система управления проектами ИСУП коммуникации конференция по управлению проектами Корпоративная Система Управления Проектами КСУП Менеджер проекта Менеджмент менеджмент менеджмент проектов веб-сервисы Методология проектного управления Мотивация области управления проектами Обучение управлению проектами Онлайн-обучение онлайн-тренинги по управлению проектами Онлайн-школа освоенный объем погуби проектное управление подборка принимать решения приоритезация провал проекта продакшн Проектный офис проекты процессное управление процессы управления проектами регулярный менеджмент Роман об управлении проектами Руководитель проекта сервисы сертификация по управлению проектами Стандарт управления проектами ГОСТ строительные проекты тайм-менеджмент технология проектного управления типы коммуникаций типы контрактов Тренинги умение договариваться умение спорить Управление бюджетом управление закупками Управление идеями управление инновациями Управление интеграцией Управление качеством Управление коммуникациями Управление персоналом управление поручениями Управление проектами управление проектами Управление проектами в органах государственной власти Управление проектом управление рисками Управление содержанием Управление сроками Управление стейкхолдерами управление хаосом Фейковое проектное управление финансовый анализ ценность проектного управления Цитаты об управлении проектами Цифровая трансформация
      Подпишитесь на нашу рассылку и получайте первыми все самые интересные новости об управлении проектами!
      Онлайн-школа по управлению проектами
      Авторский тренинг «Стань Руководителем проекта, начни зарабатывать больше»
      Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
      Услуги по управлению проектами
      Внедрение Корпоративной Системы Управления Проектами (КСУП)
      Книги по управлению проектами
      Книга "Корпоративная система управления проектами"
      Книга "Как сдать экзамен PMP (Project Management Professional)"
      Наши контакты


      Заказать звонок
      info@pmjournal.ru
      Москва, Пресненская набережная, 12
      © 2025 PMJournal.ru - управление проектами. Все права защищены.
      • Вконтакте
      • Facebook
      • Twitter
      • Instagram
      • Telegram
      0