Открыть список
Как стать автором
Обновить

Комментарии 26

«Скрам-бат» странно звучит, но «скрам-но» звучит еще хуже :) Может писать «scrum-but»?
Как ни пиши — на деле оно не лучше, чем звучит :) Но я попробую…
Если попытаться более гибко перевести, то
«типа-скрам»
«скрам-только...»
Например, в аутсорсинге проектов из США, иногда назначают скрам-мастера там, поближе к Владельцу Продукта, что бы удобно было через него отжимать команду. В результате вместо «дейли» получаем 40-минутные статус-отчеты по скайпу, и другие «но»
Если выполнить все эти требования, стоимость разработки вырастет примерно в 3-5 раз по сравнению с комплектом PO+команда. Увеличится ли эффективность в пять и более раз?
В английском языке есть понятия efficiency и effectiveness, по-нашему это эффективность и продуктивность. Будет ли команда работать эффективнее — не возьмусь утверждать. Но вы с большей вероятностью построите качественный продукт, нравящийся пользователям и ценный для рынка — в случае, если ваша идея хороша и своевременна. Либо потратите меньше сил и денег на ее проверку.

Когда мы размышляем о процессе разработки, мы часто сфокусированы на эффективности, будто это производство созданного прототипа, вроде пошива сапогов. На самом деле же мы имеем дело с проектированием — креативным процессом, и хотим соединить создание правильных вещей («Doing right things») с созданием вещей правильно («Doing things right»). Гибкие подходы — для этого.
Это всё круто, но насколько «продуктивность» будет выше в сравнении с затратами? Просто для понимания реалий — scrum-master — это такой профан, который носится по конторе с своей «библией», отрывает людей от работы и требует соблюдения идиотских правил, даже если ради этого придётся пожертвовать результатом. Рядом есть PO, который срать хотел на заморочки программистов и который не может понять как программист не может понять разницы между маршрутизируемой сетью и канальным сегментом (или дерюгой и вельветом, если хотите), рядом есть программисты, которые частично ощущают, что их не достаточно ценят, частично хотят попробовать новый фреймворк в деле, а рядом есть начальник, которого всё это мало волнует и интересует «мы решили, что запуск нашего нового убийцы Найк произойдёт в первом квартале 2012, уже 2013, и?».

Хорошо, когда полные энтузиазма люди делают правильные вещи, которые точно покупаются, кредиты дешёвые, все друг друга хорошо понимают и поддерживают и никто не умирает.

Реальная жизнь чуть-чуть другая, и чем глубже методология, тем больше она требует для себя. А что она даёт взамен? То, что она даёт в замен имеет эквивалентную рыночную стоимость?
От профанов с библией ни одна методология не спасает. К слову говоря, библия PMBook значительно толще 10-ти правил скрам.

Здесь собраны не правила методологии, а элементы рабочего контекста, способа внедрения, неверной трактовки ролей и практик, которые мешают эффективной работе по agile/scrum. Приведу такой пример:

Если при внедрении компания отправляет на обучение менеджмент и тимлидов, то команды затем получают набор правил (как работать), без понимания принципов и ценностей (почему так), часто возникает естественное сопротивление, правила кажутся идиотскими, за процесс «отвечает» один человек. На самом деле процесс разработки — это сфера ответственности (и власти) команды. Но для его обсуждения и совершенствования важна теоритическая база и будет полезен опыт практической работы. Если попытаться внедрить скрам по частям, без общего понимания (например, дейли митинги без правильного планирования), то правила действительно могут стать идиотскими.

Поэтому, когда к нам обращаются по вопросу обучения, первый вопрос, который мы задаем — «вам шашечки или ехать?». Вам нужен сертификат, углубленное обучение скрам-мастеров, или вы начинаете процесс внедрения? В последнем случе предлагаем работу со всей командой.

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

Вы пропустили вопрос: насколько «продуктивность» будет выше в сравнении с затратами?
Для небольших команд ведущих беспорядочную разработку, как моя бывшая можно получить прирост 2-3 раза 8))))
Небольшая команда, это сколько? Допустим, два программиста.

