Реально ли большое увеличение скорости в среде Scrum?

89

Мой менеджер недавно действительно настаивал на том, чтобы использовать скорость в качестве цели и показателя производительности. В настоящее время мы работаем со средней скоростью 50 баллов. Мой менеджер хочет, чтобы мы увеличили его на 40% до 70 баллов (без увеличения числа членов команды). Если мы не добьемся этого увеличения, он хочет, чтобы мы сделали полный анализ, объясняя, почему.

Сама идея измерения производительности команды по скорости и ее использования в качестве цели кажется мне неправильной, но мне трудно объяснить почему. Любая помощь? Почему это не правильный способ измерения и стимулирования производительности?

P2L
источник
19
Ух ты. Менеджер либо не понимает, что такое скорость, либо думает, что команда ослабевает. или оба. На следующем совещании по планированию выделите 70 баллов, и пусть команда расскажет ему о рисках провала, которые вызовут
Стивен А. Лоу,
25
Кажется, что это такая глупая просьба, что я хотел бы, чтобы вы спросили его, почему он считает, что это возможно - если вы уже даете 100%, он ожидает, что вы дадите 140%? Что делать, если вы просто делаете спринты на 40% длиннее?
Джонатан Рич
20
Предполагается, что скорость - это мера того, как быстро вы сможете добиться цели. Если ваша скорость и сюжетные очки абсолютно точны, это говорит о том, что вы не можете полностью заполнить отставание к крайнему сроку. Рациональная вещь, которую нужно сделать, это принять реальность и либо вычеркнуть вещи из отставания, либо расставить приоритеты в отношении того, что там происходит, чтобы то, что вы делаете, было более важным делом. Или вы можете изменить срок на что-то реалистичное.
Майкл Шоу,
45
Попросите его увеличить зарплату на 40%, если вы достигнете этих целей, а затем увеличьте свои оценки, чтобы получить увеличение на 40%.
Mattnz
18
Разве это не похоже на просьбу марафонца внезапно пробежать марафон за 1ч25м вместо 2ч?
Scroog1

Ответы:

158

Что ж, совершенно просто увеличить скорость на 40% - просто добавьте на 40% больше очков ко всем вашим оценкам и проделайте тот же объем работы.

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

Менее легкомысленный ответ заключается в том, что ваша оценка уже предполагает, что вы идете так быстро, как можете, делая все правильно. Единственный способ действительно повысить производительность на 40% - это работать сверхурочно или не делать все правильно. Обе эти вещи ускоряют процесс в краткосрочной перспективе, но замедляют процесс в долгосрочной перспективе. И длительный срок в этом случае не очень длинный, месяц снаружи. Оптимальная долгосрочная стратегия - никогда не идти быстрее, чем ваш устойчивый темп.

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

PSR
источник
28
Я твердо верю, что нет "быстрых и грязных". «Грязный» всегда делает меня медленным - даже в краткосрочной перспективе.
Док Браун
1
@ Пол - я думал, что это было хорошо. Но за советом в основном могут последовать только менеджеры, и те, кто может извлечь из этого пользу, вероятно, не будут его читать. И чтение не обязательно изменит поведение.
PSR
2
И если вы согласитесь и действительно увеличите скорость на 40%, другим будет казаться, что вы и ваша команда работали не лучшим образом. Профессиональный способ справиться с этим - дать прямой ответ: «Нет, не могу». Еще одна книжная ссылка об этом: «Чистый кодер» Роберта С. Мартина.
Паблосарайва
1
«Ваша оценка уже предполагает, что вы идете так быстро, как можете, при этом все делаете правильно». Вероятно, это неверное предположение. Мы всегда можем продолжать улучшать и оптимизировать. Команды никогда не должны предполагать, что их стабильная скорость означает, что они не могут стать лучше. Но они должны систематически рассматривать весь процесс и искать незначительные улучшения процесса.
Кертис Рид
53

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

Тем не менее, менеджеры всегда стремятся повысить производительность, а Scrum и Agile - это все, что нужно для адаптации. Хотя скорость является мерой вашего нынешнего устойчивого темпа, вы не должны сидеть сложа руки. У Scrum есть место для оценки и изменения того, что работает, а что нет в вашем процессе: ретроспектива. Если вы воспользуетесь этим и скорректируете свой процесс, производительность (и, возможно, скорость) должна возрасти.

