Если бы вам задали вопрос: "Что такое Scrum?", — что бы вы ответили?
Наверняка, большинство ответило бы что это гибкая методология разработки IT-продуктов, или это набор инструментов, или же фреймворк. Все эти определения так или иначе верны. Но я бы хотел предложить вам иное определение. Несколько глубже.
Scrum — это организационный дизайн.
Задумайтесь над ним.
Наверняка, большинство ответило бы что это гибкая методология разработки IT-продуктов, или это набор инструментов, или же фреймворк. Все эти определения так или иначе верны. Но я бы хотел предложить вам иное определение. Несколько глубже.
Scrum — это организационный дизайн.
Задумайтесь над ним.
Судя по реакции, большинству понравилось утверждение и видимо каким-то образом было воспринято. Но большинство не такое уж и абсолютное, поэтому я все-таки поясню что за этим определением стоит. В любом случае будет интересно всем.
Всем известно, и даже в скрам-гайде так написано, что Scrum — это фреймворк. Этот фреймворк представляет собой скелет, состоящий из правил, ролей, церемоний, артефактов и т.д. Сам по себе фрейм не описывает рецепт успеха. Далеко не означает, что начав жить по скрам-гайду, ваши продукты начнут приносить бОльшую ценность, а T2M сократится в разы.
Скелет это всего лишь скелет. Статичный и прочный. Чтобы скелет начал двигаться или по крайней мере пришел в движение, ему необходимы мышцы, нервная система, плоть. Плотью для скелета является организационная структура. Чтобы Scrum работал и приносил максимальную ценность, нужно менять структуру. В более плоскую, с меньшей иерархией. Scrum не любит дожности и менеджеров.
Всем известно, и даже в скрам-гайде так написано, что Scrum — это фреймворк. Этот фреймворк представляет собой скелет, состоящий из правил, ролей, церемоний, артефактов и т.д. Сам по себе фрейм не описывает рецепт успеха. Далеко не означает, что начав жить по скрам-гайду, ваши продукты начнут приносить бОльшую ценность, а T2M сократится в разы.
Скелет это всего лишь скелет. Статичный и прочный. Чтобы скелет начал двигаться или по крайней мере пришел в движение, ему необходимы мышцы, нервная система, плоть. Плотью для скелета является организационная структура. Чтобы Scrum работал и приносил максимальную ценность, нужно менять структуру. В более плоскую, с меньшей иерархией. Scrum не любит дожности и менеджеров.
В качестве примера приведу кейс компании TOP Games Tech. На картинке представлены изменения в орг структуре до и после. Уже через три месяца образованная продуктовая группа показывала высокую производительность и гибкость.
Я очень часто замечаю насколько наши Российсике компании извращают понятие Scrum Master либо PO. До тошноты. Чаще всего причиной этому является просто не знание, не понимание, не погруженность в тему, не желание разобраться.
Чтобы в этом убедиться, достаточно просто зайти на hh.ru, поискать вакансии скарм-мастера и почитать описание.
Приведу несколько свежих выдержек из требований к скрам-мастеру (ни буквы не было изменено):
Проектный менеджер (SCRUM-мастрер)
- формирование реестра проектов и отчетности
- обеспечение работы Проектного комитета
- портфельное управление
- контроль реализации проектов
Скрам-мастер (Scrum-master)
- участие в процессе разработки в качестве тестировщика/аналитика/продукт-овнера/разработчика (это мое самое любимое)
- уметь работать с контентом сообщества
- чувство юмора
Менеджер проектов по разработке ПО/Scrum Master
- постановка задач участникам проекта и контроль результатов (😫🔫)
- оценка проектов (трудозатраты, сроки, риски, ресурсы)
- взаимодействие с субподрядчиками
Scrum Master
- постановка задач участникам команды
- контроль состава и сроков реализации задач в релизах
- составление отчетности по составу и срокам релизов
- составление отчетности по исполнению и бюджету релизов
Только один вопрос. Причем здесь скрам-мастер? Ну не этим же он должен заниматься. Ну хотя бы скрам-гайд же можно почитать. Крик.
Чтобы в этом убедиться, достаточно просто зайти на hh.ru, поискать вакансии скарм-мастера и почитать описание.
Приведу несколько свежих выдержек из требований к скрам-мастеру (ни буквы не было изменено):
Проектный менеджер (SCRUM-мастрер)
- формирование реестра проектов и отчетности
- обеспечение работы Проектного комитета
- портфельное управление
- контроль реализации проектов
Скрам-мастер (Scrum-master)
- участие в процессе разработки в качестве тестировщика/аналитика/продукт-овнера/разработчика (это мое самое любимое)
- уметь работать с контентом сообщества
- чувство юмора
Менеджер проектов по разработке ПО/Scrum Master
- постановка задач участникам проекта и контроль результатов (😫🔫)
- оценка проектов (трудозатраты, сроки, риски, ресурсы)
- взаимодействие с субподрядчиками
Scrum Master
- постановка задач участникам команды
- контроль состава и сроков реализации задач в релизах
- составление отчетности по составу и срокам релизов
- составление отчетности по исполнению и бюджету релизов
Только один вопрос. Причем здесь скрам-мастер? Ну не этим же он должен заниматься. Ну хотя бы скрам-гайд же можно почитать. Крик.
В продолжении вчерашнего поста, хочу рассказать о том, кто такой скрам-мастер и зачем он нужен. Это мое личное убеждение и видение:
1. Скрам-мастер — это фасилитатор. Скрам-мастер должен фасилитировать все события скрама (кроме дейли), следить и направлять потоки идей в нужное русло, вовремя подсвечивать проблемы. Одним словом создавать условия для проведения эффективных встреч.
2. Скрам-мастер — это проводник ценностей скрама для организации. Скрам-мастер должен транслировать и распространять всю ценность скрама на ключевых стейкхолдеров и команды, с которыми скрам-мастер работает.
3. Скрам-мастер — это коуч. На мой взгляд ошибочно разделять понятия Agile Couch и Scrum Master. Это все один и тот же человек. Вспомните о 4 шляпах скрам-мастера. Скрам-мастер обязан коучить всю организацию, объяснять и внедрять лучшие практики.
4. Скрам-мастер — это агент изменений. Если ваша организация задумала трансформироваться из камня в пластелин, то скрам-мастер — это первый человек, который обязан продвигать и внедрять изменения, соответсвующие ценностям скрама. Скрам-мастер — это тот человек, который может помочь добиться вашей организации business agility.
Вот 4 ключевые вещи, которые должна четко понимать компания, нанимающая скрам-мастера. Скрам-мастер это нечто больше, чем просто слуга для команды.
1. Скрам-мастер — это фасилитатор. Скрам-мастер должен фасилитировать все события скрама (кроме дейли), следить и направлять потоки идей в нужное русло, вовремя подсвечивать проблемы. Одним словом создавать условия для проведения эффективных встреч.
2. Скрам-мастер — это проводник ценностей скрама для организации. Скрам-мастер должен транслировать и распространять всю ценность скрама на ключевых стейкхолдеров и команды, с которыми скрам-мастер работает.
3. Скрам-мастер — это коуч. На мой взгляд ошибочно разделять понятия Agile Couch и Scrum Master. Это все один и тот же человек. Вспомните о 4 шляпах скрам-мастера. Скрам-мастер обязан коучить всю организацию, объяснять и внедрять лучшие практики.
4. Скрам-мастер — это агент изменений. Если ваша организация задумала трансформироваться из камня в пластелин, то скрам-мастер — это первый человек, который обязан продвигать и внедрять изменения, соответсвующие ценностям скрама. Скрам-мастер — это тот человек, который может помочь добиться вашей организации business agility.
Вот 4 ключевые вещи, которые должна четко понимать компания, нанимающая скрам-мастера. Скрам-мастер это нечто больше, чем просто слуга для команды.
В предыдущих постах уже много говорилось о ценностях скрама, но еще ни разу они не назывались. Их немного. Всего лишь 5, но каждая ценность имеет важное значение для соблюдения скрам процесса.
1. Уважение. К примеру:
- не перебивать
- предоставить слово каждому члену команды
2. Открытость. К примеру:
- доска команды находится в открытом доступе
- расписание событий известно всем
3. Смелость. К примеру:
- есть вопрос? спроси!
- чем больше обратной связи, тем лучше
4. Фокус. К примеру:
- работаем для достижения конкретной цели
- мероприятие имеет определенный тайм-бокс
- мероприятие проходит по заданному дизайну
5. Преданность. К примеру:
- постоянная команда
- доверие PO
Соблюдение и своевременное подсвечивание данных ценностей — это прямая зона ответсвенности скрам-мастера.
Соблюдаете ли вы эти ценности?
1. Уважение. К примеру:
- не перебивать
- предоставить слово каждому члену команды
2. Открытость. К примеру:
- доска команды находится в открытом доступе
- расписание событий известно всем
3. Смелость. К примеру:
- есть вопрос? спроси!
- чем больше обратной связи, тем лучше
4. Фокус. К примеру:
- работаем для достижения конкретной цели
- мероприятие имеет определенный тайм-бокс
- мероприятие проходит по заданному дизайну
5. Преданность. К примеру:
- постоянная команда
- доверие PO
Соблюдение и своевременное подсвечивание данных ценностей — это прямая зона ответсвенности скрам-мастера.
Соблюдаете ли вы эти ценности?
Вот такой веселый постер висит у нас в офисе, который напоминает кем скрам-мастер является, а кем нет. Картинки легче воспринимаются, чем слова.
Добавляйтесь в чат о проектном менеджменте, тут обсуждаться насущные темы, все по делу. Находим решения вместе.
https://t.me/joinchat/EuUO5g6eDqLcvk4ZPu3nLg
https://t.me/joinchat/EuUO5g6eDqLcvk4ZPu3nLg
Всем известно, что обычный здоровый человек имеет 46 хромосом. Каждая хромосома несет кусочек кода (геном) — ДНК. Быают случаи, когда человек имеет меньший набор хромосом. Это сопровождается неполноценностью, мутациями и тяжелыми заболеваниями.
Scrum также имеет ДНК. Разумеется оно намного проще, чем человеческое и состоит всего из 3х элементов. При неполноценности или отсутствии хотя бы одного из них, мы имеем неполноценный, храмой или, как часто любят говорить, адаптированный (знакомо?) скрам. Ну или в противном случае и вовсе его отсутствие.
Так вот. 3 элемента:
- Эмпиризм
- Самоорганизация
- Ценности Scrum
О самоорганизации ничего нового не расскажу, думаю, и так понятно что это, много где об этом говорится.
О ценностях скрама я уже писал выше, а вот эмпиризм прокомментирую.
Эмпиризм — это непрерывный процесс познания и накопления опыта в любом его виде, через любые органы чувств. В работе мы зачастую обращаемся к своему предыдущему опыту.
Скрам также предполагает непрерывное накопление и анализ опыта. Вспомните ретроспективу. Этот процесс можно назвать эмпирическим контролем. Весь скрам базируется на эмпирическом контроле. Контроль заключен на пересечении:
- Прозрачности
- Инспекции
- Адаптации
Каждый спринт мы должны проходить цикл инспекции и адаптации. Мы должны понимать где мы отстаем (инспекция) и как нам можно улучшиться (адаптация), при этом не только в разговоре с разработчиком (прозрачность).
Соблюдая данный цикл и не забыв о двух других элементах ДНК, можно действительно ощутить всю силу скрама. Это отразится не только на рабочих процессах, но и на человеческих отношениях.
Scrum также имеет ДНК. Разумеется оно намного проще, чем человеческое и состоит всего из 3х элементов. При неполноценности или отсутствии хотя бы одного из них, мы имеем неполноценный, храмой или, как часто любят говорить, адаптированный (знакомо?) скрам. Ну или в противном случае и вовсе его отсутствие.
Так вот. 3 элемента:
- Эмпиризм
- Самоорганизация
- Ценности Scrum
О самоорганизации ничего нового не расскажу, думаю, и так понятно что это, много где об этом говорится.
О ценностях скрама я уже писал выше, а вот эмпиризм прокомментирую.
Эмпиризм — это непрерывный процесс познания и накопления опыта в любом его виде, через любые органы чувств. В работе мы зачастую обращаемся к своему предыдущему опыту.
Скрам также предполагает непрерывное накопление и анализ опыта. Вспомните ретроспективу. Этот процесс можно назвать эмпирическим контролем. Весь скрам базируется на эмпирическом контроле. Контроль заключен на пересечении:
- Прозрачности
- Инспекции
- Адаптации
Каждый спринт мы должны проходить цикл инспекции и адаптации. Мы должны понимать где мы отстаем (инспекция) и как нам можно улучшиться (адаптация), при этом не только в разговоре с разработчиком (прозрачность).
Соблюдая данный цикл и не забыв о двух других элементах ДНК, можно действительно ощутить всю силу скрама. Это отразится не только на рабочих процессах, но и на человеческих отношениях.
Снова моя любимая рубрика "Вакансия дня"
Production manager
- Помощь PO в формировании backlog перед планированием спринта
- Проведение ежедневных stand-up встреч
- Проведение ретроспектив после завершения спринта
- Обнаружение проблем, которые могут привести к закрытию целей спринта
- Устранение блокеров, озвученных командой
По описанию очень похоже на Scrum Master, но вот почему это названо Production manager ума приложить не могу😂
Production manager
- Помощь PO в формировании backlog перед планированием спринта
- Проведение ежедневных stand-up встреч
- Проведение ретроспектив после завершения спринта
- Обнаружение проблем, которые могут привести к закрытию целей спринта
- Устранение блокеров, озвученных командой
По описанию очень похоже на Scrum Master, но вот почему это названо Production manager ума приложить не могу😂
Меня искренне удивляет как люди с легкостью умудряются подменивать понятия, и даже не подозревают, что свернули не туда. А ведь именно неправильная трактовка понятий, во многих случаях, является отправной точкой к фатальной ошибке, которая стоит зря прожитого времени, и соответсвенно денег.
У меня есть показательный кейс на эту тему. Расскажу о нем позже.
У меня есть показательный кейс на эту тему. Расскажу о нем позже.
Слушайте, я тут подумал, что я как-то совсем не представился и не рассказал о себе. Гораздо приятнее читать человека, о котором ты хоть что-то знаешь :)
Меня зовут Максим. Сейчас я работаю скрам-мастером в одной из крупнейших компаний в России. Офис находится в СПб. Я работаю не только с командами, но и с организацией. У нас есть своя отдельная команда, которая занимается Agile трансформацией компании и развитием business agility.
Я посещал тренинги и конференции по Agile и Scrum. Проходил сертификацию PSMI. Читал много полезной тематической литературы.
В целом, у меня около 1,5 лет чистого опыта в качестве скрам-мастера. До этого, около года работал Project manager в одном из digital-агенств СПб.
Я открыт к диалогу, и хотел бы также узнать что-то вас. Так что не стесняйтесь писать и задавать вопросы :)
Меня зовут Максим. Сейчас я работаю скрам-мастером в одной из крупнейших компаний в России. Офис находится в СПб. Я работаю не только с командами, но и с организацией. У нас есть своя отдельная команда, которая занимается Agile трансформацией компании и развитием business agility.
Я посещал тренинги и конференции по Agile и Scrum. Проходил сертификацию PSMI. Читал много полезной тематической литературы.
В целом, у меня около 1,5 лет чистого опыта в качестве скрам-мастера. До этого, около года работал Project manager в одном из digital-агенств СПб.
Я открыт к диалогу, и хотел бы также узнать что-то вас. Так что не стесняйтесь писать и задавать вопросы :)
Scrum Master via @vote
Первое что интересно мне узнать, какая аудитория здесь собралась:
anonymous poll
Project manager – 27
👍👍👍👍👍👍👍 28%
Scrum master – 27
👍👍👍👍👍👍👍 28%
Специалист (любой) – 26
👍👍👍👍👍👍👍 27%
Top manager – 9
👍👍 9%
Product Owner – 6
👍👍 6%
Product manager – 2
👍 2%
👥 97 people voted so far.
anonymous poll
Project manager – 27
👍👍👍👍👍👍👍 28%
Scrum master – 27
👍👍👍👍👍👍👍 28%
Специалист (любой) – 26
👍👍👍👍👍👍👍 27%
Top manager – 9
👍👍 9%
Product Owner – 6
👍👍 6%
Product manager – 2
👍 2%
👥 97 people voted so far.
Спасибо за активность, друзья!
Благодаря вашим ответам четко оформилась картинка контингетна. Могу точно сказать, что контент будет полезен и интересен всем.
___________________________________
Я недавно обещал рассказать кейс о неверной трактовке понятий. Хотя, считаю его несколько преждевременным, но уже закомитился, поэтому неотвертеться.
Примерно год назад у нас в компании только началась Agile трансформация. Мы были молоды в этом плане, зеленые, неопытные. С нами работали внешние коучи. Примерно тогда мы узнали о существовании иного подхода к реализации проектов, помимо классического проектного — продуктовый, для которого очень хорошо подходит скрам.
Это было в некотором смысле открытие. Мы очень захотели приметь его, поскольку данный подход является неотъемлемой частью трансформации. Ну и особо не разобравшись в понятии "продукт", мы взяли и натянули его на большинство наших проектов. Вместе со скрамом. То есть просто проект переименовали в продукт, а PM в PO. И всем по скрам-мастеру в добавок с барского плеча.
Но ведь проект не равно продукт, а PM не равно PO. Совсем разные сущности. Это было нашей ошибкой, которую мы осознали спустя год. Год, за который мы могли бы привнести больше качественных и культурных изменений в компании. Заработать и/или потртратить больше/меньше денег. Доставить больше ценности клиенту. И много чего еще. Эта ошибка явилась следствием как раз неверной трактовки понятия и нежаланием капнуть глубже, расширить угол обзора.
Нет, все же каких-то изменений мы добились. Не все совсем так плохо было. Но могли бы выжать гораздо больше и ощутить всю силу изменений.
Сейчас же мы провели инспекцию всех наших проектов и выявили, что только пятая часть из них более или менее соответствует понятию "продукт". Теперь мы взяли верный курс, но год упущен.
P.S. Я понимаю, что этот кейс оставляет много вопросов, поэтому и считаю его не своевременным, но будем есть слона по кускам и переодически возвращаться к этому кейсу. Все же его цель — показать, что необходимо очень внимательно относиться к новому и шире смотреть на вещи. Уверен, что далее я отвечу на большинство вопросов.
Благодаря вашим ответам четко оформилась картинка контингетна. Могу точно сказать, что контент будет полезен и интересен всем.
___________________________________
Я недавно обещал рассказать кейс о неверной трактовке понятий. Хотя, считаю его несколько преждевременным, но уже закомитился, поэтому неотвертеться.
Примерно год назад у нас в компании только началась Agile трансформация. Мы были молоды в этом плане, зеленые, неопытные. С нами работали внешние коучи. Примерно тогда мы узнали о существовании иного подхода к реализации проектов, помимо классического проектного — продуктовый, для которого очень хорошо подходит скрам.
Это было в некотором смысле открытие. Мы очень захотели приметь его, поскольку данный подход является неотъемлемой частью трансформации. Ну и особо не разобравшись в понятии "продукт", мы взяли и натянули его на большинство наших проектов. Вместе со скрамом. То есть просто проект переименовали в продукт, а PM в PO. И всем по скрам-мастеру в добавок с барского плеча.
Но ведь проект не равно продукт, а PM не равно PO. Совсем разные сущности. Это было нашей ошибкой, которую мы осознали спустя год. Год, за который мы могли бы привнести больше качественных и культурных изменений в компании. Заработать и/или потртратить больше/меньше денег. Доставить больше ценности клиенту. И много чего еще. Эта ошибка явилась следствием как раз неверной трактовки понятия и нежаланием капнуть глубже, расширить угол обзора.
Нет, все же каких-то изменений мы добились. Не все совсем так плохо было. Но могли бы выжать гораздо больше и ощутить всю силу изменений.
Сейчас же мы провели инспекцию всех наших проектов и выявили, что только пятая часть из них более или менее соответствует понятию "продукт". Теперь мы взяли верный курс, но год упущен.
P.S. Я понимаю, что этот кейс оставляет много вопросов, поэтому и считаю его не своевременным, но будем есть слона по кускам и переодически возвращаться к этому кейсу. Все же его цель — показать, что необходимо очень внимательно относиться к новому и шире смотреть на вещи. Уверен, что далее я отвечу на большинство вопросов.
Сегодня у меня с коллегой завязался спор на тему того кто выбирает скрам-мастера в команду: DevTeam, PO или же DevTeam+PO.
Я глубоко убежден, что выбирать скрам-мастера должна исключительно DevTeam, а мой коллега твердит, что DevTeam+PO.
Поясню. Дело в том, что механизм выбора скрам-мастера толком нигде не описан: ни в скрам-гайде, ни в каких-либо статьях на просторах сети. Поэтому мнений множет быть достаточно. Но многие, наверняка, слышали ни раз, что скрам-мастера выбирает команда. А какая команда никто не уточняет. Но ведь в скраме есть два понятия команды: скрам команда, куда входят PO, Scrum Master и DevTeam, и команда разработки (DevTeam).
В моем восполенном воображении скрам-мастера должна выбирать именно DevTeam. Потому что скрам-мастер бОльшую часть своего времени работает именно с ней, так как именно DevTeam поставляет инкремент и от ее эффективности будет зависеть скорость и качество. PO лишь транслирует свое видение и задает вектор движения для DevTeam, понимает что клиенту нужно именно сейчас и передает это в работу. PO должен доверять своей команде разработке и ее выбору.
В очень зрелых организациях и командах именно так и поступают. DevTeam распоряжается бюджетом на спринт и вольна нанимать (либо нет) скрам-мастера в этот спринт.
Может быть я очень идеализирую.
А как считаете вы?
Я глубоко убежден, что выбирать скрам-мастера должна исключительно DevTeam, а мой коллега твердит, что DevTeam+PO.
Поясню. Дело в том, что механизм выбора скрам-мастера толком нигде не описан: ни в скрам-гайде, ни в каких-либо статьях на просторах сети. Поэтому мнений множет быть достаточно. Но многие, наверняка, слышали ни раз, что скрам-мастера выбирает команда. А какая команда никто не уточняет. Но ведь в скраме есть два понятия команды: скрам команда, куда входят PO, Scrum Master и DevTeam, и команда разработки (DevTeam).
В моем восполенном воображении скрам-мастера должна выбирать именно DevTeam. Потому что скрам-мастер бОльшую часть своего времени работает именно с ней, так как именно DevTeam поставляет инкремент и от ее эффективности будет зависеть скорость и качество. PO лишь транслирует свое видение и задает вектор движения для DevTeam, понимает что клиенту нужно именно сейчас и передает это в работу. PO должен доверять своей команде разработке и ее выбору.
В очень зрелых организациях и командах именно так и поступают. DevTeam распоряжается бюджетом на спринт и вольна нанимать (либо нет) скрам-мастера в этот спринт.
Может быть я очень идеализирую.
А как считаете вы?
Scrum Master via @vote
Друзья, мне также интересно узнать как вы оцениваете свои знания об Agile/Scrum по шкале от 1 до 55, где 55 - уровень Герман Греф, а 1 - новичок. Уделите 5 секунд времени :)
anonymous poll
21 – 23
👍👍👍👍👍👍👍 37%
34 – 13
👍👍👍👍 21%
8 – 11
👍👍👍 17%
1 – 8
👍👍 13%
3 – 6
👍👍 10%
55 – 2
👍 3%
👥 63 people voted so far.
anonymous poll
21 – 23
👍👍👍👍👍👍👍 37%
34 – 13
👍👍👍👍 21%
8 – 11
👍👍👍 17%
1 – 8
👍👍 13%
3 – 6
👍👍 10%
55 – 2
👍 3%
👥 63 people voted so far.
Сегодня проводил игру GetKanban для одной из команд, поскольку ребятам необходимо было разобраться в принципах Kanban. И после игры я попросил ребят поделиться своими мыслями, инсайтами. В общем дать любую обратную свзяь.
Один из членов команды сказал: "Любое событие влияет на скорость команды". Речь разумеется шла о событиях, которые происходили в игре. Но ведь если подумать шире, то действительно так и есть. Абсолютно любое событие, которое происходит внутри команды и во внешней окружающей ее среде — может повлиять на скорость. Как положительно, так и отрицательно.
Проблема только в том, что не всегда мы можем знать об этом событии. И не всегда можем понимать, что что-то произошло. Помочь выявить проблему могут графики скорости и эффективности команды (velocity, burndown, cycle time, CFD и др.). Важно только вовремя заметить ее. Это задача скрам-мастера.
Если график сигнализирует нам о проблеме, то докапаться до сути не составит большого труда.
Один из членов команды сказал: "Любое событие влияет на скорость команды". Речь разумеется шла о событиях, которые происходили в игре. Но ведь если подумать шире, то действительно так и есть. Абсолютно любое событие, которое происходит внутри команды и во внешней окружающей ее среде — может повлиять на скорость. Как положительно, так и отрицательно.
Проблема только в том, что не всегда мы можем знать об этом событии. И не всегда можем понимать, что что-то произошло. Помочь выявить проблему могут графики скорости и эффективности команды (velocity, burndown, cycle time, CFD и др.). Важно только вовремя заметить ее. Это задача скрам-мастера.
Если график сигнализирует нам о проблеме, то докапаться до сути не составит большого труда.
Scrum Master
Сегодня у меня с коллегой завязался спор на тему того кто выбирает скрам-мастера в команду: DevTeam, PO или же DevTeam+PO. Я глубоко убежден, что выбирать скрам-мастера должна исключительно DevTeam, а мой коллега твердит, что DevTeam+PO. Поясню. Дело в…
Итого абсолютного большинства не образовалось и мир раскололся на 2 половины :)))))))))))
Значит вопрос очень спорный
Особенно удивило, что за PO голоса тоже были.
Тут хотелось бы пояснить тогда. Не правильно, когда PO единолично выбирает SM. Все-таки PO — это 1 человек, а команда — много. SM не только с PO будет взаимодействовать и не для него лично строить процесс.
Значит вопрос очень спорный
Особенно удивило, что за PO голоса тоже были.
Тут хотелось бы пояснить тогда. Не правильно, когда PO единолично выбирает SM. Все-таки PO — это 1 человек, а команда — много. SM не только с PO будет взаимодействовать и не для него лично строить процесс.