Парное программирование со Scrum


10

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

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

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

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

Рассмотрены следующие варианты:

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

Ответы:


4

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

То есть, если для одного человека предполагается, что задача займет 3 часа, выделенное время для пары составит 6 часов.

Замените часы на очки, если это заставляет вас чувствовать себя более чистым;)


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

15

Я думаю, что другие уже дали хорошие ответы, но я добавлю свои только потому, что я думаю, что ваша команда только что перешла на 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 из команды, насколько смогу».

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

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

В вашем случае, возможно, парное программирование не является решением, если вы ищете другую внешнюю силу, которая придет в команду и скажет им, как работать. Вместо этого выкиньте правила, сядьте с ними без руководства и спросите их, что они хотят делать? Что сделает их счастливыми? Продуктивное? Определите самые большие проблемы и затем спросите КОМАНДУ, какое, по их мнению, должно быть решение.


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

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

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

«Не моя работа» означает «мне все равно», и это ваша самая большая проблема. Agile для разработчиков, которые заботятся и могут взять на себя ответственность. Команда несет ответственность за продукт. Нет «Я несу ответственность за одну часть» = член команды должен заботиться обо всем продукте. Почему у вас есть функциональные зоны? Это потому, что ваш продукт такой большой?
Ладислав Мрнка

@LadislavMrnka: Хотя в команде могут быть люди, которым все равно, и я думаю, что все в порядке. Эти люди станут рабочими мулами для ошибок и дерьма, потому что основные решения, направление продукта, архитектура и дизайн будут проходить мимо них. Но вам все еще нужен кто-то, чтобы иметь дело с техподдержкой :). Я думаю, что большинство из нас заботится о том, что мы делаем. И если вся команда настроена «не на мою работу», я думаю, что коренной причиной является какой-то другой внешний фактор, который необходимо выделить и устранить. Без этого невозможно поручить команде «вы должны заботиться».
ДХМ

2

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

Из руководства Scrum :

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


1
Интересно. У меня есть Scrum Guide в марте 2009 года, и они действительно изменили эту цитату. Раньше это было: « Команда самоорганизуется, чтобы назначить и выполнить работу в Журнале Спринта, либо на собрании по планированию Спринта, либо точно в срок во время Спринта».
Клифф

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

@ Cliff - Если ты так хочешь, это нормально. Все, что я говорю, это то, что Scrum не говорит, что ты должен делать это таким образом. Если вы предпочитаете назначать элементы в парах (что обычно делается в качестве страхования от попадания на автобусе), это тоже хорошо, и вы можете легко рассчитать метрики на основе пар.
Мэтью Флинн

0

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

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

Почему? Оценка это мусор. Как это может быть мусором? Потому что выполнение большей оценки не принесет большей ценности для бизнеса = это мусор и должно быть сведено к необходимому минимуму. Минимум оценивает / оценивает истории, которые помогут вам выполнить обязательство. После того, как вы взяли на себя обязательство, вам не нужны никакие другие оценки. Вы просто знаете, что у вас есть фиксированная дата, чтобы доставить то, что вы совершили. Вы либо сможете доставить преданные истории, либо нет. Оценка задач не поможет вам в этой доставке.

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

Просто чтобы было понятно. Обязательство означает = Мы сделаем это . Не будем пытаться делать это или что-то другое. Да, вы можете не выполнить то, что вы совершили, но ваше обязательство должно основываться на вашей вере в то, что с вашими текущими знаниями вы будете передавать выбранные истории. Если у вас есть это убеждение, вам не нужна другая оценка.

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.