Здравствуйте, cvetkov, Вы писали:

C>Здраствуйте, меня зовут Алексей и у меня проблема.
C>Я скраммастер в довольно крупной команде.
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому.
C>Я уверен что эта проблема известна и есть рекомендации по ее решению.
C>Порекомендуйте пожалуйста литературу.

Я считаю, что все проблемы в людях. Рекомендую http://www.mccarthyshow.com/ — подкасты, книга Software For Your Head, набор "протоколов" The Core Protocols (в частности глянь описание протокола "Decider" для принятия решений в группах и протокол "Meet" для митингов — http://liveingreatness.com/additional-protocols/meet/). Это от бывших майкрософтовцев, которые уже лет 20 изучают командную работу "на опытах".

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

Здравствуйте, Brutalix, Вы писали:

B>пока митинговало 3-5 человек, да не каждый день (ечли не о чем говорить — митинг отменяли), было более менее. Потом нороту прибавилось (набрали новых, + соседей к себе взяли). и когда митинговало 20 человек, уже было забавно

20 человек?! Даже если каждый всего пару минут поговорит — это ж 40 (СОРОК!) минут чисто чтоб статус доложить. А уж если в самом деле побрейнстормить — часа два считай пропало. Такие большие команды надо дробить на scrum of scrum, когда у обычных разработчиков есть лишь митинг в небольшой рабочей группе (5 девелоперов плюс-минус дельта), а затем "староста" группы идёт на менеджерский скрам, где в компании ещё нескольких "старост" можно обсудить как идёт дело (плюс такие high-level митинги "старост" можно делать не каждый день).

Здравствуйте, cvetkov, Вы писали:

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

По фичам, по тому, что урезать, что должно входить в релиз, что нет, есть еще одна роль. Называется product owner. Он исходя из фактической производительности разработчиков пытается определить, какую фичу целосообразно делать и к какому релизу, чтобы продукт развивался. Соответсвенно здесь за ним последнее слово, делаем такую то фичу или не делаем, замораживаем и т.д.

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

Здравствуйте, bazis1, Вы писали:

B>Scrum — это хороший подход, но он в первую очередь оптимизирован под поддержку, а не разработку.
Мне лично казалось, что для поддержки как раз лучше брать canban. Ибо при скраме поддержке пока клиент получит фикс своего бага, пройдет черти сколько времени. Пока баг запланируют, пока закончится итерация, пока начнется итерация тестирования, пока она закончится — за это время заказчик на нервы изойдется если бага критичная. Ему сейчас фикс нужен.

А как раз при разработке scrum работает неплохо. В определенные промежутки времени мы получаем результат, что то рабочее, что можно посмотреть, провести демо, оценить достоинства и недостатки. А также темп виден, можно скорректировать планы и тому подобные вещи. И особенно хорошо скрам работает если требования меняются. Если мы сами не знаем чего хотим, сами ищем как сделать лучше. Сделали фичу, смотрим на реакцию пользователей. Пользователи говорят что все круто, хотим еще — продолжаем развивать. Пользователи не заметили, видим, что фичей не пользуются и ее не продать — сворачиваем работы в этом направлении и думаем над другими фичами, которые востребованы. Ну а если требования постоянны, то водопад рулит, как и раньше.

MD>20 человек?! Даже если каждый всего пару минут поговорит — это ж 40 (СОРОК!) минут чисто чтоб статус доложить.

(nowork) напрашиается приём оптимизации митинга — говорить одновременно, а не по очереди.

Здравствуйте, cvetkov, Вы писали:

C>Порекомендуйте пожалуйста литературу.

Просто так читать книжки бесполезно. Попробуй развести компанию на тренинг по организации митингов, вроде у Орлов & Панкратов был такой на котором разбирают типичные ситуации.

Здравствуйте, pagrus, Вы писали:


MD>>20 человек?! Даже если каждый всего пару минут поговорит — это ж 40 (СОРОК!) минут чисто чтоб статус доложить.

P>(nowork) напрашиается приём оптимизации митинга — говорить одновременно, а не по очереди.

Вот так и начинаются традиции петь корпоративные гимны — всё равно ж никто не слушает

E>По фичам, по тому, что урезать, что должно входить в релиз, что нет, есть еще одна роль. Называется product owner. Он исходя из фактической производительности разработчиков пытается определить, какую фичу целосообразно делать и к какому релизу, чтобы продукт развивался.

В классическом scrum product owner не определяет, "что должно входить в релиз".
Более того, понятие "релиз" идет не из scrum, а из product management.

Обязанность product owner — набивать backlog сценариями (user story), где для каждого сценария есть более-менее точно определенная ценность (business value). В задачи команды входит определить сложность реализации сценария. Далее backlog сортируется по соотношению business value/SP (в некоторых случаях с учётом зависимостей между сценариями, которых, в теории, быть не должно, но на практике они есть). В следующий спринт идут сценарии, несущие самое лучшее соотношение.

Релиз-менеджмент тема отдельная, роль PO в скрам не определяет эти обязанности. Хотя конкретный человек может и совмещать роль PO и product manager.

Здравствуйте, cvetkov, Вы писали:

C>тут я ничего поделать не могу, скрам это реальность данная нам свыше.
Нет. Реальность (жестокая) — это что у вас работа не продвигается.
А скрам — это унылая виртуальность.