Кто-нибудь использует канбан? [закрытый]

Использует ли кто-нибудь Kanban (или scrumban) для гибких методов управления? Каков ваш опыт общения с Канбаном? Как это работает в больших сложных средах с зависимостями от водопадных проектов?

3 8
agile methodology

3 ответа:

Я знаю, что Би-би-си использует его довольно широко. Смотрите блог Дэвида Джойса для получения более подробной информации http://leanandkanban.wordpress.com/

У него там довольно здоровенная скользящая колода, чтобы просеять ее.

Я думаю, что следует помнить о бережливом мышлении, что вы должны рассматривать поток создания ценности в целом. В то время как вы можете супер оптимизировать команду разработчиков, используя такие методы, как канбан, более важно включить как восходящий поток (управление / анализ), так и нисходящий (QA / развертывание / поддержка), чтобы полностью пожинать плоды. Поэтому спрашивать, как это вписывается в водопад или сложный процесс (помимо вашего личного эффекта), не совсем правильный вопрос. Более важный вопрос заключается в том, как я могу начать воздействовать на весь поток создания ценности. Я знаю, что это звучит как начало религиозного бережливого фанатизма, но именно так вы поймете истинную ценность бережливого процесса.

Например, рассмотрим следующий сценарий для типичного проект:

  • Время анализа: 18 месяцев
  • Время разработки: 9 месяцев
  • QA & release time: 4 месяца
  • принятие и доработка заказчиком: 12 месяцев

Итого: 43 месяца

Если путем применения бережливого подхода к процессу разработки вы улучшаете на 100%, то есть время разработки составляет 4,5 месяца, принося новый итог в 38,5 месяцев. Таким образом, вы только увеличили общий поток создания ценности чуть более чем на 10%... ничтожество!!

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

Помните, что бережливое производство-это не процесс разработки, его можно применять к любому аспекту бизнеса.

Некоторые интересные книги о том, как вывести эту дискуссию за рамки команды разработчиков включают;

9

Во-первых, важно осознать проблемы, которые пытается решить Канбан в разработке программного обеспечения:

  • Многозадачность / перегрузка работой . Канбан обращается к ним по своему Системы Just-in-time и Queue. Там достаточно в очереди держать все заняты, но не перегружены (это приходит с практикой с оценка и эффективная скорость мониторинг). И Джит гарантирует, что люди не должны быть многозадачными и отсюда и низкая производительность труда.
  • непредсказуемо попуски. Если вы работаете в крупной программной организации, то разрабатываемый вами фрагмент может быть просто одним из большого количества программных продуктов. Следовательно, могут существовать команды, работающие ниже по потоку, которые могут ждать вашей функции. Система очередей канбана вместе с ее расписанными по времени графиками доставки гарантируют, что есть определенная степень предсказуемости в релизах.

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

Большие сложные среды с зависимостями от водопадных проектов

Это затрудняет работу, если у вас есть зависимость от проекта, который не следует agile, так как тогда ваша входная очередь не будет предсказуемой. Если проект, не являющийся гибким, зависит от вас, проблема может быть меньше, но вы можете в конечном итоге произвести больше, чем можно потребить ("muda" в бережливой терминологии). Таким образом, в идеале вы хотели бы, чтобы все зависимые проекты, по крайней мере, следовали некоторым гибким практикам, если не канбану сам.

Хорошую статью о канбане, потоке и каденции можно найтиздесь .

5

Использует ли кто-нибудь Kanban (или scrumban) для гибких методов управления?

Да, я использую : -)

Как это работает в больших сложных средах с зависимостями от водопадных проектов?

В нашей среде у нас есть >500 разработчиков, так что это довольно много. Моя команда была первой, которая использовала Канбан, в основном для ремонтных работ, а теперь и для разработки. Наша ежедневная работа была очень тяжелой, потому что другие зависимые команды следовали классике развитие и методы управления, и они любили (они до сих пор делают) толкать работу и канбан отянуть .

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

Наша пропускная способность до Канбана составляла 90% (другими словами, Когда 10 приходили товары, мы доставляли только 9), а после Канбана у нас было 100,4% и это увеличивалось. В качестве дополнительного результата, другие команды начали приходить и спрашивать о канбане, потому что им понравились наши результаты, и они хотели внедрить свою собственную систему Канбана. На данный момент я знаю около 5 команд, которые начинали Канбан в нашей организации.

HTH,

Жолт

2