Андрей Плетенев

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

Если говорить не о командных, а о персональных KPI программистов, то для переменной части з.п. я применяю персональный фокус-фактор и показатель качества отладки + оценка руководителя. Если интересно - обращайтесь в личку.

1) На практике это означает a) Людей в команду желательно подбирать более универсальных, владеющих разными технологиями и без амбиций типа "яжпрограммист, я не буду тестить". b) Если выбирать не приходится и вам достались узкие специалисты и при этом команда постоянная, то занимайтесь ее развитием, расширяя их компетенции. Это долго, но стоит того. с) Если специалисты узкие и даны на короткое время, тогда обходитесь без кроссфункциональности. Это не догма, как и все остальное в скраме.
2) В planing poker не могут участвовать 2 человека. Участвует вся команда. Кроме того на практике джуниор обычно не спорит с сеньором, а прислушивается к нему. По времени планирование спринта - ограничено. (мах 8 часов для больших и сложных спринтов) Скрам-мастер должен следить за тем, чтобы обсуждение шло конструктивно и не буксовало. Если кто-то уперся рогом в землю, не может убедить других и не слушает их аргументы - это не командное поведение. А команда - это основа agile. С ним нужно проводить воспитательную работу. Если это регулярно - возникает вопрос, действительно ли его место в этой команде.
3) Все необходимые виды тестирования должны проходить в рамках спринта. Желательно использовать Continuous Integration и тесты, включая нагрузочные гонять регулярно. Разработчики, реализуя user stories должны думать о производительности, как и о многом другом. Разумеется, требования к производительности должны быть им озвучены.
4) Это не скрам, а одна из практик экстремального программирования. Применял в компании SiberLogic. В случаях, когда было критически важно, несмотря на затраты, быстро и качественно запилить задачу за часы.
5) Коммуникацию с заказчиком в скраме обычно осуществляет продакт. Он же и отвечает перед ним. Команда отвечает перед продактом. На практике в некоторых компаниях перед заказчиком отвечает ПМ, который находится снаружи скрам-команды.
6) За найм и увольнение отвечают те же люди, что и без скрама. Это может быть директор или HR. Иногда этим занимаются ПМы. Однако, скрам-команда может "вытолкнуть" человека, если он в нее не вписывается. Если разговоры по душам не помогают, то человека перемещают в другую команду или в другую компанию :)

По книжкам скрам не внедряется. Если будут еще вопросы, пишите в личку.

a) Если объем доработок имеет небольшие колебания: На основе имеющейся статистики рассчитайте ресурс, который в среднем тратится на доработки. Выделите его для этой цели и не включайте в планирование остальных проектов. При этом, если в какой-то период не потребуется доработок, этот ресурс будет все же подключаться для помощи в других проектах.
b) Если объем доработок имеет сильные колебания
тогда

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

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

1. Способ принятия решений это не догма, как и все в скраме. Его выбирает команда. Можете использовать a) классический подход - консенсус (демократично, но медленно), b) решать большинством (менее демократично, но быстро), c) доверить оценку тем, кто наиболее вероятно будет делать задачу. В т.ч. это можно делать за рамками скрам-митинга, хотя и не рекомендуется. Если в случае b) голоса разделились поровну, то можете либо продлить обсуждение, пока один человек не изменит мнение, либо всегда использовать правило выбора меньшей (вызов) или большей (запас) оценки.
2. Судя по описанию, проблема в том, что команда пока не вполне зрелая для agile. Среди ценностей гибкой разработки важную роль играют взаимное доверие и самоорганизация. Если люди обижаются, когда другие не соглашаются с их мнением, это означает, что они ставят свое эго выше интересов команды. Так бывает в командах, которые стали командой просто по назначению начальства. Берут сам фреймворк, процедуры, но никто не думает о главных принципах. Внедрение ценностей скрам - дело скрам-мастера. Объяснять, воспитывать, в первую очередь собственным примером. Как только появится несколько лидеров, которые проникнутся - остальные подтянутся. Дальше - будет легче. Новички будут адаптироваться наблюдая за остальными.
Чтобы люди не пытались "попасть в ту же цифру" используйте planning poker. А цель обсуждения - не "отстаивать свое мнение", а дать команде больше информации для принятия взвешенного решения.