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

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

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

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

Мой вопрос в основном:

Когда справедливо искать проблему в качестве разработчиков?

Я начинаю думать, что если вы сможете выбрать свою собственную работу /функции и по-прежнему терпеть неудачу каждый спринт: - Вы не можете контролировать сложность своего собственного кода; - или код настолько сложный, что никто не может контролировать сложность.

Я что-то пропустил?

123 голоса | спросил Orca 23 MarpmWed, 23 Mar 2016 18:49:21 +03002016-03-23T18:49:21+03:0006 2016, 18:49:21

16 ответов


152

Вы должны сначала спросить: «кто заботится»?

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

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

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

ответил bmargulies 23 MarpmWed, 23 Mar 2016 21:17:57 +03002016-03-23T21:17:57+03:0009 2016, 21:17:57
131
  

Я что-то пропустил?

ДА!

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

Вам не хватает того, что ваша компания широко распространена некомпетентно .

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

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

ответил Telastyn 23 MarpmWed, 23 Mar 2016 19:05:39 +03002016-03-23T19:05:39+03:0007 2016, 19:05:39
68

Я хотел бы предложить вам сделать небольшое изменение и попробовать Kanban в течение пары недель вместо Scrum . Это может сработать лучше для вашей команды.

  

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

В двух словах, что такое Kanban?

Канбан также является инструментом, используемым для организации работы ради эффективности. Как и Scrum, Канбан поощряет работу, которая будет разбита на управляемые куски, и использует Kanban Board (очень похожее на Scrum Board), чтобы визуализировать эту работу по мере ее продвижения через рабочий процесс. В тех случаях, когда Scrum ограничивает время, необходимое для выполнения определенного объема работы (посредством спринтов), Канбан ограничивает объем работы, разрешенной в каком-либо одном состоянии (только так много задач может продолжаться, только так много может быть на -do list.)

Как SCRUM и Kanban одинаковы?

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

См. остальную часть детали из этого ссылка

ответил 23 MarpmWed, 23 Mar 2016 21:51:51 +03002016-03-23T21:51:51+03:0009 2016, 21:51:51
60
  

Мой вопрос в основном: когда справедливо искать проблему в качестве разработчиков

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

Если я невероятно талантливый разработчик, в команде невероятно талантливых разработчиков, и мы не можем закончить X историй в двух спринтах (или 36!), неужели мы некомпетентны? Или мы просто сосать оценку? Это зависит от того, были ли рассказы «создать экран входа в систему» ​​или «отправить человека безопасно на Марс».

Проблема начинается с плохих историй и /или плохих оценок

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

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

Проблема усугубляется плохими ретроспективами

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

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

Решение заключается не в том, чтобы возложить вину, а на изучение

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

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

Непрерывное улучшение - это решение

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

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

ответил Bryan Oakley 23 MarpmWed, 23 Mar 2016 23:24:16 +03002016-03-23T23:24:16+03:0011 2016, 23:24:16
17

Вы говорите, что «используете ретроспективные взгляды». Но что делает команда в этих ретроспективах? Поскольку вы прошли 18 месяцев, не обратившись к этому аспекту своего процесса, я предполагаю, что ответ таков: ничего очень полезного.

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

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

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

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

  • Возьмите меньше работы в следующем спринте (duh!)
  • Будьте более консервативны в оценках
  • Скажите, кто оказывает давление на нас, чтобы сделать больше работы, чтобы избавиться, так как мы уже принимаем участие больше, чем мы можем сделать прямо сейчас.
  • Улучшите управление прерываниями и скорректируйте объем работы в следующем спринте, чтобы удовлетворить неизбежные чрезвычайные ситуации.
  • Исправить узкие места или запланировать вокруг тех, которые вы не можете избежать.
  • Не назначайте истории членам команды, которые не могут их выполнить (и отдельно, выясните ответ руководства, чтобы решить ситуацию с неэффективным членом команды, от обучения и наставничества до увольнения).

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

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

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

ответил Zach Lipton 24 MaramThu, 24 Mar 2016 04:06:07 +03002016-03-24T04:06:07+03:0004 2016, 04:06:07
5
  

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

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

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

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

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

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

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

