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

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

Как справиться с этим? Несколько проблем ..

• Во время следующего спринта члены этой команды говорят, что работа по программированию завершена на 99% и требует только проверки и тестирования кода. Как вы справляетесь с этим в SCRUM и гибкой методологии?
• Другие разработчики жалуются на то, что они не участвуют в проектных решениях, связанных с этими историями, так как работа была сделана вне группы.
• Наш владелец продукта испытывает искушение участвовать в этой «бесплатной» работе, и участники с перевесом, вероятно, делают это специально, чтобы получить больше функций в продукте, которые в противном случае команда не смогла бы выполнить в спринте (-ах). Существует мнение, что это нарушает «процесс». Очевидно, что над этой работой еще предстоит выполнить работу по обеспечению качества, пользовательскому интерфейсу и документации.

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

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

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

ПОЗВОЛЬ ИМ

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

Я знаю нескольких удивительных программистов, которые покинули компании, потому что они не позволили программистам выйти за пределы ограничений искусственной системы, такой как Scrum (я сам оставил свою последнюю работу после того, как ко мне относились как к прославленному QA). Если есть жалобы от других разработчиков на ввод (вполне обоснованные жалобы, я могу добавить), может быть лучше ввести программу «20% времени», чтобы позволить ему (и другим) делать то, что они делают лучше всего с минимальным вмешательством.

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

Есть две вещи, которые я думаю, вы должны рассмотреть здесь:

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

Точка 2, скорее всего, беспокоит других разработчиков.

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

Так что ты можешь сделать?

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

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

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

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

Верни его в команду

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

Почему это поведение проблемы?

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

Но тут возникают другие проблемы:

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

Следующее почему я бы как есть:

Почему разработчик делает это?

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

Получив ответ на эти вопросы, вы можете начать отвечать на свой вопрос:

• если это не проблема, пусть он делает свое дело. Хотя некоторые люди считают SCRUM религией, так не должно быть.
• Скорее всего, в команде есть две проблемы: одна (ие), вызванная мошенническим разработчиком, и одна (ие), вызывающая поведение мошеннического разработчика. Найдите способ решить позже, и первый уйдет.

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

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

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

Может быть, вы получите решение, в котором каждый будет работать над своими любимыми проектами и выносить их на стол (вы можете вообразить хаос в вашей доставке, который вызвал бы :), что в первую очередь подчеркивает проблему с ним), или вы можете поручить область, в которой каждый разработчик имеет автоматику для разработки любого решения, которое им нравится, является «вкладом», аналогичным тому, как работает много проектов с открытым исходным кодом, или вы можете дать каждому немного свободного времени для экспериментов (старые 20% времени).

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

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

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

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

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

Просто мы начали прогнозировать PBI, а не брать на себя обязательства. Прогнозирование в основном означает, что мы выбираем 25 точек при планировании и начале спринта, и когда программист освобождается в середине спринта, потому что больше нет задачи кодирования, поэтому он выбирает один из будущих PBI, помещает его в Current Sprint и начинает работать на этом, если PBI мог пройти весь процесс (тестирование, объединение и т. д.) в пределах одного и того же спринта, это бонусное очко для команды, если НЕ мы не провалим спринт из-за этого PBI и просто перенесем оставшуюся работу ( тестирование, мейджинг и т. д.) до следующего спринта и повторный покер на оставшуюся работу. Так что это может быть сделано в двух разных спринтах в худшем случае. Я знаю, что это может звучать как Scrumbut, но на самом деле это улучшило нашу работу. Я просто могу суммировать его преимущества, как показано ниже:

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

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

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

В Scrum нет ничего, что могло бы предписывать, как люди работают, и все, что он делал, было бы естественно включено в скорость команды.

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

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

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

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

Возможно ли, чтобы вы позволили остальной части команды достичь большего?

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

Пусть они тоже будут учителем

Здорово, что у вас есть звездный разработчик с лучшими и самыми продвинутыми навыками в группе. Я бы похвалил и похвалил это. Часто такие люди являются «клеем», который объединяет организации.

Я бы рассматривал проблему как «как сделать менее опытных разработчиков ближе к производительности самого продвинутого разработчика».

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

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

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

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

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

1. Программист делает хорошую работу.
2. Все ли в порядке с ним, выполняющим свою работу самостоятельно (хорошо это или плохо). В конце концов, он уклоняется от процесса проектирования!
3. Оплачены ли дополнительные часы или нет.

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

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

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

Команда (не ПО или ScrumMaster) должна решить эту проблему с мошенническим программистом.