Как стать автором
Обновить

Комментарии 32

В некоторых креативных командах стало модным проводить короткие собрания в планке

Классная идея — через 30 секунд пузатенький менеджер упал с планки, все собрание закончено, возвращаемся к работе.
Достаточно пузатый менеджер имеет в планке дополнительную точку опоры
Ежедневное собрание в Scrum-команде должно помочь собственнику и менеджеру продукта

менеджеру продукта

Нечасто вижу людей которые так умело дискредитировали свою экспертизу с первых строк.
В scrum команде нет роли менеджер. Тут либо крестик снимать либо плавки надеть нужно.

Если вы судите о процессах по обертке, то это вы себя дискредитируете.
Первый принцип agile — человеческие отношения которые важнее учебника.
Есть два места, где понятие менеджер входит в scum:
1) Есть люди которые больше делают технические вещи а есть люди которые больше взаимодействуют с людьми. Первых логично назвать разработчиками, вторых менеджерами. Если назвать собственника и scrum master'а менеджерами — по сути ничего не измениться. Придираться нужно к сути, к тому как выстроены процессы, а не к названиям.
2) Вне скрама есть своя организационная структура — и у проекта есть человек который отвечает за проект/продукт. Этот человек может быть собственником, может скрам-мастером, а может быть частью команды — не суть важно. Но роль такая есть в жизни. Это задача скрама ее в себя включить, а не наоборот.

Извините меня за мою глупость, и поверхностность.
Спасибо что процитировали слова, которые я слышу раз за разом в 9 случаях из 10 когда мне объясняют зачем нужен менеджер в их версии scrum'на.
Мне повезло, когда компания решила оплатить мою сертификацю scrum-мастера международной тренинговой конторой. Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно. Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером. Проактивный разработчик договаривается с соседними командами и пилит функционал, от того что он договорился стал ли он менеджером ?

Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером

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

Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно.

Менеджер проекта/продукта есть в реальной жизни. Всегда есть человек который принимает решение, что проект будет и несет за него ответственность. До того как команда стала делать скрам должен быть человек, который принял решение делать скрам. И этот человек может быть на разных ролях в скраме, или, например, стэйкхолдером без явной роли. И в контексте статьи явно говориться про этого человека. Как еще его назвать?
Но так есть. Человека который пошел в софт скилы вместо хард скилов у нас принято называть менеджерами.

У вас в компании? Софт скилл и управленец принимающий решения — это разные вещи. Развитый софт-скилл не делает меня менеджером, он делает меня человеком с сильным софт-скиллом.


Проект стартует и строит бизнесс.
Бизнесс платит зп команде разработки, ПО и scrum-мастеру.
Бизнесс принимает решение. Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании, но это конкретная проблема натягивания scrum на вертикальную компанию, в горизонтальных таких проблем нету.

Развитый софт-скилл не делает меня менеджером

Вы меня не услышали. Я не готов рассуждать что делает менджера менеджером. В индустрии используется такое слово — не важно используют его правильно или нет. В реализации скрама люди делают много ошибок. Посмотрите соседние ветки — там притензии к статье по делу. Использование слова менеджер, к месту или нет — это шашки. Вам шашечки или ехать?

Проект стартует и строит бизнесс.

Бизнес — это кто?
В любой, даже горизонтальной структуре всегда будет человек, принимающий конкретное решение.
Бизнесс не может принять решение — бизнесс не личность.

Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании

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

CEO решил начать проект
собрали dev — команду, позвали ПО и скрам-мастера, где в этой истории менеджер ?

CEO — менеджер вот прям по определению. Если CEO не менеджер, то не понятно кто вообще менеджер.

Затем. Обычная ситуация, у ПО обычно в этой истории есть визитка, в которой написано: «продакт менеджер». И зарплату в бухгалтерии когда он получает — в ведомости написано «продакт менеджер». И когда члены команды уходят в отпуск — ПМ подписывает бумажку, где написано что он «продакт менеджер» и отпускает члена команды в отпуск. И самое главное, если проект провалится, то ПО не получит премию и нагоняй получит именно ПО в первую очередь.
Я не говорю, что ПО в этой истории ПМ или что так и должно быть всегда. Я говорю, что если вы приходите на аудит в эту историю, и первая ваша претензия: «у вас есть ПМ и скрам у вас неправильный потому что у вас есть ПМ», то вы явно упустили смысл скрама.

что делать тем людям у которх на визитки ПО нет слова менеджер, в рассчетной ведомости ПО тоже нет слова менеджер, а еще он не подписывает мне отпускные ?


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