Отключение обычно начинается с самого начала, когда описывается задача; и это обычно усугубляется нетехническим персоналом, составляющим список требований, без каких-либо определений требуемых усилий.

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

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

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

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

Итак, если разработчики участвуют в захвате требований:

  • Есть ли у команды возможность сесть с менеджером продукта, чтобы уточнить требования /определение done?
  • Означает ли команда достаточные вопросы для разъяснения предполагаемых /предполагаемых требований? Как часто эти вопросы отвечают удовлетворительно?
  • Перед тем, как предоставить оценку, требует ли команда критерии приемки (определение done)?
  • Насколько хорошо обычно применяются критерии приемки для каждой задачи? Является ли это неопределенным документом с разреженной детализацией или описывает осязаемые функциональные возможности и формулирует, что разработчик мог однозначно перевести в тест?

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

  • Неполные и неопределенные требования.
  • Требования /задачи, которые являются слишком большими, в первую очередь.
  • Плохая коммуникация между командой разработчиков и высшим руководством.
  • Отсутствие четко определенных критериев принятия до того, как задания будут переданы команде.
  • Неполная или неопределенная /неоднозначная спецификация приемочных испытаний. (т. е. определение выполненного)
  • Недостаточно времени для определения /согласования критериев приемлемости.
  • Разработчики не рассматривали время для тестирования существующего базового кода или исправления существующих ошибок.
  • Разработчики протестировали существующий базовый код, но не подняли ошибки как Проблемы с блокировкой , прежде чем предоставлять оценки требований
  • Руководство рассмотрело проблемы /ошибки и решило, что ошибки не нужно исправлять до написания нового кода.
  • Разработчики испытывают давление, на которые приходится 100% своего времени, хотя, возможно, 20% (или какое-то подобное количество) их времени, вероятно, заняты встречами, отвлечениями, электронными письмами и т. д.
  • Оценки согласовываются по номинальной стоимости, и никто не настраивает место для ошибки или непредвиденных обстоятельств (например, «Мы решили, что это займет 5 дней, поэтому мы ожидаем, что это будет сделано в 8.»).
  • Оценки рассматриваются всеми (разработчиками и менеджментом) как отдельные числа, а не реалистичные «диапазонные» числа - т. е.
    • Наилучшая оценка случая
    • Реалистичная оценка
    • Оценка наихудшего случая

... список может продолжаться намного дольше.

Вам нужно сделать «поиск фактов» и выяснить, почему оценки неизменно отключаются от реальности. Является ли существующее базовое программное обеспечение плохим? Не хватает ли единицы тестирования? Ваши разработчики избегают общения с руководством? Может ли руководство избежать общения с разработчиками? Существует ли разрыв между ожиданиями руководства и ожиданиями разработчиков, когда дело доходит до «Определение совершенного» ?

ответил Ben Cottrell 24 MarpmThu, 24 Mar 2016 13:25:53 +03002016-03-24T13:25:53+03:0001 2016, 13:25:53
4

Мой совет по перезагрузке команды - выбрать наименьшую историю, возможную для каждой команды, за спринт, и завершить эту историю, и только одну историю!

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

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

ответил bakoyaro 23 MarpmWed, 23 Mar 2016 21:32:57 +03002016-03-23T21:32:57+03:0009 2016, 21:32:57
4

Вы должны собирать данные и строить уровни доверия на основе прошлой производительности.

http://www.leadingagile.com/2013 /07 /гибкой медико-метрика-для-предсказуемости /

Самый простой пример - с постоянными временными спринтами, такими как каждые две недели. Оцените, сколько очков очков команда закончит в течение двух недель. Затем, после двухнедельного спринта, просмотрите, сколько пунктов истории было фактически завершено. Со временем вы можете увидеть, что вы оцениваете 15 очков, но только закончите 10. В этом простом случае вы можете начать движение вперед с регулировкой скорости, чтобы вы планировали только 10 очков за спринт. Или вы планируете завершить 66% оценочной работы.

