"Канбан – это метод, который направлен на улучшение процесса, базируется на ценностях Lean и бережливого мышления" Постигая Agile Дженнифер Грин

"Канбан – это метод, который направлен на улучшение процесса, базируется на ценностях Lean и бережливого мышления" Постигая Agile Дженнифер Грин

Холивар в духе с какой стороны яйцо колоть? А вы сошлись в понятии фреймворк или все одно и тоже думают?

Телекомщик стало быть?

Я хотел узнать почему решили отказаться от Scrum

Да, кровавый энтерпрайз

Интересно было бы от Вас узнать на сколько зрелый у вас зонтик и вообще обстановку в BSS стеке продуктов. Я из Netcracker, хантеры тянут к вам.

Запросто, но лучше в личку :)

Как такой вариант, команд стало больше 3х

Хм интересно, т.е. продукт остался прежний команда увеличивается

Типа того. Решили, что пора продукт снова развивать

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

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

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

А что работает?

Ваши аргументы, что это не фреймворк?

А когда была одна скрам команда продукт не развивался?

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

автор канбан метода – достаточный эксперт в нем, как мне кажется)

Нет. Только точечные изменения под законадательство.

SCRUM, канбан, производственная система Тойоты, производственная система Форда, производственная система Хитачи это прикладные решения теории ограничений для разных ситуаций.

Могу ошибаться, но кажется прикладных решений теории ограничений для сложного проекта по разработки ПО просто нет. Но, может, я ошибаюсь.

Вот про теорию ограничений вы очень зря. Производственная система Тойоты может быть дополднена теорией гораничений, но не является ее версией :)

Есть, CCPM.

А какую ценность команда несла в конце каждого спринта? Как команда получала обратную связь о инкрименте?

Это не я сказал, а Голдратт и я с ним согласен: http://ashrm.ru/upload/file/standing_on_the_shoulders_of_gigantes%281%29.pdf (и обсуждение: https://cartmendum.livejournal.com/91723.html)

В эту сторону я лет девять смотрел. В чистом виде не слишком подходит. Нужна адаптация и специфические инженерные и управленческие техники. Главное - управленческие.

А я не согласен, но обуждать можно сколько угодно :) Lean Production (он же Toyota Production System) сильно шире теории ограничений. Да, они отлично дополняют друг друга и практически все инструменты TOC можно применять в рамках TPS или других имплементаций Lean, но это не деает TPS имплементацией TOС

Если мне не изменяет память, Lean - изобретение американцев. Тойотовцы от него отпинываются руками и ногами. Сами придумали, сами и кушайте. TPS использует очень много интереснейших прикладных техник. И тем не менее это один из вариантов теории ограничений.

И с учетом взаимопроникновения инструментов и техник, можно точно так же говорить, что TOC это вариант воплощения TPS :)

В основном исправленные дефекты. Иногда немного доработок. Второй вопрос не понял.

Обратная связь это же основа адаптации, для которой скрам и существует. Не понятно, как при наличии адаптации (без которой скрам скрамом нельзя назвать) продукт не развивался. Это действительно очень странно. Вероятно потерялось смысловое наполнение скрама.

А понял. Ресурсов нет. Есть очень много дефектов в бэкллге, делать их надо. Там сла. Просто ни на что другое не хватает времени

Тогда не понимаю причем тут канбан-скрам ) Дефектов меньше не станет, времени больше не станет )

Но команд то стало три уже. И пошло развитие. Соответсено надо дефекты исправлять и новые фичи делать. А над фичей работает зачастую не одна команда. Отсюда и переход

А есть шанс, что через некоторое время дефектов станет меньше?

В масштабировании я ничерта не понимаю. Но полагаю можно масштабировать и скрам и канбан. Здесь много обсуждали масштабирование скрама. Короче, я полагал, что вопрос масштабирования перпендикулярен скраму-канбану. Одну фичу могут делать несколько команд в том смысле что у вас функциональные команды? Ожни пилят бэк, другие - фронт(просто пример)?

Да именно так, фронт, бэк. Канбан масштабируется легко, скрам, ну, наверно, успешного не видел

Продукт перешел из complex/complicated в simple

Да именно так, фронт, бэк. Канбан масштабируется легко, скрам, ну, наверно, успешного не видел

Спасибо за ответы. Сколько я видел коллективов и продуктов, где копятся проблемы, везде была одна исходная проблема - забили на обоснованность фич, коммуникации и внутреннее качество. Потом чтобы хоть как-то справляться приходилось дико раздувать штат. В два раза, бывало в три раза, полагаю в одном месте я даже видел штат раздутый в 4 раза. Потому что изначально взяли в оборот "прагматичные" установки. Прагматичные в том плане, что "главное результат", причем, краткосрочный. Т.е. полное отсутствие стратегического видения и понимания необходимости тенденции к улучшению. Чем больше люди концентрировались на тактических интересах, тем больше теряли в стратегичесих. Чем больше теряли в стратегических тем меньше было свободного времени и сил, тем меньше возможностей было удовлетворить хотя бы тактические интересы. В общем, положенные в основу установки, не учитывающие стратегические интересы, всегда приводили к падению через 2-5 лет. Говорю только про свой опыт.

Я бы перевел на более формальный язык: Обилие фич находится в равновесии по Парето с такой группой атрибутов качества, как модифицируемость (ГОСТ 25010). Ситуация описана в "Цель-3". Просто один в один. Настоящей же проблемой является то, что практически все команды в начале разработки забивают на все атрибуты качества, кроме объема фич. И SCRUM приводит к феерическим результатам. Не, сначала все хорошо. Зато потом... Справедливости ради добавим, что чем больше фич, тем хуже юзабилити. Тоже самое равновесие по Парето. Ситуация описана в "Психбольница в руках пациентов."

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

Не. Я здесь на стороне лидера по созданию аджайл манифеста и одновременно создателя линейки аджайл методологий. Он говорит: "Каждому проекту свою методологию". Он прав. Есть условно три сотни инженерных и с сотню управленческих практик. Смотрим на команду, смотрим на проект, собираем пазл. Все.

Я ж не спорю. Но и связи между феерическими последствиями и скрамом пока не вижу.

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

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

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

Спасибо! Собственно я с вами и не спорю, я это уже писал раньше. Напомню контекст. Я выяснил немного обстоятельств работы @SeaGullLingvinston, понял, что есть проблемы в понимании скрама. Собственно, не была реализована адаптация. И теперь предполагаю, что переход на канбан не решит проблем, а просто проблемы перестанут зудеть. К примеру, очень удобно переходить на канбан, если не удается завершить спринты вовремя. Или очень удобно переходить на канбан, если пожар и скоуп спринта удержать неизменным не получается. Про молотки, рубанки и гвозди - очень все очевидно. Про это и говорить особого смысла нет. Я, чаще всего, нахожусь в контексте стартапа или, как минимум, разработки нового продукта. Для меня скрам очень хорош.