Pull to refresh

Comments 25

мы, авторы #Ускорения4X, собаку съели на разборе черных ящиков, и контролю исполнения методики уделяем самое пристальное внимание. Везде, где только можно, мы будем рассказывать о способах контроля — прямых, косвенных, количественных, альтернативных, и т.д.

Меня терзают смутные сомнения, что в конце будет KPI для программистов.
Автор, ну скажите, что это не так!
А там занятная у вас статья, спасибо
Спасибо на добром слове, добрый человек.
Стадии внедрения новой методологии:

Отрицание
Гнев
Торг
Депрессия
Принятие

<:o)
А кто осуществляет этот тотальный контроль?
Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд, в пользу «внешнего» (по отношению к команде) управления и контроля?
Т.е. по сути строится «полицейский» (ну или «детсадовский») недоскрам?

P.S.
Я не отрицаю того факта, что даже в IT внедрение Agile и Scrum дается очень и очень непросто. И я вижу 2 составляющих этой проблемы: особенности менталитета и внедрение через ритуалы, а не философию.
Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама? Они же только вводят в заблуждение.
А кто осуществляет этот тотальный контроль?

О тотальном контроле речи нет, нужен контроль изменений. Осуществляет скрам-мастер — тот, кто отвечает за процесс. Но это я вперед забегаю, обо всем напишу в свое время.

Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд

Неправильно. Как только вы перестанете считать скрам-мастера внешним по отношению к команде, все встанет на свои места. Выбор скрам-мастера, как ответственного за процесс, делает команда — ровно для того, чтобы не париться всем сразу. Это и есть самоорганизация.

Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама?

Об этом говорилось в прошлой публикации. Авторская методика — это fork scrum, ровно как и написано в оригинальной методике. Часть терминов, ролей, процессов и фишек от скрама остались. Если их переобзывать по-своему, то придется вести таблицу соответствий.
Подождите, «подчинение» не входит в описание роли или круга задач скрам-мастера в Скрам Гайде.
И скрам-мастер — это все-таки не выборная должность. Откуда у команды понимание, кто сможет построить процесс, о котором команда не имеет четкого понимания?

Вы озвучили 3 принципа (лично мне их тяжело воспринимать по причине отсутствия сказуемых — только подлежащие и дополнения, приходится восстанавливать из контекста, но это отдельный вопрос).
Как эти принципы соотносятся со скрам-гайдом?

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


В книге про скрам, того же автора, написано прямо противоположное.


Книга — первоисточник, оригинал. Скрам гайд — производная, причем низкого качества.


Увы. #Ускорение4X соотносится со скрам гайдом так же, как скрам соотносится со скрам гайдом — никак. Слова похожи, но не более того.

Там прямо так и написано — запрещено менять, убирать и добавлять.

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


И я думаю, что это как раз вполне естественная реакция на печальный опыт имплементации недоскрамов — когда процесс начинают «адаптировать» до полноценного внедрения и понимания, за счет чего он на самом деле работает:
Скрам является:
  • компактным;
  • простым для понимания;
  • трудным для совершенного овладения
.


По-моему, фреймворк накладывает не так много ограничений, чтобы считать его инструкциями. А адаптация процессов заложена в сам фреймворк.

К сожалению, гайд, действительно, не охватывает тему внедрения скрама в должном объеме. А этот этап самый сложный.
Гайд делает самое поганое, что можно сделать — выключает мозг, включает только ноги и руки.

Я, честно, не думал, что все так плохо. Несколько раз в комментариях, в социальных сетях, встречал отсылки к этому гайду. Но не думал, что люди это всерьез.

Это все равно, что пытаться понять медицину по методичке оказания первой помощи, которую в институте давали. Не помню, как предмет назывался, там еще надо было искусственное дыхание делать манекену.
История изложена на scrum.org.
Как и предполагалось, основная причина — борьба с недоскрамами (или «дряблыми» скрамами в терминологии авторов, или суррогатами в Вашей термиологии):

