Канбан в IT (Kanban Development)

Я сегодня обещал написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) и вот публикую первую из них.
Основная задача первой статьи - это описать основы Канбан, что это такое и зачем нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.


Для начала напишу про происхождение термина Канбан.


Этот термин пришёл к нам из Японии благодаря широко известной в узких кругах производственной системе Тойота. Хотелось бы, чтобы как можно больше людей прочитало про эту систему и основные принципы, заложенные в неё - бережливое производство, постоянное развитие, ориентацию на клиента и т.п. Все эти принципы описаны в книге Тайити Оно Производственная система Тойоты, которая переведена на русский.


Термин Канбан имеет дословный перевод: “Кан” значит видимый, визуальный, и “бан” значит карточка или доска.
На заводах Тойота карточки Канбан используются повсеместно для того, чтобы не загромождать склады и рабочие места заранее созданными запчастями. Например, представьте, что вы ставите двери на Тойоты Короллы. У вас около рабочего места находится пачка из 10 дверей. Вы их ставите одну за другой на новые машины и, когда в пачке остается 5 дверей, то вы знаете, что пора заказать новые двери. Вы берете карточку Канбан, пишете на ней заказ на 10 дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к тому моменту, как у вас закончатся оставшиеся 5 дверей. И именно так и происходит - когда вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так постоянно - вы заказываете новые двери только тогда, когда они вам нужны.
А теперь представьте, что такая система действует на всём заводе. Нигде нет складов, где запчасти лежат неделями и месяцами. Все работают только по запросу и производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало больше или меньше - система сама легко подстраивается под изменения.


Основная задача карт Канбан в этой системе - это уменьшать количество “выполняющейся в данный момент работы” (work in progress).

Например, на всю производственную линию может быть выделено ровно 10 карточек для дверей. Это значит, что в каждый момент времени на линии не будет больше 10 готовых дверей. Когда заказывать новые двери и сколько - это задача для того, кто их устанавливает. Только он знает свои потребности, и только он может помещать заказы производителю дверей, но он всегда ограничен числом 10.
Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойоте и сейчас многие производственные компании по всему миру его внедряют или уже внедрили.


Но это всё относится к производству, а не к разработке программного обеспечения.
А что же такое Канбан разработка применительно к ПО, и чем она отличается от других гибких методологий, буть то SCRUM или XP?


Во-первых, нужно сразу понять, что Канбан - это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Во-вторых, весь Канбан можно описать одной простой фразой - “Уменьшение выполняющейся в данный момент работы (work in progress)”.
В-третьих, Канбан - это даже еще более “гибкая” методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.


Разница между Канбан и SCRUM:
- В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
- В Канбан задачи больше и их меньше
- В Канбан оценки сроков на задачу опциональные или вообще их нет
- В Канбан “скорость работы команды” отсутствует и считается только среднее время на полную реализацию задачи


А теперь посмотрите на этот список и задумайтесь - что остается от гибкой методологии, если мы удаляем спринты, увеличиваем размеры задач и перестаем мерять скорость работы команды? Ничего?
Как вообще можно говорить о контроле за разработкой, если мы убираем основные инструменты контроля - сроки, скорость работы и спринты? Для меня этот вопрос является чуть ли не самым важным.
менеджеры всегда думают о контроле и пытаются его получить, хотя на самом деле никогда его не имеют. Контроль разработки со стороны менеджера - это фикция. Если команда не хочет работать, то как ее не контролируй, она провалит проект.
Если команда получает фан от работы и работает с полной отдачей, то никакой контроль и не нужен, а только мешает, увеличивает издержки.
Например, общеизвестная проблема SCRUM - это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт - 2 недели, то 2 дня из 2 недель - это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса - на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!


Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды - это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.
Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы - тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале.
Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера - это создать приоритизированный пул задач, а задача команды - выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера - это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.


Команда для работы использует Канбан-доску. Например, она может выглядеть так (взял тут):

Столбцы слева направо:


Цели проекта:
Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, “Увеличить скорость работы на 20%” или “Добавить поддержку Windows 7″.


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