что делать тем людям у которх на визитки ПО нет слова менеджер

Так я говорю, что это вообще не важно. Скрам это про взаимодействия и итеративное улучшение. А не про роли, отпускные и слова в визитке.

Снова с вами не соглашусь. Про взаимодействие это agile.
Agile это идеология или mindset которая говорит о важности взаимодействия и итерактивности.
Scrum очень конкретный фреймворк, с определенным списком ролей и мероприятий, артефактов и правил.


Не поучатильства ради а достоверности информации в интернете для.

Так ведь Scrum это фреймворк для применения Agile.
Если делать Scrum без Agile mindset'a то скрама не получиться по определению. Пиратский кодекс-это всего лишь свод указаний, а не правил.
Тут же вопрос в том, что люди берут внешние части скрама теряя суть.
Хорошо, когда у нас есть пул задач и мы под них выбираем методологию разработки… Но в текущей компании (название умолчу) происходит всё наоборот — под методологию загоняется спринт и происходит чёрти что.
Ну и не хватает в этом тексте то, что Scrum master обязан контролировать эти миттинги, потому что всяко без лидера — все в команде начинают разглагольствовать и эти встречи затягиваются от 40 минут до 1 часу.

а сколько у вас человек в команде ?

15 человек. Мастер у нас мёртвый, просто потому что опыта не было. Иной раз рявкать приходится, потому что невозможно это. Как по мне, ежедневные Stand Up'ы, Ретро — это пустая трата времени, если команда не умеет взаимодействовать друг с другом. За рабочую неделю — мы рабочий день, извините за выражение, пустословим (п**дим) ни о чём. Я бы лучше это время потратил на разработку или ещё какое-либо полезное занятие, но нет, ты обязан слушать о том, как дизайнер или контентмейкер мусолит свою задачу, посещать собрания на которых мы очередной раз профукали спринт, потому что кто-то чё-то тормозит и вообще команда ужасная и плохая.

Не спорю, Scrum идеально вписывается под сплоченную команду, которая готова включатся и бросаться на любую проблему. Но когда у тебя коллектив забитых интровертов, которые хотят реализовывать только тот объем задач, который на них висит, да ещё сверху добитых бюрократией — по такой схеме невозможно работать. Да, и как описал выше, нужно выбирать методологию под задачи, а не подгонять задачи под методологию. Со стороны это жесть как весело смотрится, а работать в этом безобразие — вообще одно удовольствие.

Все что Вы описали — это проблемы конкретной конторы.
Неясно только зачем вы продолжаете там работать.

В пассивном поиске, мой друг, в поиске)

Поэтому, в последнее время больше склоняюсь к методологии waterfall. Так спокойно работается и каждый понимает свою зону ответственности. Лиды на своих местах, разрабы и другие на своих.
А еще классно, когда Master не может надовить на product owner'a))) Пример. Я, как разработчик вижу, что эту задачу могу сделать за 8 часов, но product owner считает, что тут можно и за 2 часа всё сделать, поэтому ставит своё время. Я смело могу с наглой рожей сказать, чтобы он сам задачу делал за 2 часа. А master стоит и хлопает глазами, потому что не понимает как работают процессы. Это его команда и он должен ей рулить, он должен диктовать правила, а не owner. Конечно, не стоит идти в штыки с owner'ом, а уметь взаимодействовать с ним. Поэтому, такой вот у нас бардак.

ну так у вас просто манагеров нарядил в PO майки

Хоть и некро комментарий, но всё же.

Только что перечитал гайд по скраму (тот, что на ~17 страниц). И там четко написано, что время должна определять только команда. Владелец продукта этого делать не может — вообще никак. Он может только искать компромиссы, изменяя задачу или приоритет задач.

Скрам мастер тут должен был скорее напомнить владельцу, что это не в его компетенции.
Если стендап превращается в никому не нужную рутину, вероятно, командная работа отсутствует. Обычно члены команды заинтересованы знать, кто что делает и какие сложности. Возможно, команда не была запущена.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Можете расшифровать, что такое DM и DoE для тех, кто не в теме?

НЛО прилетело и опубликовало эту надпись здесь
когда 15 человек в команде не знают, что делает каждый из них, это не команда, а соплежуи-индивидуалы. Тут Scrum не поможет.
НЛО прилетело и опубликовало эту надпись здесь
Это не Scrum, а отсебятина по мотивам Agile.
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.

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

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