Комментарии 26
«Скрам-бат» странно звучит, но «скрам-но» звучит еще хуже :) Может писать «scrum-but»?
Например, в аутсорсинге проектов из США, иногда назначают скрам-мастера там, поближе к Владельцу Продукта, что бы удобно было через него отжимать команду. В результате вместо «дейли» получаем 40-минутные статус-отчеты по скайпу, и другие «но»
Если выполнить все эти требования, стоимость разработки вырастет примерно в 3-5 раз по сравнению с комплектом PO+команда. Увеличится ли эффективность в пять и более раз?
В английском языке есть понятия efficiency и effectiveness, по-нашему это эффективность и продуктивность. Будет ли команда работать эффективнее — не возьмусь утверждать. Но вы с большей вероятностью построите качественный продукт, нравящийся пользователям и ценный для рынка — в случае, если ваша идея хороша и своевременна. Либо потратите меньше сил и денег на ее проверку.
Когда мы размышляем о процессе разработки, мы часто сфокусированы на эффективности, будто это производство созданного прототипа, вроде пошива сапогов. На самом деле же мы имеем дело с проектированием — креативным процессом, и хотим соединить создание правильных вещей («Doing right things») с созданием вещей правильно («Doing things right»). Гибкие подходы — для этого.
Когда мы размышляем о процессе разработки, мы часто сфокусированы на эффективности, будто это производство созданного прототипа, вроде пошива сапогов. На самом деле же мы имеем дело с проектированием — креативным процессом, и хотим соединить создание правильных вещей («Doing right things») с созданием вещей правильно («Doing things right»). Гибкие подходы — для этого.
Это всё круто, но насколько «продуктивность» будет выше в сравнении с затратами? Просто для понимания реалий — scrum-master — это такой профан, который носится по конторе с своей «библией», отрывает людей от работы и требует соблюдения идиотских правил, даже если ради этого придётся пожертвовать результатом. Рядом есть PO, который срать хотел на заморочки программистов и который не может понять как программист не может понять разницы между маршрутизируемой сетью и канальным сегментом (или дерюгой и вельветом, если хотите), рядом есть программисты, которые частично ощущают, что их не достаточно ценят, частично хотят попробовать новый фреймворк в деле, а рядом есть начальник, которого всё это мало волнует и интересует «мы решили, что запуск нашего нового убийцы Найк произойдёт в первом квартале 2012, уже 2013, и?».
Хорошо, когда полные энтузиазма люди делают правильные вещи, которые точно покупаются, кредиты дешёвые, все друг друга хорошо понимают и поддерживают и никто не умирает.
Реальная жизнь чуть-чуть другая, и чем глубже методология, тем больше она требует для себя. А что она даёт взамен? То, что она даёт в замен имеет эквивалентную рыночную стоимость?
Хорошо, когда полные энтузиазма люди делают правильные вещи, которые точно покупаются, кредиты дешёвые, все друг друга хорошо понимают и поддерживают и никто не умирает.
Реальная жизнь чуть-чуть другая, и чем глубже методология, тем больше она требует для себя. А что она даёт взамен? То, что она даёт в замен имеет эквивалентную рыночную стоимость?
От профанов с библией ни одна методология не спасает. К слову говоря, библия PMBook значительно толще 10-ти правил скрам.
Здесь собраны не правила методологии, а элементы рабочего контекста, способа внедрения, неверной трактовки ролей и практик, которые мешают эффективной работе по agile/scrum. Приведу такой пример:
Если при внедрении компания отправляет на обучение менеджмент и тимлидов, то команды затем получают набор правил (как работать), без понимания принципов и ценностей (почему так), часто возникает естественное сопротивление, правила кажутся идиотскими, за процесс «отвечает» один человек. На самом деле процесс разработки — это сфера ответственности (и власти) команды. Но для его обсуждения и совершенствования важна теоритическая база и будет полезен опыт практической работы. Если попытаться внедрить скрам по частям, без общего понимания (например, дейли митинги без правильного планирования), то правила действительно могут стать идиотскими.
Поэтому, когда к нам обращаются по вопросу обучения, первый вопрос, который мы задаем — «вам шашечки или ехать?». Вам нужен сертификат, углубленное обучение скрам-мастеров, или вы начинаете процесс внедрения? В последнем случе предлагаем работу со всей командой.
Про жизнь я в курсе :) Честно говоря, работая в формате коучинга, я не всегда понимаю — какие именно действия привели к этому результату, но изменения в процессе, команде и ее продуктивности бывают разительны. Спасибо за ваш коментарий, я поняла какие вопросы задать в последних компаниях, с которыми работали в последнее время.
Здесь собраны не правила методологии, а элементы рабочего контекста, способа внедрения, неверной трактовки ролей и практик, которые мешают эффективной работе по agile/scrum. Приведу такой пример:
Если при внедрении компания отправляет на обучение менеджмент и тимлидов, то команды затем получают набор правил (как работать), без понимания принципов и ценностей (почему так), часто возникает естественное сопротивление, правила кажутся идиотскими, за процесс «отвечает» один человек. На самом деле процесс разработки — это сфера ответственности (и власти) команды. Но для его обсуждения и совершенствования важна теоритическая база и будет полезен опыт практической работы. Если попытаться внедрить скрам по частям, без общего понимания (например, дейли митинги без правильного планирования), то правила действительно могут стать идиотскими.
Поэтому, когда к нам обращаются по вопросу обучения, первый вопрос, который мы задаем — «вам шашечки или ехать?». Вам нужен сертификат, углубленное обучение скрам-мастеров, или вы начинаете процесс внедрения? В последнем случе предлагаем работу со всей командой.
Про жизнь я в курсе :) Честно говоря, работая в формате коучинга, я не всегда понимаю — какие именно действия привели к этому результату, но изменения в процессе, команде и ее продуктивности бывают разительны. Спасибо за ваш коментарий, я поняла какие вопросы задать в последних компаниях, с которыми работали в последнее время.
Вы пропустили вопрос: насколько «продуктивность» будет выше в сравнении с затратами?
Для небольших команд ведущих беспорядочную разработку, как моя бывшая можно получить прирост 2-3 раза 8))))
Небольшая команда, это сколько? Допустим, два программиста.
К двум программистам мы теперь добавляем scrum master'а, product owner'а, и имеем двухуратный прирост. При двухкратном росте затрат, так?
К двум программистам мы теперь добавляем scrum master'а, product owner'а, и имеем двухуратный прирост. При двухкратном росте затрат, так?
4 человека
прирост будет если у вас очень не систематизированная разработка, если взять скажем команду из двух человек, у которых есть четное тз по реализации, с обратной связью, континьюс интегрейшен, гит и всякие плюшки, то тут конечно особого прироста не увидеть в производительности, но есть большая вероятность получить более качественный продукт на выходе.
Скрам я бы назвал хорошим для неорганизованных команд, чтобы начать организовываться.
Ваш случай тоже утрирован и в целом ваше недовольство ответами мне понятно.
Но опять таки если разработка заказная то овнером должен стать представитель заказчика, а скрам мастером может быть один из разработчиков. Хотя я конечно могу и во всем ошибаться.
Внедрять скрам я бы стал пробовать если есть проблемы разработки, если их нет то у вас и так все хорошо.
прирост будет если у вас очень не систематизированная разработка, если взять скажем команду из двух человек, у которых есть четное тз по реализации, с обратной связью, континьюс интегрейшен, гит и всякие плюшки, то тут конечно особого прироста не увидеть в производительности, но есть большая вероятность получить более качественный продукт на выходе.
Скрам я бы назвал хорошим для неорганизованных команд, чтобы начать организовываться.
Ваш случай тоже утрирован и в целом ваше недовольство ответами мне понятно.
Но опять таки если разработка заказная то овнером должен стать представитель заказчика, а скрам мастером может быть один из разработчиков. Хотя я конечно могу и во всем ошибаться.
Внедрять скрам я бы стал пробовать если есть проблемы разработки, если их нет то у вас и так все хорошо.
Я ждала конкретного примера, спасибо. В описанном вами случае прироста производительности не будет.
В таком проекте, я бы порекомендовала использовать Kanban, как средство визуализации потока работ. Смотрела бы какая фаза является узким местом, и как можно увеличить ее пропускную способность. Для совмещения скрам и канбан в процессе можно проводить сессии регулярного планирования, скажем раз в неделю или в две. C такой же частотой — демонстрацию (формальную приемку работ) и ретроспективу (обсуждение и адаптация процесса).
При этом демонстрации могут быть не синхронизированы с деплойментом на продакшен. Если вы можете работать в режиме непрерывной поставки, то ваша демо может быть уже на рабочем продукте. Для чего в таком случае нужна демонстрация? Что бы получить понимание того, насколько доволен заказчик (Владелец Продукта), как меняется продуктивность команды (для этого можно использовать артефакт BurnUp Chart и метрику Velocity), сколько ресурсов отнимает саппорт (если он есть). Такая формальная оценка прироста продукта может быть полезной для оценки процесса и его обсуждению на ретроспективе. Оценивать ли работу и работать ли формальными итерациями — сугубо контекстуальный вопрос.
В команде из двух человек нет потребности в формальном скрам-мастере, но стоит обучить обоих участников, что бы их понимание гибкой разработки было общим. В такой команде нет необходимости в выделенных 15-минутках, но стоит обратить внимание на распределение задач командой и сделать процесс планирования и принятия ответственности максимально общим — тогда им будет о чем говорить по мере необходимости.
Отмечу, что такая команда является крайне слабой системой просто в силу своей конструкции. Я часто вижу две крайности в командах из двух человек: либо они так «дружат», что у формируется слабое разнообразие мнений, групповое мышление (как негативный паттерн) и склонность избегать конфликтов, даже если партнер не прав, или откровенно лажает в работе. Либо наоборот — неприятие партнера мешает воспринимать его здравые мысли, личный конфликт сводит на нет любой процесс. В такой системе нужен еще хотя бы один — балансирующий элемент. Кто-то, кто может ее уравновесить в случае перекосов в одну или другую сторону.
В таком проекте, я бы порекомендовала использовать Kanban, как средство визуализации потока работ. Смотрела бы какая фаза является узким местом, и как можно увеличить ее пропускную способность. Для совмещения скрам и канбан в процессе можно проводить сессии регулярного планирования, скажем раз в неделю или в две. C такой же частотой — демонстрацию (формальную приемку работ) и ретроспективу (обсуждение и адаптация процесса).
При этом демонстрации могут быть не синхронизированы с деплойментом на продакшен. Если вы можете работать в режиме непрерывной поставки, то ваша демо может быть уже на рабочем продукте. Для чего в таком случае нужна демонстрация? Что бы получить понимание того, насколько доволен заказчик (Владелец Продукта), как меняется продуктивность команды (для этого можно использовать артефакт BurnUp Chart и метрику Velocity), сколько ресурсов отнимает саппорт (если он есть). Такая формальная оценка прироста продукта может быть полезной для оценки процесса и его обсуждению на ретроспективе. Оценивать ли работу и работать ли формальными итерациями — сугубо контекстуальный вопрос.
В команде из двух человек нет потребности в формальном скрам-мастере, но стоит обучить обоих участников, что бы их понимание гибкой разработки было общим. В такой команде нет необходимости в выделенных 15-минутках, но стоит обратить внимание на распределение задач командой и сделать процесс планирования и принятия ответственности максимально общим — тогда им будет о чем говорить по мере необходимости.
Отмечу, что такая команда является крайне слабой системой просто в силу своей конструкции. Я часто вижу две крайности в командах из двух человек: либо они так «дружат», что у формируется слабое разнообразие мнений, групповое мышление (как негативный паттерн) и склонность избегать конфликтов, даже если партнер не прав, или откровенно лажает в работе. Либо наоборот — неприятие партнера мешает воспринимать его здравые мысли, личный конфликт сводит на нет любой процесс. В такой системе нужен еще хотя бы один — балансирующий элемент. Кто-то, кто может ее уравновесить в случае перекосов в одну или другую сторону.
Я было думал, что у нас уже почти идеальный скрам… Оказывается, есть куда еще совершенствоваться.
Agile — это религия. (© не помню, кто первый эту мысль высказал)
В таком случае это религия опыта. Пока не попробуешь — кажется что не сработает. Быстро попробуешь — тоже не сработает. Многие из пунктов появляются как раз в результате внедрения «на скорую руку». А без понимания что и зачем поменять, кропотливого оттачивания процесса тут не обойтись. На и да, евангилизм — это часть работы. Как в продуктах так и в процессах.
Я скорее всего не прав, но вот что мне видится:
1. На внедрение Agile требуется время, много времени
2. Всё это время разработка происходит менее продуктивно за счёт «втягивания» и оттачивания техники
3. Оттачивание техники Agile отвлекает непосредственно от работы
4. Сроки разработки увеличиваются, а значит и стоимость проекта возрастает
Кроме того:
5. Высший менеджмент компании не в курсе, что такое Agile, они лишь решили попробовать что-то новенькое, что обещает повысить эффективность
6. Эффективность снижается на неопределённый срок
7. «Вернём как было, а то сроки-то не резиновые!»
Таким образом, мои выводы:
1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
2. В небольших фирмах и для новых проектов это может действительно дать результат
3. Среди имеющихся менеджеров и прочих сотрудников фирм вряд ли легко найдутся «пропитанные духом Agile», что потребует найма новых людей в команду, которые опять же на время «вникания в проект» на более-менее руководящей должности снизят эффективность
4. Так и бросят сие благое начинание
Опять же, во многих крупных фирмах это работает, из чего я делаю вывод, что руководство там выделило достаточно времени, денег и терпения/понимания для достижения такого результата.
1. На внедрение Agile требуется время, много времени
2. Всё это время разработка происходит менее продуктивно за счёт «втягивания» и оттачивания техники
3. Оттачивание техники Agile отвлекает непосредственно от работы
4. Сроки разработки увеличиваются, а значит и стоимость проекта возрастает
Кроме того:
5. Высший менеджмент компании не в курсе, что такое Agile, они лишь решили попробовать что-то новенькое, что обещает повысить эффективность
6. Эффективность снижается на неопределённый срок
7. «Вернём как было, а то сроки-то не резиновые!»
Таким образом, мои выводы:
1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
2. В небольших фирмах и для новых проектов это может действительно дать результат
3. Среди имеющихся менеджеров и прочих сотрудников фирм вряд ли легко найдутся «пропитанные духом Agile», что потребует найма новых людей в команду, которые опять же на время «вникания в проект» на более-менее руководящей должности снизят эффективность
4. Так и бросят сие благое начинание
Опять же, во многих крупных фирмах это работает, из чего я делаю вывод, что руководство там выделило достаточно времени, денег и терпения/понимания для достижения такого результата.
Вы правы, по крайней мере на мой взгляд.
По последнему пункту «Введение Agile в крупных фирмах» — я видела разные ситуации. За некоторые я бы не взялась. Либо оттого, что они безнадежны без радикальных изменений и сильной поддержки ТОП-менеджмента, либо потому что эта работа уж очень не fun :)
По последнему пункту «Введение Agile в крупных фирмах» — я видела разные ситуации. За некоторые я бы не взялась. Либо оттого, что они безнадежны без радикальных изменений и сильной поддержки ТОП-менеджмента, либо потому что эта работа уж очень не fun :)
1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
2. В небольших фирмах и для новых проектов это может действительно дать результат.
Не знаю насчет перевода уже имеющихся больших проектов на эджайл, не сталкивался. Но насчет новых — я за последние 5 лет работал на нескольких крупных проектах, везде — эджайл. Современный крупный проект невозможно (или неэффективно) вести методом ватерфолла — оттого эджайл и распространился.
На мелких проектах эджайл — лишняя возня с размазыванием работы по спринтам.
Мне кажется, что команд, которые внедрили на 100% scrum можно пересчитать по пальцам.
Все-таки Agile это методология, и в рамках своего типа деятельности (сектора) ты подстраиваешь его под себя.
Конечно в этом случае разбрасываться фразой «А у нас в компании scrum» не стоит.
Все-таки Agile это методология, и в рамках своего типа деятельности (сектора) ты подстраиваешь его под себя.
Конечно в этом случае разбрасываться фразой «А у нас в компании scrum» не стоит.
Некоторые пункты слишком теоретические и притянуты за уши:
Таких можно написать штук 100. Не хватает знаний, понимания, опыта, умения общаться и т.д. Это очень тяжело увидеть, а еще тяжелее измерить и убедиться в исправлении ситуации.
У некоторых это жизненная необходимость, а перебраться на Kanban они еще не готовы. Главное чтобы эти новые задачи вытесняли старые и команда вкладывалась в сроки итерации.
Только наверху было про то, что не стоит привязываться к инструментам, а тут уже все наоборот. Если Владелец Продукта имеет четкое понимание продукта и расписанные фичи хоть в блокноте, будет это работать замечательно и без других техник.
Это одна из самых противоречивых вещей. Часто для определения ценности надо знать столько составляющих, включая затраты времени и ресурсов, что лучше просто отказаться от определения ценности в числовой шкале.
И очень правильно делают. Тогда можно спокойно поговорить, иногда даже поругаться конструктивно, пожаловаться на Владельца Продукта. А еще, его участие в аутсорсинговых командах почти нереально. Не садиться же всем из-за этого в Skype.
Если толковая команда, то можно и ротировать эту роль среди ее членов. Ужасного в этом ничего нет.
Опять про смелость… В основном, этот пункт превращается на практике в отстаивание идеалов по библии Agile без вникания в контекст проекта и команды.
Ну и отлично. Если переходить на Scrum при полном хаосе, но это работать не будет. Если уже почти все наладилось, то без проблем.
В сидении большой беды нет, если никто не начинает отвлекаться. А если вы сидите в одной небольшой комнате, то можно и не вставать из-за рабочих мест. Это больше вопрос сознательности.
А нет, надо в распределенной команде человек на 30 всем собраться в Skype на часок-другой…
Опять же, если у Владельца Продукта нет проблем с выбором и приоритезацией требований, то можно замечательно жить и без этих практик.
Часто это просто необходимо на высоком уровне, потому что иначе получится затык в работе одного из специализированных членов команды. Понятное дело, что не стоит задачи разбирать, но иногда прикинуть что кто будет делать очень помогает.
Это конечно плохо, но зависит от модели планирования. Если команда разрешает вкидывать новые задачи, то есть «гарантированный» объем работы и «рискованный». И вот рискованный может вылезть за рамки итерации. В этом нет большой беды.
Цели — это хорошо на бумаге. Чаще всего Владельца Продукта интересует именно выполнение задач на итерацию, а не достижение мифической надуманной цели спринта, сделанной только для того, чтобы удовлетворить эго Скрам-Мастера с библией Agile.
Если команда попробовала разные шаблоны и выбрала самый интересный и эффективный для нее, то что в этом плохого? Другое дело, если она вообще не пробовала ничего и собралась «на поговорить».
В команде недостаточно усердия для следования принятым изменениям
В команде недостаточно смелости для качественного изменения процесса
Таких можно написать штук 100. Не хватает знаний, понимания, опыта, умения общаться и т.д. Это очень тяжело увидеть, а еще тяжелее измерить и убедиться в исправлении ситуации.
При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи
У некоторых это жизненная необходимость, а перебраться на Kanban они еще не готовы. Главное чтобы эти новые задачи вытесняли старые и команда вкладывалась в сроки итерации.
Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)
Только наверху было про то, что не стоит привязываться к инструментам, а тут уже все наоборот. Если Владелец Продукта имеет четкое понимание продукта и расписанные фичи хоть в блокноте, будет это работать замечательно и без других техник.
Беклог продукта не отображает ценность элементов в нем
Это одна из самых противоречивых вещей. Часто для определения ценности надо знать столько составляющих, включая затраты времени и ресурсов, что лучше просто отказаться от определения ценности в числовой шкале.
Владельца Продукта не приглашают на ретроспективу
И очень правильно делают. Тогда можно спокойно поговорить, иногда даже поругаться конструктивно, пожаловаться на Владельца Продукта. А еще, его участие в аутсорсинговых командах почти нереально. Не садиться же всем из-за этого в Skype.
Нет выделенного Скрам-Мастера или он меняется каждый спринт
Если толковая команда, то можно и ротировать эту роль среди ее членов. Ужасного в этом ничего нет.
У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile
Опять про смелость… В основном, этот пункт превращается на практике в отстаивание идеалов по библии Agile без вникания в контекст проекта и команды.
Один Скрам-Мастер работает более чем на 3-4 команды
Ну и отлично. Если переходить на Scrum при полном хаосе, но это работать не будет. Если уже почти все наладилось, то без проблем.
Дейли-митинг проводится сидя, за рабочими местами
В сидении большой беды нет, если никто не начинает отвлекаться. А если вы сидите в одной небольшой комнате, то можно и не вставать из-за рабочих мест. Это больше вопрос сознательности.
В распределенной команде проходят отдельные Дейли по локациям
А нет, надо в распределенной команде человек на 30 всем собраться в Skype на часок-другой…
Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)
Опять же, если у Владельца Продукта нет проблем с выбором и приоритезацией требований, то можно замечательно жить и без этих практик.
Команда договаривается кто над какими задачами будет работать в ходе спринта
Часто это просто необходимо на высоком уровне, потому что иначе получится затык в работе одного из специализированных членов команды. Понятное дело, что не стоит задачи разбирать, но иногда прикинуть что кто будет делать очень помогает.
Регулярно есть незавершенная работа в конце спринта
Это конечно плохо, но зависит от модели планирования. Если команда разрешает вкидывать новые задачи, то есть «гарантированный» объем работы и «рискованный». И вот рискованный может вылезть за рамки итерации. В этом нет большой беды.
Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта
Цели — это хорошо на бумаге. Чаще всего Владельца Продукта интересует именно выполнение задач на итерацию, а не достижение мифической надуманной цели спринта, сделанной только для того, чтобы удовлетворить эго Скрам-Мастера с библией Agile.
Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч
Если команда попробовала разные шаблоны и выбрала самый интересный и эффективный для нее, то что в этом плохого? Другое дело, если она вообще не пробовала ничего и собралась «на поговорить».
Наши менеджеры называют это «адаптивный скрам». )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
85 заблуждений и препятствий внедрения гибкой разработки