Итак, вы ищете (в своих ретроспективах) способы стать более продуктивными в команде? Есть ли в ваших спринтах что-нибудь, что регулярно потребляет непропорциональное количество усилий? Можно ли это решить? Вероятно, это не даст вам увеличения на 40%, но 5-10% - это начало, нет? На каждом спринте вы должны искать узкие места и устранять их. В конце концов, вы можете приблизиться к цели, которую он для вас поставил.

Мэтью Флинн
источник
7
+1: это хороший способ описать это менеджеру. Вы не можете искусственно увеличить скорость, но вы можете оглянуться назад после каждого спринта и узнать, что вы можете сделать, чтобы быть более эффективным в следующем спринте.
Кевин
3
Скорее всего, устранение накладных расходов менеджера (принудительные встречи, заполнение форм и т. Д.), Вероятно, даст вам эти 5-10% легко. Но как убедить его?
AviD
2
Я думаю, что ваш ответ представляет собой неправильное понимание скорости. Это не абсолютная метрика, это среднее значение, измеренное в течение жизни проекта. Более того, сами точки скорости представляют собой не проделанную работу, а грубые меры сложности. Они также являются усредненными, и задача с низкой точкой может потребовать больше времени, чем задача с более высокой точкой. Кажется немного бессмысленным просить «больше» и представляет собой фундаментальное недоразумение. Менеджер в основном просит о фиксированном сроке.
Рикардо Гладуэлл
3
@RicardoGladwell - Когда я сказал «запрос явно неправильный», я признал, что это было неправильное понимание того, как работают сюжетные пункты. Я просто предполагал, что менеджер действительно хочет, чтобы команда повысила производительность, и Scrum действительно предоставляет для этого средства. Кроме того, существуют разные взгляды на то, что представляют собой сюжетные моменты - сложность является одной из самых распространенных. Большинство команд, с которыми я работал, заставили их соответствовать уровню усилий. Простая задача с большим количеством больше не считается простой.
Мэтью Флинн
1
Вы упоминаете, что увеличение скорости на «5-10% - это начало», но, похоже, это разделяет недоразумение менеджера о том, что «повышение скорости» означает, что я обрисовал в общих чертах.
Рикардо Гладуэлл
26

TL; DR

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

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

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

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

Оцените свои политические возможности

У нас средняя скорость 50 сюжетных очков ... Меня попросили увеличить ее на 40% до 70 сюжетных очков (без увеличения числа членов команды).

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

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

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

Если вы являетесь магазином Scrum, попросите своего Scrum Master решить эту проблему через соответствующие каналы. Жалоба в отставке и спринт-ретроспективы часто являются идеальными возможностями для проверки и адаптации для этой конкретной проблемы.

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

Если ничего не помогает , подготовьтесь к смертельному маршу , приведя в порядок свое резюме, и старайтесь изо всех сил, пока проект не рухнет. 68% ИТ-проектов провалились ; если цели управления не основаны на организационном потенциале, ваши, вероятно, будут одним из них.

CodeGnome
источник
качество не является переменной настройки: поэтому мы говорим о железном треугольнике, а не железном квадрате. Другими словами, когда кто-то пытается снизить «качество», это приводит к хаосу в задержках (более длительные поставки), области действия (функции не работают и, следовательно, не реализуются) ... и в ресурсах (разработчики разочарованы и уходят). Хороший ответ рядом с этой минутной точкой.
Крис
1
@kriss Качество действительно может быть частью треугольника. Иногда его считают частью «контекста», или в некоторых треугольниках это фактическая вершина, указывающая, что это основное ограничение. Посмотрите на синий треугольник внутри звезды PMBOK в качестве конкретного примера или на Эволюцию модели ограничения проекта для некоторых деталей по этой проблеме. Пожалуйста, поднимите это на PMSE для получения дополнительной информации.
CodeGnome
это обсуждение, которое я уже имел с поддерживающими агилистами. В итоге мы не согласны с тем, что PMBOK является действительным ресурсом Agile. Он возник с моделью водопада и является ортогональным к проворному. Это в основном совместимо, но есть еще некоторые проблемы. Рассматривать качество как переменную настройки - одно. На мой взгляд (и я не одинок) использование (пытаясь использовать) качества в качестве корректирующей переменной нарушает весь Agile-процесс. Но это должен быть собственный вопрос.
Крис
Вопрос размещен здесь pm.stackexchange.com/questions/11489/...
Kriss
21