К двум программистам мы теперь добавляем scrum master'а, product owner'а, и имеем двухуратный прирост. При двухкратном росте затрат, так?
4 человека
прирост будет если у вас очень не систематизированная разработка, если взять скажем команду из двух человек, у которых есть четное тз по реализации, с обратной связью, континьюс интегрейшен, гит и всякие плюшки, то тут конечно особого прироста не увидеть в производительности, но есть большая вероятность получить более качественный продукт на выходе.
Скрам я бы назвал хорошим для неорганизованных команд, чтобы начать организовываться.
Ваш случай тоже утрирован и в целом ваше недовольство ответами мне понятно.
Но опять таки если разработка заказная то овнером должен стать представитель заказчика, а скрам мастером может быть один из разработчиков. Хотя я конечно могу и во всем ошибаться.
Внедрять скрам я бы стал пробовать если есть проблемы разработки, если их нет то у вас и так все хорошо.
Я ждала конкретного примера, спасибо. В описанном вами случае прироста производительности не будет.

В таком проекте, я бы порекомендовала использовать Kanban, как средство визуализации потока работ. Смотрела бы какая фаза является узким местом, и как можно увеличить ее пропускную способность. Для совмещения скрам и канбан в процессе можно проводить сессии регулярного планирования, скажем раз в неделю или в две. C такой же частотой — демонстрацию (формальную приемку работ) и ретроспективу (обсуждение и адаптация процесса).

При этом демонстрации могут быть не синхронизированы с деплойментом на продакшен. Если вы можете работать в режиме непрерывной поставки, то ваша демо может быть уже на рабочем продукте. Для чего в таком случае нужна демонстрация? Что бы получить понимание того, насколько доволен заказчик (Владелец Продукта), как меняется продуктивность команды (для этого можно использовать артефакт BurnUp Chart и метрику Velocity), сколько ресурсов отнимает саппорт (если он есть). Такая формальная оценка прироста продукта может быть полезной для оценки процесса и его обсуждению на ретроспективе. Оценивать ли работу и работать ли формальными итерациями — сугубо контекстуальный вопрос.

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

Отмечу, что такая команда является крайне слабой системой просто в силу своей конструкции. Я часто вижу две крайности в командах из двух человек: либо они так «дружат», что у формируется слабое разнообразие мнений, групповое мышление (как негативный паттерн) и склонность избегать конфликтов, даже если партнер не прав, или откровенно лажает в работе. Либо наоборот — неприятие партнера мешает воспринимать его здравые мысли, личный конфликт сводит на нет любой процесс. В такой системе нужен еще хотя бы один — балансирующий элемент. Кто-то, кто может ее уравновесить в случае перекосов в одну или другую сторону.
Я было думал, что у нас уже почти идеальный скрам… Оказывается, есть куда еще совершенствоваться.
Agile — это религия. (© не помню, кто первый эту мысль высказал)
В таком случае это религия опыта. Пока не попробуешь — кажется что не сработает. Быстро попробуешь — тоже не сработает. Многие из пунктов появляются как раз в результате внедрения «на скорую руку». А без понимания что и зачем поменять, кропотливого оттачивания процесса тут не обойтись. На и да, евангилизм — это часть работы. Как в продуктах так и в процессах.
Я скорее всего не прав, но вот что мне видится:

1. На внедрение Agile требуется время, много времени
2. Всё это время разработка происходит менее продуктивно за счёт «втягивания» и оттачивания техники
3. Оттачивание техники Agile отвлекает непосредственно от работы
4. Сроки разработки увеличиваются, а значит и стоимость проекта возрастает

Кроме того:

5. Высший менеджмент компании не в курсе, что такое Agile, они лишь решили попробовать что-то новенькое, что обещает повысить эффективность
6. Эффективность снижается на неопределённый срок
7. «Вернём как было, а то сроки-то не резиновые!»

Таким образом, мои выводы:

1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
2. В небольших фирмах и для новых проектов это может действительно дать результат
3. Среди имеющихся менеджеров и прочих сотрудников фирм вряд ли легко найдутся «пропитанные духом Agile», что потребует найма новых людей в команду, которые опять же на время «вникания в проект» на более-менее руководящей должности снизят эффективность
4. Так и бросят сие благое начинание

Опять же, во многих крупных фирмах это работает, из чего я делаю вывод, что руководство там выделило достаточно времени, денег и терпения/понимания для достижения такого результата.
Вы правы, по крайней мере на мой взгляд.

По последнему пункту «Введение Agile в крупных фирмах» — я видела разные ситуации. За некоторые я бы не взялась. Либо оттого, что они безнадежны без радикальных изменений и сильной поддержки ТОП-менеджмента, либо потому что эта работа уж очень не fun :)
1. Введение Agile в крупных фирмах с имеющимися большими проектами — дело почти безнадёжное
2. В небольших фирмах и для новых проектов это может действительно дать результат.


