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

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

Как вариант: любой сервис опросов с отправкой результатов на почту типа Limesurvey. Насколько я знаю, в slack можно настроить переадресацию почты. + любая напоминалка о том, что нужно пройти опрос. Напоминать регулярно может все что угодно: от будильника в телефоне до google календаря.

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

1) Оценка как правило основывается на прежнем опыте. Задачи с новой технологией и новой базой не имеют достаточной основы для оценки. Желательно сначала создать исследовательскую задачу. Результатом этой задачи должна стать оценка. Исследовательскую задачу тоже не просто оценить, но ее можно ограничить. Например: "Дать оценку с той точностью, которую можно получить, потратив 16 часов на исследование." В любом случае - это будет точнее, чем оценка "навскидку". Если задачу будет оценивать 1 человек, а не покером, то для уточнения используйте оценку по 3 точкам.
2) 50 часов - это немного больше человеко/недели. У вас спринт - меньше недели? Если все же задача выходит за границы спринта, ее нужно дробить на части (желательно не больше 3-4 человеко/дней) и распределять эти новые задачи по следующим спринтам в общем порядке. Еще один вариант - подумать можно ли получить ту же бизнес-ценность другим, менее затратным путем.
3) В скраме вместо гантта используют диаграмму сгорания. Ее двигать не надо, нужно просто дорисовывать каждый день. Кстати, при использовании гантта, его вручную двигать не нужно, если есть регулярное обновление статусов от разработчиков (например в MS Project).

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

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

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

Не знаю, что ты имеешь в виду под переходом cо Scrum на Agile, посколько Scrum - это управленческий framework в рамках Agile подхода.
По существу вопроса: Все, что в перспективе экономит время разработчиков (рефакторинг, оптимизация, документирование кода, настройка инфраструктуры и т.п.) - это технические истории. Их тоже необходимо включать в бэклог и спринты.
Вот некоторые из способов, как это делать:
a) Сделать из них обычные истории, найдя преимущества для заказчика
b) "Продать" их ожидаемый результат продакт овнеру, как повышение фокус-фактора
с) Дополнять ими спринты, в которых идет опережение срока
d) Договориться о том, что максимальное количество незакрытых технических историй должно быть фиксированным и верхние по приоритету - всегда попадают в спринт наряду с обычными историями.

Для MVP используйте одну из платформ e-commerce с бесплатным или пробным тарифным планом, типа Ecwid и т.п.
После того, как проверите гипотезы и получите продажи, можете подумать о переходе на платный план или на другую платформу.

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

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

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