Использование платы Kanban для разработчика

Question

Я пытался заставить наш отдел программного обеспечения принять какой-то метод развития процесса. У нас только 9 разработчиков и примерно столько же проектов. В настоящее время нас можно назвать хаотичным. Или, возможно, «кризисное развитие», как я заметил, другой пользователь SO вызвал его.

Использование Kanban похоже на то, что это может пригодиться нам. Поэтому я обсуждал это со всеми остальными, все думали, что это звучит неплохо. Но когда мы обсуждали вопрос о том, как следует настраивать совет (ы), все хотели сделать одну доску на человека.

Теперь я никогда не пробовал Канбан или какую-либо методологию на самом деле, но похоже, что каждый человек, управляемый на своей собственной доске, отрицает преимущества, которые должен обеспечить процесс Канбана. Это понятие меня огорчает, и я хочу сказать: «Хо-гу, давайте отбросим всю эту идею».

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

Answer 1

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

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

Answer 2

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

Subnote

Если вы используете Microsoft TFS, то вы можете использовать использовать Telerik Work Item Manager. Я использовал это сам, и это здорово. Каждый разработчик запускает копию инструмента на своем ПК, и они могут просматривать свои рабочие элементы на визуальной панели задач (с цветным пост-это). Эта доска может группироваться и фильтроваться различными способами, поэтому разработчик может видеть все свои собственные задачи, но затем они могут изменять фильтр для просмотра всех задач проекта.

(Если вы не используете TFS, извиняться за неинтересного subnote :)

Answer 3

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

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

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

Answer 4

Возможно, было бы целесообразно провести еще одну дискуссию с вашей группой. Прежде чем принимать какую-либо новую технику/практику/методологию, нужно быть откровенно открытым, почему вы хотите ее принять и какую проблему вы пытаетесь решить. Мне почти кажется, что вы наткнулись на Kanban Boards и хотите принять его, не зная, какие проблемы вы пытаетесь решить.

Я бы посоветовал попытаться сделать еще несколько размышлений или анализа проблем, которые вы видите в своей среде, сделать некоторые из анализа причинно-следственных связей, если вы можете (что-то вроде 5-whys), а затем попытаться найти какую-то практику, которая поможет вам решить эти проблемы.

Тот факт, что люди в вашей группе предлагали использовать плату за разработчика, подразумевает, что a. они не понимают, какие проблемы у них есть, и что вы пытаетесь решить, и б. они не понимают, что пытаются сделать доски Канбана. I.e, ваши проблемы таковы, что использование платформ Kanban не решит их.

Answer 5

Неплохо иметь плату за разработчика. Доска предназначена для визуализации работы. Если разработчики работают над разными проектами, тогда было бы легче визуализировать работу по проекту с отдельными платами (как правило, это так). Если ваши разработчики работают над отдельными проектами, они работают над отдельными проектами. Технически, они не совсем одна команда, а больше «практика». С этой точки зрения было бы более естественным подходом к тому, чтобы они работали над отдельными платами.

Когда я самостоятельно работаю над собственными проектами, я по-прежнему пользуюсь коробкой Heijunka - какие разработчики программного обеспечения на западе часто (ошибочно) называют «Kanban Board» - и я делаю это для визуализации работы, планирования работы и помогите ограничить количество вещей, над которыми я сейчас работаю.

Answer 6

Я реализовал Kanban для своей команды, которая выполняет автоматизацию операций (более или менее половина работы Ops и половина работы Dev). Вот что мы нашли лучше всего для нашей команды. У нас есть общая колонка для INBOX/Backlog .. Затем колонка «в разработке» разбита на 5 разделов, по одному на разработчика, с лимитом WIP для каждого разработчика. Затем еще один общий столбец «для интеграции» и, наконец, общий столбец «выпуск в производство».

Преимущество Kanban в том, что предел WIP гарантирует, что разработчики могут сосредоточиться на том, что они делают - в нашем случае каждый разработчик достаточно автономен в работе над своим проектом, но у нас есть общие столбцы для INBOX, где разработчик может тянуть любая новая задача, а также «интеграция»/«производство», в которой лидер команды участвует в принятии изменений через оставшиеся шаги.

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

Answer 7

Две самые важные причины для применения Kanban к процессу - это визуализировать этот процесс и ограничить незавершенное производство (WIP).

Если у вас есть одна доска для каждого разработчика, это скорее персональный механизм канбан, и вы можете визуализировать и ограничивать WIP для одного человека за раз, но нет обзора на уровне команды.

Если у вас есть одна доска для каждого проекта или команды, это зависит от того, существуют ли общие ресурсы, то есть люди, работающие над несколькими проектами или командой. Если это так, вы потеряете некоторый обзор и некоторые преимущества ограничения WIP, если у вас есть люди, работающие над вещами, показанными на нескольких досках. F.ex. узкие места сложнее увидеть.

Answer 8

Действительно, создайте как минимум 2 или 3 команды, затрагивая только один проект для каждого из них и, таким образом, один совет по проекту. Затем еще один совет для управления статусом проектов.

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