Использование доски Kanban для каждого разработчика
Я пытался заставить наш отдел программного обеспечения принять какую-то методологию процесса разработки. У нас всего 9 разработчиков, и примерно столько же проектов. В настоящее время нас можно назвать только хаотичными. Или, возможно, "кризис-ориентированная разработка", как я видел, как другой пользователь SO называл это.
Использование Kanban кажется нам подходящим. Я обсуждал это со всеми, все думали, что это звучит хорошо. Но когда мы обсуждали, как должны быть организованы доски, каждый хотел сделать одну доску на человека.
Так вот, я никогда не пробовал Kanban или какую-либо другую методологию на самом деле, но такое ощущение, что управление каждым человеком на собственной доске сводит на нет преимущества, которые должен обеспечить процесс Kanban. Это понятие меня огорчает, и я хочу сказать: "Хо-хам, давай отбросим всю эту идею".
Считаете ли вы целесообразным внедрение платы Kanban для каждого разработчика?
8 ответов
Если у вас должно быть множество плат, не лучше ли иметь доску для проекта, а не доску для разработчика? Может быть, со временем появятся какие-то естественные группировки проектов (и, следовательно, объединение советов), а может и нет.
Одно из назначений плат - служить "информационными излучателями". Большое количество проектных досок, прогрессирующих со скоростью улитки, передает сообщение "мы серьезно перегружены" и / или "кто-то должен установить какие-то приоритеты". Большое количество советов для разработчиков просто излучает сообщение "мы не делаем здесь командную работу".
Я внедрил Kanban для своей команды, которая занимается автоматизацией операций (более или менее половина работы Ops и половина разработки Dev). Вот что мы нашли лучше всего подходит для нашей команды. У нас есть общий столбец для INBOX/Backlog. Затем столбец "в разработке" разбит на 5 разделов, по одному на разработчика, с пределом WIP для каждого разработчика. Затем еще один общий столбец для "интеграции" и, наконец, общий столбец для "выпуска в производство".
Преимущество Kanban в том, что ограничение WIP позволяет разработчикам сосредоточиться на том, что они делают - в нашем случае каждый разработчик достаточно автономен в работе над своим проектом, но у нас есть общие столбцы для INBOX, где разработчик может выполнить любую новую задачу, и для "интеграции" / "производства", когда руководитель группы участвует в обеспечении изменений посредством оставшихся этапов.
Поэтому я рекомендую иметь несколько общих столбцов (возможно, ваше отставание и ваш выпуск) и иметь несколько столбцов для каждого разработчика (например, "в разработке"). Таким образом, каждый разработчик может управлять тем, над чем он работает, и в то же время плата может помочь визуализировать состояние всей работы, проходящей через конвейер.
Двумя наиболее важными причинами применения Kanban к процессу является визуализация этого процесса и ограничение работы в процессе (WIP).
Если у вас по одной плате на разработчика, это скорее личный механизм канбана, и вы можете визуализировать и ограничивать WIP для одного человека за раз, но без обзора на уровне команды.
Если у вас есть одно правление на проект или команду, это зависит от того, есть ли общие ресурсы, то есть люди, работающие над несколькими проектами или командой. Если это так, вы теряете некоторый обзор и некоторые преимущества от ограничения WIP, если у вас есть люди, работающие над вещами, показанными на нескольких досках. F.ex. узкие места труднее увидеть.
Kanban на самом деле является системой ограничения потока через систему, поэтому у нас есть ограничения WIP (Work In Progress) на досках канбан, и как человек может выполнять только одну работу одновременно, я не думаю, что это может сработать.
Наличие одной доски на разработчика действительно не дает никаких преимуществ (и я бы сказал, что это не совсем канбан). Одна доска на проект - лучшая идея.
Затем, если другой разработчик присоединится к некоторым задачам, вы все равно сможете увидеть общий ход проекта.
Я думаю, что было бы целесообразно провести еще одну дискуссию с вашей группой. Перед тем, как принять какую-либо новую технику / практику / методологию, нужно очень внимательно посмотреть, почему вы хотите ее принять и какую проблему вы пытаетесь решить. Для меня почти звучит, что вы наткнулись на доски Kanban и хотите принять его, не зная, какие проблемы вы пытаетесь решить.
Я бы посоветовал попытаться еще немного подумать или проанализировать проблемы, с которыми вы сталкиваетесь в вашей среде, по возможности провести анализ первопричин (что-то вроде 5-whys), а затем попытаться найти какую-то практику, которая поможет вам решить эти проблемы.
Сам факт того, что люди в вашей группе предложили использовать плату за разработчика, подразумевает для меня, что они не понимают, какие у них проблемы, и что вы пытаетесь решить, и б. они не понимают, чего пытаются достичь канбан-борды. То есть ваши проблемы таковы, что использование досок Kanban не решит их.
Нет ничего плохого в том, чтобы у каждого разработчика была доска. Доска для визуализации работы. Если разработчики работают над разными проектами, то было бы проще визуализировать работу с конкретным проектом с помощью отдельных плат (что обычно и происходит). Если ваши разработчики работают над отдельными проектами, то они работают над отдельными проектами. Технически, они на самом деле не единая команда, а скорее "практика". С этой точки зрения, было бы более естественным подходом к тому, чтобы они работали отдельными советами.
Когда я работаю над личными проектами самостоятельно, я по-прежнему использую Heijunka Box - то, что разработчики программного обеспечения на западе часто (по ошибке) называют "Kanban Board", - и я делаю это для визуализации работы, планирования работы и для ограничения количества вещей, над которыми я работаю сразу.
Мне кажется, что может быть лучше использовать одну доску Kanban со всеми задачами разработчика, а не одну доску на разработчика. Причина, по-моему, заключается в том, что идея в том, что Kanban является визуальным инструментом для всех членов команды, и если у каждого разработчика есть своя доска, то я думаю, что он немного упускает эту идею.
Subnote
Если вы используете Microsoft TFS, то вы можете использовать Telerik Work Item Manager. Я использовал это сам, и это здорово. Каждый разработчик запускает копию инструмента на своем ПК, и они могут просматривать свои рабочие элементы на визуальной доске задач (с цветом post-it). Эта доска может группироваться и фильтроваться различными способами, поэтому разработчик может видеть все свои задачи, но затем он может изменить фильтр, чтобы просмотреть все задачи в проекте.
(Если вы не используете TFS, приносим извинения за неинтересную сноску:)
Действительно, создайте как минимум 2 или 3 команды, воздействуйте только на один проект для каждой из них и, таким образом, на одну доску за проектом. Затем еще одна доска для управления статусами проектов.
Для резюме: один за проектом с каждой задачей, один для отслеживания статуса проекта, это поможет разработчикам, а также вам общаться с менеджерами.