Я не понимаю, какую роль играет ваш менеджер в команде Scrum? Он тренер? Он владелец продукта?

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

Более вероятно: он вне команды, может быть, владелец продукта? Если так, то он должен понимать, что, делая такой глупый запрос, он просто прекратил ловкость.

Основное правило заключается в том, что владелец продукта устанавливает цель, а команда устанавливает, что можно сделать за итерацию. Невыполнение этого приводит к классическому и хорошо известному железному кругу: ресурсам, скорости, особенностям. Выбери два! Вы не можете выбрать три из них одновременно (и помните: качество не является переменной настройки, попытка сократить углы через низкое качество приведет к еще большему ухудшению).

Если он не хочет менять текущую цель, может быть, 40-процентное увеличение производительности может быть достигнуто путем набора большего количества людей в команду? Может быть, вкладывать средства в повышение квалификации некоторых членов команды? Команды могут также набирать скорость с течением времени благодаря постоянному улучшению, но, конечно, не произвольным решением.

Попытка изменить скорость команды подобна попытке изменить размер комнаты. Это можно сделать, но в основном вам нужно поменять комнату.

Разве у вас нет Scrum Master или других людей с базовым пониманием Scrum, которые могли бы объяснить это ему?

Kriss
источник
15

В этом случае менеджер повернул в неправильном направлении после получения честной и верной оценки от команды. Менеджер должен обратиться к заинтересованным сторонам и сообщить им, что их требования не могут быть выполнены в запрошенное время. Затем менеджер / аналитик должен определить приоритеты, какие из функций ДОЛЖНЫ быть включены, а какие другие могут подождать (хотя бы всего пару недель). Если заинтересованная сторона неоправданна, то для участия в ней могут потребоваться руководители высшего звена, что, как правило, может быть сложным и потребовать целого ряда других обсуждений.

Если я был в вашей обуви я бы придумать подробный случай о том, почему проект IS собирается занять до тех пор , как была оценена. Также попытайтесь определить предметы с низким возвратом. Найдите элементы, которые не приносят особой пользы и требуют значительных усилий по программированию, а также аргументы в пользу их удаления из спринта. Также придумайте итеративный подход, который поставляет «X» на дату «Y» и убедитесь, что это выполнимо, затем придумайте последующую итерацию, которая получит оставшиеся элементы.

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

Однако, если клиент был слишком обещан, и никто не говорил до сих пор, это будет тяжелая битва. К сожалению, это не редкая ситуация.

hanzolo
источник
1
«честная и верная оценка» может быть проблемой.
JeffO
@JeffO - Может быть, именно поэтому я рекомендовал обосновать смету аргументами .. когда они попытаются это сделать, они либо поймут, что завышают свои оценки, либо у них действительно нет возможностей
Хансоло
9

Похоже, вы столкнулись с двумя проблемами.

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

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

редактировать: на основе вашего комментария ситуация выглядит плохо. Похоже, ваша компания закладывает фундамент, чтобы уволить вас и вашу команду (может быть, ваш менеджер тоже). Я предлагаю вам поискать другую работу.

Аарон Куртжалс
источник
3
К сожалению, это была серьезная просьба, сформулированная так: «Я не вижу причин, почему вы не можете этого достичь (но я не буду рассказывать вам, как!). Таким образом, подразумевается, что он не верит, что они работают достаточно усердно или не настолько компетентны, как следовало бы. Потом стало еще хуже, когда я уехал в отпуск, и владелец продукта сказал команде, что, если они этого не добьются, будут серьезные последствия. Так что теперь у меня также есть очень обеспокоенная команда (которую я искренне считаю отличной командой), о которой нужно беспокоиться.
P2l
4
+1 за «убирайся из доджа». Иногда это единственный способ (хотя реже, тем лучше).
Майкл
9

Увольте его. То есть, пройдите через его голову и объясните, что он потерял всякое доверие своей команды, и объясните, что он не представляет никакой ценности для бизнеса. Объясните, что менеджеров с таким уровнем некомпетентности гораздо легче заменить, чем команду ниже.

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

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

