http://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf

Вы б лучше скрам-гайд цитировали, точнее источник

С какой стати? Я не ориентируюсь только на Scrum

С какой стати? Я не ориентируюсь только на Scrum

Это как?

Это как?

Это значит, отсутствие скрама головного мозга и признание существования других методологий, перечисленных в заголовке данной группы

😂

Встреча раз в неделю это уже поболее чем стендап ).. Обычно на мы на стендапе встретились, отчитались кто где сейчас, скрам мастер проверил пульс и разошлись. Если ктото над какойто задачей начал буксовать то узнали причины, поискали решение как помочь.. ктото задал вопросы.. получил ответы или назначили друг другу отдельно митинга для унлубленного обсуждения. БА и прочие поняли где и кто сейчас и тп. Вообщем полезно.

Это значит, отсутствие скрама головного мозга и признание существования других методологий, перечисленных в заголовке данной группы

Так может быть сначало стоило почитать литературу, а потом задавать вопросы?

Так может быть сначало стоило почитать литературу, а потом задавать вопросы?

Давайте список, где есть ответы на заданные вопросы, с удовольствием почитаю

Это значит, отсутствие скрама головного мозга и признание существования других методологий, перечисленных в заголовке данной группы

Вы для начала разберитесь как хотя бы Scrum работает, прежде чем начинать выкидывать из него «ненужное» и с чем-то скрещивать. Для Kanban-метода у меня аналогичный совет

Давайте список, где есть ответы на заданные вопросы, с удовольствием почитаю

А вдруг разовьётся скрам головного мозга?

Давайте список, где есть ответы на заданные вопросы, с удовольствием почитаю

Пункт 1 в списке - скрам гайд.

Пункт 1 в списке - скрам гайд.

Нельзя давать, там же одни мантры 😊

Вы для начала разберитесь как хотя бы Scrum работает, прежде чем начинать выкидывать из него «ненужное» и с чем-то скрещивать. Для Kanban-метода у меня аналогичный совет

Михаил, спасибо за совет! Ответов на мои вопросы в скрамгайде не вижу.

Я пока не понял, а что вас останавливает от того, чтобы самим попробовать сделать как написано?

Я пока не понял, а что вас останавливает от того, чтобы самим попробовать сделать как написано?

1. Отсутствие чётких ответов на заданные вопросы 2. Нежелание слепо следовать методологии, особенно не разбираясь что к чему (вот тут даже скрам-мастера путаются в целях, зачем нужен daily standup, и ставят под сомнение его эффективность) и 3. Наличие альтернативных хорошо зарекомендовавших практик из других методологий, которые Вы почему-то игнорируете, а вместо того чтобы изучить их и подумать/сравнить, призываете читать б̶и̶б̶л̶и̶ю̶ ScrumGuide.

1. Отсутствие чётких ответов на заданные вопросы 2. Нежелание слепо следовать методологии, особенно не разбираясь что к чему (вот тут даже скрам-мастера путаются в целях, зачем нужен daily standup, и ставят под сомнение его эффективность) и 3. Наличие альтернативных хорошо зарекомендовавших практик из других методологий, которые Вы почему-то игнорируете, а вместо того чтобы изучить их и подумать/сравнить, призываете читать б̶и̶б̶л̶и̶ю̶ ScrumGuide.

а как у вас щас?

вам столько всего мешает

сейчас у нас то, что по смыслу близко к слову Scrumban 😊 На 75% тяготеет к Канбану

честно я не знаю что это такое)

у нас дейли митинги нормально работают

А) Реально; Б) Если члены команды начинают вести себя так, как вы описали, значит проблема со здоровьем команды в целом и пониманием цели данного мероприятия у людей

возможно они както не по скраму работают но свою функцию выполняют

"Слепо следовать" можно именно что "методологиям", а не фреймворку. Если вы используете что-то из него, но не весь целиком - просто не называйте это Скрамом, все же просто :)

"Слепо следовать" можно именно что "методологиям", а не фреймворку. Если вы используете что-то из него, но не весь целиком - просто не называйте это Скрамом, все же просто :)

шаг в сторону сделать нельзя?)

все по библии?