By early 2009, more organizations were using Agile processes than waterfall processes, and of those employing Agile 84% were using Scrum. However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. Martin Fowler wrote in his blog that he was encountering many instances of «Flaccid Scrum.» Teams were using Scrum vocabulary but weren’t able to create a potentially shippable increment of functionality within a single Sprint.

Т.ч. мне не очень понятна Ваша неприязнь к Скрам Гайду (который этот самый фреймворк формализует).
Мне ключевой показалась другая фраза:
This journey has been shaped by two opposing forces: the desire to do the right thing, and the desire to make money.


Значит, в предыдущей статье я был прав наполовину:
Корень проблемы кроется в упрощении методики. Кто это упрощение сделал – не знаю. Вероятно, консультанты, которые изучили методику и должны были ее продавать. Продать скрам с ускорением до 4X за короткое время – нельзя, потому что для получения высокого результата невозможно использовать только инструкции из книги – нужно искать пути оптимизации для конкретной команды… Намного проще, с точки зрения бизнеса консультанта, продать инструкцию, научить выполнять эту инструкцию и получить свои деньги


Честно, не знал, что и авторы скрама пошли по этому пути.

Это и ужасная, и прекрасная новость.

Ужас в том, что скоро никто не вспомнит, зачем был создан скрам и в чем его смысл.

Прелесть в том, что у нас не осталось конкурентов.

мне не очень понятна Ваша неприязнь к Скрам Гайду

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

Адаптация
При обнаружении отклонений от допустимых пределов одного или несколько элементов процесса или продукта, следует внести соответствующие изменения. Это могут быть как изменения самого процесса, так и материалов, используемых в нем.

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

В том и разница. В книге непрерывное совершенствование называлось «непрерывным совершенствованием». С циклом Деминга, отсылкой к японским итерационным же практикам совершенствования процессов, и красной нитью через всю книгу — «надо совершенствоваться, в этом смысл».

А теперь, в гайдах, такую информацию только выискивать и вычленять можно, иногда притягивая за уши. Изначальная главная цель методики стала двумя-тремя короткими фразами инструкции, которые без болта не заметишь.

Ладно, чего-то разнылся я. Если у вас получается ускорить разработку в разы, используя скрам гайд — ок, рад за вас. Пишите опыт, с удовольствием почитаю, ибо такого опыта в публичном пространстве практически нет. Одни гайды :)
Добавьте ссылки на предыдущие статьи, чтобы удобнее было ориентироваться
Вы публикуете 3-4 статьи в месяц (усредняя). Если будете продолжать такими темпами — ориентироваться по профилю скоро станет неудобно.
Ок, я понял, учту. Спасибо.
И на это есть ответ в скрам-гайде:
Роли, артефакты, правила и события Скрама не подлежат
изменению. При внедрении отдельных элементов данного фреймворка, полученный
результат не может называться Скрамом.


Авторы же не запрещают частичную имплементацию, им просто не нравится, когда ее называют скрамом.

Хорошая ссылка, спасибо.


В книге про скрам написано примерно то же самое.

Спасибо за серию статей, очень интересно знать опыт коллег по счастью/несчастью. У меня есть вопрос насчет системного подчинения — правильно ли я понимаю, что вы имеете ввиду создание механизмов поощрения/порицания, которые воздействуют на объект управления таким образом, что он сам принимает решение о подчинении? (я бы заменил слово на сотрудничество, звучит менее отталкивающе чтоли).

Т.е., для примера, с штрафом за заезд за стоп линию — решение о не заезде принимает сам водитель. Он может и заехать, но это ему дороже (негативное подкрепление)?

В дальнейших статьях вы поделитесь приемами обеспечения системного подчинения(сотрудничества)?
правильно ли я понимаю, что вы имеете ввиду создание механизмов поощрения/порицания, которые воздействуют на объект управления таким образом, что он сам принимает решение о подчинении?


Нет. То, что вы описываете — путь системы мотивации. Он тоже вполне себе ничего, некоторым больше нравится.

На днях должна следующая публикация серии #Ускорение4X выйти, там будет поподробнее про подчинение.
Sign up to leave a comment.

Articles