Здравствуйте, SkyDance, Вы писали:
B>>Scrum — это хороший подход, но он в первую очередь оптимизирован под поддержку, а не разработку.
SD>Позволю себе с вами не согласиться. SD>Разработка нового продукта (в том числе и с нуля) ничуть не хуже работает со scrum.
работает лучше по сравнению с классической схемой при отсутствии ответственных за конкретные решения?
, и вообще в том треде. Краткое содержание: уровень ответственности разработчиков и тестировщиков в точности равен уровню полномочий. Околонулевых для большинства. Поэтому ваше высказывание "Берите сильных людей и делайте их ответственными за решения." по своей сути аналогично "мышки, станьте ёжиками". Люди внутри скрам-команды не могут влиять на бюджет проекта или feature set. Ответственность программистов ограничена их полномочиями. Они не могу принять решение "мы не релизимся в сентябре" или "мы возьмём еще двух человек на проект". Да и нечем программистам отвечать. Особенно, если их зарплата среднерыночная и время поиска следующей работы равно двум неделям обязательной отработки. И вы никак не сможете сделать их "ответственными" — им тупо нечем отвечать.
Если же вы вправду хотите вводить ответственность — готовьтесь ее оплачивать соответственно.
Здравствуйте, cvetkov, Вы писали:
C>Здраствуйте, меня зовут Алексей и у меня проблема. C>Я скраммастер в довольно крупной команде. C>Проблема заключается в следующем. Команда очень часто не может принять решение. Наши митинги постоянно теряют фокус. Обсуждение перетекает от одного вопроса к другому. C>Я уверен что эта проблема известна и есть рекомендации по ее решению. C>Порекомендуйте пожалуйста литературу.
Помните как в старом Ералаше: "Забыл предупредить. Чалма без сковородки не работает".
Так вот про "сковородку". Вы по факту являетесь руководителем.
Не важно, что там говорят в книгах о скрам про роль скрам-мастера.
По факту вам нужно командой руководить. Вот тут-то у вас и проблема: отсутствие власти и авторитета.
Не важно как вы будете прерывать выступающего: флажком или выстрелом в голову, совещаться сидя или лежа,
2 или 20 минут.
Хотите успешно сделать проект? Думайте о себе как о тимлиде.
Вам нужно иметь авторитет лидера в команде.
Многие руководители-программисты разных уровней, придя в новую компанию, ощущают недостаток "авторитета" в новой команде. Проявляется это не в том, что их поручений не выполняют, а, как бы это сказать, в том, что их воспринимают со скепсисом. "Ну, мы, конечно, сделаем, но...". В общем, в той или иной степени повергают "авторитет руководителя сомнению".
Поэтому, "авторитет надо заработать". Тут уж кто во что горазд.
...
Легитимность — есть желание людей подчиняться решениям власти при отсутствии принуждения.
...
Вебер выделяет целых три типа легитимности. Вам уже интересно, правда? Разберем их подробнее:
1) Традиционная легитимность. Деды наши так делали, и мы делать будем. Рюриковичи нами долго правили, старожилы не упомнят, они не подведут. И вообще, власть — она от Бога, а у власти не кто-нибудь, а помазанник божий.
...
2) Легитимность харизматичного лидера. О-о-о, сколько об этом написано. А ведь это по сути и есть тот самый "авторитет", который, как считается, вам нужно "заработать". Смотрите, цитирую википедию: "Этот образ непогрешимого, наделенного исключительными качествами человека (харизма) переносится общественным мнением на всю систему власти. Безоговорочно веря всем действиям и замыслам харизматического лидера, люди некритически воспринимают стиль и методы его правления."
Удобно быть [харизматичным] лидером, ничего не скажешь!
...
3) Рациональная (демократическая) легитимность.
Она основана на нашей вере в правильность процедуры, посредством которой было получено то решение, которому мы должны подчиниться. Для этого, сами понимаете, процедура должны быть открыта, понятна людям, и они должны верить в ее справедливость — это необходимый минимум.
К примеру. Вы с друзьями, после долгих споров, договорились, что примете решение, куда поедете отдыхать, голосованием. Проголосовали. Да, действительно, в результате, получилось не то, что вам нравится, но — вы подчиняетесь принятому решению без споров и принуждения. Магия!
Почитайте.
Ваша цель: рациональная легитимность.
И тут рекомендации SkyDance в самый раз.
В общем, делайте правильные вещи с правильной целью .
Будет желание — отпишитесь потом тут о результатах .
Спасибо за подробный ответ.
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). Грубо говоря, нужен "пробивной чел". Тот, кому это нравится. Если автора скраммастером просто назначили "с потолка", опять получатся "мышки, станьте ёжиками" и никакого эффекта. Но, опять же, этот вопрос не ставился.
Занятный случай. Обычно больше рассусоливают на 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>боюсь что не наш случай
А может тогда ну его, этот скрам? Он хорош только тогда, когда правильно организован. И в этом подвох: скрам настолько прост, что мало кто в состоянии эту простоту выдержать. "А поговорить?" (С)
SVZ>А вот как проходит планирование для новых проектов? Когда неизвестно, что делать (вернее, понятно что, но еще непонятно как) и сколько времени это займет? SVZ>Посвятить первый спринт исключительно исследованию?
Это не будет являться спринтом, поскольку на выходе не будет ничего готового, что могли бы "пощупать" пользователи.
А как вы понимаете, что надо делать? Что у вас на входе уже есть? Текст сценариев? Скетчи UI? Откуда они взялись? Может, кто-то уже набивал шишки на этом поле, и можно у него проконсультироваться по планированию?
SVZ>Коллеги, как у вас все это проходит?
На самом старте совсем нового проекта обычно происходит бардак с непредсказуемыми прыжками всех параметров. Первые пару спринтов зачастую вовсе приходится исключить из статистики как нерепрезентативные.
Но с этим, как правило, и бороться нет большого смысла, т.к. новые проекты очень редко запускают сразу с большой командой. Обычно над новым проектом начинает работать лишь небольшой костяк людей (а то и вовсе один человек). В их задачу входит создание прототипа и набивание шишек.
Опыта неожиданного перемещения сразу десятка людей на "пустой" проект у меня нет. Возможно, кто-то другой ответит.
Здравствуйте, 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>Коллеги, как у вас все это проходит?
Я со скайдансом совершенно не согласен, но работает Scrum независимо от типа задач.
SVZ>А вот как проходит планирование для новых проектов? Когда неизвестно, что делать (вернее, понятно что, но еще непонятно как) и сколько времени это займет?
Неопределенность бывает разных видов. Если мы знаем что нужно сделать, но не знаем как (например нужно прикрутить XXX но никто из нас его еще не прикручивал) то мы выделяем время на ресерч. Уж ресерч-то мы знаем как делать и сколько времени займет. Другая неопределенность в том что мы не знаем что нужно сделать. Например, система по пятницам падает под нагрузкой. В этом случае опять же ресерч и по результатам новая задача или фикс. Важно что результатом ресерча должно быть не "я разобрался", а осязаемый документ с обоснованием для постановки задачи.
SVZ>У нас, в лучшем случае, выделялось несколько дней перед планированием, чтобы как-то познакомиться с задачей и хоть как-то попытаться поделить ее на составные части. И то помогало мало, ибо в процессе работы всплывало дофига нюансов и все планы "плыли".
Если задача не делится, ее нужно не делить насильно, а отдать вкуривать самому толковому. Как только он вкурит, он замечательно заведет в бэклоге достаточное число подзадач. Грубо говоря если на этот спринт нам нужно мигрировать с VPS в облако, то мы не пытаемся придумать задачу для каждого, а отдаем задачу по миграции Васе. Пока Вася курит доки, остальные фиксают баги. Как только вася закончит, он накидает в бэклог задач. Тогда остальные побросают баги и займутся миграцией.
SVZ>Посвятить первый спринт исключительно исследованию?
Тоже можно. Вообще у любого проекта есть такая стадия как предпродакшен, во время которого можно и нужно заниматься устранением рисков вида "а х.з. сколько это займет и как это вообще делать"
Здравствуйте, 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>Обязанности скраммастера — это по сути обязанности тимлида. Да, формально у него нет властных полномочий, но ему нужно людьми руководить. И, как ни странно, люди от него этого ждут.
У роли скраммастера есть некоторое сходство с руководством и властными полномочиями. Так, скраммастер обязан следить за соблюдением процедур скрам — назначать время митингов, оповещать заинтересованных лиц. Но в остальное это сходство обманчивое. Традиционно, в обязанности тимлида входит раздавать задачи, проверять исполнение, помогать принять решение. Скраммастер этим не занимается. Скраммастер — это модератор и помощник. Главное, что он должен делать — помогать команде, устраняя блокирующие разработку проблемы. Иными словами, если в конторе часто падает сеть и это мешает разработке — именно скраммастер должен озаботиться разрешением проблемы.
Если так выходит, что длительные непроизводительные митинги являются блокирующей разработку проблемой — скраммастер должен ее решить. Что, судя по всему, автор треда и делает.
SVZ>Я правильно понимаю, что ресёрч проводится вне спринта? Ну а пока Вася занят, остальные стартуют свой спринт, в рамках которого занимаются багфиксом? SVZ>Или он входит в текущий спринт, но его результаты будут использованы уже в следующем спринте?
Вы можете организовать ваш процесс так, как вам удобнее.
Я видел как минимум два работающих варианта.
1. Timeboxed research activity. Это время просто изымается из спринта (соответственным образом уменьшая фокус-фактор — как если бы Васю отдали на это время в другой проект).
2. Wild estimation. То, что называется "с шашкой наголо" — сценарий (фича) берется в спринт с совершенно отфонарной оценкой сложности, но такой, на которую команда пятой точкой согласна. В некотором смысле расчёт на авось, но, как показала практика, с опытными разработчиками "авось" не так и плохо работает.
C>ну когда я сказал что у нас скрам я несколько исказил факты. правильнее сказать что у нас декларируется скрам, а на деле что-то на него местами похожее.
<...> SD>>А может тогда ну его, этот скрам? Он хорош только тогда, когда правильно организован. И в этом подвох: скрам настолько прост, что мало кто в состоянии эту простоту выдержать. "А поговорить?" (С) C>да я бы с радостью, но начальство вцепилось в него зубами.
Не совсем понял. Если скрама нет, во что начальство вцепилось зубами?
Можно попробовать поговорить с начальством. Если они действительно хотят скрам, значит, надо его и организовать — для начала by the book, ни на шаг не отступая.
Разберем их подробнее:
пожалуй с этого и стоит начать лечение.
Но только после 100% спринтов, когда сделали ровно то, что запланировали. Обсуждать-то особо нечего было. 
Первые пару спринтов зачастую вовсе приходится исключить из статистики как нерепрезентативные.
Некоторые спринты так и проходили. Задачи накидывались во время планирования, соответственно заранее ознакомиться возможности не было. А т.к. кода не видел, проблема неизвестна, то и сроки ставить приходилось от фонаря. 
