мы начали внедрять Scrum и „монстра“ мешала в процессе
Я, конечно, очень давно последний раз видел Bugzilla, но мне мне кажется очень сомнительной идея использовать ее при внедрения Скрама.
Или там была какая-то кастомизация? Вот цитату нашел:
Unlike some other tools, Bugzilla aims to be fairly generic. It was not built specifically for managing Scrum user stories, so it may take some work, frustration, and training to set it up appropriately. The writeup from the Songbird team hints at this — the first section is named «Wrestling Bugzilla into shape» and the next sentence explains that the team primarily chose Bugzilla for managing Scrum because they had already been using it.
Ну вообще мне кажется, что инспекция и адаптация как раз и есть про непрерывное совершенствование. А ревью и ретроспектива — инструменты, используемые для инициирования изменений. Ошибаюсь?
С целью улучшения степени прогнозируемости и эффективности управления рисками, Скрам использует итеративный и инкрементальный подход. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и адаптации.
Адаптация
При обнаружении отклонений от допустимых пределов одного или несколько элементов процесса или продукта, следует внести соответствующие изменения. Это могут быть как изменения самого процесса, так и материалов, используемых в нем.
История изложена на 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.
Т.ч. мне не очень понятна Ваша неприязнь к Скрам Гайду (который этот самый фреймворк формализует).
Там прямо так и написано — запрещено менять, убирать и добавлять.
Это относится только элементам, котрые и определяет Скрам фреймворк:
Роли, артефакты, правила и события Скрама не подлежат
изменению. При внедрении отдельных элементов данного фреймворка, полученный
результат не может называться Скрамом.
Скрам существует только в качестве цельного фреймворка. Он также может служить
контейнером для других техник, методологий и практик.
И я думаю, что это как раз вполне естественная реакция на печальный опыт имплементации недоскрамов — когда процесс начинают «адаптировать» до полноценного внедрения и понимания, за счет чего он на самом деле работает:
Скрам является:
компактным;
простым для понимания;
трудным для совершенного овладения
.
По-моему, фреймворк накладывает не так много ограничений, чтобы считать его инструкциями. А адаптация процессов заложена в сам фреймворк.
К сожалению, гайд, действительно, не охватывает тему внедрения скрама в должном объеме. А этот этап самый сложный.
Подождите, «подчинение» не входит в описание роли или круга задач скрам-мастера в Скрам Гайде.
И скрам-мастер — это все-таки не выборная должность. Откуда у команды понимание, кто сможет построить процесс, о котором команда не имеет четкого понимания?
Вы озвучили 3 принципа (лично мне их тяжело воспринимать по причине отсутствия сказуемых — только подлежащие и дополнения, приходится восстанавливать из контекста, но это отдельный вопрос).
Как эти принципы соотносятся со скрам-гайдом?
А кто осуществляет этот тотальный контроль?
Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд, в пользу «внешнего» (по отношению к команде) управления и контроля?
Т.е. по сути строится «полицейский» (ну или «детсадовский») недоскрам?
P.S.
Я не отрицаю того факта, что даже в IT внедрение Agile и Scrum дается очень и очень непросто. И я вижу 2 составляющих этой проблемы: особенности менталитета и внедрение через ритуалы, а не философию.
Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама? Они же только вводят в заблуждение.
Реестр недвижимости, реестр автомобилей…
Зачем Вам терабайты данных о чужих сделках? Для иллюзии надежности? Вендором софта будет тот же государственный реестр недвижимости (иначе оно не будет признанно), которому Вы почему-то не доверяете…
Опять же, у объектов уже есть история. Кто ее будет вносить в систему? Почему этим данным можно доверять?
Возможно, что у меня просто нет такой потребности.
В любом случае, реальные деньги в систему нужно как-то ввести и как-то вывести, чтобы сумма стала копеечной (а не витруально-валютной).
Это может быть несколько дольше и сложнее, чем сам перевод.
И вопрос валютного контроля встанет уже в момент вывода.
Сервис суррогатных переводов можно сделать вполне себе централизованным (и такие давно существуют, на самом деле).
Исключительно вопрос доверия, удобства и размера комиссии, а не технологий, которые под этим лежат.
Я тоже иногда пишу код, это же не делает меня разработчиком.
Там результаты просто не коррелируют. Возможно, что часть вопросов можно было пропускать (методика это не раскрывает). Иначе получается, что в группе из 40% ответивших, включающей студентов, менеджеров, системных администраторов и тех. поддержку, половина утверждает, что пишет код профессионально.
Почти 2/3 вносят вклад в open source.
Как-то это все очень сомнительно.
Посмотрел внимательнее, откуда в заголовке статьи взялось слово «разработчиков»? Только 30% ответивших работают в software и 46% считают себя разработчиками + 11% devops.
Т.е. примерно половина респондентов не занимается разработкой ПО профессионально.
Какие выводы можно сделать из такого опроса?
Интересно, а почему CI и CD рассматриваются вместе? CD труднореализуем без CI, но сам по себе CI вполне может существовать без CD, т.к. способ поставки определяет бизнес, а методологии разработки определяет команда разработки.
Я бы посоветовал относиться к покрытию кода как температуре тела — 36.6 не говорит, что человек здоров, но большие отклонения от нормы обычно говорят о серьезных проблемах.
Нужно ли мерить покрытие кода авто-тестами? Мое мнение — обязательно. И в первую очередь не ради магической цифры, а для анализа результатов.
Да, как и любую другую метрику ее можно скомпрометировать.
Да, метрика является линейной — не может отличить полезный код от мало- или бесполезного. Но если фокусироваться на анализе, то смотреть можно на покрытие отдельных компонент или библиотек. При желании можно как-то разметить код и получить нелинейную метрику (примерно как раскладка багов по северити).
Да, метрика не показывает отсутствующие ветки кода или покрытие граничных условий. Примите как ограничение. Покрытие требований избавлено от этих недостатков? Вы все граничные условия прописываете в требования?
Я бы выделил следующие сильные стороны измерения и анализа покрытия кода по сравнению с покрытием требований:
1. тестовое покрытие можно мерить при отсутствии требований или других артефактов.
2. метрика инструментальная, т.е. ее получение обычно относительно недорого (в плане трудозатрат).
3. Т.ч. процесс измерений автоматизирован, то исключен человеческий фактор — труднее манипулировать результатом.
4. Т.к. процесс относительно дешев, то можно мерить часто и отслеживать тренды.
И если смотреть на тренды, а не на абсолютные цифры, то легко ответить на данные вопрос " Нужно ли покрывать мертый код?" — Нет, не нужно. Если он реально мертвый, то нужно выбросить. Если он редкоиспользуемый и мы не хотим его покрывать, но тренд все равно будет растущий (при условии, что новый код покрыт на достаточном уровне).
И опять же, любую полезную метрику можно превратить во вредный KPI, т.ч. я бы не стал на этом моменте фокусироваться. Гораздо интереснее сопоставлять сильные и слабые стороны разных метрик оценки тестового покрытия.
Так все-таки, для ускорения первична команда или скрам-мастер?
Допустим, цель ускориться (как и любую другую) ставит «бизнес», он ее озвучивает команде или скрам-мастеру?
Почему во главу процесса поставлен скрам-мастер, а не продакт-овнер, например? Ведь ускорение разработки — это долговременная цель. А за стратегическое развитие продукта или сервиса отвечает именно продакт-овнер. Откуда у скрам-мастера берется понимание, что сейчас удачный момент (с точки зрения «бизнеса») для экспериментов с процессами, которые могут сказаться негативно?
BTW
По поводу прожект-менеджеров и ресурсов — модель уж очень упрощенная, по крайней мере в сферах с интеллектуальной деятельностью. Но не вижу смысла вдаваться в дискуссию.
А как все-таки формулируется второй принцип?
Ускорением должен заниматься скрам-мастер?
Если цель ставится не команде, а скрам-мастеру, чем он отличается от прожект-менеджера?
Т.е. если в данной статье заменить скрам-мастер на прожект-менеджер, какие утверждения станут неверными?
Спасибо!
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
У меня 3 вопроса, признаю, что 2 последних могут быть отражены в последующих статьях. А что с первым про контекст организации?
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
Команда должна стать средой исполнения – гибкой, адаптивной, не возражающей.
Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?
Я, конечно, очень давно последний раз видел Bugzilla, но мне мне кажется очень сомнительной идея использовать ее при внедрения Скрама.
Или там была какая-то кастомизация?
Вот цитату нашел:
Unlike some other tools, Bugzilla aims to be fairly generic. It was not built specifically for managing Scrum user stories, so it may take some work, frustration, and training to set it up appropriately. The writeup from the Songbird team hints at this — the first section is named «Wrestling Bugzilla into shape» and the next sentence explains that the team primarily chose Bugzilla for managing Scrum because they had already been using it.
Уже неактуально?
Как и предполагалось, основная причина — борьба с недоскрамами (или «дряблыми» скрамами в терминологии авторов, или суррогатами в Вашей термиологии):
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.
Т.ч. мне не очень понятна Ваша неприязнь к Скрам Гайду (который этот самый фреймворк формализует).
Это относится только элементам, котрые и определяет Скрам фреймворк:
И я думаю, что это как раз вполне естественная реакция на печальный опыт имплементации недоскрамов — когда процесс начинают «адаптировать» до полноценного внедрения и понимания, за счет чего он на самом деле работает:
По-моему, фреймворк накладывает не так много ограничений, чтобы считать его инструкциями. А адаптация процессов заложена в сам фреймворк.
К сожалению, гайд, действительно, не охватывает тему внедрения скрама в должном объеме. А этот этап самый сложный.
И скрам-мастер — это все-таки не выборная должность. Откуда у команды понимание, кто сможет построить процесс, о котором команда не имеет четкого понимания?
Вы озвучили 3 принципа (лично мне их тяжело воспринимать по причине отсутствия сказуемых — только подлежащие и дополнения, приходится восстанавливать из контекста, но это отдельный вопрос).
Как эти принципы соотносятся со скрам-гайдом?
Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд, в пользу «внешнего» (по отношению к команде) управления и контроля?
Т.е. по сути строится «полицейский» (ну или «детсадовский») недоскрам?
P.S.
Я не отрицаю того факта, что даже в IT внедрение Agile и Scrum дается очень и очень непросто. И я вижу 2 составляющих этой проблемы: особенности менталитета и внедрение через ритуалы, а не философию.
Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама? Они же только вводят в заблуждение.
Зачем Вам терабайты данных о чужих сделках? Для иллюзии надежности? Вендором софта будет тот же государственный реестр недвижимости (иначе оно не будет признанно), которому Вы почему-то не доверяете…
Опять же, у объектов уже есть история. Кто ее будет вносить в систему? Почему этим данным можно доверять?
В любом случае, реальные деньги в систему нужно как-то ввести и как-то вывести, чтобы сумма стала копеечной (а не витруально-валютной).
Это может быть несколько дольше и сложнее, чем сам перевод.
И вопрос валютного контроля встанет уже в момент вывода.
Сервис суррогатных переводов можно сделать вполне себе централизованным (и такие давно существуют, на самом деле).
Исключительно вопрос доверия, удобства и размера комиссии, а не технологий, которые под этим лежат.
И мне, как пользователю, обеспечивают более высокое качество сервиса при меньших накладных расходах?
Там результаты просто не коррелируют. Возможно, что часть вопросов можно было пропускать (методика это не раскрывает). Иначе получается, что в группе из 40% ответивших, включающей студентов, менеджеров, системных администраторов и тех. поддержку, половина утверждает, что пишет код профессионально.
Почти 2/3 вносят вклад в open source.
Как-то это все очень сомнительно.
Т.е. примерно половина респондентов не занимается разработкой ПО профессионально.
Какие выводы можно сделать из такого опроса?
Спасибо!
Нужно ли мерить покрытие кода авто-тестами? Мое мнение — обязательно. И в первую очередь не ради магической цифры, а для анализа результатов.
Да, как и любую другую метрику ее можно скомпрометировать.
Да, метрика является линейной — не может отличить полезный код от мало- или бесполезного. Но если фокусироваться на анализе, то смотреть можно на покрытие отдельных компонент или библиотек. При желании можно как-то разметить код и получить нелинейную метрику (примерно как раскладка багов по северити).
Да, метрика не показывает отсутствующие ветки кода или покрытие граничных условий. Примите как ограничение. Покрытие требований избавлено от этих недостатков? Вы все граничные условия прописываете в требования?
Я бы выделил следующие сильные стороны измерения и анализа покрытия кода по сравнению с покрытием требований:
1. тестовое покрытие можно мерить при отсутствии требований или других артефактов.
2. метрика инструментальная, т.е. ее получение обычно относительно недорого (в плане трудозатрат).
3. Т.ч. процесс измерений автоматизирован, то исключен человеческий фактор — труднее манипулировать результатом.
4. Т.к. процесс относительно дешев, то можно мерить часто и отслеживать тренды.
И если смотреть на тренды, а не на абсолютные цифры, то легко ответить на данные вопрос " Нужно ли покрывать мертый код?" — Нет, не нужно. Если он реально мертвый, то нужно выбросить. Если он редкоиспользуемый и мы не хотим его покрывать, но тренд все равно будет растущий (при условии, что новый код покрыт на достаточном уровне).
И опять же, любую полезную метрику можно превратить во вредный KPI, т.ч. я бы не стал на этом моменте фокусироваться. Гораздо интереснее сопоставлять сильные и слабые стороны разных метрик оценки тестового покрытия.
Допустим, цель ускориться (как и любую другую) ставит «бизнес», он ее озвучивает команде или скрам-мастеру?
Почему во главу процесса поставлен скрам-мастер, а не продакт-овнер, например? Ведь ускорение разработки — это долговременная цель. А за стратегическое развитие продукта или сервиса отвечает именно продакт-овнер. Откуда у скрам-мастера берется понимание, что сейчас удачный момент (с точки зрения «бизнеса») для экспериментов с процессами, которые могут сказаться негативно?
BTW
По поводу прожект-менеджеров и ресурсов — модель уж очень упрощенная, по крайней мере в сферах с интеллектуальной деятельностью. Но не вижу смысла вдаваться в дискуссию.
Ускорением должен заниматься скрам-мастер?
Если цель ставится не команде, а скрам-мастеру, чем он отличается от прожект-менеджера?
Т.е. если в данной статье заменить скрам-мастер на прожект-менеджер, какие утверждения станут неверными?
Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
Запасусь терпением и буду ждать дальнейших статей :-)
Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?