Я думаю, что другие уже дали хорошие ответы, но я добавлю свои только потому, что я думаю, что ваша команда только что перешла на 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 из команды, насколько смогу».
Это началось как эксперимент (по моему подозрению, он никогда не говорил мне об этом), но теперь наша группа делает большой удар по сравнению с другими группами разработчиков в отделе, и у нас даже есть другие разработчики, которые сейчас пытаются прийти и присоединиться к нам.
Самым большим препятствием для нас с тех пор, как это изменение произошло (и остается проблемой сегодня), было то, что инженеры в обычной корпоративной среде похожи на экспериментальных мышей в клетке. Даже когда ваш менеджер решает действовать по-настоящему «проворно» и убирает клетку, все в этой клетке так долго находятся, что даже не осознают, что свободны. Так что даже при всей свободе они продолжают действовать так, как будто они все еще ограничены. Я думаю, что было бы полезно, если бы в команде было как минимум несколько человек (таких как вы), которые выходят за пределы группы и ищут более эффективные способы ведения дел. Затем вернитесь в эту группу и немного перемешайте.
В вашем случае, возможно, парное программирование не является решением, если вы ищете другую внешнюю силу, которая придет в команду и скажет им, как работать. Вместо этого выкиньте правила, сядьте с ними без руководства и спросите их, что они хотят делать? Что сделает их счастливыми? Продуктивное? Определите самые большие проблемы и затем спросите КОМАНДУ, какое, по их мнению, должно быть решение.