Да, в вашем примере это имеет некий смысл. Потому что в том примере, о котором говорил я - а он легко гуглится, модная была картинка, напр https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154 - скажите мне как из самоката сделать велосипед, а их него авто? ) У вас то как раз то, на что Атлассиан говорит "не надо так делать!" )) Даже к вашему примеру сразу возникают вопросы:
А что вообще клиенту надо, автомобиль для передвижения вероятно? Ок, в первой итерации мы ему дали самай самый MVP, можно катать как тележку. А дальше что? Он сможет поехать на авто с рамой, колесами и кузовом, но без руля и двигателя? Какую ценность он извлечет из сверкающего новым лаком авто который не едет? И какой фидбэк он даст, что мы сможем скорректировать в работе? А не получится так что он покатает руками раму, потом посидит в салоне, порулит, "все Ок, продолжайте парни!" - а в финале, любуясь на сверкающий спорткар, спросит "Супер тачка, а куда тут бетонные плиты то грузить?" Тут изобретать примеры можно долго, но думаю идея понятна - если вы не сможете каждый спринт отгружать ценныйрабочий инкремент и получать по нему фидбэк "да, это то что надо", или "нет, мне нужно совсем другое" - толку от Скрама не будет.
Мне кажется вы путаете гибкую методологию управления и отсутствие методологии. Ответы на ваши вопросы на самом деле уже есть в гайде по скраму. Но кто-то заставляет вас использовать именно этот фреймворк? Если вам не нравятся дейли или ретроспективы - не проводите их. Не хотите брать писать цель продукта и цель спринта, брать на себя ответственность, хотите полную свободу - ну на здоровье. Если у вас в таком виде все работает - отлично, если нет - не стоит считать что скрам какой-то не такой. Судя по вашей риторике, "хотим работать так как удобно нам", "искать виноватого" - мне кажется скрам вам не нужен, при всем уважении.
Как управлять качеством разработки - закладывайте 30% от оценки разработки на тестирование и еще 30% резерв на отладку, и собирайте метрики. А это точно управление качеством? ) В PMBoK например аж 7 основных инструментов контроля качества. Используете?
Мысль интересная. Хотя в гайде и написано что дейли на то и дейли, чтобы каждый день в одно и то же время проходить, но если нет никаких проблем, всем понятен план на день (а предназначение дейли как раз "создает план действий на следующий рабочий день"), то наверное можно и не проводить каждый день. Только мне кажется тут рисков будет больше чем выгоды с экономии этих 15 минут
Хорошо, я чуть подробнее объясню свою мысль: Вы описываете некие проблемы, не связанные со скрамом как подходом к организации работы, а потом делаете вывод "такие жесткое следование гайду работает против интересов заказчика". Какое следование гайду? "От принудительных не приносящих продукту никакой оптенциальной пользы ритуалов (как например, давайте придумаем название нашей команде) " - нет там никаких названий команд. Вам эти ритуалы не приносят пользы, и вы делаете вывод что они бесполезные - а для других польза есть, представьте. Может дело не в ритуалах, а в том как вы их проводите? "Ты приучаешься ждать какого-то собрания чтобы о чем-то сказать. Вместо того, чтобы общаться естественно и непринужденно" - нет этого в скраме и близко, там все наоборот. Если ваш менеджер не дает вам обсуждать проблемы с аргументом "сейчас не время, на ретро скажешь" - это не скрам.
Ну и так далее по остальным пунктам. Скрам последовательно сокращают, оставляя только самое важное, остальное - пробуйте и подбирайте для себя сами.
P.S. Вот "бирюзовые организации" это действительно глупость, притянутая за уши в отрасль.
Сделать это сотрудники по своей инициативе конечно могут, но они должны этого захотеть сами. А зачем, если главная причина увольнений - низкая ЗП? Платить больше после внедрения CI/CD или авто тестирования на станут, разве что потренироваться, для собственного развития, а потом уйти туда где оплачивают эти знания
Здесь как мне кажется в MBWA тонкая грань между полезным приемом "гемба-менеджмент" или гемба-спринты, которые действительно могут быть полезны и помочь руководству получше узнать детали работы, и MBWA превращающийся в чайка-менеджемент.
Под "чёрным скрамом" вы видимо имели в виду "Черную книгу Скрама" И. Селиховкина?
Так это был ответ на посыл "можно релизить без всяких скрамов и целей"
Можно то можно, но на практике подход "просто дайте программистам работать, без скрамов и управлений проектами" работает редко :) Мне кажется весь этот Скрам-хайп уже прошел пик, дальше будет нормальное использование там где это уместно
А вот и не согласен. CI/CD, автотесты и т.п. - это инструменты. Они ничего не дадут, если команде фиолетово какие там у клиента проблемы, и целью спринта считается закрыть все взятые в спринт таски. Ну а релизить несколько раз в день конечно хорошо, главное релизить то что надо клиенту или пользователям, а это бывает не всегда )
Судя по описанию, новой идеи там нет, то что например velocity очень условный показатель уже давным-давно все говорят, не надо начинать "управлять метриками" Но в любом случае спасибо за ссылки
"давайте сократим менеджера/линейщика (а точнее дадим ему ещё три группы/команды) а его работу спустили посредством скрама(или другой подобной модной штуке) на рядовых работников" - а вот тут выше товарищ пишет что менеджеры и всякие скрам-мастера это паразиты, нет у них никакой работы ))
Но вы правильно написали - унылая реализация. При должном старании любой самый проверенный и надежный метод работы можно провалить. Скрам, как мне кажется, только миновал пик хайпа. Лет через 5 никто не будет ругать его как пустышку или считать волшебной таблеткой, просто еще один инструмент.
Скрам не задумывался как подход, предназначенный для уменьшения работы в общем случае. Он предназначен для уменьшения лишней "неправильной" работы, когда конечный результат не ясен, промежуточные шаги не ясны и т.п. Вместо того чтобы пытаться изначально все планировать, Скрам предлагает идти мелкими шагами, после каждого шага пробуя что получилось и выясняя, туда ли мы движемся. И да, в Скраме нет менеджера. Если вы работаете в окружении что менеджер есть и он всю ответственность переложил на команду, Скрам тут не при чем. Скрам-мастер запросто может быть один из разработчиков, PO (product owner - владелец продукта) формально тоже, хотя в реальности так бывает редко - человек с такими навыками, которые нужны хорошему РО, сам код не пишет, это нерационально.
Проблемы не в подходе Скрам/Канбан/водопад/whatever как таковом, а в неумелом управлении, неуместном или неправильном применении подхода, неправильном подборе команды и так далее
Никто не говорит что статус вообще не нужно детально обсуждать или описывать. Здесь речь конкретно про дейлики - если нет блокировщиков, и нет какой-то важной информации по этой задаче для остальной команды, не смысла подробно описывать что вы там сделали и что собираетесь делать, команда от этого теряет бдительность и засыпает )
Спасибо, рад что усилия потрачены не зря.
Да, в вашем примере это имеет некий смысл. Потому что в том примере, о котором говорил я - а он легко гуглится, модная была картинка, напр https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154 - скажите мне как из самоката сделать велосипед, а их него авто? ) У вас то как раз то, на что Атлассиан говорит "не надо так делать!" ))
Даже к вашему примеру сразу возникают вопросы:
А что вообще клиенту надо, автомобиль для передвижения вероятно? Ок, в первой итерации мы ему дали самай самый MVP, можно катать как тележку. А дальше что? Он сможет поехать на авто с рамой, колесами и кузовом, но без руля и двигателя? Какую ценность он извлечет из сверкающего новым лаком авто который не едет? И какой фидбэк он даст, что мы сможем скорректировать в работе? А не получится так что он покатает руками раму, потом посидит в салоне, порулит, "все Ок, продолжайте парни!" - а в финале, любуясь на сверкающий спорткар, спросит "Супер тачка, а куда тут бетонные плиты то грузить?"
Тут изобретать примеры можно долго, но думаю идея понятна - если вы не сможете каждый спринт отгружать ценный рабочий инкремент и получать по нему фидбэк "да, это то что надо", или "нет, мне нужно совсем другое" - толку от Скрама не будет.
Так это же не инкрементальный подход, это обычное эволюционное развитие.
Точно так же и любая другая техника создается
Неужели до сих пор платят бонусы за "успешное внедрение Скрама"? )
Мне кажется такое только в крупных компаниях может быть, а там уже по скрам-граблям не ходят. Хотя...
Вот так делать не надо ))
Лучше сразу сказать "Вангую, не взлетит, и вот почему"
Мне кажется вы путаете гибкую методологию управления и отсутствие методологии.
Ответы на ваши вопросы на самом деле уже есть в гайде по скраму. Но кто-то заставляет вас использовать именно этот фреймворк? Если вам не нравятся дейли или ретроспективы - не проводите их. Не хотите брать писать цель продукта и цель спринта, брать на себя ответственность, хотите полную свободу - ну на здоровье. Если у вас в таком виде все работает - отлично, если нет - не стоит считать что скрам какой-то не такой.
Судя по вашей риторике, "хотим работать так как удобно нам", "искать виноватого" - мне кажется скрам вам не нужен, при всем уважении.
Как управлять качеством разработки - закладывайте 30% от оценки разработки на тестирование и еще 30% резерв на отладку, и собирайте метрики.
А это точно управление качеством? )
В PMBoK например аж 7 основных инструментов контроля качества. Используете?
Мысль интересная. Хотя в гайде и написано что дейли на то и дейли, чтобы каждый день в одно и то же время проходить, но если нет никаких проблем, всем понятен план на день (а предназначение дейли как раз "создает план действий на следующий рабочий день"), то наверное можно и не проводить каждый день.
Только мне кажется тут рисков будет больше чем выгоды с экономии этих 15 минут
Хорошо, я чуть подробнее объясню свою мысль:
Вы описываете некие проблемы, не связанные со скрамом как подходом к организации работы, а потом делаете вывод "такие жесткое следование гайду работает против интересов заказчика".
Какое следование гайду?
"От принудительных не приносящих продукту никакой оптенциальной пользы ритуалов (как например, давайте придумаем название нашей команде) " - нет там никаких названий команд. Вам эти ритуалы не приносят пользы, и вы делаете вывод что они бесполезные - а для других польза есть, представьте. Может дело не в ритуалах, а в том как вы их проводите?
"Ты приучаешься ждать какого-то собрания чтобы о чем-то сказать. Вместо того, чтобы общаться естественно и непринужденно" - нет этого в скраме и близко, там все наоборот. Если ваш менеджер не дает вам обсуждать проблемы с аргументом "сейчас не время, на ретро скажешь" - это не скрам.
Ну и так далее по остальным пунктам. Скрам последовательно сокращают, оставляя только самое важное, остальное - пробуйте и подбирайте для себя сами.
P.S. Вот "бирюзовые организации" это действительно глупость, притянутая за уши в отрасль.
Сделать это сотрудники по своей инициативе конечно могут, но они должны этого захотеть сами. А зачем, если главная причина увольнений - низкая ЗП? Платить больше после внедрения CI/CD или авто тестирования на станут, разве что потренироваться, для собственного развития, а потом уйти туда где оплачивают эти знания
А виноват во всех этих бедах скрам, как я понял?)
Зачем строительная компания скрам использует, они что наугад строят БЦ?
Зачем геймдевы скрам используют при фиксированном бюджете и чётком ТЗ?
У вас логическая ошибка.
Все что выше фразы "такое жесткое следование гайду" - никакого отношения к скраму не имеет
Здесь как мне кажется в MBWA тонкая грань между полезным приемом "гемба-менеджмент" или гемба-спринты, которые действительно могут быть полезны и помочь руководству получше узнать детали работы, и MBWA превращающийся в чайка-менеджемент.
Под "чёрным скрамом" вы видимо имели в виду "Черную книгу Скрама" И. Селиховкина?
Так это был ответ на посыл "можно релизить без всяких скрамов и целей"
Можно то можно, но на практике подход "просто дайте программистам работать, без скрамов и управлений проектами" работает редко :) Мне кажется весь этот Скрам-хайп уже прошел пик, дальше будет нормальное использование там где это уместно
А вот и не согласен.
CI/CD, автотесты и т.п. - это инструменты.
Они ничего не дадут, если команде фиолетово какие там у клиента проблемы, и целью спринта считается закрыть все взятые в спринт таски.
Ну а релизить несколько раз в день конечно хорошо, главное релизить то что надо клиенту или пользователям, а это бывает не всегда )
Судя по описанию, новой идеи там нет, то что например velocity очень условный показатель уже давным-давно все говорят, не надо начинать "управлять метриками"
Но в любом случае спасибо за ссылки
"давайте сократим менеджера/линейщика (а точнее дадим ему ещё три группы/команды) а его работу спустили посредством скрама(или другой подобной модной штуке) на рядовых работников" - а вот тут выше товарищ пишет что менеджеры и всякие скрам-мастера это паразиты, нет у них никакой работы ))
Но вы правильно написали - унылая реализация. При должном старании любой самый проверенный и надежный метод работы можно провалить. Скрам, как мне кажется, только миновал пик хайпа. Лет через 5 никто не будет ругать его как пустышку или считать волшебной таблеткой, просто еще один инструмент.
Скрам не задумывался как подход, предназначенный для уменьшения работы в общем случае.
Он предназначен для уменьшения лишней "неправильной" работы, когда конечный результат не ясен, промежуточные шаги не ясны и т.п. Вместо того чтобы пытаться изначально все планировать, Скрам предлагает идти мелкими шагами, после каждого шага пробуя что получилось и выясняя, туда ли мы движемся.
И да, в Скраме нет менеджера.
Если вы работаете в окружении что менеджер есть и он всю ответственность переложил на команду, Скрам тут не при чем.
Скрам-мастер запросто может быть один из разработчиков, PO (product owner - владелец продукта) формально тоже, хотя в реальности так бывает редко - человек с такими навыками, которые нужны хорошему РО, сам код не пишет, это нерационально.
Проблемы не в подходе Скрам/Канбан/водопад/whatever как таковом, а в неумелом управлении, неуместном или неправильном применении подхода, неправильном подборе команды и так далее
Где вы это увидели? В таблице по ссылке нет резкого скачка вероятности после 11 лет
Никто не говорит что статус вообще не нужно детально обсуждать или описывать.
Здесь речь конкретно про дейлики - если нет блокировщиков, и нет какой-то важной информации по этой задаче для остальной команды, не смысла подробно описывать что вы там сделали и что собираетесь делать, команда от этого теряет бдительность и засыпает )