Проработка дизайна:
этот и остальные столбцы до “Закончено” могут меняться, т.к. именно команда решает, какие шаги проходит задача до состояния “Закончено”.
Например, в этом столбце могут находиться задачи, для которых дизайн кода или интерфейса еще не ясен и обсуждается. Когда обсуждения закончены, задача передвигается в следующий столбец.


Разработка:
Тут задача висит до тех пор, пока разработка фичи не завершена. После завершения она передвигается в следующий столбец.
Или, если архитектура не верна или не точна - задачу можно вернуть в предыдущий столбец.


Тестирование:
В этом столбце задача находится, пока она тестируется. Если найдены ошибки - возвращается в Разработку. Если нет - передвигается дальше.


Деплоймент:
У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то - просто закомитить код в репозиторий.


Закончено:
Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью.


В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как “Expedite”). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна - она должна быть добавлена в “Очередь задач”.


А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Например, если вы имеете 8 программистов в команде, то в строку “Разработка” вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, а значит у них будет много причин для общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача Канбан - это уменьшение времени прохождения задачи от начала до стадии готовности.
Никто не даст точный ответ, какие должны быть эти лимиты, но попробуйте для начала разделить число разработчиков на 2 и посмотреть, как это работает в вашей команде. Потом эти числа можно подогнать под вашу команду.
Под “разработчиками” я понимаю не только программистов, но и других специалистов. Например, для столбца “Тестирование” разработчики - это тестеры, т.к. тестирование - это их обязаность.


Задачи на такой доске - это не просто задачи, а то, что называется Минимальной Маркетинговой Фичей, то есть фича, которую можно “продать” клиентам.
Хорошая проверка для ММФ - это вопрос себе “А стал бы я писать про эту фичу в блоге компании?”. Если нет - это не ММФ.


Что нового и полезного дает такая доска с лимитами?


Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. - делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце “очередь задач”, а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться.


Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что “мы - команда” и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее.


В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.


Весь Канбан можно описать всего тремя основными правилами:
1. Визуализируйте производство
- Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.
- Используйте названные столбцы, чтобы показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.
3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.


Всего 3 правила!
Например, в SCRUM - 9 базовых правил. В XP - 13,а в классическом RUP - аж более 120. Почувствуйте разницу.


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


Дополнительные ссылки:


43 комментариев к Канбан в IT (Kanban Development)

  • И сразу вопрос :

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

    Разве в Канбан карточки могут возвращаться обратно ?

    • Просто тут как раз выплывает то что Канбан вышел из производственных предприятий - если карточка изделия не проходит ОТК (или в нашем случае тестирования) то она вероятнее всего забраковывается и заводится новая карточка которая проходит весь процесс.
      Если карточка откатывается, то это должно регулироваться какими то правилами. А это уже усложнение и отступление от Канбан.
      Или я в чем то не прав ?

      • Зачем нужны сложные правила внутри одной команды? Все сидят вместе и если есть ошибка - её автор мгновенно про это узнает и начинает исправлять. Двигать или нет при этом карточку - это не важно.
        Важно, что цель всей команды - двигать карточку как можно быстрее к “Закончено”, а регламентировать и усложнять перемещение - это лишнее.

      • Вообще-то в “Разработку”, действительно, карточку вернуть бывает обычно трудно — не даёт ограничение. Мы обычно возвращаем на этап “Готово к разработке”, откуда она дальше следует на общих основаниях в соответствии с приоритетом (если есть более важные фичи, то исправление выявленных дефектов может подождать).

    • Конечно, почему нет?
      Идея Канбан - это сокращение времени work in progress. Доска с задачами - это просто визуализация workflow задачи. Если команде удобнее возвращать таски - пусть возвращает. Если удобнее, чтобы таск оставался в “Тестируется”, пока он исправляется - пусть оставляет.
      Тут нет конкретных правил, команда решает.

  • Владимир

    А что значит горизонтальная линия, разделяющая колонки Elaboration/Development/Tes?

    • Да, забыл про это написать. Эта линия разделяет то, что сейчас в разработке в этой фазе - это сверху. И то, что уже сделано и должно быть перемещено в следующий шаг - это буфер, снизу.
      Буфер нужен, т.к. не всегда можно просто переместить задачу, ведь часто надо сначала поговорить и обсудить следующие действия (например, программист закончил задачу, но не может ее сам в тестирование переместить, т.к. надо рассказать, что тестировать - можно поместить ее в буфер и когда тестер освободится - поговорить и потом уже переместить).
      Либо же просто следующий столбец полностью занят - тогда задача идет в буфер.

      Но надо заметить, что общий лимит на задачи включает и буфер. Так что, если лимит - 4 и задач в буфере 2, то в прогрессе (выше линии) может быть только 2 задачи.

  • Лучшая статья за всё время существования блога. Спасибо!

    • +1 действительно отличная статья, лучшая с тех пор как подписался. Чуть было не грохнул фид в ридере на прошлой неделе, а тут такое.

      Спасибо.

    • Рад, что статья понравилась.
      А комментарии и вопросы будут? :)

      • Роман

        Олег, хотелось бы больше услышать о различных непредвиденных ситуациях. Например, каким образом меняются параметры пулов (лимиты задач и т.п.) при болезни или уходе сотрудника, работающего в определнном пуле (сам примерно вижу, но может есть какие то формулы :) ).
        Кроме того, было бы замечательно увидеть наметки success story использования Канбан в Вашем проекте.
        Хотелось бы также больше примеров ММФ и не-ММФ.
        Да и вообще больше примеров из жизни.

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

          Вот “примерно” и меняются :) Команда должна подобрать лимиты так, чтобы ей было удобно работать и задачи делались как можно быстрее. Для одной команды это будет значить выставить лимит в половину числа разработчиков, а для другой - в число разработчиков. Всё зависит от команды.
          Плюс я бы не стал жестко задавать эти числа и не давать их менять - это просто числа, которые должны помогать, а не ограничивать. Так что, если чувствуешь, что прибавив 1 можно сделать работу быстрее - прибавляй и пробуй.

          Кроме того, было бы замечательно увидеть наметки success story использования Канбан в Вашем проекте.

          Наш главный success story - это удовлетворенный product owner :) Мы делали техподдержку последние полгода и на работу в техподдержке скрам ложится очень плохо. Все эти строгие спринты и неготовность к изменениям делали product owner-a несчастным и задачи затягивались. С Канбан это все намного лучше - нет спринтов, задачи делаются быстрее, новые задачи берутся в работу спокойнее и быстрее. В общем, все довольны.

          Хотелось бы также больше примеров ММФ и не-ММФ.
          ММФ:
          - Добавить русскую локализацию в продукт
          - Сделать возможность задавать wildcards в путях и правилах конфигурации
          - Изменить внешний вид интерфейса под новые стандарты
          - Исправить баг номер 12345, важный для кастомера XYZ

          не ММФ:
          - Убрать кнопку “Назад” в окне номер 3
          - Добавить юнит тесты для класса FOO
          - Установить Win7 на тестовую машину

          В общем, как я и писал, ММФ - это то, о чем не стыдно было бы написать в корпоративном блоге.
          Я специально написал в “не ММФ” такие задачи для примера, которые для SCRUM вполне валидны. Грубо говоря, SCRUM оперирует задачами по 1-2 дня, а ММФ - это задачи на 1-2 недели.
          Хотя бывают ММФ, которые делаются за пару часов - время тут тоже неважно по сути. Важна только важность фичи :)

    • Роман

      Подерживаю. Статья действительно объясняет принци работы по Канбану в простой и понятной (наконец то) форме.

  • Очень интересно! Вопросы, конечно, есть - но ждем продолжения. Может было бы интересно рассмотреть конкретные ситуации, проблемы и т.д. Хотя бы парочку.

  • Алексей

    1 . Как контролировать?
    Допустим разработчик не справляется. Ну, т.е он делает что может, но может плохо. В отсутствии планирования и контроля выполнения непонятно задача требует столько времени, или стоит сменить разработчика, или пересмотреть задачу.

    2. Что делать если ММФ зависит больше чем от одной задачи?

    • 1. В Канбане, как и в других гибких методологиях, нет понятия “разработчик”. Есть понятие “команда”. Если внутри команды один из разрабов не тянет - это команда его должна выявить и удалить или научить. Если же команда в целом не тянет - это уже задача менеджера поменять команду или методологию.
      2. ММФ - это комплексная задача почти всегда. Часто бывает нужно взаимодействие с другими командами, чтобы выполнить задачу. Это можно отразить на доске отдельными шагами. Или не отражать. Идея в том, что ТЫ берешь ответственность за выполнение задачи, если она на твоей доске и ты начал ее делать. И неважно, что есть зависимости - твоя задача их все разрешить и как можно быстрее. Знаю, это звучит странно, но это работает :) Не на кого пенять и некого обвинять - задача висит на твоей доске. Даже если другие команды не помогают - делай сам.

      • Это Вы, уважаемый, перегнули :)
        Понятие “команда” навязывает Скрам, канбан в этом отношении более терпим, он вполне допускает выделение ролей.
        А контролировать очень просто — когда на какой-то части доски возникает “затор”, не хватает пропускной способности, тогда требуется вмешательство, нужно провести “ретроспективу”, выявить причины возникновения затора, устранить их и снова погрузиться в созерцание.
        В этом и есть главная прелесть канбана, которой лишён Скрам.

        • Да, в Канбане роли допустимы и даже выделены. Собственно шаги разработки задачи обычно и поделены по ролям. Но прелесть команды в том, что в случае затыков, роли уже не играют роли (о какой каламбур :)).
          Идея в том, что затыки решает целиком команда (например, ретроспективом, причем немедленным). Например, если тестеры все время в затыке, то программисты видят, что что-то не так и должны помочь тестерам. Например, создав автоматическое тестирование или начав тестировать лучше самостоятельно. В общем, это сильно командная работа, а не единоличная или работа “по ролям”.

        • Алексей

          Как может возникнуть затор в первом шаге? Если задачи добавляются с определенной скоростью, то вводятся жесткие сроки на их реализацию, если задачи добавляются по мере готовности, как декларируется, то и затора не будет. Да и потом, простеший для реализации функции могут потребовать значительного времени для тестирования и что делать разработчику, если у тестера затор? Вариант помогать тестеру это чушь, это разные специальности, во-первых; а во-вторых, за тестирование все равно отвечает тестер и полагаясь на такую “помощь” он только подставляет себя.

          • Вариант помогать тестеру это чушь, это разные специальности, во-первых; а во-вторых, за тестирование все равно отвечает тестер и полагаясь на такую “помощь” он только подставляет себя.

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

            И наоборот - тестеры могут помогать программисту в разработке, если возьмут на себя часть разработческих задач - документацию, общение с product owner-ами, выявление деталей, предварительное тестирование и т.п. А если тестеры опытные и умеют скриптовать, то они могут уже на этапе разработки параллельно разрабатывать скрипты для тестирования.
            Всякое бывает :)

            • Алексей

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

              • потому что навыки нужны совершенно разные. Работа тестера это поиск багов, если разработчик уже отдал программу тестеру он полагает, что там багов нет, чем он поможет тестеру? Если разработчик и сам не тестировал, то это случай еще более печальный.

                Не все так просто. Часто работа тестера - это проверка каких-то предположений, которые программист сам не имеет времени протестировать. Например, “будет ли это все работать на Win7 64 bit?”.
                Или “У нас есть продукт и 10 плагинов. Проверить, что все комбинации плагинов работают, поотключав их по-одному”. Куча работы на самом деле.
                Если программист берется за это - он быстро придет к тому, что это надо автоматизировать, т.к. это скучно и глупо и легко автоматизируется. И в итоге будет создан скрипт.
                То есть, получится, что программист и не тестирует, а опять же программирует, но при этом помогает улучшить процесс тестирования.

                P.S.:
                И это не надуманные случаи - так оно и происходит.

      • Алексей

        Как выявить, если нет ни сроков, ни других пунктов для проверки? Получается внутри одной методологии надо вводить еще одну для проверки тянет разработчик или не тянет…

        Звучит все это не столь странно, сколько неправдоподобно. Работает не аргумент, так можно сказать про любую методологию или даже ее отсутствие, если на выходе все же есть продукт. Да, продукт есть, но лучше ли он или хуже при использовании канбана, как проверить? Как в научных теориях должна быть фальсифицируемость, так и в методологии должен быть аналогичный признак. В канбане я такого признака не вижу, хоть год пиши, все равно успех, сроки то относительные.

        • Как выявить, если нет ни сроков, ни других пунктов для проверки? Получается внутри одной методологии надо вводить еще одну для проверки тянет разработчик или не тянет…

          На это я могу даже из своего собственного опыта ответить.
          У нас есть daily meetings. Это когда мы обсуждаем текущую работу и проблемы. И все члены команды участвуют. И все члены команды - не дураки и видят, если кто-то фичу на полдня делает неделю. Это просто видимо и не скрыть, если ты каждый день про это говоришь. И если такое отношение к работе продолжается месяц-два, то уже команда начинает волноваться и пытается “переделать” нерадивого работника.

          На практике у нас, например, это привело к увольнению одного сотрудника. Команда пыталась пару месяцев его “раскачать”, но он не тянул общий темп. После этого совместно было решено обратиться к менеджеру и менеджер уже решил что с таким сотрудником делать. То есть, эта система работает, я могу подтвердить это своим опытом :) Причем, увольнение (или перевод куда-то) одного положительно влияет на остальных - все работают лучше и видят, что никто не халявит :) Так что команда - это мощная сущность. Менеджеру вообще не надо париться о производительности отдельных личностей - если что ему о проблемах команда доложит.

          • Роман

            Вот тут опасно звучит: “Так что команда - это мощная сущность. Менеджеру вообще не надо париться о производительности отдельных личностей - если что ему о проблемах команда доложит.”.
            К сожалению, это не сильно работает. Без вовлечения менеджера в ежедневные задачи и проблемы есть высокая степень риска, что что то пойдет не так и менеджер будет жить “на другой планете”. Нужно хорошо знать людей, которые работают с Вами, а без тесной работы с каждым в отдельности всего не увидишь. Кроме того, в команде могут быть некоторые личные взаимоотношения, которые утаят от Вас, как менеджера, о проблемах производительности определенного сотрудника.

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

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

              Повторюсь, что команда - мощная сущность, если менеджер ей не мешает :)

          • Алексей

            Команда где все разработчики замотивированы по самое не балуйся, талантливы и компетентны во всех вопросах? Ну… Вы сами то в такое верите? :) Если говорить не о мнении команды о себе, а о взгляде со стороны.

            • Команда где все разработчики замотивированы по самое не балуйся, талантливы и компетентны во всех вопросах? Ну… Вы сами то в такое верите? :) Если говорить не о мнении команды о себе, а о взгляде со стороны.

              Мотивация и компетентность команды - это основа того же SCRUM. Он не будет работать без этого. И Канбан не будет - факт.
              Вообще, все гибкие технологии основаны на мотивации - за счет этого и контроля надо меньше. Но есть дополнительные артефакты для того, чтобы поднять мотивацию - ежедневные митинги, парное программирование, ретроспективы и тим билдинги и т.п.

              • Роман

                Мотивация отдельно взятого сотрудника - вещь непостоянная. Я бы даже сказал, что постоянная мотивация не есть хорошо, так как можно “сгореть”. Иногда полезно похандрить и снизить свою вовлеченность в дела проекта, чтобы немного отдохнуть (не уходя в отпуск). Обычно, такое снижение наблюдается после достижения какого-либо весомого результата и упорного труда и по-научном называется “отдача”.
                Поэтому хорошо бы, если менеджер проекта смог отделять временное снижение продуктивности сотрудника от окончательной атрофии интреса к работе и саботажа, а не принимал бы решение о хирургическом вмешательстве при звоночке команды о снижении продуктивности одного сотрудника.
                Этим постом я не хотел бы показать, что я отвергаю силу командной работы. Просто хочется сказать, что пуская тонкие “душевные” вещи на самотек менеджером проекта и принятие кадровых решений на основе только мнения команды может привести к нежелательным результатам.

                • Просто хочется сказать, что пуская тонкие “душевные” вещи на самотек менеджером проекта и принятие кадровых решений на основе только мнения команды может привести к нежелательным результатам.

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

                  • Роман

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

  • dmodeus

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

  • Блин, бред очередной…

    Система, как показывает пример Тойоты, хороша для Тойоты. Для software development она совсем не хороша. Описанная методология очень похожа на то, как работала 3D Realms… В итоге они так и не доделали Дюка Нюкема….

    А все из за чего? Разработчики при такой системе производства просто со временем теряют связь с реальностью… А на кой она, если “нет таймбоксов ни на что”… 12 лет разрабатывать игру…. да легко….

    “задачи больше и их меньше”… Задача была использовать самый опупенный игровой движок… Отлично, после 3-х лет разработки, выкидываем движок от Квейка, переходим на уже более современный к тому времени от Анрыла… Нам пофиг на время и возможные проблемы, такая задача - движок должен быть самым современным.

    К чему это все может привести: http://www.3drealms.com/news/2009/05/goodbye.html

    Когда вы забиваете в забор 300 гвоздей в час, безусловно, через полчаса нужно заказать еще 150 гвоздей… в данном случае даже вопроса не возникает о смене гвоздей или… или может это вообще не тот забор… не в том месте… или вы забиваете не так, как нужно… или не тем молотком…

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

    • Резюмировать можно что угодно, но есть команды, которые так работают и работают успешно.
      Да, канбан подходит не для любой работы. Если product owner (или менеджер) настолько плох, насколько он был плох в 3D realms, то неважно, как работает команда - проект не будет выполнен. Это задача менеджера направлять разработку и управлять ей. Задача команды - следовать за менеджером и обслуживать его как можно быстрее и качественнее. Собственно всё.

    • Роман

      Хватит! :) Я бы не говорил категорично, что, мол, kanban в software development “лажа” или любой другой подход, методология или система принципов не работают в целом для software development. Все сильно зависит от конкретных обстоятельств (окружения проекта, участников, времени, бизнес среды, фазы луны и еще черт знает чего). “Священные войны” в методологиях управления проектами - это пустая трата времени, так как все зависит от кучи параметров и контекста. Хотя, примеры неуспешности и успешности проектов с использованием определенного подхода очень важны, но с детальным описанием предыстории и контекста. Кроме того, просто знать больше методов и иметь их на вооружении полезно, не так ли?

      • Золотые слова! Полностью согласен.
        Как давно известно - нет серебряной пули в разработке ПО. И ни одна из методологий не является такой пулей. У каждой из них свои лимиты, плюсы и минусы. И разным командам нужны разные методологии. Так что хорошо, что их много.
        И знать их надо именно для того, чтобы иметь возможность выбора.

  • vit_r

    Эк идею-то извратили… Вотличие от оригинальной Тайотовской трактовки тут как раз будет прятанье проблем.

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

    Если команда получает фан от работы и работает с полной отдачей, то никакой контроль и не нужен, а только мешает, увеличивает издержки.

    Это в корне не верно. У клиента, менеджмента и команды цели разные по определению.

    Кстати, вот написано десяток лет назад (КОИ-8)
    http://www.geocities.com/vit_r/Experiments.html

  • Я сам работаю по Канбан но предпочел бы более формализованную методологию. Почему: http://www.vzzvzz.com/kanban/ Но, пока не могу себе позволить.

    • У меня все руки не доходят написать вторую часть статьи про Канбан - там я обязательно отвечу на ваши проблемы-вопросы. В принципе все они решаемы как раз потому, что Канбан - это не четкая методология, а просто фактически образ мыслей. Методологию можно подогнать любую. В том числе и поддерживающую постоянное изменение задач, добавление новых задач, планирование сроков и релизов и т.п.

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>