Построив уровни доверия со стандартными отклонениями, вы можете сказать, что руководство: согласно текущим целям проекта, мы ожидаем только 50% -ную уверенность, которую мы можем завершить за 3 недели, но 95% -ную уверенность мы можем завершить через 5 недель.

ответил Rich Remer 23 MarpmWed, 23 Mar 2016 23:15:19 +03002016-03-23T23:15:19+03:0011 2016, 23:15:19
3

Идея Agile и Scrum состоит в том, чтобы построить жесткий контур обратной связи, чтобы вы могли оценить ваш процесс. Вы должны спросить: «Где это сломалось?», Так как оно, кажется, сломалось полностью.

  1. Планируйте то, что вы собираетесь делать, и сделайте список
    • Это должно состоять из выбора предметов из отставания элементов, которые необходимо выполнить. Прежде чем что-либо втянуть в список дел для спринта, команде необходимо согласиться с тем, что они полностью понимают это и что они грубо оценивают, что для завершения потребуется меньше, чем спринт.
    • В идеале отставание упорядочено по приоритету (для бизнеса), и вы можете выполнить приоритет.
    • Если элементы из отставания слишком велики, разбивайте их на более мелкие куски. Затем разбивайте куски на отдельные задачи, которые могут быть завершены через день или меньше.
    • Не ожидайте, что это планирование будет простым или быстрым.
  2. Выполнять элементы из списка в течение определенного периода времени (спринт)
  3. Просмотрите, что вы сделали
    • Какие истории были закончены?
    • Если истории не закончились, то какие задачи составляли рассказы?
    • Если никакие задачи не были завершены, то что именно делали в прошлый понедельник? В прошлый вторник? И т. Д. - на этот момент пришло время для серьезной самоанализа ...
  4. Устранение неполадок (анализ обратной связи и адаптация)

    • Сколько времени прошло, что закончилось?
    • Что не позволило выполнить задания?
    • Разве члены команды разбивают истории (функции) на задачи, которые могут быть завершены за 1 день или меньше? Если нет, сделайте это и сделайте его частью списка дел.
    • Какие изменения в списке задач или в списке задач были сделаны во время спринта? Было ли это причиной того, что он не закончил? Если это так, не изменяйте список или функции. Бросьте измененную функцию на отставание, пока оно не станет стабильным.
    • Как вы можете уменьшить размер и объем нескольких элементов до того, что можно завершить в спринте? Выберите что-то крошечное, как улучшение журналов, простое исправление ошибок, опечатка, просто чтобы кое-что закончить, чтобы дать команде понять, что они могут сделать. Если вы не можете этого сделать, прекратите спринт и перепланируйте .
  5. Вернитесь к шагу 1 и повторите до выпуска ...

Есть ли препятствия в документации, проблемы с связями, создающие зависимости, проблемы связи, недостаточно информации в требованиях? ... Что? Разве разработчики тратили свое время на изучение новых технологий? Они тратили огромное количество времени на дизайн? Были ли такие вещи, как учеба в списке задач спринта?

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

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

ответил Lindsay Morsillo 23 MarpmWed, 23 Mar 2016 23:13:33 +03002016-03-23T23:13:33+03:0011 2016, 23:13:33
2

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

Является ли мастер схватки, используя эти встречи, для измерения прогресса каждого разработчика в отношении их целей?
Вам нужно использовать эту часть методологии Scrum для отслеживания прогресса по мере продвижения. Это должно дать вам хорошее представление о том, что делают люди.
Отвлечены ли они? Проводить слишком много времени на кофе или помогать другим людям в SE /SO, читать новости или делать проверки, которые не учитываются? Или они действительно крутые, полные впереди и полностью перегруженные? Ежедневный обзор должен дать вам хорошую идею. Это также поможет держать разработчиков сосредоточенными на задаче, поэтому им не нужно признавать, что вчера ничего не делали.
И, конечно, если они сообщают о устойчивом прогрессе через весь спринт и до сих пор не доставляют в конце, тогда они лгут, и настало время для нового разработчика.

ответил Sinc 24 MarpmThu, 24 Mar 2016 21:59:42 +03002016-03-24T21:59:42+03:0009 2016, 21:59:42
2

