Дайте больше работы, новые инженерные практики, дайте ответственность за работу (а не чтобы «тестирование» отвечало).

Где есть разбиение по отделам

Скрам в каждом из отделов?

Но в целом идея понятна, если есть четкая орг структура и разбиение по отделам со спец навыками, то Скраму там не жить(резюмируя наш диалог)

Грубо говоря - да.

Скрам в каждом из отделов?

Нет 1 проект 1 команда, структура матричная. У нас как и 99% компаний которые любят Скрам но при этом живут отделами такая проблема, что есть четкое разделение, и в итоге либо народ не до загружен и тестировщик успевает дотестмровать до конца спринта, либо все под завязку и естественно тестирование не успевается.

Я смотрю в сторону кабана, что думаете? Мне в нем все нравится, единственное непонятно как мотивировать команду на результат

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

Я смотрю в сторону кабана, что думаете? Мне в нем все нравится, единственное непонятно как мотивировать команду на результат

Берите. Если вам скрам не заходит, то и работать он у вас не будет.

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

мы начинали с Канбана, потом поняли, что Скрам подходит лучше) и перешил постепенно не него там где новая разарботка; в техподдержке Канбан-подход

Ну я про то, что если нет веры в скрам, то лучше не начинать.

Неосознанно будут саботировать :)

мы начинали с Канбана, потом поняли, что Скрам подходит лучше) и перешил постепенно не него там где новая разарботка; в техподдержке Канбан-подход

в поддержке канбан хорошо работает, главное за приоритетами следить, а не только за временем поставки

У нас заказаная разработка по ТЗ, правда его аналитики доводят до нормального вида, более детализированного(да есть еще и аналитики)

В поддержке у нас он да

Но мы в DevOps, поэтому хотелось бы админов сделать ближе к разработке, но не заставлять их писать код

Поэтому на кабан и смотрю, есть у кого нибудь опыт мотивации а канбан? В Скрам это спринты, а тут нет конца команда расслабиться..

Боюсь, проблема мотивации лежит в другой плоскости. Канбан и скрам не помогут в этом. Так мне кажется.

Поэтому на кабан и смотрю, есть у кого нибудь опыт мотивации а канбан? В Скрам это спринты, а тут нет конца команда расслабиться..

в Канбан каденции есть если что, а мотивация, например, в этой части от понимания "нужности", например, когда команда показывает результаты и получает обратную связь от заказчика

Я больше склоняюсь к кабану, но у на почему то все в ИТ любят Скрам, хотя Андрей с вами полностью согласен, что при четкой орг структуре Скрам не заходит

Я не говорил про "чёткую оргструктуру", я говорил про привычные функциональные колодцы. Можно построить продуктово-ориентированную структуру не меньшей чёткости, в которой всё будет хорошо со Скрамом.

То же самое и с размером - SAFe и LeSS как раз предназначены для крупных компаний

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

Самая настоящая не материальная мотивация

Спасибо за доходчивое разъяснение, буду смотреть

про мотивацию хорошо Дэниел Пинк сформулирвоал, что грубо говоря есть три мотивирующих компонента: стремление к мастерству, автономность и стремление к цели))

Подходит ли в таким случае Скрам для крупных серьезных продуктов, а не экспериментов?

Знаю о чем речь так как работал в инвест-банке. Да, было разделение на роли из-за запредельной сложности домена. Аналитики (причём двух типов - бизнес и системные) были необходимы просто потому, что разработчикам без соответствующего финансового образования было практически не реально понять домен на нужном уровне. Тем не менее мы работали по скраму. Конечно там не было полной кросс функциональности, но по крайней мере это было эталоном к которому стремились: разработчики посещали тренинги по финансовым инструментам, аналитики пытались разобраться в архитектуре. Тестировщики учились программировать и автоматизировать тесты.

Знаю о чем речь так как работал в инвест-банке. Да, было разделение на роли из-за запредельной сложности домена. Аналитики (причём двух типов - бизнес и системные) были необходимы просто потому, что разработчикам без соответствующего финансового образования было практически не реально понять домен на нужном уровне. Тем не менее мы работали по скраму. Конечно там не было полной кросс функциональности, но по крайней мере это было эталоном к которому стремились: разработчики посещали тренинги по финансовым инструментам, аналитики пытались разобраться в архитектуре. Тестировщики учились программировать и автоматизировать тесты.

Я не понимаю как можно закрыть спринт не универсальной командой, это тупо математически не возможно. Либо недозагруз, что все ИТ работает в пол силы. Порой Скрам есть, да он не настоящий.

То же самое и с размером - SAFe и LeSS как раз предназначены для крупных компаний

LeSS не только для крупных компаний. от 20-40 человек

LeSS не только для крупных компаний. от 20-40 человек

Но и для крупных тоже, а вопрос-то именно в том, заходит ли крупным компаниям Скрам. Заходит, но оргструктуру и образ мышления надо менять.

Но и для крупных тоже, а вопрос-то именно в том, заходит ли крупным компаниям Скрам. Заходит, но оргструктуру и образ мышления надо менять.

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