Теперь это может выглядеть как стратегия, которая может иметь неприятные последствия. Но подумайте: если бы высшее руководство поддерживало вашего менеджера независимо от того, вы все равно были бы в проигрышной позиции. Итак, если вы рассматриваете только ситуации, в которых вы еще не находитесь в проигрышной позиции, результат, скорее всего, будет гораздо более позитивным. Реальный риск заключается в том, что высшее руководство просто увольняет всю команду, включая менеджера. Только вы можете оценить этот риск. По-видимому, ваша продукция нужна, иначе они не стали бы просить больше, но по какой цене?

MSalters
источник
5
Другими словами, поднимите руки в воздух, вопите и подбадривайте. Такое отношение никогда не решает проблемы. Есть гораздо лучшие способы справиться с ситуацией.
MrFox
Нет. Плакать или подбадривать - драматические действия. Это можно игнорировать. То, что я предлагаю, это ультиматум. Либо этот менеджер уходит, либо команда уходит. Никакой драмы, только холодная бизнес-логика. Он не подходит для этой работы, и задача высшего руководства - действовать в этом направлении. Но их предпочтительным вариантом может быть игнорирование ситуации, если вы позволите им. Вот почему вам нужно отобрать этот выбор.
MSalters
@nathanhayfield Типичный? Я думаю, что команда будет состоять из разных личностей и людей. Ленивым следует обращаться индивидуально, а не к общей просьбе команды.
Джеймс Хоури
1
@MSalters Есть много людей в разных слоях бизнеса, которые не понимают определенные вещи. Правильный подход состоит в том, чтобы смягчить конфликт и обучить всех вовлеченных. Может быть, этот менеджер не понимает Agile, но у него могут быть другие искупительные качества (что может быть гораздо важнее). Как профессионал, вы должны максимально использовать каждую ситуацию и работать с каждым типом личности - потому что это действительно конструктивно и полезно в долгосрочной перспективе. Делать то, что вы предлагаете, не масштабируется.
MrFox
3
@MrFox: прямые менеджеры должны понимать планирование; на самом деле они являются слоем, самым непосредственным образом ответственным за это. Предполагается, что члены команды являются экспертами в данной области, а руководство высшего уровня находится вдали от проекта. Так что этот менеджер, в месте , где он будет делать заявление о расписании, доказывает , что он не понимает , что это , возможно , его наиболее важная задача. Если бы рынок труда был плотным, найти лучшего менеджера было бы проблематично. Но сегодня вы можете найти кого-то лучше.
MSalters
6

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

Там, где мне удавалось добиться увеличения, речь шла о:

  • очистка технического долга; обеспечение того, чтобы все работало в правильной (не обязательно последней!) версии, чтобы код был хорошо продуман, и чтобы в системе не было избыточности (дублированный код, неиспользуемый код и т. д.)

  • совершенствование практики; спаривание, где это возможно (да, я обнаружил, что это увеличивает скорость), что требует времени для агрессивного рефакторинга (то же самое!) и безжалостности в отношении масштабов и фокуса

  • поиск и / или покупка лучших инструментов для работы (например, ReSharper для .NET стоит на вес золота, Airbrake и Splunk для разработки на Ruby и т. д.)

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

Дункан Бэйн
источник
3

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

Давайте рассмотрим сценарий.

Для двухнедельного взаимодействия, скажем, 10 дней. Утопия - это 8 часов в день, с историей, отведенной на рабочий день. Итак, сверху, ваш Velcoity будет 8. Но, поистине, люди, вероятно, получают по 6 хороших часов в день с электронной почтой, встречами, перерывами в ванной и т. Д. Так что теперь у вас по 6 на разработчика. Итак, ваш базовый уровень - 6. Допустим, вы хотите, чтобы люди работали сверхурочно, сейчас там по 10 часов в день. Таким образом, это будет 10 точек скорости на разработчика.

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

Но если у вас стабильная 50, на самом деле, чтобы добраться до 70, потребуются дополнительные часы.

Джон Рейнор
источник
2

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

Работа большего количества часов не увеличивает скорость, если вы измеряете ее правильно, скажем, в характерных точках за час разработки. Это работает, только если вы измеряете количество точек в день, а затем переопределяете, что такое «день» в середине измерения. Это обеспечивает только иллюзию скорости.

