Я работаю в команде, которая в настоящее время использует Scrum, и мы рассматриваем возможность добавления парного программирования, чтобы улучшить межфункциональные навыки команды, а также помочь уменьшить дефекты с философией «две головы лучше, чем одна».
В нашей команде каждый член команды обычно подписывается на полную рабочую нагрузку во время планирования спринта («полный» - это число, которое составляет менее 40 часов в неделю, с учетом собраний, совместной работы и т. Д.), С одним выделенным владельцем для каждое задание Я полагаю, что это довольно часто встречается в командах Scrum, но не обязательно из книги.
В частности, я стараюсь избегать ситуации, когда члены команды колеблются в паре, потому что у них есть свои собственные задачи для работы, что, я боюсь, может произойти, если команда просто самоорганизуется без времени, отведенного для спаривания ,
Учитывая это, каков наилучший способ учесть усилия / часы / сюжетные моменты в сценарии сопряжения, чтобы убедиться, что мы соответствующим образом отводили время для сопряжения?
Рассмотрены следующие варианты:
- Разрешить двум людям подписаться на каждую задачу и (примерно) удвоить количество часов
- Только участник команды «руки на клавиатуре» подписывается на каждую задачу, которая оценивается на основе предполагаемых часов этого человека. Любой в команде, который будет поддерживать спаривание, подпишется на меньшее количество задач в спринте, чтобы дать время для поддержки спаривания.
Я думаю, что другие уже дали хорошие ответы, но я добавлю свои только потому, что я думаю, что ваша команда только что перешла на Scrum, и теперь вы, ребята, находитесь в очень похожей позиции, в которой мы были, когда мы начинали.
Во-первых, наше знакомство с Agile, а точнее Scrum, было не очень гладким. В основном менеджмент пришел и сказал, что с этого дня вы должны делать Scrum, и вы будете следовать этому процессу. Так много для людей над процессом .
Процесс, которым мы первоначально следовали (я бы добавил, вслепую), оказался очень похожим на то, что вы описали. Людям назначают задачи, всех забронируют, и мы все возвращаемся к нашим столам и отключаемся. Тогда у нас есть скучная стоячая встреча каждый день.
Ключ к пониманию заключается в том, что Agile, в том числе Scrum, на самом деле о людях. Когда команда приступает к планированию итераций, не позволяйте своему мастеру Scrum (который, вероятно, является вашим менеджером) назначать вам часы, истории и задачи. Это полностью до команды. Я думаю, что для многих людей это очень сложная концепция, потому что в течение многих лет до этого они приходили на работу и у них был начальник (менеджер, технический руководитель ...), который просто назначал бы работу. Они погружаются в Scrum, но все (включая самого scrum master) продолжают работу в том же режиме.
Однажды вам это надоест, и вы начнете читать книги, блоги и будете задавать подобные вопросы на стеке. Осознание того, что вы получите, заключается в том, что вы, как разработчик, и ваши товарищи по команде, должны быть движущей силой принятия историй и задания. Если вы, ребята, чувствуете, что выиграете от парного программирования, непременно создайте 2 задания для каждого из инженеров и назначьте им оба часа. Единственное, что должен делать мастер схватки, - это измерение скорости по сравнению с законченными историями, которые вы поставили КАК КОМАНДУ на предыдущей итерации.
Еще одна вещь, которая выводит меня из себя, это то, как людям говорят, что их емкость ВСЕГДА составляет 75% от общего количества часов, так что это то, что они обязуются, а затем на протяжении всей продолжительности итерации они жалуются, что а) они не могут помочь вам или б) они не могут поступить правильно, потому что им отведено слишком много часов. Людям не нужно сообщать, сколько часов нужно совершить, и им, безусловно, следует отодвинуться, если мастер схватки пытается что-то подобное сделать! Каждый должен делать то, что ему удобно. Например, я руководитель группы и часто бываю в случайной незапланированной дискуссии о дизайне, или помогаю кому-то с кодом, или с устранением странных проблем, поэтому моя емкость никогда не превышает 50%.
Наша команда выпустила 4 цикла релизов, чтобы научиться не делать то, что я только что упомянул, и хотя мы определенно улучшили, если вы спросите экспертов, мы даже не наполовину проворны. Так что еще много учусь делать.
Обновление 1: Ответ на комментарий Клиффа Ну, вы предложили свои уши, так что вот оно ...
Вы правы, культурный сдвиг является ключевым, но этот сдвиг не обязательно должен происходить на исполнительном уровне. Ваш собственный руководитель группы может изменить культуру в вашей команде и изолировать вас, ребята, от корпоративной BS, с которой ему приходится иметь дело. То, что вы описываете, было ТОЛЬКО нами с 2007 по 2010 год. Наша команда (и другие команды тоже) выпускали релиз после релиза. В одном из выпусков, использующих «процесс гибкости» руководства, нам удается заставить 9 человек выполнить работу, которую обычно выполняет один человек, и нам понадобилось вдвое больше времени. У меня было так много свободного времени, что я даже обновил свое резюме.
Затем я поговорил с моим боссом и объяснил ему все, что такое гибкость в отношении людей, и что если вы хотите, чтобы мы заботились о продукте, давайте принимаем решения, которые влияют на то, как мы работаем над продуктом и предоставляем его. Я думаю, что он решил сделать из этого эксперимент, он сделал каждое изменение, которое мы ... ну, в основном, я, но я много общаюсь с остальной командой, следовательно, 50% возможностей :) ... предложено. Возможно, он решил, что если он внесет все изменения, о которых мы просим, и мы все равно потерпим неудачу, он вернется с победным «Я тебе так сказал».
Так что за последние 12 месяцев мы устранили столько «глупостей», что это даже не смешно. Наши постоянные встречи действительно имеют смысл сейчас, потому что мы работаем вместе, а не в изоляции. У нас все еще есть право собственности (по крайней мере, на данный момент) на определенные части продукта, но мы также очень часто пересекаемся в коде друг друга. Мы постоянно проводим обзоры кода, чтобы не только члены команды изучали другой код, но и изучали лучшие методы кодирования и проектирования. Мы разбили монолитную, гигантскую «гибкую» команду на 3 разных команды, поэтому планирование и другие встречи намного короче, и люди на самом деле заботятся о них, потому что они не сидят и не слушают вещи, которые им не нужны. Я' мы видели ночи, когда 4 из 5 наших парней (одна из команд) были в онлайне в 23 часа вечера, и никто на самом деле не говорил нам, что мы должны усердно работать, или когда-либо заставляли нас работать более 40 часов. Люди, которым пол года назад было наплевать, внезапно становятся занятыми и взволнованы работой, которую делают. И все, что понадобилось нашему менеджеру, это сказать: «Вы, ребята, решаете, что правильно, и делайте то, что вам нужно, и я постараюсь исключить корпоративную BS из команды, насколько смогу».
Это началось как эксперимент (по моему подозрению, он никогда не говорил мне об этом), но теперь наша группа делает большой удар по сравнению с другими группами разработчиков в отделе, и у нас даже есть другие разработчики, которые сейчас пытаются прийти и присоединиться к нам.
Самым большим препятствием для нас с тех пор, как это изменение произошло (и остается проблемой сегодня), было то, что инженеры в обычной корпоративной среде похожи на экспериментальных мышей в клетке. Даже когда ваш менеджер решает действовать по-настоящему «проворно» и убирает клетку, все в этой клетке так долго находятся, что даже не осознают, что свободны. Так что даже при всей свободе они продолжают действовать так, как будто они все еще ограничены. Я думаю, что было бы полезно, если бы в команде было как минимум несколько человек (таких как вы), которые выходят за пределы группы и ищут более эффективные способы ведения дел. Затем вернитесь в эту группу и немного перемешайте.
В вашем случае, возможно, парное программирование не является решением, если вы ищете другую внешнюю силу, которая придет в команду и скажет им, как работать. Вместо этого выкиньте правила, сядьте с ними без руководства и спросите их, что они хотят делать? Что сделает их счастливыми? Продуктивное? Определите самые большие проблемы и затем спросите КОМАНДУ, какое, по их мнению, должно быть решение.
источник
Scrum не обязывает назначать задачи отдельным лицам - это далеко не так. Ответственность за выполнение задач ложится на Команду в целом. Если команда хочет заняться парным программированием, когда каждая пара выбирает задачу, она, безусловно, должна это сделать.
Из руководства Scrum :
источник
Распределение заданий на совещании по планированию - это именно то, что противоречит своевременным решениям и расширению возможностей команды. Это также идет вразрез с ловкостью спринта, потому что с первого дня спринта каждый разработчик выровнял, что ему делать. Это также означает, что каждая задача должна быть очень правильно оценена, чего почти никогда не бывает.
Имхо оценка задач излишня. Вы посвятили себя работе над набором историй, и для планирования встречи 2 достаточно времени, чтобы разделить эти истории на задачи и создать карточки для этих задач (или заполнить их какой-либо системой). Недостаточно времени для оценки каждой задачи, и эти оценки не должны занимать время для реальной разработки.
Почему? Оценка это мусор. Как это может быть мусором? Потому что выполнение большей оценки не принесет большей ценности для бизнеса = это мусор и должно быть сведено к необходимому минимуму. Минимум оценивает / оценивает истории, которые помогут вам выполнить обязательство. После того, как вы взяли на себя обязательство, вам не нужны никакие другие оценки. Вы просто знаете, что у вас есть фиксированная дата, чтобы доставить то, что вы совершили. Вы либо сможете доставить преданные истории, либо нет. Оценка задач не поможет вам в этой доставке.
Пропуск оценки заданий никоим образом не повлияет на видимость прогресса в спринте, потому что единственное реальное измерение прогресса - это количество завершенных историй (сюжетных точек), и это все еще может быть показано в диаграмме выгорания спринта.
Просто чтобы было понятно. Обязательство означает = Мы сделаем это . Не будем пытаться делать это или что-то другое. Да, вы можете не выполнить то, что вы совершили, но ваше обязательство должно основываться на вашей вере в то, что с вашими текущими знаниями вы будете передавать выбранные истории. Если у вас есть это убеждение, вам не нужна другая оценка.
Я всегда использовал Scrum так, чтобы разработчик выбирал новое задание после того, как он завершил свое последнее. Разработчики обычно говорят, какой из них они выберут на фуршете. Вообще нет правил, какую задачу он должен выбрать. Это зависит от самоорганизации команды и обсуждения между членами команды (вне совещания). Это откладывает решение до последней возможной точки, где вы можете реагировать на некоторые изменения и проблемы, не затрагивая ваш воображаемый план. Само задание может даже сменить владельца, если у кого-то возникнут проблемы с его выполнением - альтернативно, такое задание может быть разработано в паре.
Как парное программирование может быть вовлечено в это? С легкостью. Команда делает обязательство, и команда должна сделать так, чтобы освободить место для всех методов разработки, необходимых для обеспечения рабочего прироста продукта. Вы оцениваете задачу или разработку задачи и тестирование задачи? Последний подход совершенно неверен. Тестирование является частью разработки, и, в случае необходимости, проверка кода или сопряжение являются частью разработки.
Выполнение парного программирования должно привести к более быстрому выполнению задачи с меньшим количеством ошибок и лучшим качеством кода. Это не будет в два раза быстрее, поэтому будут некоторые накладные расходы, но реальное влияние на обязательства, вызванное случайным спариванием, должно быть очень небольшим. Это не тот случай для наставничества или обучения. Если у вас есть такой разработчик, который нуждается в наставничестве или обучении, вы не должны планировать его возможности вообще для спринтов, где он изучает кодовую базу продукта или какую-либо технологию.
источник