Не знаю насчет перевода уже имеющихся больших проектов на эджайл, не сталкивался. Но насчет новых — я за последние 5 лет работал на нескольких крупных проектах, везде — эджайл. Современный крупный проект невозможно (или неэффективно) вести методом ватерфолла — оттого эджайл и распространился.
На мелких проектах эджайл — лишняя возня с размазыванием работы по спринтам.
Думаю, вы говорите конкретно о скрам? На мелких проектах лучше работает канбан (чуть выше об этом писала). Визуализация потока работ, фокус на ценности работы, уход от детальной заготовленной наперед спецификации — будут оправданы.
Да, мы скрамим. В позапрошлом году пытались что-то канбанить, но это прошло мимо меня, и насколько оно было эффективно, судить не могу.
Мне кажется, что команд, которые внедрили на 100% scrum можно пересчитать по пальцам.
Все-таки Agile это методология, и в рамках своего типа деятельности (сектора) ты подстраиваешь его под себя.
Конечно в этом случае разбрасываться фразой «А у нас в компании scrum» не стоит.
Некоторые пункты слишком теоретические и притянуты за уши:

В команде недостаточно усердия для следования принятым изменениям
В команде недостаточно смелости для качественного изменения процесса


Таких можно написать штук 100. Не хватает знаний, понимания, опыта, умения общаться и т.д. Это очень тяжело увидеть, а еще тяжелее измерить и убедиться в исправлении ситуации.

При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи


У некоторых это жизненная необходимость, а перебраться на Kanban они еще не готовы. Главное чтобы эти новые задачи вытесняли старые и команда вкладывалась в сроки итерации.

Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)


Только наверху было про то, что не стоит привязываться к инструментам, а тут уже все наоборот. Если Владелец Продукта имеет четкое понимание продукта и расписанные фичи хоть в блокноте, будет это работать замечательно и без других техник.

Беклог продукта не отображает ценность элементов в нем


Это одна из самых противоречивых вещей. Часто для определения ценности надо знать столько составляющих, включая затраты времени и ресурсов, что лучше просто отказаться от определения ценности в числовой шкале.

Владельца Продукта не приглашают на ретроспективу


И очень правильно делают. Тогда можно спокойно поговорить, иногда даже поругаться конструктивно, пожаловаться на Владельца Продукта. А еще, его участие в аутсорсинговых командах почти нереально. Не садиться же всем из-за этого в Skype.

Нет выделенного Скрам-Мастера или он меняется каждый спринт


Если толковая команда, то можно и ротировать эту роль среди ее членов. Ужасного в этом ничего нет.

У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile


Опять про смелость… В основном, этот пункт превращается на практике в отстаивание идеалов по библии Agile без вникания в контекст проекта и команды.

Один Скрам-Мастер работает более чем на 3-4 команды


Ну и отлично. Если переходить на Scrum при полном хаосе, но это работать не будет. Если уже почти все наладилось, то без проблем.

Дейли-митинг проводится сидя, за рабочими местами


В сидении большой беды нет, если никто не начинает отвлекаться. А если вы сидите в одной небольшой комнате, то можно и не вставать из-за рабочих мест. Это больше вопрос сознательности.

В распределенной команде проходят отдельные Дейли по локациям


А нет, надо в распределенной команде человек на 30 всем собраться в Skype на часок-другой…

Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)


Опять же, если у Владельца Продукта нет проблем с выбором и приоритезацией требований, то можно замечательно жить и без этих практик.

Команда договаривается кто над какими задачами будет работать в ходе спринта


Часто это просто необходимо на высоком уровне, потому что иначе получится затык в работе одного из специализированных членов команды. Понятное дело, что не стоит задачи разбирать, но иногда прикинуть что кто будет делать очень помогает.

Регулярно есть незавершенная работа в конце спринта


Это конечно плохо, но зависит от модели планирования. Если команда разрешает вкидывать новые задачи, то есть «гарантированный» объем работы и «рискованный». И вот рискованный может вылезть за рамки итерации. В этом нет большой беды.

Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта


Цели — это хорошо на бумаге. Чаще всего Владельца Продукта интересует именно выполнение задач на итерацию, а не достижение мифической надуманной цели спринта, сделанной только для того, чтобы удовлетворить эго Скрам-Мастера с библией Agile.

Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч


Если команда попробовала разные шаблоны и выбрала самый интересный и эффективный для нее, то что в этом плохого? Другое дело, если она вообще не пробовала ничего и собралась «на поговорить».
Наши менеджеры называют это «адаптивный скрам». )
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Украина
Сайт
www.scrumguides.com
Численность
2–10 человек
Дата регистрации

Блог на Хабре