Канбан в IT: Ответы

Достаточно давно уже написал статью Канбан в IT (Kanban Development) и обещал в ней продолжить серию статей про Канбан.
Сегодня публикую вторую статью про Канбан - ответы на вопросы, которые я получил к первой статье.
Было очень интересно прочитать ваши отзывы и подискутировать на тему этой новой методологии, а самое интересное (на мой взгляд) из комментариев и обсуждений я собрал в этой статье.

Вопрос:

Олег, хотелось бы больше услышать о различных непредвиденных ситуациях. Например, каким образом меняются параметры пулов (лимиты задач и т.п.) при болезни или уходе сотрудника, работающего в определнном пуле (сам примерно вижу, но может есть какие то формулы :) ).
Кроме того, было бы замечательно увидеть наметки 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.:
И это не надуманные случаи - так оно и происходит.

Вопрос (проблема):

В канбан легко потерять цель проекта. За счет того, что ограничивается только количество одновременных задач в разработке, всегда можно решением product-owner приостановить выполнение одной работы и начать другую. С течением времени может оказаться, что вы делали много приоритетных задач, которые однако никакого отношения к выпуску продукта не имели. В канбан ценность таких документов как scope, или техническое задание, несколько ниже, чем в том же Scrum, они вас не защитят. Впрочем, в жизни я наблюдал много ситуаций, когда подписанное техническое задание, в дальнейшем игнорировалось заказчиком, и он оказывал давление на разработчика. Никакая методология от этого не защитит.



Ответ:
Как и в SCRUM, например, задача отслеживания цели проекта и её достижимости - это не задача команды, а задача Product Owner-a (PO). Если команда является сама себе PO, или PO настолько плох, что не может выставлять правильные приоритеты, то жди беды - действительно текущие задачи займут все время и проект не будет двигаться вперед. В принципе у SCRUM та же проблема - плохой PO может все испортить, как бы хороша не была команда.
Если же PO нормальный и следит за бэклогом и его выполнением - всё будет в порядке. По крайней мере у нас все было в порядке.

Вопрос (проблема):

Нестабильный список задач в разработке. В ситуации ,когда чтоб добавить одну задачу надо выкинуть какую то другую, мы получим списочек недоделанных задач. Недоделанный код будет болтаться в репозитарии, его надо будет поддерживать, а спустя некоторое время, переделывать заново. Более того, ваш топ-менеджер может начать думать, что работы уже выполнены (ведь ему о них рассказывали!), а вы то знаете, как на самом деле. Эта ситуация – прямая потеря денег для разработчика. Нельзя допускать произвол product-ownera! И так как спрингов нет, это становится головной болью руководителя проекта.



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

Вопрос (проблема):

А что считать задачей? Основная идея канбан – ограничивать Work In Progress (WIP) В качестве “work” надо выбирать minimal marketable feature (MMF) MMF, как точно отметил bishop, это то “о чем не стыдно написать на блоге”. Однако, не про все нужные задачи вы захотите рассказывать на корпоративном блоге. :-) А главное, понятие minimal feature, чрезвычайно относительное понятие. Как пример относительности, один и тот же список MMF можно раздать участникам команды в зависимости от их опыта так, что он будет выполним или невыполним. Так что на практике WIP часто “плывет”. Подбор этого значения для команды часто является непрерывным процессом. Как следствие – руководитель проекта вынужден в каждый отдельный моент заново решать, потянет его команда сейчас “еще одну маленькую но очень важную задачу” или нет.



Ответ:
Идея MMF и измерения времени на выполнения MMF достаточно странная. Она оперирует статистикой, а не единичными задачами. Дав команде одну MMF, PO не может гарантировать ничего - выполнение этой конкретной задачи может занять 1 день, а может 1 месяц. Но если PO дает команде бэклог на 30 MMF и знает, что в среднем каждая из них занимает неделю, то тут уже работает статистика и можно утверждать, что 30 задач будут завершены за 30 недель делить на пропускную способность команды (число параллельных MMF).
Чтобы сделать оценки более точными, многие команды используют 3 типа MMF - маленькие, средние и большие. У каждого типа свое среднее время выполнения. Когда PO изобретает новую фичу, команда должна решить, какой это тип - маленький, средний или большой. И с этой информацией, вооруженный статистикой PO, может планировать проект вперед.




Похожие записи:
Канбан в IT (Kanban Development)
Software Engineering is Dead?!
Исключения и goto


Понравилась статья? Подпишись на RSS!

9 комментариев к Канбан в IT: Ответы

  • Alexander

    А зачем переписывать обсуждение из предыдущего поста? Не для того ли чтобы упустить не угодные комментарии?

    • Alexander

      Простите не сдержался.. Расстроился из за перечитывания старого…

    • Мало кто читает комментарии к старым постам. Так что для того, чтобы их прочитали - их надо выносить в отдельный пост.
      А на какие неугодные комментарии вы намекаете? Я не Канбан-проповедник, так что готов к критике.

  • Добрый день, я не являюсь разработчиком, а занимаюсь внедрением ИС, какую методологию можно подобрать для оптимального использования?

    • Сложно сказать, я не специалист по внедрению ИС. Да и не знаю, что именно вы внедряете. Нужно знать подробнее вашу конкретную ситуацию, чтобы посоветовать.
      Я знаю, например, что админы в крупных корпорациях любят работать по Канбану.

  • Алексей

    Как это программист не имеет времени “сам не имеет времени протестировать.” зато у него есть время это запрограммировать для тестера? Тут либо крестик надо снять, либо штаны одеть. :D
    Тут, кстати, есть одно серьезное заблуждение, как мне кажется. Тестер не проверяет предположения и правильность работы. Тестер должен искать баги! Иначе говоря ищет способ как завалить программу или добиться ее некорректного поведения. Все предположения должен проверять не тестер, а программист и не в виде добровольной помощи, а потому что работа у него такая.

    >И наоборот - тестеры могут помогать программисту в разработке, если возьмут на себя часть разработческих задач - документацию, общение с product owner-ами, выявление деталей, предварительное тестирование и т.п.
    Они не могут, они просто обязаны это делать. Тестер это такой же разработчик как и программист. Хороший тестер становится экспертом в предметной области. Т.е. если программист видит стандарт и может (попытаться :) ) просто его реализовать, так сказать “в лоб”, то тестер обязан в нем разобраться досконально. Выявить все нестыковки и узкие места и потом проверить как оно работает и как это можно сломать. И какой здравомыслящий человек откажется от эксперта при разработке?

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

    ps: зачем требовать обязательный емайл?

    • >>ps: зачем требовать обязательный емайл?

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

      • Алексей

        >Чтобы пришло оповещение о комментарии. На самом деле туда можно вписать что угодно, если реальный не хочется писать.
        Как программист, программисту - это-то и удивляет. :D Если “что угодно”, то поле опционально должно быть. А так идет сбор мусора, а то еще случайно можно и чужой угадать.

  • Лазая по интернету не нашел ни одной нормальной программной реализации таскборда для работы команды по удаленке, плохо искал ?

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

Ответить

 

 

 

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

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