Warning: Creating default object from empty value in /home/sofonov/pmscrum.ru/wp-content/themes/StandardTheme_261/admin/functions.php on line 229
SCRUM – от идеи до реализации быстрее конкурентов | Scrum Project Management

Зачем нужен Scrum?

  • Scrum позволяет сократить сроки реализации от идеи до продукта или услуги на рыке.
  • Scrum делает проекты предсказуемыми для заказчика.
  • Scrum делает проекты прозрачными и понятными.

Что такое Scrum?

  • Scrum – это рабочая среда, используемая для гибкого управлении проектами.
  • Scrum проекты реализуется через серию циклов  длительностью 2-8 недель каждый.
  • Scrum позволяет быстро адаптировать проект под изменения рынка и бизнеса.

Как работает Scrum?

  • Scrum процессы – описание основных процессов для реализации проектов Scrum.
  • Scrum роли – описание главных участников проектов Scrum.



Что такого плохого в традиционном управлении проектами?

Хотите вы того или нет, но вы в любом случае при управлении проектом касаетесь традиционного подхода “водопад” (waterfall). Но важно помнить, что уровень изменений происходящих в мире за последние 30 лет вырос в десятки, а то и стони раз. Особенно ярко этот эффект проявился в последние 10 лет. И подходы по управлению проектами, которые работали 10 лет назад не выдерживают ни какой критики сегодня.

И нет никаких оснований полагать, что мир станет менее изменчивым. Сегодняшнее “быстро” вполне может оказаться “медленным” завтра. И для того, чтобы удержаться на рынке и соответствовать быстро изменяющимся тенденциям опережая конкурентов современные компании должны обладать соответствующими процессами управления. Гибкий (Agile) подход в управлении проектами, такой как Scrum помогает командам управлять проектами быстрее с меньшими затратами со значительным конкурентным преимуществом.

Какова методология гибкого управления проектами (Agile methodologie)?

Гибкая методология (Agile methodologie), такая как Scrum – это “легковесный” подход к управлению проектами по сравнению с традиционным подходом. В основе гибкой (Agile methodologie) методологии лежит самоорганизующаяся команда, способная и замотивированная на достижение конкретных целей бизнеса.

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

Гибкие методологии (Agile methodologie) продемонстрировали себя как один из лучших способов создания высококачественных продуктов с наименьшими временными затратами при этом достигая удовлетворения заказчика.

Пожелания пользователей (User Stories) заменяют список требований?

Гибкие проекты (Agile projects), особенно Scrum, используют резерв продукта (product backlog), который является приоретезированным списком функционала, создаваемого продукта или услуги. Тем не менее составляющие резерва проекта (product backlog) могут быть представлены разным способом. Наиболее распространенный подход заключается в перечислении пожеланий пользователей (user stories).

В то время как резерв проекта (product backlog) может рассматриваться как замена списка требований в традиционном управлении проектами, важно помнить, что описанное пожелание пользователя (user stori), написанная в форме: Как пользователь я хочу, чтобы… в любом случае будет незавершенным пор пока команда не обсудит это пожелание.

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

Можно ли масштабировать Agile проекты.?

Процессы Agile также как и Scrum масштабируемы. В то время как типичный Agile проект включает от 5 до 20 участников и примерно от одной до трех команд, есть успешная практика реализации успешных проектов с численностью 200, 500 и даже 1000 участников. Как вы предполагаете подобные, значительные проекты требуют больше внимания к координации, по сравнению с небольшими проектами.

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

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

Кто в гибком управлении проектами выполняет обязанности традиционного управления проектами

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

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

Скрам-мастер, это Гибкий руководитель проекта?

В Гибком управлении проектами Миру явился в 21 веке Скрам-мастер, как новая версия руководителя проекта. В отличие от традиционного Руководителя проекта, Скрам-мастер не расписывается “на крови” за успех или провал проекта. Скрам-мастер отвечает именно за качество процесса Скрам. Скрам-мастер отвечает перед бизнесом за производительность команды, чтобы команда работала на пике своих возможностей. Но при все этом Скрам-мастер не имеет множества из традиционных обязанностей, таких как: определение содержание проекта, бюджета проекта, управление рисками и т.п.

Как управляют гибкими (Aglie) проектами?

В гибком управлении проектами (Agile Project Management), Scrum это гибкий процесс, обеспечивающий коммуникации при управлении проектом. На проектах Скрам выделяют три основных роли: Владелец продукта, Скрам-мастер, и Команда.

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

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

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

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

Что такое пожелания пользователей (User Stories)?

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

Я как “тип пользователя”, хочу “какая-то цель” по “такой-то причине” 

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

Когда пишут пожелания пользователей (User stories)

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

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

Кто пишет пожелания пользователей (User stories)

По сути каждый может написать свое пожелание к функционалу (user stories). И это как раз ответственность Владельца продукта обеспечить полноту Резерва проекта, но это не означает, что только владелец продукта тот кто этим занимается. По мере реализации Agile проекта, появляются новые пожелания пользователей и это нормально.

 

Резерв спринта (Sprint backlog)..

Резерв спринта (Sprint backlog) – это список задач, установленный Командой-скрам в ходе планирования спринта Во время планирования спринта команда выбирает ряд позиций из Резерва проекта (Product backlog), обычно описанных в форме пожеланий пользователя (user stories) и определяет задачи необходимые к реализации для реализации каждого из пожеланий. Большинство команд также оценивают сколько времени им потребуется на каждую задачу для ее завершения.

Это принципиально важно, чтобы команда сама выбирала и оценивала позиции для Резерва спринта (sprint backlog). Потому как Команда  берет на себя обязательства за успешную реализацию выбранных позиций.

В ходе спринта участники команды актуализируют Резерв спринта (Sprint backlog)  минимум раз в день. Многие команды проводят актуализацию в течение Ежедневного Скрама.  Каждый день оцененная работа оставшаяся до конца спринта рассчитывается и объединяется Скрам-мастером, а затем отображается на Графике сгорания спринта.

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

Page 1 of 3123»