Comments 32
В некоторых креативных командах стало модным проводить короткие собрания в планке
Классная идея — через 30 секунд пузатенький менеджер упал с планки, все собрание закончено, возвращаемся к работе.
Ежедневное собрание в Scrum-команде должно помочь собственнику и менеджеру продукта
менеджеру продукта
Нечасто вижу людей которые так умело дискредитировали свою экспертизу с первых строк.
В scrum команде нет роли менеджер. Тут либо крестик снимать либо плавки надеть нужно.
Первый принцип agile — человеческие отношения которые важнее учебника.
Есть два места, где понятие менеджер входит в scum:
1) Есть люди которые больше делают технические вещи а есть люди которые больше взаимодействуют с людьми. Первых логично назвать разработчиками, вторых менеджерами. Если назвать собственника и scrum master'а менеджерами — по сути ничего не измениться. Придираться нужно к сути, к тому как выстроены процессы, а не к названиям.
2) Вне скрама есть своя организационная структура — и у проекта есть человек который отвечает за проект/продукт. Этот человек может быть собственником, может скрам-мастером, а может быть частью команды — не суть важно. Но роль такая есть в жизни. Это задача скрама ее в себя включить, а не наоборот.
Извините меня за мою глупость, и поверхностность.
Спасибо что процитировали слова, которые я слышу раз за разом в 9 случаях из 10 когда мне объясняют зачем нужен менеджер в их версии scrum'на.
Мне повезло, когда компания решила оплатить мою сертификацю scrum-мастера международной тренинговой конторой. Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно. Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером. Проактивный разработчик договаривается с соседними командами и пилит функционал, от того что он договорился стал ли он менеджером ?
Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером
Я согласен, что странно. Но так есть. Человека который пошел в софт скилы вместо хард скилов у нас принято называть менеджерами. Так называется должность в платежной ведомости, так пишут в вакансиях на хэдхантере и так называет таких людей уборщица баба Маня. Не важно, оправдано это или нет.
Я лишь утверждаю, что можно сделать правильный скрам, продолжая использовать слово менеджер. И можно провалить скрам польностью отказавшись от этого слова. Не в слове дело.
Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно.
Менеджер проекта/продукта есть в реальной жизни. Всегда есть человек который принимает решение, что проект будет и несет за него ответственность. До того как команда стала делать скрам должен быть человек, который принял решение делать скрам. И этот человек может быть на разных ролях в скраме, или, например, стэйкхолдером без явной роли. И в контексте статьи явно говориться про этого человека. Как еще его назвать?
Но так есть. Человека который пошел в софт скилы вместо хард скилов у нас принято называть менеджерами.
У вас в компании? Софт скилл и управленец принимающий решения — это разные вещи. Развитый софт-скилл не делает меня менеджером, он делает меня человеком с сильным софт-скиллом.
Проект стартует и строит бизнесс.
Бизнесс платит зп команде разработки, ПО и scrum-мастеру.
Бизнесс принимает решение. Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании, но это конкретная проблема натягивания scrum на вертикальную компанию, в горизонтальных таких проблем нету.
Развитый софт-скилл не делает меня менеджером
Вы меня не услышали. Я не готов рассуждать что делает менджера менеджером. В индустрии используется такое слово — не важно используют его правильно или нет. В реализации скрама люди делают много ошибок. Посмотрите соседние ветки — там притензии к статье по делу. Использование слова менеджер, к месту или нет — это шашки. Вам шашечки или ехать?
Проект стартует и строит бизнесс.
Бизнес — это кто?
В любой, даже горизонтальной структуре всегда будет человек, принимающий конкретное решение.
Бизнесс не может принять решение — бизнесс не личность.
Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании
Я не жалуюсь. Я работаю на аутстафе и часто меняю компании, поэтому вижу разные ситуации.
Я предложил конкретный пример, когда понятие проект менджера применимо к scrum — что ПМ создает scrum команду и становится собственником или стейкхолдером. Мне кажется, что это вполне рабочий вариант. Вы в ответ предлагаете менять всю вертикальную структуру компании?
У горизинтальный компаний есть свои проблемы — горизонтальность нельзя назвать универсальным решением.
CEO решил начать проект
собрали dev — команду, позвали ПО и скрам-мастера, где в этой истории менеджер ?
Затем. Обычная ситуация, у ПО обычно в этой истории есть визитка, в которой написано: «продакт менеджер». И зарплату в бухгалтерии когда он получает — в ведомости написано «продакт менеджер». И когда члены команды уходят в отпуск — ПМ подписывает бумажку, где написано что он «продакт менеджер» и отпускает члена команды в отпуск. И самое главное, если проект провалится, то ПО не получит премию и нагоняй получит именно ПО в первую очередь.
Я не говорю, что ПО в этой истории ПМ или что так и должно быть всегда. Я говорю, что если вы приходите на аудит в эту историю, и первая ваша претензия: «у вас есть ПМ и скрам у вас неправильный потому что у вас есть ПМ», то вы явно упустили смысл скрама.
что делать тем людям у которх на визитки ПО нет слова менеджер, в рассчетной ведомости ПО тоже нет слова менеджер, а еще он не подписывает мне отпускные ?
Пускай каждый окажеться при своем, вам кажеться что в скрам нормально иметь менеджера, мне нет. Взрослые люди должны остаться при своем мнение.
что делать тем людям у которх на визитки ПО нет слова менеджер
Так я говорю, что это вообще не важно. Скрам это про взаимодействия и итеративное улучшение. А не про роли, отпускные и слова в визитке.
Снова с вами не соглашусь. Про взаимодействие это agile.
Agile это идеология или mindset которая говорит о важности взаимодействия и итерактивности.
Scrum очень конкретный фреймворк, с определенным списком ролей и мероприятий, артефактов и правил.
Не поучатильства ради а достоверности информации в интернете для.
Ну и не хватает в этом тексте то, что Scrum master обязан контролировать эти миттинги, потому что всяко без лидера — все в команде начинают разглагольствовать и эти встречи затягиваются от 40 минут до 1 часу.
а сколько у вас человек в команде ?
Не спорю, Scrum идеально вписывается под сплоченную команду, которая готова включатся и бросаться на любую проблему. Но когда у тебя коллектив забитых интровертов, которые хотят реализовывать только тот объем задач, который на них висит, да ещё сверху добитых бюрократией — по такой схеме невозможно работать. Да, и как описал выше, нужно выбирать методологию под задачи, а не подгонять задачи под методологию. Со стороны это жесть как весело смотрится, а работать в этом безобразие — вообще одно удовольствие.
Все что Вы описали — это проблемы конкретной конторы.
Неясно только зачем вы продолжаете там работать.
ну так у вас просто манагеров нарядил в PO майки
Только что перечитал гайд по скраму (тот, что на ~17 страниц). И там четко написано, что время должна определять только команда. Владелец продукта этого делать не может — вообще никак. Он может только искать компромиссы, изменяя задачу или приоритет задач.
Скрам мастер тут должен был скорее напомнить владельцу, что это не в его компетенции.
Scrum — вполне конкретная авторская методика, описанная в Scrum Guide.
Ежедневные «Stand-Up» — это встречи команды Разработки. Product Owner в них не участвует:
The Daily Scrum is a 15-minute time-boxed event for the Development Team.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Ох как же айтишники любят изобретать велосипеды. Учите историю индустриализации. Это называется оперативка. Почитайте и поспрашивайте как это было. Более того процесс производства на порядки сложнее чем процесс написания софта.
Как превратить 15 минут Scrum-собрания в ежедневный аншлаг?