Оценка усилий и времени, необходимых для выполнения сложной задачи, такой как программный код, сложна. Как Joel Spolsky говорит:

  

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

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

ответил hakanc 25 MarpmFri, 25 Mar 2016 13:56:36 +03002016-03-25T13:56:36+03:0001 2016, 13:56:36
2

Scrum делает несколько вещей.

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

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

В-третьих, он дает более узкую петлю обратной связи. Настаивая на том, чтобы в конце спринта дела «делались», вы избегаете «90% -ной функции, полной, но только наполовину сделанной» проблемы; когда вы нажимаете на крайние сроки, вы можете засунуть вещи, которые нужно сделать в стороне, так что похоже, что вы почти достигли крайнего срока, или вы можете подделать его. Имея определение сделанного и настаивая на делах, вы знаете, что что-то сложнее, чем раньше, а не позже.

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

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

Это полезный способ использования шаблонов scrum-esque. Он продолжает работать, он продолжает планировать близость к производству, он обеспечивает некоторые петли обратной связи и т. Д. Он даже имеет преимущества в том, что он не деформирует разработку и тестирование в соответствии с системой (если тестирование лучше всего сделать, поскольку работа в основном завершена , пытаясь добиться чего-то законченного и испытанного в рамках одного и того же спринта, заставляет back-end спринт не привлекать новую разработку!)

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

Если бы они вдвое сократили (или расквартировали), сколько они совершили на каждый спринт, но все остальное оставалось одинаковым, тогда они закончили бы больше, чем они сделали для каждого спринта! У вас будет одинаковый объем кода. Очевидно, что «спринтерские отказы» не являются важной частью, поскольку это всего лишь внутренняя деталь процесса. Цель компании - сделать дерьмо, и это дерьмо будет хорошим; не следовать определенному процессу, если только ваша цель не является определением сертификации процесса ISO.

Процесс существует, подчиняясь цели сделанного материала.

С другой стороны, поскольку они не следуют правилам SCRUM, вы не получаете одинаковый вид обратной связи. Вы должны изучить полученный материал, чтобы узнать, являются ли порожденные дефекты недостатками, с которыми был разработан SCRUM; есть истории, которые живут на таких же зомби навсегда, и только убивают путь поздно? Есть истории, которые кажутся легкими, они взрываются и в ретроспективе, где не стоит общей работы? Является ли продукт действительно доступным в любое время, когда вам нужно /хотите его отправить?

ответил Yakk 27 MarpmSun, 27 Mar 2016 17:11:20 +03002016-03-27T17:11:20+03:0005 2016, 17:11:20
1

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

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

Точка быстрого развития заключается в том, что каждая новая работа должна быть такой же хорошей, как требуется для удовлетворения этого спринта И НЕТ ЛУЧШЕГО !!!!!! Да, это самый акцент, который я могу добавить в StackOverflow - и этого все еще недостаточно. Если вы обнаружите, что люди добавляют вещи, которые не требуются right this second , тогда они нуждаются в обучении правильному развитию гибкой разработки.

ответил Graham 24 MarpmThu, 24 Mar 2016 14:56:17 +03002016-03-24T14:56:17+03:0002 2016, 14:56:17
1
  

О, и да, мы используем ретроспективы.

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

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

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

  

Когда справедливо искать проблему в качестве разработчиков?

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

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

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

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

ответил Cort Ammon 26 MarpmSat, 26 Mar 2016 20:25:46 +03002016-03-26T20:25:46+03:0008 2016, 20:25:46
0

«Когда честно смотреть на качество разработчиков?»

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

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

Это даст вам хорошее сравнение с текущим рынком, не запивая вас в долгосрочную аренду.

Это может также дать парням-ребятам немного поднять задницу.

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

Если это долгосрочный материал, он заставит вас количественно определить его и положить в спринте в качестве требований!

ответил Ewan 25 MaramFri, 25 Mar 2016 00:56:33 +03002016-03-25T00:56:33+03:0012 2016, 00:56:33
0

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

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

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

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


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

ответил David 27 MarpmSun, 27 Mar 2016 19:55:49 +03002016-03-27T19:55:49+03:0007 2016, 19:55:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132