Мы небольшая софтверная компания с одним продуктом.
Мы используем scrum , и наши разработчики выбирают функции, которые они хотят включить в каждый спринт. К сожалению, за последние 18 месяцев команда ни разу не предоставила функции, которые они взяли на себя для спринта.
Я прочитал много постов / ответов, в которых говорится, что «программное обеспечение готово, когда оно готово, не раньше, не позже ... это не помогает оказывать давление на команду, заставлять больше людей, ... «Я получил аналогичную обратную связь от одного из разработчиков на мой вопрос, как мы можем улучшить показатель успеха спринтов. Да, и мы используем ретроспективы .
Мой вопрос в основном:
Когда справедливо искать проблему в качестве разработчиков?
Я начинаю думать, что если вы выбираете свою собственную работу / функции и по-прежнему терпите неудачу в каждом спринте, либо: - вы не можете контролировать сложность своего собственного кода; - или код настолько сложен, что никто не может контролировать сложность.
Я что-то пропустил?
Ответы:
Сначала вы должны спросить: "кого это волнует?"
Завершение спринтов чувствует себя хорошо, и в некоторых компаниях получаются куки-файлы от родителя. Но главное испытание - отвечает ли компания своим целям.
Выше сказанное. Если компания добивается успеха, хотя никогда не завершает запланированное содержание спринта, вы также можете использовать Kanban вместо этого: вы сортируете отставание, вы работаете над тем, что является наиболее важным, и не слишком беспокоитесь об определенных итерациях.
Одно из значений определенных итераций заключается в том, чтобы стимулировать улучшение процессов (или в некоторых менталитетах изгонять неэффективных). Вы не получите это сейчас. Таким образом, вы можете либо принять остальную часть процесса, который улучшает процесс (и в конечном итоге завершить спринты), либо вы можете решить, что вам нравится то, что у вас есть.
источник
ДА!
Вы прошли 18 месяцев - или где-то по соседству 36 спринтов с ретроспективами, но как-то не смогли это исправить? Руководство не считало команду ответственной, а затем их руководство не считало их ответственными за то, что они не считали команду ответственной?
Вам не хватает того, что ваша компания некомпетентна .
Итак, как это исправить. Вы (разработчик) перестаете совершать так много работы. Если истории настолько велики, что вы не можете этого сделать, то вам нужно разбить истории на более мелкие куски. И затем вы заставляете людей отвечать за то, что они сделали, что, по их словам, они будут выполнены. Если оказывается, что они могут получить только крошечную функцию, выполняемую каждым спринтом, то выясните, почему и сделайте ее лучше (что может включать замену разработчика). Если окажется, что они не могут понять, как выполнить разумное количество работы, вы их увольняете .
Но перед этим я бы посмотрел на менеджмент, который позволил бы так долго продолжаться, и выяснил, почему они не выполняют свою работу.
источник
Я хотел бы предложить вам внести небольшие изменения и попробовать Kanban на пару недель вместо Scrum . Это может работать лучше для вашей команды.
В двух словах, что такое Канбан?
Канбан также является инструментом, используемым для организации работы ради эффективности. Как и Scrum, Kanban поощряет разделение работы на управляемые куски и использует Kanban Board (очень похожий на Scrum Board) для визуализации этой работы по мере ее прохождения через рабочий процесс. В тех случаях, когда Scrum ограничивает время, отводимое на выполнение определенного объема работы (с помощью спринтов), Kanban ограничивает объем работы, разрешенный в одном условии (только столько задач может выполняться, только столько может быть выполнено). Список дел.)
Как SCRUM и Kanban одинаковы?
Как Scrum, так и Kanban позволяют разбивать и эффективно выполнять большие и сложные задачи. Оба придают большое значение постоянному улучшению, оптимизации работы и процесса. И те, и другие разделяют очень похожую направленность на хорошо видимый рабочий процесс, который держит всех членов команды в курсе WIP и что будет дальше.
Смотрите остальные детали по этой ссылке
источник
Kanban drives productivity and velocity by limiting the number of active, concurrent issues.
" - у Scrum есть и это противопоказание: завершать одну историю за другой .В вашем сообщении недостаточно информации, чтобы ответить на этот вопрос. Нет никакого способа узнать, терпят ли они неудачу, потому что они некомпетентны, или терпят неудачу, потому что они обязуются выполнять больше работы, чем разумно.
Если я невероятно одаренный разработчик из команды невероятно одаренных разработчиков, и мы не можем закончить X-истории в двух спринтах (или 36!), Мы некомпетентны? Или мы просто сосем на оценку? Это зависит от того, были ли истории «создать экран входа в систему» или «безопасно отправить человека на Марс».
Проблема начинается с плохих историй и / или плохих оценок
Оценка сложная. Очень трудно. Люди сосут это, поэтому Scrum заставляет нас разбивать работу на блоки, которые не должны занимать более дня или двух, и собирать небольшие группы из тех блоков, которые, мы уверены, мы сможем завершить за короткий промежуток времени. , Чем больше блоков и чем больше период времени, тем менее точны наши оценки.
Какие у вас магазины? Они хорошо написаны, с хорошими критериями приемлемости? Каждый из них достаточно мал, чтобы сделать это всего за несколько дней? Без хорошо написанных историй (что является ошибкой всей команды разработчиков, включая владельца продукта), от команды нельзя ожидать хорошей оценки.
Проблема усугубляется плохой ретроспективой
Похоже, что вы делаете неправильно, что вы не пользуетесь ретроспективами. Вы прошли 18 месяцев без решения этой проблемы, поэтому либо команда не замечает проблему, либо не решает ее в своих ретроспективах.
Завершает ли каждая ретроспектива хотя бы один элемент действий для команды, чтобы добиться большего успеха на следующем спринте. Включает ли каждая ретроспектива обсуждение элементов действий из предыдущего спринта, чтобы увидеть, были ли они выполнены и были ли они эффективными?
Решение не в том, чтобы обвинить, а в том, чтобы научиться
Первым шагом должно стать прекращение поиска вины, и вместо этого начать работать над улучшением команды. Ваша команда, вероятно, не некомпетентна, просто плоха в оценке и планировании. Заставьте команду закончить спринт, даже если это означает, что они выберут одну историю и закончат неделю раньше. Если они не могут этого сделать, то либо они некомпетентны, либо истории слишком сложны. Ответ на этот вопрос должен быть очевидным.
Как только они смогут закончить одну историю, они будут знать с достаточной уверенностью, что они могут набрать X очков истории в спринте. Простая математика поможет ответить на вопрос, могут ли они делать больше историй или нет.
Постоянное улучшение - это решение
Как только они закончили одну историю в спринте, пришло время посмотреть, смогут ли они сделать две. Вспенить, промыть, повторить. Когда они начинают терпеть неудачу в спринтерских целях, вы находите предел их оценочных способностей. Вернитесь к количеству пунктов истории из предыдущей истории и придерживайтесь этого некоторое время.
Всегда относитесь к ретроспективе серьезно. Если они не закончили спринт, выясните почему и действуйте по нему. У них было слишком много неизвестных? У них неправильное сочетание навыков? Насколько хороши были их оценки? Если они оценили историю как X баллов, потребовалось ли для нее относительно равное количество работы, как истории с X баллами? Если нет, используйте это, чтобы скорректировать точки истории в будущем.
источник
Вы говорите, что «используете ретроспективы». Но что на самом деле делает команда в этих ретроспективах? Поскольку вы прошли 18 месяцев, не обращаясь ни разу к этому аспекту вашего процесса, я предполагаю, что ответ таков: ничего очень полезного.
Для меня ретроспектива - самая важная часть процесса. Выбросьте или измените что-нибудь еще о схватках, сколько хотите (по обоюдному согласию команды во время ретроспективы, конечно), но примите на себя обязательство регулярно уделять время тому, чтобы рассказать о том, как этот процесс работает для всех, поделиться тем, что сработало, а что нет. не работают, и предлагают идеи для улучшения. Старайтесь постепенно улучшать свой процесс каждый спринт, и рано или поздно у вас может получиться что-то, что будет работать очень хорошо.
В вашем случае этот процесс не работает. Поскольку спринтерские цели не достигаются, целесообразно ретроспективно сосредоточиться на том, почему это так. Очевидно, команда взяла на себя слишком много работы для спринта. Но почему они это сделали?
Именно такие вопросы команда должна была задавать себе каждый спринт в течение последних 18 месяцев. Затем, вооружившись ответами, они могут предложить предлагаемые улучшения процесса для пробного запуска на следующий спринт. Они могут включать в себя:
Это такой разговор, который должен был происходить каждый спринт в течение последних 18 месяцев. Дело не в том, чтобы оказывать давление на команду или добавлять больше ресурсов, а в том, чтобы использовать ваши ретроспективы для постоянного улучшения вашего процесса. Это явно не происходит здесь.
Можно подумать, что к 15-му спринту с пропущенными целями команда обсуждала это много раз в своей ретроспективе, вплоть до того момента, когда они решили просто взять самые минимальные спринтерские цели из возможных только ради достижения одного. К 25-му незавершенному спринту я бы просто сделал спринт с одним изменением строки и ничего больше. Если команда не может справиться с этим в спринте, проблемы еще хуже, чем вы позволяете.
Чтобы было ясно, как уже указывалось несколько здесь, цели спринта - это прогнозы, а не железные обязательства, а недостающие цели сами по себе не указывают ни на что, кроме как делать неточные прогнозы. Отличная команда может пропустить кучу голов, потому что они плохие предсказатели, в то время как ужасная команда может встретиться с каждым и не дать никакой реальной ценности. Но если ваши прогнозы неверны в одном и том же направлении в течение 18 месяцев подряд, эта часть вашего процесса не работает. Используйте свои ретроспективы, чтобы зафиксировать процесс, чтобы ваши прогнозы были достаточно близки к реальной реальности того, что команда может предоставить каждому спринту.
источник
Это правда, но для каждой задачи, над которой начинают работать ваши разработчики, все ли в вашей организации понимают определение «Готово» для каждой задачи?
Кажется, что одна из ваших самых больших проблем - оценка , но разработчики могут предоставить реалистичную оценку, только когда у них есть однозначное и четко определенное «определение выполненного». (К ним относятся проблемы, связанные с процессами компании - например, пользовательская документация, рабочие пакеты для официального выпуска и т. Д.)
Неудивительно, что переоценка вызывает проблему, учитывая, что большинство разработчиков считают, что оценка времени, необходимого для выполнения задачи, является самой сложной задачей, которую им задают.
Тем не менее, большинство разработчиков, как правило, имеют разумный (хотя и оптимистичный ) контроль над количеством усилий они могут приложить за определенный период времени.
Часто проблема заключается в том, что разработчики изо всех сил пытаются создать взаимосвязь между задачей и общим объемом усилий, необходимых для работы с неполной информацией - особенно, если на них оказывается давление, чтобы найти ответы на все вопросы перед действительно огромной задачей. ,
Это, естественно, приводит к тому, что оценки времени отсоединяются от реальности, и они теряют из виду такие вещи, как процесс сборки и пользовательская документация.
Разъединение имеет тенденцию начинаться в самом начале, когда описана задача; и это обычно составляется нетехническим человеком, составляющим список требований, не имея никакого представления о количестве необходимых усилий.
Иногда люди в высшем руководстве задают задачи и полностью игнорируют проблемы процесса компании; старшее руководство нередко думает, что такие вещи, как определение тестов, создание формально выпущенной сборки или обновление пользовательского документа, происходят просто волшебным образом, без времени и усилий. требуется.
Иногда проекты терпят неудачу, прежде чем разработчик даже написал строку кода, потому что кто-то где-то не выполняет свою работу правильно.
Если команда разработчиков не участвует в согласовании требований или получении критериев приемлемости, то это провал менеджмента - потому что это означает, что тот, кто недостаточно понимает код и технические проблемы, поставил бизнес перед неполным набором требований, и оставил проект открытым для неверного толкования, ползучести, позолоты и т. д.
Если команда разработчиков вовлечена в сбор и согласование требований, то это может быть провал команды, которая несет ответственность за уточнение деталей (и критериев приемлемости - то есть, «Как выглядит результат? Когда это сделано ?»). ). Команда разработчиков также отвечает за отказ « НЕТ», когда возникают другие проблемы с блокировкой или если требование просто нереально.
Так что, если разработчики участвуют в захвате требований:
Скорее всего, производительность вашей команды не проблема; Ваша команда, вероятно, прилагает все усилия, которые они могут приложить в отношении развития. Ваши реальные проблемы могут быть одним или несколькими из следующих:
... список может продолжаться намного дольше.
Вы должны сделать некоторые "выяснения фактов" и выяснить, почему оценки постоянно отсоединены от реальности. Является ли существующее базовое программное обеспечение плохим? У него нет покрытия модульным тестом? Ваши разработчики избегают общения с руководством? Руководство избегает общения с разработчиками? Есть ли несоответствие между ожиданиями руководства и ожиданиями разработчиков, когда дело доходит до «Определение выполненного» ?
источник
Мой совет перезагрузить команду - выбрать наименьшую возможную историю для каждой команды, для каждого спринта и завершить одну и только одну историю!
Я согласен с другими авторами: либо команда некомпетентна, либо они пытаются сделать слишком много вещей.
Начните с самых маленьких вещей, самых урезанных историй и завершите один спринт. Сделайте так, чтобы команда закончила спринт и добилась успеха, и это поможет им понять, как расставить приоритеты во времени и в работе. Со временем команда сможет выполнять все больше и больше работы, пока не достигнет своей максимальной производительности.
источник
Вы должны собирать данные и строить доверительные уровни на основе прошлых результатов.
http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/
Простейший пример - спринты с постоянным временем, например каждые две недели. Оцените, сколько очков истории команда закончит в течение двух недель. Затем, после того, как двухнедельный спринт закончился, посмотрите, сколько баллов было фактически завершено. Со временем вы можете увидеть, что вы оценили 15 баллов, но только финишировали 10. В этом простом случае вы можете начать движение вперед с регулировкой скорости, поэтому вы планируете только 10 баллов за спринт. Или что вы планируете закончить 66% сметной работы.
Выстраивая уровни достоверности со стандартными отклонениями, вы можете сказать руководству: в соответствии с текущими целями проекта мы ожидаем, что только 50% уверенности мы сможем завершить за 3 недели, а 95% уверенности мы сможем завершить за 5 недель.
источник
Идея Agile и Scrum заключается в том, чтобы создать тесную обратную связь, чтобы вы могли оценить свой процесс. Вы должны спросить «Где это сломалось?», Так как оно, кажется, полностью сломалось.
Устранять проблемы (анализировать обратную связь и адаптировать)
Вернуться к первому шагу и повторять до выпуска ...
Есть ли в документации препятствия, проблемы с соединением, создающие зависимости, проблемы со связью, недостаточно информации в требованиях? ... Что? Разработчики потратили свое время на изучение новых технологий? Они потратили огромное количество времени на дизайн? Были ли такие вещи, как обучение, учтены в списке задач спринта?
Как вы думаете, ваша команда думала, что они изолировали свои проблемы в каждой ретроспективе? Команда действовала, чтобы исправить проблемы. Разве команда не ответила, а руководство просто продиктовало решения и курс действий?
Учитывая длительный промежуток времени, что-то не так системно, а не просто с разработчиками. В какой - то момент (до того, как год был вверх) кто - то в команде ( в том числе мастер схватки) должен был спросил, на что, однако мало, может мы достигаем?
источник
В твоей ситуации ретроспективы уже поздно.
Проводите ли вы ежедневные встречи в режиме ожидания и действительно ли получаете от людей статус о том, что они делали в предыдущие 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 в качестве методологии управления проектами, если вы также не следуете хорошим процессам разработки. Вы проводите автоматическое модульное тестирование? или, еще лучше, автоматизированное приемочное тестирование? У вас есть пара разработчиков, или вы хотя бы часто делаете обзоры кода и / или прохождения? Вы практикуете какую-то форму непрерывной интеграции?
источник