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

Мы небольшая софтверная компания с одним продуктом.

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

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

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

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

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

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

Сначала вы должны спросить: "кого это волнует?"

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

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

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

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

ДА!

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

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

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

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

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

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

В двух словах, что такое Канбан?

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

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

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

Смотрите остальные детали по этой ссылке

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

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

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

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

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

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

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

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

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

Решение не в том, чтобы обвинить, а в том, чтобы научиться

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

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

Постоянное улучшение - это решение

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

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

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

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

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

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

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

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

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

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

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

«Программное обеспечение готово, когда оно готово, не раньше, не позже».

Это правда, но для каждой задачи, над которой начинают работать ваши разработчики, все ли в вашей организации понимают определение «Готово» для каждой задачи?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

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

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

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

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

4. Устранять проблемы (анализировать обратную связь и адаптировать)

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

5. Вернуться к первому шагу и повторять до выпуска ...

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

Как вы думаете, ваша команда думала, что они изолировали свои проблемы в каждой ретроспективе? Команда действовала, чтобы исправить проблемы. Разве команда не ответила, а руководство просто продиктовало решения и курс действий?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс существует в зависимости от цели проделанной работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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