Северсталь например ведет разработку по скраму :)

И какие у них цели спринтов?

Внести то или иное улучшение в продукцию на основе полученного фидбека )

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

вроде от этого LeSS помогает ;)

вроде от этого LeSS помогает ;)

Ну как помогает, скалирование всегда челендж и похоже серебрянной пули там нет. Там есть underlying problem, которую я обозначил в верху и она никуда не девается.

да, пулями не сложилось)

Увадаемые, Agile коучи, scrum mastera, участники dev команд, kabanero, проддект менеджеры (использующие в работе pmbok, prince2) с наступающим новым годом, пусть в следующем году наших разногласий будет меньше. Ведь "люди и взаимодействие превыше процессов и инструментов, работающий продукт превыше исчерпывающей документации, взаимодействие с заказчиком превыше условий контракта, готовность к изменениям превыше плана.

Сейчас самое время временно поставить новый постулат: праздник превыше работы :) всех С НОВЫМ ГОДОМ! 👍

Всех с праздником!

🌶🌶🌶🌶🌶🌶

Ребята, поздравляю вас с праздником! Профессиональных и личных успехов! 🎉🎉🎉

🎉❄️ ура

Друзья с новым годом!!

Урааа!!!))

Уррррааааа! С Новым годом!!!

С новым годом

С новым годом! Ура!

Уже 364 новых дней для улучшений! Не теряем время зря.

Уже 364 новых дней для улучшений! Не теряем время зря.

Иван эффективней считать в часах

Я составил пока глобальные улучшения, исчисляемые в Спринтах

Я составил пока глобальные улучшения, исчисляемые в Спринтах

эх, фишка спринта в том что он заполняется по мере необходимости, закладывать спринты иммутабельные или наоборот которые еще по 100 раз изменятся... Какой смысл?

Это самая мощная критика Agile/Scrum, которую мне приходилось читать: https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?srid=2DC7

Это самая мощная критика Agile/Scrum, которую мне приходилось читать: https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?srid=2DC7

Денис, но разве это критика? Это всего лишь адаптация принципов к проектам, имеющим большую сложность под капотом. Я бы назвал данную статью уточнением нежели критикой тем более что сам автор пишет "the high level Agile Manifesto is flexible enough to work with these principles". Поэтому говорить о критике неуместно. Agile он ведь потому и agile что способен адаптироваться. Почему бы не адаптировать собственные принципы, когда открывается их слабость в определенных условиях?

это точно, скорее уточнения, что им не подошли некоторые мифы об Agile)

О каких мифах речь?

Денис, но разве это критика? Это всего лишь адаптация принципов к проектам, имеющим большую сложность под капотом. Я бы назвал данную статью уточнением нежели критикой тем более что сам автор пишет "the high level Agile Manifesto is flexible enough to work with these principles". Поэтому говорить о критике неуместно. Agile он ведь потому и agile что способен адаптироваться. Почему бы не адаптировать собственные принципы, когда открывается их слабость в определенных условиях?

Да, там критика непосредственно Scrum. Ведь scrum продаётся как фреймворк для сложных проектов. Но там валидный поинт - действительно технически сложный проект требует R&D, который выходит далеко за рамки двухнедельных спринтов.

Да, там критика непосредственно Scrum. Ведь scrum продаётся как фреймворк для сложных проектов. Но там валидный поинт - действительно технически сложный проект требует R&D, который выходит далеко за рамки двухнедельных спринтов.

Почему-то не воспринимаю статью как критику. У каждой теории есть рамки ее актуальности. Ну ок, подкорректировали рамки.

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

Почему-то не воспринимаю статью как критику. У каждой теории есть рамки ее актуальности. Ну ок, подкорректировали рамки.

Я бы сказал, что это критика скрам-пропаганды, которая утверждает что это фреймворк для сложных проектов. В моем понимании скрам это отличный фреймворк для не очень то сложных проектов, где а) пользователи знают что им нужно б) PO знает что нужно пользователям в) Нет технический челенджей требующих фундаментальной работы. Нарушение любого из этих пунктов требует большой подготовительной работы. Хотя как только она выполнена, стадия непосредственно Деливери может быть выполнена по скраму.

Я бы сказал, что это критика скрам-пропаганды, которая утверждает что это фреймворк для сложных проектов. В моем понимании скрам это отличный фреймворк для не очень то сложных проектов, где а) пользователи знают что им нужно б) PO знает что нужно пользователям в) Нет технический челенджей требующих фундаментальной работы. Нарушение любого из этих пунктов требует большой подготовительной работы. Хотя как только она выполнена, стадия непосредственно Деливери может быть выполнена по скраму.

Плюсую. Хотя пункт А несколько спорный. Разве в манифесте scrum написано, что бэклог составляется из пожеланий заинтересованных сторон? Они в любом случае проходят интерпретацию PO, в том числе и согласно первому принципу из списка принципов в конце статьи - "Don’t give the customer what they ask for; understand them, and revolutionize their world.". А так я согласен.

Товарищи, добрый день! Может ли кто-то подсказать небольшую команду, работающую по принципам SCRUM в сфере веб программирования и верстки?