Можно, но тут я соглашусь с предыдущими ораторами - прежде чем говорить что что-то не работает, нужно попробовать оригинал) причем на мой взгляд это относится к каждой команде, а не к "личному опыту" Скрам Мастера

Опять же, одно дело дополнять костяк фреймворка какими-то техническими или бизнес техниками из других фреймворков, и другое дело - заменять ими инструментарий первоначального фреймворка. Какой тогда смысл продолжать называть его "Скрамом", "Канбаном" или чем бы то ни было еще?)

важнее быть "скрамом" или делать дело?

Важнее делать дело, но тут вопрос в другом

я понимаю конечно что в этом чате все обсуждаюткак делать дело по скраму

но я просто ваш поинт не пойму

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

Мы же не называем маффин блином или брауни, хотя это тоже выпечка. Когда каждому понятно что конкретно скрывается под тем или иным названием, все сразу становится проще - consistency reduces complexity :)

ну слушайте если у вас все работает то че выделываться?)

все же это сделано чтобы круто доставлять продукт. если вы и так доставляете круто то че париться?)

ну так ни одна команда и ни один продукт же не существует в вакууме)) Ваш довод звучит как коронная фраза “У меня локально все работает” в споре между разработчиком и тестировщиком)

а что у вас не работает?

ничто не будет работать если один раз “настроить” и не трогать - вся суть что Аджайл в целом, что Скрама в continuous improvement и способах сделать хорошее еще лучше

откуда такой вывод?

если у вас все хорошо то чего трогать?

если у вас все хорошо то чего трогать?

Потому что может и должно быть лучше.

Потому что может и должно быть лучше.

это вы как определили?

все что не скрам то плохо?

это вы как определили?

Это внутренне убеждение. Что то аналогичное: "много денег не бывает". Но кому то для полного счастья шесть тысяч четыреста рублей в самый раз.

у вас "внутреннее убеждение" что нет мира без скрама?

"Много денег не бывает" вы тоже без скрама не видите?) Процесс непрерывных улучшений - часть скрама. Но придуман не в рамках этого фреймворка. Популяризировали этот подход успехи Тойота 80х и книга Масааки.

если честно я не понимаю на что вы отвечаете

скрам круто? — да

нужно искать узкие места? — да

причем тут к нашему диалогу тойота?

вы по-моему говорите лозунгами

Если мы работаем по КанБан у нас конвеер с относительно простыми задачами, мы собираем метрики у нас WIP определены. Зачем этот процесс трогать?

Если я правильно понял, нашу беседу, то Константин говорит, а давайте возьмём все самое лучшее из методологий и фреймворков самое лучшее и будем так работать.

Если я правильно понял, нашу беседу, то Константин говорит, а давайте возьмём все самое лучшее из методологий и фреймворков самое лучшее и будем так работать.

А Влад говорит о том, что ретроспективы нужны для постоянного улучшения работы в рамках фреймворка scrum

Если я правильно понял, нашу беседу, то Константин говорит, а давайте возьмём все самое лучшее из методологий и фреймворков самое лучшее и будем так работать.

Мысль замечательная и интересная, вот только, чтобы выбрать самое лучшее - нужно досконально понимать как эти самые фреймворки и методологии работают и почему. Я выше примерно за это топил. А так на практике Scrum и Kanban вполне себе могут дополнять друг друга

Мысль замечательная и интересная, вот только, чтобы выбрать самое лучшее - нужно досконально понимать как эти самые фреймворки и методологии работают и почему. Я выше примерно за это топил. А так на практике Scrum и Kanban вполне себе могут дополнять друг друга

Желательно понимать фреймворки не только теоретически но и практически.

Нужна и практика

У scrum команд нет начальников, за результат спринта отвечает команда.

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

Нужна и практика

Согласен

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

Очень странный аргумент "мы же старались".

Очень странный аргумент "мы же старались".

Если владелец бюджета отказывается от команды, потому что они делают не то что нужно или получает не такой результат, то любой аргумент "а еще мы сделали вот это.." будет нести тот же смысл "мы же старались, давайте еще раз попробуем". У руководителя есть весомый "аргумент" - он или платит этим людям или не платит. Его можно называть "владелец продукта" или "начальник" но рычаг бюджета это его "аргумент": Нет денег - нет работы дла команды. Я это всё к тому, что принцип "локальной адаптации" должен работать. и нельзя списывать со счетов реальность. Scrum хорош но как базовый процессный каркас кторый нужно вшивать в структуру и правила компании. И у компании всегда есть тот кто владеет бюджетом и тот кто "начальник".

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

