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

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

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

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

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

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

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

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

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

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

TL; DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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