Комментарии 14
В рамках фидбэка
В scrum-командах нет начальника, который в классической системе управления дает фидбэк (к слову говоря, совершенно субъективный) своим сотрудникам. Эту функцию берет на себя вся команда.
Это неверно. У скрам-команды, конечно, же есть начальник. Который отвечает за оценку команды в целом и отдельных сотрудников, нанимает/увольняет/отправляет на обучение, отвечает за результаты работы команды.
Начальник команды — это тот ради кого и внедряется Scrum. Два главных отличия от традиционного подхода:
1) не нужно каждому выдавать задачи, сами разбируться
2) можно быстро оценить прогресс в проекте (т.е. вовремя заметить и исправить ошибки, сделанные на этапе планирования)
Подробное описание роли менеджера скрам-команды читайте в Essential Scrum by K.Rubin. Chapter 13 Managers.
не слышал
это слабый аргумент в дискуссии.
на какой именно странице
У меня к вам встречный вопрос. На какой странице там идет речь о том, что менеджеры не нужны? И если вы не нашли там слово manager и решили, что они не нужны, нужен ли такой вывод для CTO,CEO, VP of Product, HR etc? Про зарплату там также ничего не написано.
это слабый аргумент в дискуссии.Это, как раз, ключевой аргумент. K.Rubin может выражать официальную позицию Scrum не больше, чем Вы, в отличии от первых двух персон, перечисленных мною: «Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them.» — «The official Scrum Guide»
нужен ли такой вывод для CTO,CEO, VP of Product, HR etc?Нужны ли эти роли в Scrum-команде и требуется ли их участие именно в Scrum-процессе? «This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together… The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.» — «The official Scrum Guide».
Таким образом, участие перечисленных Вами ролей в Scrum-процессе не требуется, поскольку официальный документ однозначно говорит, что Scrum состоит только из тех ролей, которые содержит документ.
Но, поскольку Scrum — это фреймворк, а не финальная методология, то Вы вольны строить на его основе свои собственные процессы (только они не будут при этом изменять сам Scrum): «Rather, it is a framework within which you can employ various processes and techniques.» — «The official Scrum Guide»
есть начальник. Который отвечает за оценку команды«The Development Team is responsible for all estimates.» — «The official Scrum Guide»
есть начальник. Который… отвечает за результаты работы команды.«The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.» — «The official Scrum Guide». А вообще, в Agile заказчик принимает на себя часть финансовой ответственности за право влиять на процесс разработки.
Начальник команды — это тот ради кого и внедряется Scrum.Scrum внедряется ради получения заказчиком бизнес-выгод, предоставляемых Agile-разработкой, которая заключается в техническом обеспечении итеративной разработки, таким образом, чтобы будущие проектные решения опирались на feedback от практической эксплуатации реализации проектных решений предыдущих итераций. Это открывает возможность эффективного управления бизнес-рисками.
А роль «начальника» в Agile-разработке закреплена в 4-м принципе Agile Manifesto: «Business people and developers must work together daily throughout the project.» А также в «The official Scrum Guide»: «Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.»
Вы приписали мне позицию, которую я не выражал и доблестно бросились ее опровергать. Повторяя иногда мои же тезисы.
K.Rubin может выражать официальную позицию Scrum не больше, чем Вы, в отличии от первых двух персон, перечисленных мною.
Иронично) Себе то вы право рассказывать про скрам оставили.
Вы приписали мне позициюТут, наверное, опечатка. «Процитировал» Вас, а не «приписал».
и доблестно бросились ее опровергать.Если помните, то я просто спросил у вас номер страницы «The official Scrum Guide», которая подтверждает Ваши слова. Вы написали кучу слов, но так и не ответили на первоначальный вопрос.
Повторяя иногда мои же тезисы.Если только Вы — Ken Schwaber, Jeff Sutherland, или, на худой конец, Kent Beck (по вопросам Agile, учитывая что Scrum — это Agile, надеюсь, что хоть это не стало для Вас сюрпризом).
Себе то вы право рассказывать про скрам оставили.И вы, конечно же, не поленились процитировать эти мои слова перед своей репликой.
P.S.: Тот факт, что Вы перешли от аргументации по сути к обсуждению субъекта диалога, говорит намного больше, чем само содержание Вашего ответа. И это, как бы, не совсем профессионально.
P.S.S.: Когда выбираете литературу, то, если это не первоисточник (и), то старайтесь, хотя бы, чтобы ее рецензировал первоисточник, как, например, книги автора Henrik Kniberg. Я не хочу сказать, что вы прочитали плохую книгу, в конце-концов, Mike Cohn и Ron Jeffries обладают весомым авторитетом в Agile. Может быть, вы просто не так поняли автора. Я не знаю, и это не есть предмет обсуждения. Есть только один документ, который устанавливает, что в Scrum должно быть.
«Процитировал» Вас, а не «приписал».
Вы именно приписали. Я не утверждал, что менеджер входит в Scrum-команду. Поэтому вашего доблестного разоблачения не требовалось. В котором вы, к тому же, допустили ряд ошибок. Например, перепутали оценку эффективности работы команды и оценку командой трудозатрат на элементы Backlog.
Mike Cohn и Ron Jeffries обладают весомым авторитетом в Agile
Сново очень иронично. Как раз эти два человека написали вступительные слова к книге Essential Scrum, которую вы не читали и об авторе которой вы не слышали. Что, по вашим словам, является ключевым аргументом.
Кстати о Ron Jeffries. У него есть пост о менеджерах в котором он также подчеркивает, что если в компании есть менеджеры (т.е. в подавляющем большинстве компаний), то они дают задания и несут обязанность исправлять вещи, которые идут не так. А scrum позволяет выявить эти ошибки быстрее. В своем первоначальном комментарии я писал об этом же.
https://ronjeffries.com/articles/018-01ff/agile-manager/
Я не утверждал, что менеджер входит в Scrum-команду.Автор: В scrum-командах нет начальника, который в классической системе управления дает фидбэк (к слову говоря, совершенно субъективный) своим сотрудникам. Эту функцию берет на себя вся команда.
Вы: Это неверно. У скрам-команды, конечно, же есть начальник… Подробное описание роли менеджера скрам-команды (род. падеж) читайте в...
Вы именно приписали.Всякое может быть. Если Вы процитируете, о каких именно моих словах идет речь — мне будет понятней. Пока что я не могу обнаружить, чтобы я что-то Вам приписал.
P.S.: Если Вы хотите поговорить не по предмету обсужения, то я предлагаю не флеймить здесь, а продолжить в привате.
Как вы видите, я использовал предлог "у", который в русском языке имеет смысл, отличный от предлога "в".
Попробуйте в связи с этим переосмыслить мой изначальный комментарий и если у вас будут возражения, дополнения, комментарии, начните новый тред. Эта ветка уже потеряла смысл.
Который отвечает за оценку команды в целом и отдельных сотрудников, нанимает/увольняет/отправляет на обучение, отвечает за результаты работы команды.
Вы даже попросили меня оспорить это:
На какой странице [The official Scrum Guide] там идет речь о том, что менеджеры не нужны?
Так вот, согласно этой книге, у команд все еще могут быть классические менеджеры — Head of QA, Head of BA, CTO, CEO, CFO, CIO etc. Роли этих менеджеров примерно следующие — формирование команды, постановка целей, определение границ работы команды и смена участников команды. Менеджер и правда может уволить или выдать бонус (если он гендир, например). Но в этом он опирается в первую очередь на мнение скрам-команды и это явно написано в книге — там даже есть пример с Фредом, который плохо работает в команде и СНАЧАЛА команда разработки работает с ним, потом СМ (как часть уже скрам-команды), и только потом они идут к менеджеру вне скрам-команды — см. скриншот из книги ниже. Скрамгайду на мой взгляд это совсем не противоречит. А вот такого, что бы менеджер кого то оценивал сам, без ОС команды разработки — это явный антипаттерн.
А вот такого, что бы менеджер кого то оценивал сам, без ОС команды разработки — это явный антипаттерн
В традиционном подходе оценивать сотрудника без опоры на мнение его пиров также не приветствуется.
команд все еще могут быть классические менеджеры
как их может не быть?)
Вы представьте. Работает скрам-команда. Колбасит тикеты. Закрывает спринты. А кому это все нужно? Кто сформировал команду и зачем? Кто смотрит на результаты спринтов и проверяет их вклад в выполнение бизнес целей? Кто проверяет, что они разрабатывают с нужной скоростью или скорость маловата. Или что продукт вообще не выполняет тех целей, которые предполагалось? Кто кладет айтемы в бэклог? Кто ответственен за успех продукта?
Команду в целом не предлагать) Они ответственны за оценку айтемов в бэклоге и за то, чтобы позакрывать тикеты. Product ownerа также не предлагать. От не управляет продуктом, он управляет только бэклогом.
>> как их может не быть?)
Возможно все, например — стартап. Собрался я с Васей и Колей сделать лучшую в мире блокчейн-платформу, Вася привел свою девушку, Коля привел своего брата. Из инвестиций у нас — собственные ноуты и коворкинг, оплаченный из денег на завтраки, Idea по студенческой лицензии. Работаем just for fun до первых инвестиций, менеджеров не будет. Но это, конечно, утрированно сильно )))
В идеальном случае, должно быть так — стейкхолдеры объясняют РО свою стратегию развития организации\возврата инвестиций, и РО обеспечивает эту стратегию через управление бэклогом.
Иначе говоря, критерии успешности продукта — задают стейкхолдеры, за достижение этих критериев — отвечает РО (естественно, через правильное наполнение беклога). И эти критерии могут быть и прибыль, и лидерство на рынке, и РОИ, и просто вывод продукта на рынок, и укрепление HR-бренда, да что угодно.
Пример — у вас есть 1 млрд рублей и вы хотите сделать новую игру. Поздравляю, вы стейкхолдер — и теперь вам можно нанять скрам-команду. Вы находите РО, который хорошо шарит в рынке игр, понимает что в тренде, какие есть каналы продвижения и т.д. и т.п. Вы формируете ему цели, например сделать отдачу от инвестиций 5% в течении этого года и он приступает — наполняет беклог тем, что может этой цели достигнуть (и тут важно сказать что РО разделяет ваше видение, если вы например говорите что хотите фентези игру, РО может сказать вам что нынче в моде танки и не согласиться работать с вами, т.к. считает цели недостижимыми при таких условиях). Команда разработки же превращает элементы беклога — в инкримент, который потом можно зарелизить и вывести на рынок (и тут то РО проверит, был он прав предполагая что на этом можно получить денег или нет).
Следите за своим эмоциональным состоянием. Оно говорит за нас гораздо больше слов. Если мы опираемся на объективные и понятные собеседнику факты, но при этом злимся на него, испытываем неприязнь или раздражение, то человек в первую очередь воспримет наши эмоции и закроется. Злость и раздражение — эмоции агрессии
Лайфхак: если хочется сказать сотруднику какую-то гадость, я иду к кулеру, выпиваю стакан воды, возвращаюсь на рабочее место и после этого способна дать нормальную обратную связь)
Компас команды