Если владелец бюджета отказывается от команды, потому что они делают не то что нужно или получает не такой результат, то любой аргумент "а еще мы сделали вот это.." будет нести тот же смысл "мы же старались, давайте еще раз попробуем". У руководителя есть весомый "аргумент" - он или платит этим людям или не платит. Его можно называть "владелец продукта" или "начальник" но рычаг бюджета это его "аргумент": Нет денег - нет работы дла команды. Я это всё к тому, что принцип "локальной адаптации" должен работать. и нельзя списывать со счетов реальность. Scrum хорош но как базовый процессный каркас кторый нужно вшивать в структуру и правила компании. И у компании всегда есть тот кто владеет бюджетом и тот кто "начальник".

Да, к сожалению реальность такова, что CEO читает книжки, статьи, понимает, что нужно переходить на Agile. И пишет приказ, с понедельника вся компания Agile, и тут начинается самое веселое....

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

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

И ваша Аджайл методология у нас не работает, к нашей компании гибкие не применимы

Без обучения всей компании что такое Agile, scrum, kanban, без изменения орг структуру в сторону кросс функциональных команд. Изменения функциональных обязанностей прослойки менеджеров среднего звена и многих других изменений Agile,scrum, kanban это полумеры.

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

Дополню, то что у вас получится назовите (название вашей компании)джайл. И никого не надо обманывать, главное себя.

Без обучения всей компании что такое Agile, scrum, kanban, без изменения орг структуру в сторону кросс функциональных команд. Изменения функциональных обязанностей прослойки менеджеров среднего звена и многих других изменений Agile,scrum, kanban это полумеры.

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

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

Да, конечно, все должны понимать, зачем компания делает этот шаг. Ведь раньше компания как то работала.

Да, конечно, все должны понимать, зачем компания делает этот шаг. Ведь раньше компания как то работала.

Думаю, этот момент много важнее, чем кажется на первый взгляд. Это означает, готовы ли люди "сверху" перекроить "пирамидку власти" и поставить вопрос о том, что им нужно другое качество управляемости компании - управляемость по предсказуемости. Командное управление компанией всей компанией. Это очень не очевидный тезис, думаю, тут есть кто-то с примерами "как я почти развалил бизнес клиента, попытавшись поставить его на Agile-SCRUM-...". Как минимум, я :)

👍

Нихрена себе меня повысили

Дима, вот признание и пришло

#whois Работаю в EY Повышение эффективности бизнеса (стратегия, модели управления, б-процессы) Москва Интересно использование agile в консалтинговых проектах Могу поделиться собственным проектным опытом Ссылку на группу дал знакомый по фб

Подписка на #whois

Что такое EY?

Ernst and young

Спасибо

Думаю, этот момент много важнее, чем кажется на первый взгляд. Это означает, готовы ли люди "сверху" перекроить "пирамидку власти" и поставить вопрос о том, что им нужно другое качество управляемости компании - управляемость по предсказуемости. Командное управление компанией всей компанией. Это очень не очевидный тезис, думаю, тут есть кто-то с примерами "как я почти развалил бизнес клиента, попытавшись поставить его на Agile-SCRUM-...". Как минимум, я :)

Нашел аналогичные слова с позиции "digital transformation": "Действительно, одним из основных элементов преобразования от от ручной к машинной продукции является творческий редизайн эквивалентного продукта. Таким образом, механизация крупной организации может не сработать, если вы попытаетесь сохранять продукт в деталях точно таким же, скорее, должен быть принят крупный компромисс, если мы хотим обеспечить себе значительный успех. Вы должны понять суть производства, а затем разработать алгоритм производства продукта, его новую форму, а не пытаться механизировать текущую версию и текущие производственные реалии — если вы хотите добиться значительного успеха в долгосрочной перспективе. " https://habrahabr.ru/post/345836/

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

а в чем проблема дэйли статус митингов?