Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению.
Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению.
Проблема давно известна и имеет широко известное решение, оно называется "начальник" или "главный конструктор".
Дальше я бы мог написать много матерных слов по поводу того, что почему-то во всех остальных областях это прекрасно работает, а программистам какого-то хрена нужны "самоорганизующиеся команды".
C>Я скраммастер в довольно крупной команде. C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению.
Классика: книга Майка Коэна Agile Estimating and Planning.
Попробуйте описать ситуацию подробнее. В известном мне SCRUM есть ровно три варианта митингов: daily stand-up (15 min), sprint planning (2 hr) и sprint exit (2 hr). В скобках указаны максимальные продолжительности таких митингов. Начинающие скрам-команды, или команды из более чем 8 человек, могут иметь пропорционально удлиненные таймбоксы. В любом случае, каждый митинг имеет строгий лимит — это одно из правил скрам.
В одном из встречавшихся мне вариантов также присутствовал (неявный) pre-planning meeting, но это скорее набор локальных междусобойчиков из кучек по 2-3 человека + product owner, для того, чтобы PO ответил на вопросы "а вот в этом сценарии если случается А, то нужно сделать Б или В". Тем не менее, эти встречи также учитываются в sprint plan.
Теперь попробуйте честно ответить на следующий набор вопросов:
1. Какие конкретно митинги встречаются с этой проблемой?
2. Что вы делаете для того, чтобы эту проблему решить?
3. Есть ли у вас и у руководства воля для реального решения этих проблем? (это, наверное, самый важный вопрос — очень часто случается, что декларируемая поддержка не есть реальное проявление воли, а, скорее, показное).
4. Какие именно решения ваша команда должна принять, но не может?
5. Есть ли необходимость принять эти решения прямо сейчас, или они могут быть приняты позже?
6. Как скраммастер, справляетесь ли вы с основной задачей — устранением блокирующих разработку проблем (impediments)?
7. Соблюдаются ли требования SCRUM по проведению митингов?
Немного о требованиях к скрам-митингам. Скорее всего, вы их прекрасно знаете, но не лишним будет повторить.
* каждый митинг имеет конкретную цель и конкретный список вопросов
* на митинге есть два типа участников (см. chicken and pigs, здесь, здесь и вообще в литературе по скрам)
* сhicken не имеет права говорить. Если начинает — скраммастер делает предупреждение, затем второе, на третий раз chicken по просьбе скраммастера обязан удалиться
* каждый митинг имеет общее ограничение по времени (ровно такое, какое запланировано в этот спринт)
* на daily standup каждый участник также ограничен по времени (2-3 минуты)
* на daily standup не задаются никакие вопросы (более того, говорить допускается лишь о "планировал то, сделал это, заблокирован этим")
* скраммастер должен прерывать оффтопик, по возможности ненавязчиво (не обязательно давать пинка говорящему — можно просто красный флажок поднимать, или включать кондиционер)
* daily standup должны быть stand up!
Пока вы ищете ответы на заданные вопросы, попробую дать несколько общих рекомедаций. Понимаю, что выступлю вместо Капитана, но всё же.
1. Всегда имейте план встречи со списоком вопросов, которые необходимо решить.
2. При первых признаках переключения на другой вопрос скраммастер обязан прервать выступающего.
3. Не стесняйтесь прерывать chicken. Это ваша работа и за вас ее никто не сделает. Даже если chicken — владелец компании: попросите его войти в положение.
4. Заведите большой таймер-будильник. Да хоть шахматные часы — любое, что может выступать независимым арбитром и дамокловым мечом.
Ну и самая важная рекомендация, к которой, увы, мало кто прислушивается — пригласите хорошего скрам-консультанта, чтобы он смог обнаружить ошибки и проблемы в вашей реализации скрам. Кстати, а кто именно учил вас и вашу команду?
Здравствуйте, <Аноним>, Вы писали:
А>Проблема давно известна и имеет широко известное решение, оно называется "начальник" или "главный конструктор".
А>Дальше я бы мог написать много матерных слов по поводу того, что почему-то во всех остальных областях это прекрасно работает, а программистам какого-то хрена нужны "самоорганизующиеся команды".
тут я ничего поделать не могу, скрам это реальность данная нам свыше.
Scrum — это хороший подход, но он в первую очередь оптимизирован под поддержку, а не разработку. Задача — взять группу людей с внешней мотивацией (т.е. людей, которые если теоретически останутся без присмотра, будут просто сидеть и плевать в потолок) и переориентировать их с чтения фейсбука на рутинное исправление багов и прочие подобные занятия. Проблемы появляются, когда этот подход начинают применять везде, где попало.
Команды не принимают решения. Решения принимают люди, способные взять на себя за них ответственность. С другой стороны, от рутинной работы по поддержке стопятисотой версии продукта такие люди убегут нафиг, ибо скучно. И тогда приходят всякие скрамы, цель которых добиться стабильного среднего результата от средних людей, делающих среднюю работу.
Если цель митинга — решить конкретную проблему, а не напомнить команде раздолбаев, зачем они вообще пришли на работу, меняйте формат. Берите сильных людей и делайте их ответственными за решения. Не облажаются — хвала и почет. Облажаются — пусть будут готовы сами разгребать и в следующий раз лучше думают.
Здравствуйте, cvetkov, Вы писали:
C>Здраствуйте, меня зовут Алексей и у меня проблема. C>Я скраммастер в довольно крупной команде. C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению. C>Порекомендуйте пожалуйста литературу.
Была подобная проблема на одной из прошлых работ. На фоне прогрессирующей говорильни и замедлении собственно разработки закончилась добровольным уходом трех из четырех человек нашей субкоманды, включая меня (одного из старших разработчиков), еще одного старшего, тех лида всего проекта и потерей минимум человека-года на переходные процессы (это только то, что успел увидеть я до увольнения).
В той ситуации корень проблемы был в том, что на митингах было слишком много левых людей которым по большому счету было по барабану, какое решение будет принято. По барабану — это не значит, что оно их вообще не волнует, похоливарить лишь бы не работать определенная категория людей всегда рада, по барабану — значит вне зависимости от принятого решения, для левых людей ничего не изменится. И беда даже не в том, что чем больше людей — тем сложнее договориться, а в том, что левые люди начинают принимать решения за которые не будут отвечать.
Что касается именно фокуса митинга, то наш менеджер следил за тем чтоб были выписаны пункты обсуждения, о них говорили последовательно не сильно отклоняясь в сторону, по итогам обсуждения по каждому выписывались действия и ответственные лица. Это необходимо, но недостаточно.
Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому.
Может, надо поменьше митинговать и заняться чем-то полезным?
Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Порекомендуйте пожалуйста литературу.
Тут не литература нужна, а тимлидер, аноним правильно написал.
Из практики:
1. Обязательно нужен человек с банхаммером, который ведёт митинг и не даёт съехать в срач/обсуждение мелких ненужных деталей.
2. Если обсуждать нечего — не надо отрывать людей от работы.
3. Если на вопрос уйдёт больше чем 3-5 минут — не надо обсуждать его на митинге. Лучше собраться отдельно тем, кому этот вопрос интересен и не грузить всех остальных.
4. Не надо выносить сырые идеи на митинг. Если даже докладчик не может описать проблему — чего ждать от остальной команды?
MD>>20 человек?! Даже если каждый всего пару минут поговорит — это ж 40 (СОРОК!) минут чисто чтоб статус доложить.
P>(nowork) напрашиается приём оптимизации митинга — говорить одновременно, а не по очереди.
Вот так и начинаются традиции петь корпоративные гимны — всё равно ж никто не слушает
Здравствуйте, cvetkov, Вы писали:
C>Здраствуйте, меня зовут Алексей и у меня проблема. C>Я скраммастер в довольно крупной команде. C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению. C>Порекомендуйте пожалуйста литературу.
Помните как в старом Ералаше: "Забыл предупредить. Чалма без сковородки не работает".
Так вот про "сковородку". Вы по факту являетесь руководителем.
Не важно, что там говорят в книгах о скрам про роль скрам-мастера.
По факту вам нужно командой руководить. Вот тут-то у вас и проблема: отсутствие власти и авторитета.
Не важно как вы будете прерывать выступающего: флажком или выстрелом в голову, совещаться сидя или лежа,
2 или 20 минут.
Хотите успешно сделать проект? Думайте о себе как о тимлиде.
Вам нужно иметь авторитет лидера в команде.
Многие руководители-программисты разных уровней, придя в новую компанию, ощущают недостаток "авторитета" в новой команде. Проявляется это не в том, что их поручений не выполняют, а, как бы это сказать, в том, что их воспринимают со скепсисом. "Ну, мы, конечно, сделаем, но...". В общем, в той или иной степени повергают "авторитет руководителя сомнению".
Поэтому, "авторитет надо заработать". Тут уж кто во что горазд.
...
Легитимность — есть желание людей подчиняться решениям власти при отсутствии принуждения.
...
Вебер выделяет целых три типа легитимности. Вам уже интересно, правда? Разберем их подробнее:
1) Традиционная легитимность. Деды наши так делали, и мы делать будем. Рюриковичи нами долго правили, старожилы не упомнят, они не подведут. И вообще, власть — она от Бога, а у власти не кто-нибудь, а помазанник божий.
...
2) Легитимность харизматичного лидера. О-о-о, сколько об этом написано. А ведь это по сути и есть тот самый "авторитет", который, как считается, вам нужно "заработать". Смотрите, цитирую википедию: "Этот образ непогрешимого, наделенного исключительными качествами человека (харизма) переносится общественным мнением на всю систему власти. Безоговорочно веря всем действиям и замыслам харизматического лидера, люди некритически воспринимают стиль и методы его правления."
Удобно быть [харизматичным] лидером, ничего не скажешь!
...
3) Рациональная (демократическая) легитимность.
Она основана на нашей вере в правильность процедуры, посредством которой было получено то решение, которому мы должны подчиниться. Для этого, сами понимаете, процедура должны быть открыта, понятна людям, и они должны верить в ее справедливость — это необходимый минимум.
К примеру. Вы с друзьями, после долгих споров, договорились, что примете решение, куда поедете отдыхать, голосованием. Проголосовали. Да, действительно, в результате, получилось не то, что вам нравится, но — вы подчиняетесь принятому решению без споров и принуждения. Магия!
Почитайте.
Ваша цель: рациональная легитимность.
И тут рекомендации SkyDance в самый раз.
В общем, делайте правильные вещи с правильной целью .
Будет желание — отпишитесь потом тут о результатах .
, и вообще в том треде. Краткое содержание: уровень ответственности разработчиков и тестировщиков в точности равен уровню полномочий. Околонулевых для большинства. Поэтому ваше высказывание "Берите сильных людей и делайте их ответственными за решения." по своей сути аналогично "мышки, станьте ёжиками". Люди внутри скрам-команды не могут влиять на бюджет проекта или feature set. Ответственность программистов ограничена их полномочиями. Они не могу принять решение "мы не релизимся в сентябре" или "мы возьмём еще двух человек на проект". Да и нечем программистам отвечать. Особенно, если их зарплата среднерыночная и время поиска следующей работы равно двум неделям обязательной отработки. И вы никак не сможете сделать их "ответственными" — им тупо нечем отвечать.
Если же вы вправду хотите вводить ответственность — готовьтесь ее оплачивать соответственно.
SVZ>А вот как проходит планирование для новых проектов? Когда неизвестно, что делать (вернее, понятно что, но еще непонятно как) и сколько времени это займет? SVZ>Посвятить первый спринт исключительно исследованию?
Это не будет являться спринтом, поскольку на выходе не будет ничего готового, что могли бы "пощупать" пользователи.
А как вы понимаете, что надо делать? Что у вас на входе уже есть? Текст сценариев? Скетчи UI? Откуда они взялись? Может, кто-то уже набивал шишки на этом поле, и можно у него проконсультироваться по планированию?
SVZ>Коллеги, как у вас все это проходит?
На самом старте совсем нового проекта обычно происходит бардак с непредсказуемыми прыжками всех параметров. Первые пару спринтов зачастую вовсе приходится исключить из статистики как нерепрезентативные.
Но с этим, как правило, и бороться нет большого смысла, т.к. новые проекты очень редко запускают сразу с большой командой. Обычно над новым проектом начинает работать лишь небольшой костяк людей (а то и вовсе один человек). В их задачу входит создание прототипа и набивание шишек.
Опыта неожиданного перемещения сразу десятка людей на "пустой" проект у меня нет. Возможно, кто-то другой ответит.
Здравствуйте, igor-booch, Вы писали:
IB>Устные разговоры нужны для тем которые трудно сформулировать письменно.
Но обязательно должны заканчиваться итогами, зафиксированными письменно. Иначе разговоры не нужны вообще...
Занятный случай. Обычно больше рассусоливают на planning, т.к. там действительно есть о чем поспорить — как делать тот или иной сценарий и как его разбивать на атомарные задачи. Более того, sprint exit (review/retrospective) зачастую даже раньше заканчивается, если спринт был рутинным успехом с примерным повторением velocity из прошлого спринта.
На всякий случай попробую описать, что и как должно быть на этой встрече. Чтобы вы могли сравнить и сказать, где ваша реальность расходится с требуемым представлением.
1. Этот митинг состоит из двух частей — собственно демонстрация (review) и "разбор полётов" (retrospective).
2. Демонстрация должна быть подготовлена заранее (т.е. не должно быть ситуации, когда во время митинга подключают ноутбуки к проектору, инсталлируют какой-нибудь софт и занимаются всем тем, что можно было сделать заранее).
3. Демонстрация ведется исключительно на "живом продукте". На том, что вы разрабатываете. Никаких powerpoint'ов или скриншотов — надо показывать ровно то, что работает. Исключение — если в Definition of Done есть какие-то специфичные для демонстрируемой фичи пункты, которые просто нельзя показать наглядно (например, результаты overnight нагрузочного тестирования).
4. Демонстрацией единичного сценария занимается один человек. Например, тот, кто эту фичу писал. Остальные — молчат, допускаются лишь замечания от Product Owner, и только по теме (например, что сценарий не будет принят в этом спринте, т.к. работает не так, как требовалось и как договорились во время sprint planning).
Честно сказать, мне трудно представить себе ситуацию, когда результат 2х-3х недельного спринта одной скрам-команды можно демонстрировать более часа-полутора.
После окончания демонстрации всех, кто не входит в команду, просят удалиться. Всех, включая Product Owner (несмотря на то, что он в терминологии скрам — pig). Ретроспектива проводится за закрытыми дверями, никого "снаружи" не должны интересовать ее результаты. Вы там можете хоть пиво пить на тему успешного окончания спринта. Собственно, так мы иногда поступали Но только после 100% спринтов, когда сделали ровно то, что запланировали. Обсуждать-то особо нечего было.
Однако если спринт был проблемным (что-то не успели, или кому-то пришлось сверхурочно работать), на ретроспективе каждый член команды выдает список проблем, которые привели к провалу. Из этих проблем затем выбирается N самых важных. Голосованием — скажем, если N=3, каждому члену команды выдается по 3 балла, которые он может распределить по списку. Остальные проблемы отбрасываются (один из принципов скрам — не хранить хлам "про запас", включая хлам старых проблем). Для топ N принимается решение, как их решить (или избежать) в следующем спринте. Проблемы должны быть предельно конкретными, т.е. "не нравится отношение начальства" в качестве проблемы не годится. Проблема — всё то, что мешает выполнению задач и увеличивает время на разработку.
К примеру, такой проблемой может стать использование модуля, разрабатываемого соседней командой. Если та команда постоянно обновляет модуль, нарушая совместимость и внося баги. Решений у такой проблемы несколько — например, фиксация версии модуля. Или организация автоматического входного контроля качества, с помощью которой битые билды сразу будут возвращаться на доработку.
Важно правильно сформулировать проблему. Так, формулировка "нам не нравится, что они всё постоянно ломают" — негодная. Годная звучит вот так: "из-за того, что вот тут был внесен баг xxxxx, а вот там — xxxxy, в этом спринте мы не смогли выкатить фичу zzzzz, потому что тот модуль иногда падает, а в нашем definition of done сделанной считается только тот сценарий, в процессе работы которого софт не крешится".
SD>>3. Есть ли у вас и у руководства воля для реального решения этих проблем? (это, наверное, самый важный вопрос — очень часто случается, что декларируемая поддержка не есть реальное проявление воли, а, скорее, показное). C>а можно что либо сделать если ответ отрицательный? потому что похоже что это мой случай.
Если всех устраивает затягивание митингов, одним из вариантов решений будет просто удлинить таймбокс. Иными словами, заложить 4 часа на sprint exit.
Другой вариант — посчитать расходы времени. Скажем, команда из 6 человек + 4 начальника + 2 представителя клиента. В нормальном варианте демо длится 1 час (6 + 4 + 2 часов общих потерь), ретроспектива — тоже час (еще +6 часов). Если у вас всё затягивается вдвое при коротких спринтах (2 недели, например) — значит, каждый месяц ваша команда зря тратит 24 своих часа, 8 часов начальства и 4 клиентских часа. Эти подсчёты можно предъявить руководству. Затем в качестве решения предложить соблюдать правила скрам. Особенно в той части, где chicken не дают право голоса. По опыту, именно трёп не входящих в команду людей часто затягивает митинги.
C>практически любые. Но видимо часть проблемы в том что у нас нет четкой цели митинга.
Гуглить по словам "scrum sprint planning meeting agenda", "scrum sprint review meeting agenda". Для начала попробуйте scrum by the book. Т.е. без каких-либо самопридуманных идей.
C>да, решение можно отложить.
Вот и откладывайте до следующего спринта. А там или ишак, или падишах.
SD>>Ну и самая важная рекомендация, к которой, увы, мало кто прислушивается — пригласите хорошего скрам-консультанта, чтобы он смог обнаружить ошибки и проблемы в вашей реализации скрам. C>боюсь что не наш случай
А может тогда ну его, этот скрам? Он хорош только тогда, когда правильно организован. И в этом подвох: скрам настолько прост, что мало кто в состоянии эту простоту выдержать. "А поговорить?" (С)
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Коллеги, как у вас все это проходит?
Я со скайдансом совершенно не согласен, но работает Scrum независимо от типа задач.
SVZ>А вот как проходит планирование для новых проектов? Когда неизвестно, что делать (вернее, понятно что, но еще непонятно как) и сколько времени это займет?
Неопределенность бывает разных видов. Если мы знаем что нужно сделать, но не знаем как (например нужно прикрутить XXX но никто из нас его еще не прикручивал) то мы выделяем время на ресерч. Уж ресерч-то мы знаем как делать и сколько времени займет. Другая неопределенность в том что мы не знаем что нужно сделать. Например, система по пятницам падает под нагрузкой. В этом случае опять же ресерч и по результатам новая задача или фикс. Важно что результатом ресерча должно быть не "я разобрался", а осязаемый документ с обоснованием для постановки задачи.
SVZ>У нас, в лучшем случае, выделялось несколько дней перед планированием, чтобы как-то познакомиться с задачей и хоть как-то попытаться поделить ее на составные части. И то помогало мало, ибо в процессе работы всплывало дофига нюансов и все планы "плыли".
Если задача не делится, ее нужно не делить насильно, а отдать вкуривать самому толковому. Как только он вкурит, он замечательно заведет в бэклоге достаточное число подзадач. Грубо говоря если на этот спринт нам нужно мигрировать с VPS в облако, то мы не пытаемся придумать задачу для каждого, а отдаем задачу по миграции Васе. Пока Вася курит доки, остальные фиксают баги. Как только вася закончит, он накидает в бэклог задач. Тогда остальные побросают баги и займутся миграцией.
SVZ>Посвятить первый спринт исключительно исследованию?
Тоже можно. Вообще у любого проекта есть такая стадия как предпродакшен, во время которого можно и нужно заниматься устранением рисков вида "а х.з. сколько это займет и как это вообще делать"
K>И понесёт ответственность за косяки этого решения.
Каким именно методом? Занесением выговора в грудную клетку? Господа, когда вы упоминаете слово "ответственность", пожалуйста, уточняйте, что вы имеете в виду.
PS: почему-то вспомнился Черномырдин с его "какую партию ни делай, все равно получится КПСС". Как ни пытаются организовать в России гибкие методики, а всё в итоге сводится к "косяки", "принять решение" и "понести ответственность". На самом деле что ли "место проклято"? Больше позитива, господа — следует думать о победах и наградах в первую очередь, и лишь затем о провалах. А то вы сами себя программируете на недостижение цели. Понятно, что у всего этого есть глубокие исторические корни, но надо же преодолевать это как-то.
SVZ>Я правильно понимаю, что ресёрч проводится вне спринта? Ну а пока Вася занят, остальные стартуют свой спринт, в рамках которого занимаются багфиксом? SVZ>Или он входит в текущий спринт, но его результаты будут использованы уже в следующем спринте?
Вы можете организовать ваш процесс так, как вам удобнее.
Я видел как минимум два работающих варианта.
1. Timeboxed research activity. Это время просто изымается из спринта (соответственным образом уменьшая фокус-фактор — как если бы Васю отдали на это время в другой проект).
2. Wild estimation. То, что называется "с шашкой наголо" — сценарий (фича) берется в спринт с совершенно отфонарной оценкой сложности, но такой, на которую команда пятой точкой согласна. В некотором смысле расчёт на авось, но, как показала практика, с опытными разработчиками "авось" не так и плохо работает.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Я правильно понимаю, что ресёрч проводится вне спринта? Ну а пока Вася занят, остальные стартуют свой спринт, в рамках которого занимаются багфиксом? SVZ>Или он входит в текущий спринт, но его результаты будут использованы уже в следующем спринте?
Ресерч входит в этот спринт, результаты используются любо в этом спринте, либо в следующем. Как только Вася завершает ресерч, он собирает внеочередной planning session. По результатам часть задач, к которым еще не приступали, переносится в следующий спринт, а на их место ставятся задачи по результатам ресерча. Если вдруг времени в этом спринте не хватает, текущий спринт не меняется, а к новым задачам приступаем в новом спринте.
Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение.
Чтобы команда была в состоянии принять решение, в каждой команде должен быть один человек с квалификацией, опытом на проекте, компетентностью, выше, чем у остальных. И не назначенный свыше, а тот, кто пользуется авторитетом у команды, к которому команда действительно будет обращаться по спорным техническим вопросам. Соответственно в случае проблем последнее слово будет всегда за этим человеком. Это касается технических вещей.
По фичам, по тому, что урезать, что должно входить в релиз, что нет, есть еще одна роль. Называется product owner. Он исходя из фактической производительности разработчиков пытается определить, какую фичу целосообразно делать и к какому релизу, чтобы продукт развивался. Соответсвенно здесь за ним последнее слово, делаем такую то фичу или не делаем, замораживаем и т.д.
Соответственно это вообще не обязанность скрам мастера. Задача скрам мастера в том, чтоб митинги продолжались не более определенного количество времени, чтобы они проводились, документировались, чтобы дела на таск трекере соответствовали фактическому положению вещей, чтобы в любой момент можно было сделать relis notes. Плюс возможно организация демонстраций продукта внутри команды, чтобы все видели над чем работаем и представляли продукт в целом, возможно помощь продакт овнеру в ведении переписки. Как добиваться будешь — на твое усмотрение. Можешь с секундомером сидеть и прерывать слишком заговорившегося, можешь перебивать говорящего что он отвлекается от темы и просить созвать отдельный экшен, с участием только заинтересованных, а не отвлекать всех. То есть твоя задача чтоб коммуникации проходили максимально эффективно, чтоб те, которым не следует тратить рабочее время на дескуссии не тратили время на просмотры демо, а занимались делом. Видишь что проблемы, нет явного лидера, в команде разброд и шатание — поднимаешь этот вопрос для вышестоящих и объясняешь им, что нужна ротация состава и нужен более квалифицированный разработчик, который будет в состоянии принимать решение и который быстро в состоянии будет овладеть кодовой базой, что нужна ротация членов команды и т.д.
Здравствуйте, cvetkov, Вы писали:
C>Здраствуйте, меня зовут Алексей и у меня проблема. C>Я скраммастер в довольно крупной команде. C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению. C>Порекомендуйте пожалуйста литературу.
Сразу жестко прерывай прямо в середине предложения, если оно не относится к теме разговора.
Часто попадались люди которые сильно растекаются мыслью и почти сразу начинают говорить не по делу.
Лучший вариант резко прерывать его и вовзвращать нужное русло.
Да может выглядит и не очень культурно. Но как тогда назвать того человека, который начинает переводить разговоров совсем не по текущей проблеме.
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, rlabs, Вы писали:
C>>>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>>>Я уверен что эта проблема известна и есть рекомендации по ее решению.
R>>С этим может помочь скрам-мастер.
C>но я и есть скраммастер
Синихс и ононим дело глоголят. Я б еше добавил — попробуй посчитать сколько нороту у вас участвует в митингах. Если больше некого разумного числа — лишних изгони проводить отдельные митинги (если уж приспичило) Из опыта — сын ошибок трудных (или даже я б сказал выкидышь):
пока митинговало 3-5 человек, да не каждый день (ечли не о чем говорить — митинг отменяли), было более менее. Потом нороту прибавилось (набрали новых, + соседей к себе взяли). и когда митинговало 20 человек, уже было забавно
Здравствуйте, cvetkov, Вы писали:
C>Здраствуйте, меня зовут Алексей и у меня проблема. C>Я скраммастер в довольно крупной команде. C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению. C>Порекомендуйте пожалуйста литературу.
Ну так, если в двух словах. то:
1. У всех встреч должна быть четкая повестка:
цель встречи,
список обсуждаемых вопросов,
ожидаемый результат встречи.
К сожалению часто вижу, как люди собираются без внятной повестки "просто поговорить о..."
2. У каждой встречи должен быть свой ведущий, который направляет обсуждение, модерирует дискуссию, пресекает оффтопик, организует брейнштормы и т.п. Причем этот человек не должен быть очень активным участником обсуждения, иначе у него возникнет конфликт интересов с его ролью модератора.
3. Надо прокачивать у людей навыки проблем-солвинга, чтобы интеллектуальная работа, в т.ч. и коллективная, была более эффективой.
В принципе ты, как скрам-мастер, находишься в идеальной позиции для внедрения этих практик.
Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому.
Это какое это решение не может принять команда? На скрам-митингах решаются примерно два вопроса. Первый: что делать. В первую очередь это решает заказчик. Он учитывает информацию от разработчиков. Но решает почти единолично (это его деньги). Второй: кто что будет делать. Если команда не может решить, кто и что будет делать в итерацию, скрам к ним не применим. Совсем. Им нужен руководитель, который будет распределять между ними задачи. Все остальное — это отдельные митинги которые собираются по необходимости (если вообще собираются, может быть, имеет решать вопросы по почте). Если они периодически завязают в решениях вопросов между собой, опять нужен руководитель (или man in charge, кто может принять окончательное решение по конкретному вопросу).
И еще один вывод. К митингу нужно готовиться. К нему должна быть готова команда (иначе она не сможет ничего продуктивно обсуждать). К митингу должен быть готов заказчик. Он должен представлять, что для него более важно, что — менее. Может быть, предварительные оценки стоит собрать за день до "большого" митинга и отдать заказчику. На митинге уже принимать окончательные решения. stand-up митинг (если он есть) вообще служит не для обсуждения а для донесения информации "сделано то-то".
P.S. Еще раз повторю. Scrum (как и любая другая методология) — не для всех команд.
C> скрам это реальность данная нам свыше.
Ну так и сформулируйте этому "свыше" проблему. И вывод о неприменимости скрама. Пусть это "свыше" само и мучается с решением своих проблем.
Здравствуйте, SkyDance, Вы писали:
K>>И понесёт ответственность за косяки этого решения.
SD>Каким именно методом?
Методом перебора зубов, блин. SD>Занесением выговора в грудную клетку? Господа, когда вы упоминаете слово "ответственность", пожалуйста, уточняйте, что вы имеете в виду.
Я не говорю про наказания. Я говорю про принятие последствий решений таким человеком. А то бывают вылезут уники, продавят решения, а решения не работают. Потом этим умникам начинаёт шкурить задницу, а они переносят ответсвенность на команду или отдельные персоны с криками: "Это не я, это ОН!" или начинают выкручивать овертаймы и прессовать команду. И это вместо того, чтобы конструктивно решать проблему, стойко принять поражение и найти выход.
SD>Больше позитива, господа — следует думать о победах и наградах в первую очередь, и лишь затем о провалах. А то вы сами себя программируете на недостижение цели. Понятно, что у всего этого есть глубокие исторические корни, но надо же преодолевать это как-то.
Да я не о том.
Здраствуйте, меня зовут Алексей и у меня проблема.
Я скраммастер в довольно крупной команде.
Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому.
Я уверен что эта проблема известна и есть рекомендации по ее решению.
Порекомендуйте пожалуйста литературу.
C>>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>>Я уверен что эта проблема известна и есть рекомендации по ее решению.
R>С этим может помочь скрам-мастер.
но я и есть скраммастер
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[3]: Много слов а мало дела
От:
Аноним
Дата:
28.06.13 18:11
Оценка:
R>>С этим может помочь скрам-мастер. C>но я и есть скраммастер
Тогда делайте почаще умное лицо
спасибо за подробный ответ.
к сожалению он мне не помогает, по всей видимости, я не правильно сформулировал вопрос. C>> скрам это реальность данная нам свыше. M>Ну так и сформулируйте этому "свыше" проблему. И вывод о неприменимости скрама. Пусть это "свыше" само и мучается с решением своих проблем.
я оставил этот выход в качестве запасного плана, т.к. он ведет к наименьшему количеству фана.
Здравствуйте, cvetkov, Вы писали:
C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому.
Здравствуйте, SkyDance, Вы писали:
B>>Scrum — это хороший подход, но он в первую очередь оптимизирован под поддержку, а не разработку.
SD>Позволю себе с вами не согласиться. SD>Разработка нового продукта (в том числе и с нуля) ничуть не хуже работает со scrum.
работает лучше по сравнению с классической схемой при отсутствии ответственных за конкретные решения?
Спасибо за подробный ответ.
SD>Классика: книга Майка Коэна Agile Estimating and Planning.
Постараюсь ознакомиться.
SD>Теперь попробуйте честно ответить на следующий набор вопросов: SD>1. Какие конкретно митинги встречаются с этой проблемой?
В разной степени все.
Но самые большие проблемы с sprint exit SD>2. Что вы делаете для того, чтобы эту проблему решить?
вот обратился за помощью на форум. SD>3. Есть ли у вас и у руководства воля для реального решения этих проблем? (это, наверное, самый важный вопрос — очень часто случается, что декларируемая поддержка не есть реальное проявление воли, а, скорее, показное).
а можно что либо сделать если ответ отрицательный? потому что похоже что это мой случай. SD>4. Какие именно решения ваша команда должна принять, но не может?
практически любые. Но видимо часть проблемы в том что у нас нет четкой цели митинга.
вроде проблемы есть, вроде надо их решать. но заканчивается тем что поговорили и разошлись. SD>5. Есть ли необходимость принять эти решения прямо сейчас, или они могут быть приняты позже?
да, решение можно отложить. SD>6. Как скраммастер, справляетесь ли вы с основной задачей — устранением блокирующих разработку проблем (impediments)?
не знаю что ответить. SD>7. Соблюдаются ли требования SCRUM по проведению митингов?
нет пожалуй с этого и стоит начать лечение.
SD>Ну и самая важная рекомендация, к которой, увы, мало кто прислушивается — пригласите хорошего скрам-консультанта, чтобы он смог обнаружить ошибки и проблемы в вашей реализации скрам.
боюсь что не наш случай SD> Кстати, а кто именно учил вас и вашу команду?
наш скрам перекочевал из интела вмести с несколькими менеджерами и разработчиками
Здравствуйте, SkyDance, Вы писали:
SD>Попробуйте описать ситуацию подробнее. В известном мне SCRUM есть ровно три варианта митингов: daily stand-up (15 min), sprint planning (2 hr) и sprint exit (2 hr). В скобках указаны максимальные продолжительности таких митингов. Начинающие скрам-команды, или команды из более чем 8 человек, могут иметь пропорционально удлиненные таймбоксы. В любом случае, каждый митинг имеет строгий лимит — это одно из правил скрам.
Прикольно. Но насколько я понимаю, это работает только для случая, когда пилим один и тот же код и все задачи заведомо понятны. Тогда и планирование получается быстрым, а спринт — более менее предсказуемым.
А вот как проходит планирование для новых проектов? Когда неизвестно, что делать (вернее, понятно что, но еще непонятно как) и сколько времени это займет?
Посвятить первый спринт исключительно исследованию?
У нас, в лучшем случае, выделялось несколько дней перед планированием, чтобы как-то познакомиться с задачей и хоть как-то попытаться поделить ее на составные части. И то помогало мало, ибо в процессе работы всплывало дофига нюансов и все планы "плыли".
А частенько планирование сводилось к "...я х.з. как это решать и сколько дней займет, но давай выделим 3 дня, а там посмотрим...".
Коллеги, как у вас все это проходит?
_____________________
С уважением,
Stanislav V. Zudin
). Но... TG>Помните как в старом Ералаше: "Забыл предупредить. Чалма без сковородки не работает".
Без сковородки никак — ее я упоминаю во многих сообщениях. В том числе и в моём развёрнутом вопросе-ответе, там эта сковородка идет самым последним абзацем.
TG>По факту вам нужно командой руководить. Вот тут-то у вас и проблема: отсутствие власти и авторитета.
Об этом автор не писал. И не на этот вопрос он хотел получить ответ. Соответственно, нет смысла углубляться в изучение власти вообще. Более того, скраммастер не является тем самым властным начальником. Хотя лидерские качества ему нужны. В меньшей степени для контроля митингов, в большей степени для выполнения своих непосредственных задач — устранения блокирующих проблем (impediments). Грубо говоря, нужен "пробивной чел". Тот, кому это нравится. Если автора скраммастером просто назначили "с потолка", опять получатся "мышки, станьте ёжиками" и никакого эффекта. Но, опять же, этот вопрос не ставился.
Здравствуйте, SkyDance, Вы писали:
SVZ>>А вот как проходит планирование для новых проектов? Когда неизвестно, что делать (вернее, понятно что, но еще непонятно как) и сколько времени это займет? SVZ>>Посвятить первый спринт исключительно исследованию?
SD>Это не будет являться спринтом, поскольку на выходе не будет ничего готового, что могли бы "пощупать" пользователи.
SD>А как вы понимаете, что надо делать? Что у вас на входе уже есть? Текст сценариев? Скетчи UI? Откуда они взялись? Может, кто-то уже набивал шишки на этом поле, и можно у него проконсультироваться по планированию?
Под "что надо делать" я имею в виду какую-то спецификацию или user story.
Если, к примеру, надо написать парсер для какого-то файла, который создается внешней системой, то на входе имеем спецификацию и дюжину примеров. Хотя, это может быть недостаточно. По ходу пьесы может выясниться, что какие-то данные пользователь должен задать сам или их можно/нужно откуда-то дочитать...
Как правило задачи получаются мало пересекающиеся с предыдущими. Т.е. если брать в качестве примера тот же парсер, то другие парсеры писали, но там другие условия — для каких-то смогли применить стандартный flex/byson/CocoR, для других — писали все руками, ибо формат хитровывернутый. Поэтому предыдущий опыт никак не помогает оценить сроки.
SD>На самом старте совсем нового проекта обычно происходит бардак с непредсказуемыми прыжками всех параметров. Первые пару спринтов зачастую вовсе приходится исключить из статистики как нерепрезентативные.
SD>Но с этим, как правило, и бороться нет большого смысла, т.к. новые проекты очень редко запускают сразу с большой командой. Обычно над новым проектом начинает работать лишь небольшой костяк людей (а то и вовсе один человек). В их задачу входит создание прототипа и набивание шишек.
Я понял, спасибо.
Значит у нас не так все плохо
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, SkyDance, Вы писали:
SD>Об этом автор не писал. И не на этот вопрос он хотел получить ответ. Соответственно, нет смысла углубляться в изучение власти вообще. Более того, скраммастер не является тем самым властным начальником. Хотя лидерские качества ему нужны. В меньшей степени для контроля митингов, в большей степени для выполнения своих непосредственных задач — устранения блокирующих проблем (impediments). Грубо говоря, нужен "пробивной чел". Тот, кому это нравится. Если автора скраммастером просто назначили "с потолка", опять получатся "мышки, станьте ёжиками" и никакого эффекта. Но, опять же, этот вопрос не ставился.
По данным многолетних наблюдений, если некая команда в принципе может самоорганизоваться и договориться, то методики (в т.ч. SCRUM) могут им помочь, хоть необходимыми и не являются. А вот если команда не может договориться, то тут никакие методики не помогут. В таком случае работает только волевое решение. Нужен лидер, который скажет: "баста! делаем вот так!" и проконтролирует исполнение.
У автора топика, как я понял, именно второй случай. Поэтому-то он и не может организовать митинг и команда не может принять решение. Ну согласится команда на формальное следование процедурам SCRUM и получите в итоге "итальянскую забастовку", ага.
Обязанности скраммастера — это по сути обязанности тимлида. Да, формально у него нет властных полномочий, но ему нужно людьми руководить. И, как ни странно, люди от него этого ждут.
Здравствуйте, SkyDance, Вы писали:
SD>Если автора скраммастером просто назначили "с потолка", опять получатся "мышки, станьте ёжиками" и никакого эффекта. Но, опять же, этот вопрос не ставился.
Мастер-класс превращения мышек в ежиков от Гапертона:
Но мы оставили на последок третий, самый невзрачный на вид тип легитимности. Который, в отличии от предыдущих, способен творить чудеса на ровном месте, и не требует никаких особых условий, чтобы им воспользоваться.
3) Рациональная (демократическая) легитимность.
Она основана на нашей вере в правильность процедуры, посредством которой было получено то решение, которому мы должны подчиниться. Для этого, сами понимаете, процедура должны быть открыта, понятна людям, и они должны верить в ее справедливость — это необходимый минимум.
К примеру. Вы с друзьями, после долгих споров, договорились, что примете решение, куда поедете отдыхать, голосованием. Проголосовали. Да, действительно, в результате, получилось не то, что вам нравится, но — вы подчиняетесь принятому решению без споров и принуждения. Магия!
Доступно? А теперь к делу. Есть широкий спектр методов, которые может использовать руководитель, чтобы одновременно (а) выработать более качественные решения, и (б) обеспечить их легитимность (исполнение без необходимости принуждения), которые используют данный тип легитимности. Что удивительно — вам никаких стартовых условий для этого не требуется, и ничего плохого за это не будет. Я покажу лишь пару примеров.
Допустим, вы хотите ввести новые правила. Пусть это будет, скажем, самое элементарное — стандарт оформления кода.
Из практики известно, что попытки принятия такого стандарта часто сопровождаются бурлением говн, и нулевым результатом. Либо, саботажем при попытке ввести его "волевым решением". В редчайших случаях команде удается прийти к согласию по этой теме самостоятельно, без участия руководителя. И именно поэтому это будет хороший пример.
Начать мы должны с того, чтобы подготовить хоть что-то. Первый вариант стандатра. Любую, простите, хрень.
Не, конечно, мы должны очень сильно стараться, и сильно думать. Просто не надо питать никаких иллюзий, что это годный документ. Это — хрень, как бы вы не старались, запомните это, и примите как аксиому, ибо оно еще не прошло процедуры.
А процедура следующая. Мы созываем экспертный совет, в котором должны присутствовать все заинтересованные лица. И проводим обсуждение "законопроекта" в "трех чтениях". В целом, по своему духу, процесс обсуждения следует инспекциям Фагана, однако, вы, как модератор, допускаете свободные обсуждения между участниками, сохраняя за собой право подводить итог.
На "первом чтении" вы предъявляете плод долгих раздумий (не обязательно своих — вы можете поручить составление стандарта кому-то), и собираете конкретные замечания и вопросы.
На втором, вы представляете исправленный документ (он, скорее всего, будет сильно отличаться от изначального), и собираете уже конкретные замечания к пунктам.
На третьем, если вы сделали все правильно, будут мелкие правки, после чего документ немедленно принимается большинством голосов, что справедливо, учитывая, что у каждого было право и время высказаться.
Пара советов, которые важны.
— Не пытайтесь собирать сразу слишком большие группы. Начните с частностей. Добейтесь сначала согласия в небольшой группе, и только потом выносите обсуждение на уровень выше. В этом случае, от изначальной группы должен быть выделен "выборщик", который примет участие в прениях на следующем уровне. Вы не можете представлять интересы этой группы, вы модератор.
— Не пытайтесь делать документ слишком детальным, обрабатыващим все ситуации и случаи. Гораздо больше пользы в простых базовых правилах, относительно которых все согласны, чем в сложных, но нелигитимных правилах, исполнение которых сложно проверить, и которые все один хер будут нарушать. Смело исключайте из документа спорные пункты, которые не принципиальны, или принципиальность которых сомнительна.
Например, говоря о кодстандарте — он не должен содержать советов о правильном программировании и проектировании. Это стандарт оформления кода, а не руководство, как его правильно писать. Тем не менее, эти дурацкие пункты всегда там почему-то оказываются. Резать, к чертям. Не дожидаясь перитонита. Умникам, пытающимся заставить через кодстандарт всех писать код "правильно", ответьте просто — "это тема другого, отдельного документа, который мы обсудим потом".
Этот процесс, "три чтения", начиная с небольших групп, а также указанные рекомендации, прекрасно работает при принятии любых правил и регламентов. И прекрасно помогает вам не оказаться в дураках, и не потерять авторитет, ибо вы столкнетесь с нюансами на фазе обсуждения, а не "в бою".
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Под "что надо делать" я имею в виду какую-то спецификацию или user story.
SVZ>Если, к примеру, надо написать парсер для какого-то файла, который создается внешней системой, то на входе имеем спецификацию и дюжину примеров. Хотя, это может быть недостаточно. По ходу пьесы может выясниться, что какие-то данные пользователь должен задать сам или их можно/нужно откуда-то дочитать...
Это какой-то странный пример. Разве вы не исследуете задачу перед планированием? Как так получается что критичные требования выясняются по ходу пьесы?
SVZ>Как правило задачи получаются мало пересекающиеся с предыдущими. Т.е. если брать в качестве примера тот же парсер, то другие парсеры писали, но там другие условия — для каких-то смогли применить стандартный flex/byson/CocoR, для других — писали все руками, ибо формат хитровывернутый. Поэтому предыдущий опыт никак не помогает оценить сроки.
Ну ок, допустим задачу вы не исследовали, срок назначили с потолка, и собрали грабли. Но если у вас скрам, на ретроспективе обязательно должно всплыть что вы предполагали использовать flex, а он не пошел. Т.е. либо тот кто анализировал спеку не заметил что грамматика кривая, либо заметил но не придал этому значения. В любом случае будет сделан вывод и ошибка больше не повторится.
Здравствуйте, Miroff, Вы писали:
SVZ>>Под "что надо делать" я имею в виду какую-то спецификацию или user story.
SVZ>>Если, к примеру, надо написать парсер для какого-то файла, который создается внешней системой, то на входе имеем спецификацию и дюжину примеров. Хотя, это может быть недостаточно. По ходу пьесы может выясниться, что какие-то данные пользователь должен задать сам или их можно/нужно откуда-то дочитать...
M>Это какой-то странный пример. Разве вы не исследуете задачу перед планированием? Как так получается что критичные требования выясняются по ходу пьесы?
Да пример ничуть не странный, так сказать, из личной практики. Некоторые спринты так и проходили. Задачи накидывались во время планирования, соответственно заранее ознакомиться возможности не было. А т.к. кода не видел, проблема неизвестна, то и сроки ставить приходилось от фонаря.
Собсно я и влез в тему, потому что интересен чужой опыт, как решаются подобные проблемы. Насколько я понял, на исследование выделяется отдельное время и планирование начинается, когда уже все разложено по полочкам.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Аноним, Вы писали:
А>Неопределенность бывает разных видов. Если мы знаем что нужно сделать, но не знаем как (например нужно прикрутить XXX но никто из нас его еще не прикручивал) то мы выделяем время на ресерч. Уж ресерч-то мы знаем как делать и сколько времени займет. Другая неопределенность в том что мы не знаем что нужно сделать. Например, система по пятницам падает под нагрузкой. В этом случае опять же ресерч и по результатам новая задача или фикс. Важно что результатом ресерча должно быть не "я разобрался", а осязаемый документ с обоснованием для постановки задачи.
SVZ>>У нас, в лучшем случае, выделялось несколько дней перед планированием, чтобы как-то познакомиться с задачей и хоть как-то попытаться поделить ее на составные части. И то помогало мало, ибо в процессе работы всплывало дофига нюансов и все планы "плыли".
А>Если задача не делится, ее нужно не делить насильно, а отдать вкуривать самому толковому. Как только он вкурит, он замечательно заведет в бэклоге достаточное число подзадач. Грубо говоря если на этот спринт нам нужно мигрировать с VPS в облако, то мы не пытаемся придумать задачу для каждого, а отдаем задачу по миграции Васе. Пока Вася курит доки, остальные фиксают баги. Как только вася закончит, он накидает в бэклог задач. Тогда остальные побросают баги и займутся миграцией.
Я правильно понимаю, что ресёрч проводится вне спринта? Ну а пока Вася занят, остальные стартуют свой спринт, в рамках которого занимаются багфиксом?
Или он входит в текущий спринт, но его результаты будут использованы уже в следующем спринте?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, SkyDance, Вы писали:
C>>Но самые большие проблемы с sprint exit
SD>Занятный случай. Обычно больше рассусоливают на planning, т.к. там действительно есть о чем поспорить — как делать тот или иной сценарий и как его разбивать на атомарные задачи. Более того, sprint exit (review/retrospective) зачастую даже раньше заканчивается, если спринт был рутинным успехом с примерным повторением velocity из прошлого спринта.
ну когда я сказал что у нас скрам я несколько исказил факты. правильнее сказать что у нас декларируется скрам, а на деле что-то на него местами похожее.
вобщем спасибо за подробный расказ, но к сожалению это не то что мне нужно.
SD>Если всех устраивает затягивание митингов, одним из вариантов решений будет просто удлинить таймбокс. Иными словами, заложить 4 часа на sprint exit.
у нас проблема другая. на митинг отведено время,но его не хватает. в результате решения не принимаются, а следовательно и то время которое выделено уходит в никуда.
C>>практически любые. Но видимо часть проблемы в том что у нас нет четкой цели митинга. SD>Гуглить по словам "scrum sprint planning meeting agenda", "scrum sprint review meeting agenda". Для начала попробуйте scrum by the book. Т.е. без каких-либо самопридуманных идей. C>>да, решение можно отложить. SD>Вот и откладывайте до следующего спринта. А там или ишак, или падишах.
проблемы имеют тенденцию накапливаться. заметание_под_ковер/игнорирование, на мой взгляд, не лучший выход.
SD>>>Ну и самая важная рекомендация, к которой, увы, мало кто прислушивается — пригласите хорошего скрам-консультанта, чтобы он смог обнаружить ошибки и проблемы в вашей реализации скрам. C>>боюсь что не наш случай
SD>А может тогда ну его, этот скрам? Он хорош только тогда, когда правильно организован. И в этом подвох: скрам настолько прост, что мало кто в состоянии эту простоту выдержать. "А поговорить?" (С)
да я бы с радостью, но начальство вцепилось в него зубами.
SVZ>Как правило задачи получаются мало пересекающиеся с предыдущими. Т.е. если брать в качестве примера тот же парсер, то другие парсеры писали, но там другие условия <...>
В разработке софта всегда так — задачи каждый раз "мало пересекаются с предыдущими". Однако же на основе накопленного опыта становится возможным сравнивать сложность задачи с приемлемой точностью. Жестко поставленные спринты вынужденно формируют ритм работы команды и значительно упрощают сбор статистики.
Важной особенностью такого процесса является его самокалибровка. В скрам сложность задач оценивается относительно друг друга (и единичного "самого простого" сценария). Как показывает практика, ошибка при оценке сложности задачи остается довольно постоянной (не зря же кто-то принимает эту константу как Пи, кто-то как e, кто-то как еще какое число). После нескольких спринтов средняя константа станет известна — и ее называют velocity.
TG>По данным многолетних наблюдений, если некая команда в принципе может самоорганизоваться и договориться, то методики (в т.ч. SCRUM) могут им помочь, хоть необходимыми и не являются. А вот если команда не может договориться, то тут никакие методики не помогут. В таком случае работает только волевое решение. Нужен лидер, который скажет: "баста! делаем вот так!" и проконтролирует исполнение.
TG>У автора топика, как я понял, именно второй случай. Поэтому-то он и не может организовать митинг и команда не может принять решение. Ну согласится команда на формальное следование процедурам SCRUM и получите в итоге "итальянскую забастовку", ага.
Мне доводилось сталкиваться и с таким мнением.
Однако такой подход скорее характерен для жестко иерархических структур (армии, например) с очень высоким уровнем ответственности. Так, за невыполнение приказа в армии подчиненный будет отдан под трибунал. В софтостроительных компаниях, к счастью, подобное невозможно, и "волевые решения лидера" будут ровно так же вязнуть в "итальянской забастовке". Кстати, вы не могли бы определиться, вы за "волевое решение" (суть "легитимность по праву рождения", аки у королей) или за "рациональную легитимость", когда решение принимается с согласия команды, или, как минимум, ее неявных лидеров.
Чтобы понять, что именно у автора не получается, надо подробнее изучать ситуацию. Прочитав крайнее на данный момент сообщение, у меня сложилось впечатление будто автору самому весь этот скрам неинтересен и навязан руководством. Скраммастер не по собственному желанию, а по назначению. Кем автор на самом деле хочет быть — пока неизвестно. Возможно, просто разработчиком. Или, как вариант, начальником, а то и вовсе командиром — дабы приказы раздавать и за исполнением следить.
TG>Обязанности скраммастера — это по сути обязанности тимлида. Да, формально у него нет властных полномочий, но ему нужно людьми руководить. И, как ни странно, люди от него этого ждут.
У роли скраммастера есть некоторое сходство с руководством и властными полномочиями. Так, скраммастер обязан следить за соблюдением процедур скрам — назначать время митингов, оповещать заинтересованных лиц. Но в остальное это сходство обманчивое. Традиционно, в обязанности тимлида входит раздавать задачи, проверять исполнение, помогать принять решение. Скраммастер этим не занимается. Скраммастер — это модератор и помощник. Главное, что он должен делать — помогать команде, устраняя блокирующие разработку проблемы. Иными словами, если в конторе часто падает сеть и это мешает разработке — именно скраммастер должен озаботиться разрешением проблемы.
Если так выходит, что длительные непроизводительные митинги являются блокирующей разработку проблемой — скраммастер должен ее решить. Что, судя по всему, автор треда и делает.
C>ну когда я сказал что у нас скрам я несколько исказил факты. правильнее сказать что у нас декларируется скрам, а на деле что-то на него местами похожее.
<...> SD>>А может тогда ну его, этот скрам? Он хорош только тогда, когда правильно организован. И в этом подвох: скрам настолько прост, что мало кто в состоянии эту простоту выдержать. "А поговорить?" (С) C>да я бы с радостью, но начальство вцепилось в него зубами.
Не совсем понял. Если скрама нет, во что начальство вцепилось зубами?
Можно попробовать поговорить с начальством. Если они действительно хотят скрам, значит, надо его и организовать — для начала by the book, ни на шаг не отступая.
Здравствуйте, SkyDance, Вы писали:
SD>Чтобы понять, что именно у автора не получается, надо подробнее изучать ситуацию. Прочитав крайнее на данный момент сообщение, у меня сложилось впечатление будто автору самому весь этот скрам неинтересен и навязан руководством. Скраммастер не по собственному желанию, а по назначению. Кем автор на самом деле хочет быть — пока неизвестно. Возможно, просто разработчиком. Или, как вариант, начальником, а то и вовсе командиром — дабы приказы раздавать и за исполнением следить.
Мне тоже так показалось. Не будем гадать — давайте спросим.
Алексей, а каковы ваши цели в этом проекте? Хотите ли Вы на самом деле внедрить SCRUM? Или же чтоб руководство просто было спокойно и от Вас отстало?
Здравствуйте, SkyDance, Вы писали:
SD>Мне доводилось сталкиваться и с таким мнением. SD>Однако такой подход скорее характерен для жестко иерархических структур (армии, например) с очень высоким уровнем ответственности. Так, за невыполнение приказа в армии подчиненный будет отдан под трибунал. В софтостроительных компаниях, к счастью, подобное невозможно, и "волевые решения лидера" будут ровно так же вязнуть в "итальянской забастовке".
У автора топика особый случай: команда сама не может договариваться. В этом случае должен быть человек (да-да, руководитель, что уж там ), который выслушает всех и примет решение и команда это решение примет и исполнит, даже если есть несогласные. Иначе проекту крышка. Вот для этого и нужна руководителю Рациональная (демократическая) легитимность. Нужна она и для того, что бы не попасть в ту самую итальянскую забастовку.
SD>Кстати, вы не могли бы определиться, вы за "волевое решение" (суть "легитимность по праву рождения", аки у королей) или за "рациональную легитимость", когда решение принимается с согласия команды, или, как минимум, ее неявных лидеров.
Лично мне нравится "рациональная легитимость". Это, кстати, залог успешности проекта.
Здравствуйте, SkyDance, Вы писали:
C>>ну когда я сказал что у нас скрам я несколько исказил факты. правильнее сказать что у нас декларируется скрам, а на деле что-то на него местами похожее. SD><...> SD>>>А может тогда ну его, этот скрам? Он хорош только тогда, когда правильно организован. И в этом подвох: скрам настолько прост, что мало кто в состоянии эту простоту выдержать. "А поговорить?" (С) C>>да я бы с радостью, но начальство вцепилось в него зубами.
SD>Не совсем понял. Если скрама нет, во что начальство вцепилось зубами?
в название видимо. и в создание видимости что он есть.
SD>Можно попробовать поговорить с начальством. Если они действительно хотят скрам, значит, надо его и организовать — для начала by the book, ни на шаг не отступая.
это понятно.
Здравствуйте, TopGear, Вы писали:
TG>Мне тоже так показалось. Не будем гадать — давайте спросим.
TG>Алексей, а каковы ваши цели в этом проекте?
Это, кстати, хороший вопрос. Обидно что я сам не додумался его себе задать.
Хочется иметь стабильную предсказуемую обстановку. И какой угодно но четкий процесс. TG>Хотите ли Вы на самом деле внедрить SCRUM? Или же чтоб руководство просто было спокойно и от Вас отстало?
Конкретный процесс для меня не принципиален. Но каков бы он ни был он должен соблюдатся всеми сторонами.
Но мы ушли от изначальной моей проблемы (которая, по иронии, и заключается в том что моя команда пытается решить все проблемы разом и переходит от одной к другой не решив ничего)
Здравствуйте, cvetkov, Вы писали:
C>Но мы ушли от изначальной моей проблемы (которая, по иронии, и заключается в том что моя команда пытается решить все проблемы разом и переходит от одной к другой не решив ничего)
Ну приведите пример вопросов, по котрым вы не можете договориться?
) чтобы узнать что-то новое и лучше понимать друг друга.
Хуже если всем пофиг, каждый механически делает задания, а потом выясняется, что задание было неправильно понято и нужно переписывать.
Теперь надо задать вопрос: а почему разговоры малопродуктивны.
Ответ прост: во время дискуссии нет времени думать, нужно говорить, демонстрируя что ты в теме.
Хорошо если участники митинга за несколько часов узнают перечень вопросов которые будут обсуждаться, есть время подумать.
Но очень часто вопросы заданы очень кратко и поэтому понять их тяжело.
В начале митинга team lead объясняет вопросы более подробно и сразу же начинаются необдуманные ответы и глупые необдуманные вопросы. На них даются необдуманные ответы. И пошло поехало.
Вот после этого разговор и перестает быть продуктивным.
Но дальше хуже. Так как разговор не продуктивный, то окончательное решение не принимается. И эти же самые вопросы начинают мусолиться с разных сторон на последующих совещаниях.
Этих недостатков частично лишено общение на форуме и вики. Есть время подумать над ответом и вопросом, решения фиксируются в вики.
Устные разговоры нужны для тем которые трудно сформулировать письменно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
C>>Но мы ушли от изначальной моей проблемы (которая, по иронии, и заключается в том что моя команда пытается решить все проблемы разом и переходит от одной к другой не решив ничего)
TG>Ну приведите пример вопросов, по котрым вы не можете договориться?
боюсь что не смогу. это потребует довольно много контекста.
Здравствуйте, SkyDance, Вы писали:
TG>>Ну приведите пример вопросов, по котрым вы не можете договориться?
SD>Я бы, скорее, попросил пример фрагмента бэклога. Судя по всему, у команды нет понимания, а что они вообще делают.
привести пример будет затруднитеьно из-за ограничений на разглашение всякого, да и контекста много придется описать.
) чтобы узнать что-то новое и лучше понимать друг друга.
Увы, это не так. Посмотрите хоть шоу Малахова на Первом.
IB>Хуже если всем пофиг, каждый механически делает задания, а потом выясняется, что задание было неправильно понято и нужно переписывать. IB>Теперь надо задать вопрос: а почему разговоры малопродуктивны. IB>Ответ прост: во время дискуссии нет времени думать, нужно говорить, демонстрируя что ты в теме. IB>Хорошо если участники митинга за несколько часов узнают перечень вопросов которые будут обсуждаться, есть время подумать. IB>Но очень часто вопросы заданы очень кратко и поэтому понять их тяжело. IB>В начале митинга team lead объясняет вопросы более подробно и сразу же начинаются необдуманные ответы и глупые необдуманные вопросы. На них даются необдуманные ответы. И пошло поехало. IB>Вот после этого разговор и перестает быть продуктивным. IB>Но дальше хуже. Так как разговор не продуктивный, то окончательное решение не принимается. И эти же самые вопросы начинают мусолиться с разных сторон на последующих совещаниях.
По данным тех же многолетних наблюдений, дискуссия заканчивается ничем из-за того, что все стоят на своем и не хотят
идти на уступки. Еще раз по этой причине оцените необходимость тимлида, а не просто скрам-мастера.
IB>Этих недостатков частично лишено общение на форуме и вики. Есть время подумать над ответом и вопросом, решения фиксируются в вики. IB>Устные разговоры нужны для тем которые трудно сформулировать письменно.
Здравствуйте, TopGear, Вы писали:
TG>По данным многолетних наблюдений, если некая команда в принципе может самоорганизоваться и договориться, то методики (в т.ч. SCRUM) могут им помочь, хоть необходимыми и не являются. А вот если команда не может договориться, то тут никакие методики не помогут. В таком случае работает только волевое решение. Нужен лидер, который скажет: "баста! делаем вот так!" и проконтролирует исполнение.
И понесёт ответственность за косяки этого решения.
TG>По данным тех же многолетних наблюдений, дискуссия заканчивается ничем из-за того, что все стоят на своем и не хотят TG>идти на уступки. Еще раз по этой причине оцените необходимость тимлида, а не просто скрам-мастера.
Да, тимлид должен принять окончательное решение, это его работа.
Но отчего получаются малоконструктивные споры? От того что нет времени думать, надо говорить + эмоции + желание выпендриться.
И тип лиду сложно принять решение в таком малоконструктивном споре. И кто-то обидется. А другой зазвездиться может.
Письменное общение склоняет людей в более конструктивную сторону, так как есть время подумать и все слова фиксируются.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, 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 митинги "старост" можно делать не каждый день).
Здравствуйте, bazis1, Вы писали:
B>Scrum — это хороший подход, но он в первую очередь оптимизирован под поддержку, а не разработку.
Мне лично казалось, что для поддержки как раз лучше брать canban. Ибо при скраме поддержке пока клиент получит фикс своего бага, пройдет черти сколько времени. Пока баг запланируют, пока закончится итерация, пока начнется итерация тестирования, пока она закончится — за это время заказчик на нервы изойдется если бага критичная. Ему сейчас фикс нужен.
А как раз при разработке scrum работает неплохо. В определенные промежутки времени мы получаем результат, что то рабочее, что можно посмотреть, провести демо, оценить достоинства и недостатки. А также темп виден, можно скорректировать планы и тому подобные вещи. И особенно хорошо скрам работает если требования меняются. Если мы сами не знаем чего хотим, сами ищем как сделать лучше. Сделали фичу, смотрим на реакцию пользователей. Пользователи говорят что все круто, хотим еще — продолжаем развивать. Пользователи не заметили, видим, что фичей не пользуются и ее не продать — сворачиваем работы в этом направлении и думаем над другими фичами, которые востребованы. Ну а если требования постоянны, то водопад рулит, как и раньше.
Здравствуйте, cvetkov, Вы писали:
C>Порекомендуйте пожалуйста литературу.
Просто так читать книжки бесполезно. Попробуй развести компанию на тренинг по организации митингов, вроде у Орлов & Панкратов был такой на котором разбирают типичные ситуации.
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>тут я ничего поделать не могу, скрам это реальность данная нам свыше.
Нет. Реальность (жестокая) — это что у вас работа не продвигается.
А скрам — это унылая виртуальность.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Первые пару спринтов зачастую вовсе приходится исключить из статистики как нерепрезентативные.
Некоторые спринты так и проходили. Задачи накидывались во время планирования, соответственно заранее ознакомиться возможности не было. А т.к. кода не видел, проблема неизвестна, то и сроки ставить приходилось от фонаря. 
