четверг, 8 августа 2013 г.

Почему канбан НЕ поможет вам при ведении проекта?

В очередной раз на форуме RSDN.RU возник спор про гибкие методологии и, в частности, канбан. Некоторое время назад я опубликовал статью "Халтура.Ру: Как халтурят отечественные ИТ-консультанты?".

Сегодня мне бы хотелось привести дополнительные аргументы.



Предположим, команда из 6 разработчиков + 1 аниматор + 1 UI-дизайнер + 2 3D-моделлера + 2 2D-артиста делают игру. Как Вы думаете, сколько нужно поставить deliverables к ближайшему майлстоуну? Промежуток между майлстоунами месяц — полтора. В нашем случае количество deliverables — 45.

Каждый deliverable — это feature, которая включает в себя несколько технических и артовых задач. Сколько было таких задач? Порядка 300 технических + артовые, которые я не считал, т.к. ими занимался ведущий артист.

Каждая техническая задача имеет свой estimate (который, согласно отраслевым стандартам варьируется от 4 до 24 часов) и текущий прогресс по нему. Некоторые задачи закрываются с опережением срока. Некоторые — с задержкой, которая связана с обнаружением непредвиденных обстоятельств. Происходит переоценка задач и, как результат, перепланирование работы и перераспределение задач между разработчиками. Нередко случается, что задача одного разработчика переходит к другому из-за того, что первый разработчик погряз в предыдущей своей задаче, а другой — справился со своей быстрее, чем ожидалось.

Ряд задач откладывается из-за того, что арт у художников ещё не готов или продюсеры (о, чудо!) решают полностью переделать дизайн фичи.

Как всем этим управлять при помощи карточек? При таком объёме задач бумажные карточки осыпятся под собственной тяжестью, а электронные канбан-доски будут полностью захламлены.

Представьте теперь, что произойдёт, когда над проектом работают не 10, а 100 человек. А ведь именно так и происходит при разработке больших игр.

Z>Ну, наверное, это можно только составить для какой-то работы, которая постоянно повторяется. Например, делать одинаковые сайты — картинки меняй и всё. Тут и сроки известны, и бюджет и соответствования целям. Ну, или траншею рыть — тоже всё известно.


Вы ошибаетесь. Есть вполне устоявшиеся и апробированные процессы в крупных корпорациях. Они не так известны и популярны, как модные аджайл и канбан, однако предсказуемы и приводят к запланированному результату. Да что там корпорации! Даже американские стартапы используют процессы. И без дизайн-документации и планирования никто и строчки кода не напишет.

Просто это не так весело, как играть в геймификацию и тасовать карточки. Зато — надёжно и практично.

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

Обсуждение на форуме RSDN.RU можно прочитать здесь.

9 комментариев:

  1. Канбан работает в Яндекс.Картинках, там команда в 45 человек, доста у них 1,5 на 6 метров.

    Для менеджеров есть упрощенные доски по фичам.

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

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

    И везде применяется основной принцип kanban - ограничение WIP.


    Кстати когда на одном проекте 100 человек и нету никакой внутренней структуры в этой толпе, то любая методология плохо сработает.

    ОтветитьУдалить
    Ответы
    1. Станислав, а чем, например, redmine или jira хуже, чем доска с карточками? Тем более, что такс-трекеры обладают фильтрами, инструментами для поиска, отслеживают историю изменений и т.д. и т.п.

      Никто не говорит, что у команды нет структуры. Просто за списками фич и технических задач нужно следить, как бы ни структурировались разработчики.

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

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

      Удалить
    3. В ТФС есть доска. И для распределенных команд она очень помогает. А редмайн не имеет никакой интеграции со студией как и жираф. Вот обычный юз кейс как я мучась с редмайном:

      В редмайн, чтобы залить картинку с результатом работ, надо проделать следующие операции.

      1. Зайти в РЕДМАЙН свернув IDE.
      2. Выбрать задачу.
      3. Закачать картинку в задачу, нажать обновить.
      4. Нажать обновить, вставить уже закаченную картинку в html разметку и отписаться под картинкой.

      Что надо сделать в ТФС:

      1. Не выходя из студии выбрать нужную задачу.
      2. Отписаться вставив туда хоть видео хоть, что без тыкания обновить загрузить.. и.т.д.
      3. Нажать чекин с прописанным ID work item.

      Какой профит?
      1. В случае с ТФС я получаю привязанную задачу к чекину.
      2. На доске в ТФС отразятся эти изменения (если настроить воркфлоу то захламления можно избежать - это фишка канбана в тфс. Там можно поставить ограничения количества тикетов на 1 столб).

      Удалить
    4. В редмайне неудобная навигация, а в студии, я могу поставить древовидное представление задач, и не выходя из студии, сразу увидеть, чего не хватает для реализации фичи - это позволяет сразу увидеть как обстоят дела и выбрать, то, что ты сейчас можешь делать. Для ПМ-ов это представление дает огромное преимущество, он сразу видеи затыки и проблемы, где не может двигаться команда. JIRA и REDMINE (работаю с этими недотрекерами уже 2й год).

      Удалить
    5. Станислав,

      1)При сотнях запланированных и открытых задач на доске появляется мешанина, в которой невозможно разобраться. Если в электронной системе задач ещё можно поставить фильтр, то тут его не применишь.

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

      Удалить
    6. Виталий,

      Речь не идёт о споре Электронная Система Контроля Задач № 1 vs. Электронная Система Контроля Задач № 2.

      Удалить
    7. Неужели прямо таки "Канбан"? Ставлю десятку против рубля, что вы гоните. Принимаем пари?

      Удалить
  2. Странно спорить о методологиях. Гибкие методологии управления проектом, как и паттерны проектирования, не являются серебряной пулей, работают далеко не во всех случаях, и порой приводят к катастрофе и хаосу, будучи внедренными без осознания причин и последствий. В каждой компании свой канбан, скрам или whatever, которые отличаются от канбанов и скрамов компании по соседству. Процесс разработки формируется эволюционно, и в этом участвует вся команда. Какой смысл пытаться внедрять процесс из книжки? Используйте то, что в вашей ситуации может работать лучше всего.

    ОтветитьУдалить