Это самая мощная критика Agile/Scrum, которую мне приходилось читать: https://www.quora.com/Why-do-some-developers-at-strong-companies-like-Google-consider-Agile-development-to-be-nonsense/answer/David-Jeske?srid=2DC7

Это адекватная статья про "целевые" и "обеспечивающие" системы: "Projects like Bigtable and Borg are the anti-scrum. They represent extremely long term thinking on the part of the technical leaders. Instead of working on something that would meet a small need this week, they were laying a foundation for a fundamental shift .... oftware which has a very simple interface and tons of hidden internal complexity, software which isn’t useful until it’s fairly complete, or leapfrog solutions the customer can’t imagine."" "Целевая система пассивна, и до стадии эксплуатации её буквально волокут за шкирку по жизненному циклу другие системы, которые называются обеспечивающими."

Это вполне запрос на постановку адекватного системноинженерного мышления.

Плюсую. Хотя пункт А несколько спорный. Разве в манифесте scrum написано, что бэклог составляется из пожеланий заинтересованных сторон? Они в любом случае проходят интерпретацию PO, в том числе и согласно первому принципу из списка принципов в конце статьи - "Don’t give the customer what they ask for; understand them, and revolutionize their world.". А так я согласен.

Нет, не написано. Но что можно успеть наинтрпретировпть за две недели? Это уже требует каких-то дизайн спринтов, создания прототипов, юзер ресеч, аналитики и тп. Рекомендую почитать про процесс Spotify.

Нет, не написано. Но что можно успеть наинтрпретировпть за две недели? Это уже требует каких-то дизайн спринтов, создания прототипов, юзер ресеч, аналитики и тп. Рекомендую почитать про процесс Spotify.

Но и основываясь на мнении клиента мы получим только более быстрых лошадей. А где почитать про процесс Spotify?

Книберга смотрел про Spotify, а вот читать - не читал.

Я бы сказал, что это критика скрам-пропаганды, которая утверждает что это фреймворк для сложных проектов. В моем понимании скрам это отличный фреймворк для не очень то сложных проектов, где а) пользователи знают что им нужно б) PO знает что нужно пользователям в) Нет технический челенджей требующих фундаментальной работы. Нарушение любого из этих пунктов требует большой подготовительной работы. Хотя как только она выполнена, стадия непосредственно Деливери может быть выполнена по скраму.

Хорошо, что скрам и "скрам в вашем понимании" это разные вещи

Хорошо, что скрам и "скрам в вашем понимании" это разные вещи

Успокаивайте себя :)

Но и основываясь на мнении клиента мы получим только более быстрых лошадей. А где почитать про процесс Spotify?

https://blog.crisp.se/wp-content/uploads/2013/01/HowSpotifyBuildsProducts.pdf

В целом просматриваются достаточно "водопадные" свойства - проектный подход, наличие четких стадий, написание проектной документации (Narrative, Product definition). Но скрам вполне себе живет в стадии Build It, да.

В целом просматриваются достаточно "водопадные" свойства - проектный подход, наличие четких стадий, написание проектной документации (Narrative, Product definition). Но скрам вполне себе живет в стадии Build It, да.

Что вы скажете о "Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. " ?? Это "водопадные" свойства?

Что вы скажете о "Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. " ?? Это "водопадные" свойства?

Я думаю Денис, говоря о водопадных свойствах, имел ввиду описание процесса Spotify.

Я думаю Денис, говоря о водопадных свойствах, имел ввиду описание процесса Spotify.

Я об этом же: Там прямо по тексту: "The product definition is not a requirements document or a project plan. It does not contain lists of features, budgets, resources plans, and such. It is more like a data-driven purpose statement."

Что вы скажете о "Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. " ?? Это "водопадные" свойства?

Насколько я понимаю их процесс на основе общения с гуглерами (у нас в компании работают несколько разработчиков упомянутого в статьей Borg), этот документ - необходимый минимум, дальше каждая команда имеет свободу выбирать процесс для каждого проекта. В случае проектов уровня Borg - там куча документации включая ресеч алгоритмов с написанием reasearch papers.

Насколько я понимаю их процесс на основе общения с гуглерами (у нас в компании работают несколько разработчиков упомянутого в статьей Borg), этот документ - необходимый минимум, дальше каждая команда имеет свободу выбирать процесс для каждого проекта. В случае проектов уровня Borg - там куча документации включая ресеч алгоритмов с написанием reasearch papers.

Да, согласен. Я говорю лишь о том, что "reasearch papers" помогают вывести на поверхность "ощущения исследователей относительно ландшафта исследования и целевых систем"

Ivan Ferraz: Fala galera. Sou do grupo Descomplicando Agilidade e gostaria de fazer um convite. Venha participar do Grupo Descomplicando Agilidade, temos várias pessoas engajadas na causa e muita troca de experiência. Hoje no Descomplicando já somos + de 500 . Descomplicando fez seu primeiro evento na Nextel. Janeiro teremos ou na Lambda 3. O grupo é no telegram https://t.me/descomplicado_scrum_Br