Увеличение скорости требует улучшения независимых переменных в процессе разработки; более быстрые компьютеры и компиляторы, более эффективная система сборки, лучший процесс проектирования, более способные разработчики, лучшее рабочее пространство, супер-мотивация. Улучшение на 40% потребует очень значительных изменений.

Спросите, подумает ли ваш менеджер о размещении вашей команды в закрытых офисах вокруг общей рабочей комнаты, покупке нового оборудования для команды или найме нескольких действительно старших разработчиков для наставничества команды, если это принесет ему 40%. Если нет доступных ресурсов для улучшения входных данных для вашего процесса разработки, это в значительной степени исключает искреннюю заинтересованность в улучшении. Это оставляет реверс-инжиниринг вашего менеджера, чтобы выяснить, что на самом деле его мотивирует, что могло бы стать предметом «другой темы».

SeattleCplusplus
источник
1

Ну, я немного удивлен, что другие ответы относятся к просьбе босса серьезно. Кто-то, кто требует повышения производительности на 40%, не знает в первую очередь о разработке программного обеспечения.

Я до сих пор люблю читать Phil Factor на эту тему:

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

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

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

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

Совет, чтобы не стать "грустным и озлобленным" - лучшее, что вы можете получить. Не боритесь с технически некомпетентным боссом по техническим вопросам. Он увидит это как личную атаку.

Andomar
источник
Ну, я думаю, что это зависит от того, на какую модель управления вы подписываетесь. Лидер коучинга: признанный эксперт, который пачкает руки и учит других, как стать хорошим, но обычно остается «Гуру». Лидерский директор: «эксперт», который знает все (или думает, что знает) и просто отдает приказы и говорит людям, что нужно сделать. Руководство делегацией: не может быть экспертом, доверяет своей экспертизе и способствует. Поддерживающее лидерство: группа поддержки помогает сформировать их, мотивировать, убедить команду, что они могут это сделать, и помочь им достичь этого.
Кертис Рид
0

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

Причина, по которой неправильно использовать его в качестве цели и / или метрики, заключается в том, что это сделало бы его метрикой тщеславия. На бумаге это выглядело бы хорошо, но абсолютно ничего не отражало бы, или ваши продукты полностью удовлетворяют потребности ваших клиентов. И это то, что является наиболее важным (я надеюсь).

Стефан Биллиет
источник
насколько я могу судить, это уже объясняется в другом ответе : «диапазон, который выражает среднюю пропускную способность команды за некоторый исторический период. Это статистический анализ прошлых результатов, который затем можно использовать для прогнозирования вероятностных оценок будущей рабочей нагрузки. емкость или время цикла ... "
комнат
@gnat часть этого да, хотя этот ответ ничего не говорит об использовании скорости в качестве метрики тщеславия, что все еще важно, потому что для многих менеджеров делать глупости, основанные на числах прокси ОП сказал, что он чувствовал, что это неправильно, но не мог объяснить это. Я чувствовал, что термин «тщеславие» (из The Lean Startup) предлагает хорошее объяснение.
Стефан Биллиет
-1

Что касается моего опыта и прямо к делу.

Во-первых, вы можете раздуть оценку, но это не значит, что вы делаете больше.

Второе (предпосылка: без надувания, просто сосредоточение на командной скорости),

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

Они удобны, сосредоточены и стимулированы? Что будет дальше для них?

Это не «я нахожусь на пределе» ... это больше похоже на вопрос для всей команды: «Мы на пределе?» и "Как мы можем раздвинуть границы?" ...

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

Иногда, когда я вижу, что мои товарищи теряют работоспособность, я пытаюсь сломаться и пригласить их выпить пива или что-нибудь по вкусу. Это решает любые конфликты, и на следующий день они снова сосредоточены.

ПРОДАВАТЬ ...

Если объяснить причины, по которым вы не можете увеличить скорость, сложно, используйте ROI.

Скрам сосредоточиться на том, что самое важное для клиента. Теоретически самые выгодные задачи.

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

Покажите историю задач, доход (если есть), использованную вами историю и покажите, что ПРОИЗВОДИТЕЛЬНОСТЬ НЕ ЭФФЕКТ КОМАНДЫ - это расчет, определенный командой для оценки сложности и, возможно, времени, чтобы что-то получить. сделанный

Маркос Лима
источник