Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится.
В области информации каркас и есть описание. И так же как обшиание сайдингом (не знаю, обшивают ли на самом деле или как-то прикрепляют панели, а сайдинг это уже не то) требует сайдинга и навыков а не только каркаса (я, например, не смогу без дополнительного обучения), так же каркаса процесса недостаточно чтобы им овладеть.
Предствьте что Скрам это программный фрефмворк вот с таким кодом
public static void main()
{
IScrumTeam team = this.GetScrumTeam();
while (true)
{
var backlog = team.GetBacklog();
team.RefineBacklog(backlog);
var sprintBacklog = team.GetSprintBacklog(backlog);
team.DoBacklog(sprintBacklog, timeout: team.GetSprintLenght())()
team.ReviewSprint();
var processChanges = team.PerformRetrospective(sprint);
}
}
IScrumTeam это абстрактный интерфейс - задача конкретной команды его реализовать. Чтобы ее написать, надо знать алгоритмы, которые распространяются отдельно либо можете придумать самостоятельно, если готовые не устраивают.
В вашем случае мне непонятно, почему скрам мастера не помогли.
По идее, их задача помось скоммуницировать команде - подружить вас с PO чтобы он смог вам обяснить почему не берутся в спринт предложенные вами изменения либо чтобы вы объяснили PO, почему их надо взять. PO мог бы помочь с определением бизнес-ценности того, что вы хотели сделать (например, поговорить с заинтересованными лицами) и тогда или бы PBI взяли в спринт либо вы бы могли сказать почему их не взяли.
Приведите, пожалуйста, пример проблемы, созданной из-за несоблюдения интересов наемных инженеров, но никак не затрагивающих интересы бизнеса.
Я тут вижу только три варианта:
Инженеры действуют в интересах бизнеса напрямую - делают фичи, фиксят баги
Инженеры действуют в интересах бизнеса опосредованно (рефакторят код, чтобы его потом проще было менять, т.е. уменьшают стоимость и время пукта 1 в будущем)
Инженеры занимаются инженирингом just for fun - хобби проект, рефакторинг модуля, который все равно выкинут через неделю и заменят сторонним решением, оптимизация како-то процесса, который не находится в узком месте и никогда не будет
Третье я бы классифицировал как хобби за деньги и на оборудовании работодателей. Это не плохо, но должно быть согласовано и рассматриваться как часть пакета компенсации (зарплата, ДМС, льготы на обслуживание у работодателя и т.п.)
Если инженеры действуют в интересах бизнеса то бизнес обладает полнотой информации и ответственнустью за принятия решений - инженер может только рассказать про возможные варианты последствий решения (Если сейчас не отрефактрим, то потом будет в 10 раз труднее менять).
Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании.
Вот это интересно. А почему вы не можете обосновать бизнес ценность? Вы делаете какие-то задачи не зная зачем? Или вы считаете что надо посчитать с точностью до копейки?
Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов
Каркас дома это не дом - посмотрите на картинку. Для постройки дома на основании каркаса нужны материалы для стен и прочее. В каркасе нельзя жить.
В случае скрама есть дополнительная информация - книжки и люди.
Как я понимаю, со скрам мастерами так же как и с психологами. Окончания ВУЗа недостаточно чтобы он был гарантировано полезен. Вот, напрмимер, статья про то, как человек их собеседовал и сколько он отсеял
Любое слово похоже на стандарт, так как есть набор критериев, обозначать ли им явление или нет.
Допустим вы выпускаете каркасы домов (ну или набор чертежей для производства каркасов) под названием "Сетунь-3". Кто-то покупает ваши каркасы, навешивает на них каки-нибудь панели и получается готовый дом.
Потом вдруг люди начинают жаловаться что "Сетунь-3" непрочный отстой.
Вы расследуете причины и выясняете, что покупатели решили что часть балок им не нужно, и решили их отпилить, но готовые дома все равно называют "сделано на базе Сетунь-3" потому, что "Сетунь-3" это раскрученная марка и модно в определенных кругах.
Вы добавляете в инструкцию слова "Вы можете производить любые модификации, только, пожалуйста, на называйте результат "Сетунь-3"".
Фактически, с программными фреймворками та же ситуация - если вы переделаете Spring и будете называть свой фреймворк тоже Spring это приведет к путанице.
Програмные фреймворки в отличие от библиотек, это то, что вызывает ваш код => код должен подчиняться каким-то ограничениям (реализовывать предопределенные фремворком интерфейсы, например), а в библиотеках вы просто пользуетесь набором иструментов из коробки (или как если бы вам поставляли набор балок для вашего каркаса вместо самого каркаса)
In a framework, all the control flow is already there and there are many predefined white spots that we should fill out with our code.
Фактически как и скрам, которые определяет некоторые события и артефакты (control flow) и что от них ожидается, а не просто набор практик.
Вот, кстати, какое-то исследование в качестве примера https://www.researchgate.net/publication/304269511_A_statistical_analysis_of_the_effects_of_Scrum_and_Kanban_on_software_development_projects
Полный текст недоступен бесплатно но заключение можно почитать.
Неа, это будет наблюдение а не эксперимент. Это принципиальная разница - невозможность рандомизации.
Но даже на хорошее наблюдение не тянет.
Рандомный интернетный чувак не осилит прочитать несколько страничек и понять что ему подсунули не скрам под именем скрама. И он будет молчать когда все хорошо и жаловаться когда все плохо.
А видел разных "ответственных за" которые ревьюили код. Я слышал о техническом консалтинге - приходит человек, организует разработку, включая технические практики, когда наладилось уходит. По организационным практикам часто то же самое. Например ведение собрания и организация процессов.
Скрам мастер в гайде это роль, а не человек, возможность ее совмещения не апрещается, хотя в сети есть мнения на этот счет.
А соблюли ли мы при этом методологию или нет - абсолютно неважно.
Совершенно верно. Неважно как сделан салат, главное чтобы был вкусным. Но при этом есть и рецепты.
Если у вас был скрам, то в него встроены механизмы обратной связи от daily scrum где можно сказать что мешает работать до ретроспективы, которая специально предназначена для исправления процесса. В данном случае их можно использовать для выработки компромисса. Вы пытались обсудить это с командой?
По вашему тексту я вижу что вы общались с мастерами, но не вижу взаимодействия с другими людьми.
Я вижу например, претензию к тому, что у вас были навыки которые не использовались в то же время вам назначали работу для которой у вас было недостаточно навыков. К тому же у вас отобрали владение компонентов но назначили владельцем кода компонента.
Как я понимаю, эти вещи взаимосвязанны - из-за депреоритезации работ над компонентом, который вы знаете вы занимались какой-то другой работой. Причем вас это не устраивало а всех остальных да (то есть ваша производительность была нормальной с их точки зрения?).
Теоретически я вижу два выхода из этого:
Назначать вам задачи на компонент (а еще вы хотите выполнять роль PO для него - решать что делать и когда)
Вам доучиться чтобы быть эффективным на этих новых задачах
Из того, что вы написали, непонятно, почему именно задачи были депреоритизированы. Непонятно, общались ли вы с PO чтобы выработать общее понимание приоритетов и стоимости задач ("если бы вы мне дали вон ту задачу, я принес бы пользу вон тому пользователю").
То есть непонятно, была ли попытка сторон понять друг друга и выработать этот самый компромисс. Она была?
я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
Васе больно
Почему? Петя агрессивно по мнению Васи себя повел
А что именно сделал Петя?
Не скажу
Как из таких сведений извлечь для себя какую-то пользу или хотя бы понять причины и следствия?
реальное влияние на приоритеты было только у ПО
По гайду за ПО последнее слово, но совещательный голос может быть у каждого. По гайду, ПО должен обхяснить цель продукта. Вы пробовали как-то аргументировать почему ваши PBI более ценны с точки зрения цели и надо делать их а не то, что выбрал ПО?
Как вы определили, что их нет? Они есть, но не везде, как и коачи.
Есть консалтинг по инженерным практикам, есть инжениринг/техлиды которые выполняют те же функции. Есть практики, типа код ревью, которые поддерживают соблюдение устоявшихся соглашений.
Гайд определяет набор ролей, но не требует, чтобы это были отдельные люди.
Разным людям подходит разный способ работы. Возможно этому человеку скрам просто не подходит (или сочитание скрама и задач). Возможно, он хочет работать не на конечный результат, а полировать конкретный компонент и не важно что заказчику нужно сейчас.
Может ему подойдет какое-то место, где целая команда занимается таким компонентом. Или заказчику не нужен результат, а надо потратить деньги.
Но это очень поверхностное впечатление и я бы без конкретики не делал выводов.
Хорошо, тысячу неодинаковых команд, распределить по методологиям рандомизированно желательно с плацебо-методологиями. Теперь давайте оценим себестоимость такого исследования
Да нет, некоторые инженеры договорятся, некоторые - нет. Можно ли как-то увеличить вероятность того, что они договорятся и выпустят то, что нужно заказчику - вот вопрос.
Не только чтение молитв, есть куча методик как аджайл так и нет. Вы же читали "мифческий человекомесяц", да?
Без конкретики стало непонятно и поэтому неубедительно. Мы можем выбрать какой-то один аспект и разобрать?
Нельзя просто посадить человека в машину и ждать что он доедет сам.
В моем представлении скрам мастера должны быть инструктами по вождению. Куда ехать определяет команда, но как половчее переключать передачи может подсказать скрам мастер.
Когда ты единственный недовольный из нескольких десятков человек,
Вы были единственным недовольным, для остальных это работало, да?
Я больше не могу класть задачи по компоненту в беклог(только на самое дно)
То есть можете, но их приоретизацией (по гайду) должна заниматься команда в соответствии с ценностью, да?
я был занят чем угодно кроме того что умел.
Задач по вашей компетенции не было, они были низкоприоритетными или как? Если встать на точку зрения владельцв продукта, вы бы так же приоретизировали?
Так скрам не содержит инструкции как, например, проводить ретроспективу, что делать, если решения принимаются, но не проводятся в жизнь и так далее. Он не содержит подробных инструкций и методик.
Всякие мастера и коачи по идее должны помогать команде организоваться, следить за настроением в команде, стараться чтобы все были услышанными.
Практически, как я понимаю тут как со школьным психологами - знающих свое дело надо поискать
В области информации каркас и есть описание. И так же как обшиание сайдингом (не знаю, обшивают ли на самом деле или как-то прикрепляют панели, а сайдинг это уже не то) требует сайдинга и навыков а не только каркаса (я, например, не смогу без дополнительного обучения), так же каркаса процесса недостаточно чтобы им овладеть.
Предствьте что Скрам это программный фрефмворк вот с таким кодом
IScrumTeam это абстрактный интерфейс - задача конкретной команды его реализовать. Чтобы ее написать, надо знать алгоритмы, которые распространяются отдельно либо можете придумать самостоятельно, если готовые не устраивают.
Например, для backlog refinement надо знать техники декомпозиции PBI и для приоретизации тоже есть техники.
В вашем случае мне непонятно, почему скрам мастера не помогли.
По идее, их задача помось скоммуницировать команде - подружить вас с PO чтобы он смог вам обяснить почему не берутся в спринт предложенные вами изменения либо чтобы вы объяснили PO, почему их надо взять. PO мог бы помочь с определением бизнес-ценности того, что вы хотели сделать (например, поговорить с заинтересованными лицами) и тогда или бы PBI взяли в спринт либо вы бы могли сказать почему их не взяли.
Приведите, пожалуйста, пример проблемы, созданной из-за несоблюдения интересов наемных инженеров, но никак не затрагивающих интересы бизнеса.
Я тут вижу только три варианта:
Инженеры действуют в интересах бизнеса напрямую - делают фичи, фиксят баги
Инженеры действуют в интересах бизнеса опосредованно (рефакторят код, чтобы его потом проще было менять, т.е. уменьшают стоимость и время пукта 1 в будущем)
Инженеры занимаются инженирингом just for fun - хобби проект, рефакторинг модуля, который все равно выкинут через неделю и заменят сторонним решением, оптимизация како-то процесса, который не находится в узком месте и никогда не будет
Третье я бы классифицировал как хобби за деньги и на оборудовании работодателей. Это не плохо, но должно быть согласовано и рассматриваться как часть пакета компенсации (зарплата, ДМС, льготы на обслуживание у работодателя и т.п.)
Если инженеры действуют в интересах бизнеса то бизнес обладает полнотой информации и ответственнустью за принятия решений - инженер может только рассказать про возможные варианты последствий решения (Если сейчас не отрефактрим, то потом будет в 10 раз труднее менять).
Вот это интересно. А почему вы не можете обосновать бизнес ценность? Вы делаете какие-то задачи не зная зачем? Или вы считаете что надо посчитать с точностью до копейки?
Каркас дома это не дом - посмотрите на картинку. Для постройки дома на основании каркаса нужны материалы для стен и прочее. В каркасе нельзя жить.
В случае скрама есть дополнительная информация - книжки и люди.
Как я понимаю, со скрам мастерами так же как и с психологами. Окончания ВУЗа недостаточно чтобы он был гарантировано полезен. Вот, напрмимер, статья про то, как человек их собеседовал и сколько он отсеял
Любое слово похоже на стандарт, так как есть набор критериев, обозначать ли им явление или нет.
Допустим вы выпускаете каркасы домов (ну или набор чертежей для производства каркасов) под названием "Сетунь-3". Кто-то покупает ваши каркасы, навешивает на них каки-нибудь панели и получается готовый дом.
Потом вдруг люди начинают жаловаться что "Сетунь-3" непрочный отстой.
Вы расследуете причины и выясняете, что покупатели решили что часть балок им не нужно, и решили их отпилить, но готовые дома все равно называют "сделано на базе Сетунь-3" потому, что "Сетунь-3" это раскрученная марка и модно в определенных кругах.
Вы добавляете в инструкцию слова "Вы можете производить любые модификации, только, пожалуйста, на называйте результат "Сетунь-3"".
Фактически, с программными фреймворками та же ситуация - если вы переделаете Spring и будете называть свой фреймворк тоже Spring это приведет к путанице.
Програмные фреймворки в отличие от библиотек, это то, что вызывает ваш код => код должен подчиняться каким-то ограничениям (реализовывать предопределенные фремворком интерфейсы, например), а в библиотеках вы просто пользуетесь набором иструментов из коробки (или как если бы вам поставляли набор балок для вашего каркаса вместо самого каркаса)
Фактически как и скрам, которые определяет некоторые события и артефакты (control flow) и что от них ожидается, а не просто набор практик.
То есть это не комромисс, а подчинённость интересам бизнеса, только долгосрочным, да?
Вот, кстати, какое-то исследование в качестве примера https://www.researchgate.net/publication/304269511_A_statistical_analysis_of_the_effects_of_Scrum_and_Kanban_on_software_development_projects
Полный текст недоступен бесплатно но заключение можно почитать.
Неа, это будет наблюдение а не эксперимент. Это принципиальная разница - невозможность рандомизации.
Но даже на хорошее наблюдение не тянет.
Рандомный интернетный чувак не осилит прочитать несколько страничек и понять что ему подсунули не скрам под именем скрама. И он будет молчать когда все хорошо и жаловаться когда все плохо.
Так приведите ссылку на исследование зачем "кажется"? Кто и где этот эксперимент проводил?
А видел разных "ответственных за" которые ревьюили код. Я слышал о техническом консалтинге - приходит человек, организует разработку, включая технические практики, когда наладилось уходит.
По организационным практикам часто то же самое. Например ведение собрания и организация процессов.
Скрам мастер в гайде это роль, а не человек, возможность ее совмещения не апрещается, хотя в сети есть мнения на этот счет.
Совершенно верно. Неважно как сделан салат, главное чтобы был вкусным. Но при этом есть и рецепты.
Если у вас был скрам, то в него встроены механизмы обратной связи от daily scrum где можно сказать что мешает работать до ретроспективы, которая специально предназначена для исправления процесса. В данном случае их можно использовать для выработки компромисса. Вы пытались обсудить это с командой?
По вашему тексту я вижу что вы общались с мастерами, но не вижу взаимодействия с другими людьми.
Я вижу например, претензию к тому, что у вас были навыки которые не использовались в то же время вам назначали работу для которой у вас было недостаточно навыков. К тому же у вас отобрали владение компонентов но назначили владельцем кода компонента.
Как я понимаю, эти вещи взаимосвязанны - из-за депреоритезации работ над компонентом, который вы знаете вы занимались какой-то другой работой. Причем вас это не устраивало а всех остальных да (то есть ваша производительность была нормальной с их точки зрения?).
Теоретически я вижу два выхода из этого:
Назначать вам задачи на компонент (а еще вы хотите выполнять роль PO для него - решать что делать и когда)
Вам доучиться чтобы быть эффективным на этих новых задачах
Из того, что вы написали, непонятно, почему именно задачи были депреоритизированы. Непонятно, общались ли вы с PO чтобы выработать общее понимание приоритетов и стоимости задач ("если бы вы мне дали вон ту задачу, я принес бы пользу вон тому пользователю").
То есть непонятно, была ли попытка сторон понять друг друга и выработать этот самый компромисс. Она была?
Васе больно
Почему? Петя агрессивно по мнению Васи себя повел
А что именно сделал Петя?
Не скажу
Как из таких сведений извлечь для себя какую-то пользу или хотя бы понять причины и следствия?
По гайду за ПО последнее слово, но совещательный голос может быть у каждого. По гайду, ПО должен обхяснить цель продукта. Вы пробовали как-то аргументировать почему ваши PBI более ценны с точки зрения цели и надо делать их а не то, что выбрал ПО?
А какой бы он был?
Как вы определили, что их нет? Они есть, но не везде, как и коачи.
Есть консалтинг по инженерным практикам, есть инжениринг/техлиды которые выполняют те же функции. Есть практики, типа код ревью, которые поддерживают соблюдение устоявшихся соглашений.
Гайд определяет набор ролей, но не требует, чтобы это были отдельные люди.
Разным людям подходит разный способ работы. Возможно этому человеку скрам просто не подходит (или сочитание скрама и задач). Возможно, он хочет работать не на конечный результат, а полировать конкретный компонент и не важно что заказчику нужно сейчас.
Может ему подойдет какое-то место, где целая команда занимается таким компонентом. Или заказчику не нужен результат, а надо потратить деньги.
Но это очень поверхностное впечатление и я бы без конкретики не делал выводов.
Хорошо, тысячу неодинаковых команд, распределить по методологиям рандомизированно желательно с плацебо-методологиями. Теперь давайте оценим себестоимость такого исследования
Да нет, некоторые инженеры договорятся, некоторые - нет. Можно ли как-то увеличить вероятность того, что они договорятся и выпустят то, что нужно заказчику - вот вопрос.
Не только чтение молитв, есть куча методик как аджайл так и нет. Вы же читали "мифческий человекомесяц", да?
Без конкретики стало непонятно и поэтому неубедительно. Мы можем выбрать какой-то один аспект и разобрать?
В моем представлении скрам мастера должны быть инструктами по вождению. Куда ехать определяет команда, но как половчее переключать передачи может подсказать скрам мастер.
Вы были единственным недовольным, для остальных это работало, да?
То есть можете, но их приоретизацией (по гайду) должна заниматься команда в соответствии с ценностью, да?
Задач по вашей компетенции не было, они были низкоприоритетными или как?
Если встать на точку зрения владельцв продукта, вы бы так же приоретизировали?
Можно специфический пример?
Вы рассмотрели все опенсурс проекты или только выжившие?
Хороший поп имхо тоже типа психолога
Так скрам не содержит инструкции как, например, проводить ретроспективу, что делать, если решения принимаются, но не проводятся в жизнь и так далее. Он не содержит подробных инструкций и методик.
Всякие мастера и коачи по идее должны помогать команде организоваться, следить за настроением в команде, стараться чтобы все были услышанными.
Практически, как я понимаю тут как со школьным психологами - знающих свое дело надо поискать