Pull to refresh

Comments 91

Вот из-за таких вот идей руковдство и покупает дурацкие доски с наклейками вместо настольного тениса и кофемашины.=)
У нас и доски, и кофемашины, и спортзал, и чего только нет :)
Если методология подходит команде и команда работает лучше, то она приносит больше денег фирме, а значит фирма тратит больше денег на всякие полезные мелочи.
Значит, руководство видит доску и не видит идею. Жаль.
Вчера внедрял Kanban в нашей небольшой организации, доска + канцелярские принадлежности вышло в 528 рублей, да и то, стикеры можно было найти дешевле, а не покупать их за 220 рублей. А сама доска — лист пленки «оракал» 2 метра (220 р), наклеенной прямо на стену, + 2 кольца черной изоленты по 30р.
Теннисный стол стоит дороже)
Круто. Почтав про Scrum, я сделал доску, выкинув то, что быстро и безболезнено не втыкалосб. Оказывается, я внедрил Канбан :-)
Так оно обычно и получается — дял реально гибких разработчиков даже Scrum недостаточно гибок, да и не для каждой работы он подходит, так что начинают его упрощать. А тут уже и Канбан.
Но основная идея Канбана — ограничивать число «работы в данный момент» на каждом этапе разработки. Без этого Канбан -не совсем Канбан.
"… для реально гибких разработчиков даже Scrum недостаточно гибок" — главное, чтобы под маской этой «гибкости» не скрывался хаос в проекте, что бывает в большинстве случаев.
Интересная методология.
Вопрос автору: если нет временнных отметок, как тогда продаются эти проекты?
>> если нет временнных отметок, как тогда продаются эти проекты?

А как временные отметки (итерации, спринты) связаны с продажей? Итерации в Scrum или XP — это просто квант работы команды. А проект содержит результат работы нескольких команд и в течение нескольких итераций.
В случае с Канбан никаких итераций нет — есть задачи. Они постепенно выполняются, проект наполняется фичами. В какой-то момент менеджер или product owner может решить, что проект достаточно хорош и готов к релизу и «продать» его.
Либо же просто ждать, пока самые важные фичи не будут выполнены.
Что вы говорите. Одно из понятий скрама — фокус-фактор, который говорит, как эффективно работает команда и сколько она способна решить задач за квант! Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.

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

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

В канбане этого нет. Что я менеджеру скажу? Я не могу ему сказать, что ему надо убрать пять задач, потому что мы их тупо не успеем сделать — у нас статистикой доказано, что средний фокус фактор, например, 48%. Менеджер от меня ждет оценку (от менеджера этого требуют заказчики) — мне нужно дать ему оценку, пусть даже вы правы насчет тем, кто решает успех проекта.

В канбане нет фокус фактора, весь процесс производства — постоянная текучка, стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами. Говорить ему при этом «Дядя, че ты ко мне лезешь, неужели ты не знаешь, что от тебя в разработке проекта ничего не зависит?», как было заявлено в статье, это моветон, меня дядя в 24 часа уволит за некомпетентность.
Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.

Так ли это по сути?
Вы можете рассчитать этот квант и соотношение запланированного к выполненому. Вы можете знать, сколько команда выполнит в следующем спринте, исходя из этих данных.
И это всё!

Что вы знаете про весь проект с этими данными? Ведь чтобы оценить весь проект, надо оценить каждую фичу в проекте, причем довольно точно. Если неточно оценил — грош цена такой оценке и это тоже самое, что и менеджер на коленке бы прикинул, что успеет сделаться, а что нет.
Собственно, гибкая разработка как раз о том, что нифига мы не можем прогнозировать точно и должны быть просто готовы зарелизить тогда, когда надо, а что не успели — отрезать.
Точные прогнозы — это к более тяжелым процессам, а не к agile.

В канбане все тоже самое — есть примерный скоуп проекта и команда его выполняет максимально быстро. product owner следит за скоупом и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну и меняет приоритеты, если что.
Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.

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

Ну, если менеджер — обезьяна, то тут и скрам не поможет. Обезьяна все равно скакать вокруг постоянно будет :)
>Ну, если менеджер — обезьяна, то тут и скрам не поможет.
Именно что поможет. Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

>Что вы знаете про весь проект с этими данными?
Зависит от срока и размера проекта. Если проект мелкий — средний, то всю картину можно разбить на бизнес-задачи. Если он очень большой (как у нас сейчас, например), то берется некоторый актуальный зазор задач, определяемый на встречах с заказчиком — своего рода «мелкий» проект, без особых четко очерченных границ. В любом случае, я хочу сказать, что «знать» про проект — можно. Составление бэклога с последующей приоретизацией и межкомандным согласованием — это очень важная задача. Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.

>когда надо, а что не успели — отрезать.
Вы знаете, получается что в канбане так — ВДРУГ всем стало ясно, что не успели. Работали работали, и не успели.
Итерация дает обратную связь, позволяет изменять процесс и делать его прозрачным.

>Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.

Вот этого я не понимаю. Спринт закончился — если остались задачи, спринт провалился, устраивается разбор полетов. В канбане задача может провисеть мертвой некоторое время, пока кто-нибудь не спохватится — «ой, что это у нас тут».

>и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну
По-моему, это некорректно. Задачи ведь неравномерны по времени своего исполнения!

>Если оно растет — что-то не так.
В статье писалось, что такого аспекта как замеры времени в процессе не существует:)))

Ладно, хватит придирок. Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.
Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

Значит все-таки не обезьяна :)

Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.

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

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

Всё верно написано. В жестких условиях может не подойти. И это не процесс, а надстройка над процессом — над тем же скрамом или xp.
Комментарий заставил задуматься над тем как я работаю со своей командой, спасибо…
Фокус-фактор штука мощная, когда она есть. Но, если в команде работают люди с сильно разной квалификацией, он превращается в среднюю температуру по палате.
Вопрос «будут ли ВСЕ важные запланированные задачи готовы к сроку поставки» не всегда является центральным. Подход может быть другим, например: «Вот задачи А, В, С. Скажите нам, что из них когда мы будем продавать». Получается поток задач и это не плохо само по себе. Всего лишь вопрос выбора бизнес-модели.
Впихивания задач в канбане не произойдет, если менеджер ( мы кстати о каком менеджере говорим? о менеджере продаж надеюсь? ) принимает условие, что количество открытых задач в потоке конечно, и чтобы что то добавить — надо что то убрать. Как оценить это количество? Тут фокус-фактор сам по себе меня никогда не спасал. На самом деле эту оценку всегда приходится проводить и доказывать заново, как только кому то надо подвинуть сроки или расширить объем работ. Можете считать индивидуальный фокус-фактор для каждого члена команды, и давать оценки в зависимости от того, кто конкретно будет делать работу.

Что-то вы усложняете. Какая еще средняя температура по больнице? Есть спринт в днях, есть задачи, есть их оценка в идеальных днях. Устанавливаете фокус-фактор, умножаете и отрезаете те задачи, которые не вмещаются в спринт. Если сделали все задачи — угадали с фокус-фактором, не сделали — значит, фокус фактор был ниже и на следующий спринт его надо скорректировать. Сделали больше — круто, значит, фокус-фактор на следующий спринт можно как-то увеличить.

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

Вам следует прочитать вот эту книгу:
scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf

Там всего 100 страниц и все на русском. Не поленитесь, это очень полезно.
все 100 на русском? :-) а картинки перевести забыли, без картинок неподготовленным читателям тяжко разобраться

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

В книжке рассмотрены приводимые вами ситуации. Вы бы почитали сначала, а потом умничали.
Прочитал, рецепты из книжки не подходят.
Вот из-за таких статей я и люблю хабр! Все по делу, грамотно, профессионально, интересно, актуально. Автор — молодец. Спасибо за статью!
Почитайте оригинальные книги по канбан 70-ых годов и вы поймёте, что канбан притянут за уши в разработку программного обеспечения. Как минимум по двух причинам. Одно из обязательных условий для того, чтобы TPS работал является постоянность временных интервалов связанные с выполнением определённых процедур. Именно поэтому в разрезе TPS планирование — это «waste» (потеря, лишняя трата времени).
Это один из китов на котором основан ТПС и Канбан. А так как такое требование никогда не может быть выполнены в разработке (вы в 30-40 процентов никогда не скажете точно сколько времени уйдёт на исправление того или иного бага), то мы приходим к выводу, что это всего лишь очередная маркетинговая замануха.
плюс еще если речь идет о стартапе, то маркетинговые вещи должны начинаться заранее, а не отсчитывая от конца разработки, иначе теряется время. для автомобилей, причем устоявшейся линейке эти процессы могут идти параллельно, а в стартапе и вообще разработке тут же получим просос.

очень конечно красиво, но думать о внедрении любой методологии тоже надо. причем _до_ внедрения и оценивать не красивость\простоту\что-еще-там идеи, а то, как она реально наложится на существующие процессы :)
Я не говорю про TPS, я говорю про Канбан. Никто не пытается перенести всю систему работы в Тойоте в IT — это невозможно и не нужно. Да и само слово «Канбан» взято из TPS скорее потому, что красиво звучит :)

Основа у Канбан та же, что и у TPS — уменьшение work in progress, но это и всё. Что еще взято из TPS?

Канбан — это просто адаптация хорошей идеи к реалиям разработки ПО.
Канбан, вырванный из TPS — это всего лишь практика и никак не методология.
Даже Хенриг Книберг в своём сравнении скрама и канбана (вдруг не читали, blog.crisp.se/henrikkniberg/2009/05/29/1243594140000.html) скатывается к откровенно премитивному выводу — вся суть «методологии» канбан — это контроль WIP-а, а всё остальное по вашему усмотрению. Опытному менеджеру и разрабочки при этом становится просто смешно.
Приведу вам хороший пример использования практики (именно практики, а не методологии) канбан.
«Не разрабатывайте фичей больше чем можете протестировать».
Спасибо, мы давно так не смеялись. Это удивительная методология! Шедеврально почти все, но особенно порадовало: «Например, в SCRUM — 9 базовых правил. В XP — 13, а в классическом RUP — аж более 120. Почувствуйте разницу».
Из зала добавили: копаем от забора и до заката
я один неправильно прочитал слово канбан? оО
Нет, я тоже прочитал его раза 4 неправильно, прежде, чем понял.
1) Как данная методология решает основной вопросы на уровне топ-менеджмента: Когда в продакшене будет следующая стабильная версия системы?

Решение вижу только одно: манагер все равно должен трэкать частоту закрытия ММФ в период времени, получать project velocity, смотреть на burn-down, отчитываться перед руководством. Поэтому имею мнение, что:

— Методология подходит только для проектов с дедлайнами типа «when it's done» (таких меньшинство) -ИЛИ-
— Оценка временнЫх факторов решения задач все равно присутствует в неявной форме в ежедневной работе менеджера

2) Частично согласен, что кол-во параллельных задач в работе определяется кол-вом программистов. Частично, потому что это кол-во еще определяется индивидуальными качествами программистов, маркетинговыми потребностями, техническими взаимосвязями в задачах.

3) Несогласен, что контроль — это фикция. Либо вы как-то по-своему понимаете значение этого слова. В моем понимании, контроль — это _управляемость_ процессом разработки, т.е. возможность направлять его в нужное на данный момент русло. «Данный момент» в контексте бизнеса — недельный срок вполне приемлем.

В-общем, если резюмировать — agile с недельными спринтами и оценками задач при планировании более предсказуем для команды, которая уже хотя бы один проект по такой методике имеет за плечами.
Как данная методология решает основной вопросы на уровне топ-менеджмента: Когда в продакшене будет следующая стабильная версия системы?

А как любая другая методология решает этот вопрос? Фактически никак — ставится срок на основе каких-то предварительных оценок и проект движется к этому сроку. Что успели сделать — то входит в состав проекта. Что не успели — не входит, либо срок передвигается.
Какую методологию не используй, точно спрогнозировать вначале не сможешь. Можно только буферы задать побольше, чтобы подстраховаться.
В Канбане тоже самое, только измерение времени идет по скорости разработки одной задачи. Если на проект есть 100 задач и мы знаем, что команда в среднем делает задачу за неделю и параллельно может делать до 5 задач, то можем считать, что через 20 недель все будет готово.

— Методология подходит только для проектов с дедлайнами типа «when it's done» (таких меньшинство)

Не только. Но для работы над проектами с жестким дедлайном и жестким набором фич эта методология плохо подходит — факт.

— Оценка временнЫх факторов решения задач все равно присутствует в неявной форме в ежедневной работе менеджера

Конечно присутствует. Иначе зачем мерять время на выполнение одной задачи?
Менеджер (product owner) по-прежнему должен общаться с маркетингом и другими заинтересованными лицами и должен следить за конечным сроком. Инструменты для этого в Канбан есть — это время на выполнения 1 задачи и число задач, выстроенных по приоритетам.

2) Частично согласен, что кол-во параллельных задач в работе определяется кол-вом программистов. Частично, потому что это кол-во еще определяется индивидуальными качествами программистов, маркетинговыми потребностями, техническими взаимосвязями в задачах.

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

В моем понимании, контроль — это _управляемость_ процессом разработки, т.е. возможность направлять его в нужное на данный момент русло.

В моем тоже. И тут Канбан как нельзя лучше подходит к проектам, где изменения происходят очень часто. Например — поддержка (maintenance). Или любая другая разработка, где 2 недели на спринт — это слишком много, т.к. изменения в планы приходится вносить чуть ли не каждый день.

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

Не согласен. Чистый Agile (Scrum) с недельными спринтами будет иметь слишком большой оверхед на поддержку методологии — слишком много «обязательных» артефактов и обсуждений. Хотя опять же все зависит от команды и условий проекта, так что тут нет общего решения.
Ну в целом я с Вами согласен =) Каждому проекту своя методология.

И тут Канбан как нельзя лучше подходит к проектам, где изменения происходят очень часто.

Факт! И таких проектов не так уж мало. Когда в разгар работы приходит менеджер по продажам и говорит что нашел кучу денег, но надо срочно делать прототип — моя команда садится и делает. И приходится забыть про текущий спринг, рассчитанный фокус-фактор… И с кураторами проектов мне проще торговаться за то, какие задачи сейчас отложить, чтоб сделать что то внезапно-срочное, чем доказывать что сначала надо закончить текущий спринг. И зачастую это единственнный выход!

Кстати, 8 месяцев назад общались мы с Robin Dymond (CST), которые сейчас читает также тренинги по лин и канбану. Так вот спросили его потом за бутылочкой пивка, а ты хоть раз в жизни видел проект, который бы работал использую Канбан. Его ответ? «Нет» )))
Я работал прошлые полгода с использованием Канбан. Проект вышел достаточно успешный и все остались довольны :)

То есть вы никогда не планировали? Просто сидели и что-то потихоньку делали?
Или как там из зала добавляли «копали от забора и до заката»?

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

Опять же повторюсь — если команда работает и хочет работать хорошо, то какое еще планирование нужно? Если в бэклоге 50 задач, то мы должны все их сесть и оценить? Или мы должны, как в Scrum, оценивать только на 2 недели вперед? Так через день придет новый баг и его надо исправлять. В Scrum это решается планированием «непредвиденных задач», но если непредвиденных — 50%, то это уже глупо становится.
А в канбан непредвиденных не бывает, получается?
Имхо если 50% непредвиденных — то это уже даже не управлятор рисками дал сбой, а в понимании задачи командой что-то не то, или команда представляет из себя не то, что думает лид. И методология тут уже ИМХО влияет мало.
В Канбан нет непредвиденных задач, т.к. никто не планирует вперед. Задача обсуждается и принимается в работу только когда для нее появляется место. Поэтому если появляется новая задача — ее приоритизирует product owner и помещает в буфер задач, а оттуда она уже будет взята в разработку, когда команда доберется. А если приоритет очень высок, то можно и вверх списка поместить и получить выполненную задачу уже очень скоро.

Имхо если 50% непредвиденных — то это уже даже не управлятор рисками дал сбой, а в понимании задачи командой что-то не то, или команда представляет из себя не то, что думает лид. И методология тут уже ИМХО влияет мало.

В техподдержке крупной системы только так люди и работают — каждый день что-то новое :)
В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
>>В Канбан нет непредвиденных задач
Как это нет — поясните, пожалуйста? Он живет в другой реальности? Или имеется в виду, что в ваших терминах новая != непредвиденная?

>>никто не планирует вперед
В моем понимании в таком случае каждая задача — непредвиденная

>> вверх списка поместить и получить выполненную задачу уже очень скоро.
Чем это отличается от бэклога в scrum?

>>В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
Если я правильно понимаю, то это — не очень хорошо и вряд ли позитивно сказывается на качестве.
Или имеется в виду, что в ваших терминах новая != непредвиденная?

Да, новая != непредвиденная. Непредвиденные задачи — это когда у тебя распланирован спринт и все заполнено и вдруг приходит новая срочная задача. А ты сопротивляешься ей, т.к. внутри спринта задачи нельзя новые добавлять.

Я считаю, что это — хорошо, когда проект сопротивляется внедрению фич. Каждая фича должна доказать свою необходимость, ее необходимость будет выражена в приоритете. Тут же я воздержусь от спора, потому что мне пока непонятно, кто ставит приоритеты задачам в канбан.
Приоритеты ставит product owner. И он же должен и фичам сопротивляться — он владелец проекта и он лучше всех остальных должен знать, что хорошо, а что плохо.
В случае IT, похоже, в канбан предлагается просто иметь пул задач, куда они все валятся — первый освободившийся берет задачу и делает. Освободился от текущей — делай следующую.

Это хорошо для Toyota, где технические аспекты не рассматриваются — есть хорошо известный процесс («приделывать двери»), который невозможно испортить (разве что делать медленно) и где не нужно экспериментировать, и вся затыка — только в ресурсах.

Кто будет думать над hi-lvl архитектурой, когда product owner лично назначает приоритеты? Где в данной схеме место тех.лида?
>> Кто будет думать над hi-lvl архитектурой, когда product owner
>> лично назначает приоритеты? Где в данной схеме место
>> тех.лида?

Я могу сказать только про наш опыт. Мы разрабатывали архитектуру по большей части сами, то есть и тех. лид и архитектор находились в команде.
Когда были совсем высокоуровневые вопросы, то у нас в компании есть должность главного архитектора — шли к нему и обсуждали. Никаких проблем с архитектурой замечено не было.
>> вверх списка поместить и получить выполненную задачу уже очень скоро.
Чем это отличается от бэклога в scrum?


Бэклог в скраме трогается только при планировании нового спринта и если туда что-то помещается, то в работу это пойдет только в след. спринте. А если спринт — 1 месяц, то это ой как нескоро. Да и 2 недели тоже.

>>В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
Если я правильно понимаю, то это — не очень хорошо и вряд ли позитивно сказывается на качестве.


В целом — да. Но там по-другому нельзя — слишком много креатива, проб и ошибок.
Т.е. канбан — это скрам со сверхкраткими спринтами длиной иногда и в один день, с удалением всех активностей, которые не влезли в спринт, типа планирования/проектирования?
Канбан может быть использован вместе с Scrum или XP.
Канбан-команда может использовать любые артефакты из других методологий, т.к. Канбан — это не методология по сути, а набор ценностей, надстройка над методологией.

Вы можете по-прежнему делать TDD, парное программирование, daily митинги, даже может быть итерации — все, что угодно, что помогает вам двигать задачи по доске Канбан как можно быстрее. Про конкретные методы и приемы разработки Канбан вообще ничего не говорит.
Кстати, что происходит в канбан (ну, или в вашей интерпретации канбан), когда одна критическая высокоприоритетная задача уже есть, появляется ещё одна такая же — а очередь задач уже забита?
В классическом Канбан Product Owner должен решить, какую из задач в очереди убрать и куда поместить новую высокоприоритетную. Но он не может ее впихнуть в производство, т.к. только одну может.

У нас же проще — мы просто берем вторую в производство. Третью уже можем и не взять — тогда это задача product owner-а поменять список в очереди задач.
Еще в канбан можно отдельно ввести ограничение на количество высокоприоритетных задач, такой «блэклог высокоприоритетных задач».Тут конечно могут быть трудности с такими product owner, которые считают все свои задачи приоритетными. Но штука полезная, препятствует бардаку в приоритетах, который может взорвать канбан
У меня сейчас в проекте намечается момент, когда канбан может взорваться как раз из-за множества высокоприоритетных задач, которые берутся в работу немедленно. Из-за этого могут откладываться старые задачи.

Пробую с этим справиться, но пока что таким образом, что product owner-у не отказываю, но людей со старых задач стараюсь не снимать — пытаюсь хэндлить их самостоятельно. То есть как бы есть специальный выделенный человек на «неожиданности».
То что вы только что описали, уже как лет 10-20 имеет очень чёткое определение в мире управления разработкой программного обеспечения. И имя ему «Ad hoc development». По склассификации CMMI относится к уровню 2 и имеет крайне низкий уровень предсказуемости и управляемости.
www.ctg.albany.edu/publications/reports/survey_of_sysdev?chapter=4
А то что для старых дел придумали новомодное очередное название, ещё раз говорит о том, что это всего лишь наживка для армии agile-тренеров.

извините, последнюю фразу нужно читать как «наживка, созданная армией agile-тренеров»
Это не совсем Ad hoc, т.к. есть бэклоги, приоритизация, оценки времени на выполнение задач, ограничение работы в прогрессе и т.д.
А так в целом — да, похоже на Ad hoc.
В канбан — ничего не сказано про приоритезацию. Там сказано — делайте как хотите, можете вообще не приоритезировать. Про оценку времени тоже ничего не сказано. Она не нужна, оценка — это трата времени. Когда будет сделано, тогда и будет сделано.

Всё что есть в канбан — это ограничение WIP и всё.
Про приоретизацию в трех основных правилах не сказано, да. Наверное потому, что это не задача команды, а задача product owner-а, который является внешней силой.
Про оценку времени сказано в третьем правиле.
«В Канбан оценки сроков на задачу опциональные или вообще их нет» — это ваши слова.
Дальше — в канбан нет роли PO. В канбан нет вообще ролей. И в отличае от скрама в канбан не говорится что именно он должен делать приоритезацию.
Такие вот «мелочи» и отличают настоящую методологию от набора «полезных советов»
А вот еще мои слова, подтверждающие ваши: :)
Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Так ты всё таки определись, что это. Потому что самое первое твоё предложение звучит так «Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан». Это во-первых, а во-вторых Канбан не может быть системой ценностей, потому что это место уже забито таким понятием как «lean».
Scrum и XP — это методологии.

Читайте первоисточники.
jeffsutherland.com/oopsla/schwapub.pdf

Our new approach to systems development is based on both defined and black box
process management. We call the approach the SCRUM methodology (see Takeuchi and
Nonaka, 1986), after the SCRUM in rugby — a tight formation of forwards who bind
together in specific positions when a scrumdown is called.
Да, первое предложение не очень-то верно.
Канбан — это не полноценная методология разработки. Это скорее надстройка над другими методологиями. Канбан добавляет в то, над чем он построен, некоторые плюсы, и это методология, но не полная.

А «lean» и канбан — это немного понятия разного уровня. lean — это высокоуровневая система ценностей, в которую канбан входит, как составная часть.
Перенесли бы в «Agile: Живая разработка» (agile)
ИМХО там оно уместнее :)
Минус идее.

Канбан и прочее — для конвейера.

IT чуть менее чем полностью конвейер. Хотя в небольшой доле он конвейер.

И по-мойму изобрели его не в Японии, а в США. Японцэ его внедрили.
Вы похоже не поняли идею применения Канбан к IT. Конвеер — это в TPS (toyota production system), а в IT Канбан совсем о другом — о разработке новых больших фич (ММФ) как можно быстрее. Никакого конвеера нет и в помине.
Новая большая фича = качество?
Быстрее = скорость?

=> Затраты стремятся к бесконечности.

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

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

Контроль — это пассивная штука, а мотивация — активная.

Контроль — это панель приборов, а мотивация — педаль.
IT чуть менее чем полностью конвейер. Хотя в небольшой доле он конвейер.

У вас лурчанка головного мозга
очень понравилась статья.
обьясните пожалуйста, канбан является одной из методик agile разработки?
Да, конечно. В самом начале написано: новую методологию гибкой разработки Канбан
Статья поначалу вызывает, восторг, да. Пока думать не начинаешь:) Почитайте комменты оппонентов.
Кстати, в макдоналдсе тоже что-то похожее видел: кассиры такие пластмасски с циферками на кухню запускают и им по ним уже делают и возвращают всякие гамбургеры-чизбургеры
Я вам больше скажу, Таичи Оно придумал канбан для тойоты, когда посетил американский супермаркет.
Полмесяца назад была встреча «SCRUM против Kanban» сообщества AgileRussia.
Там все кости и первому и второму перетерли.

Есть видео в достойном качестве.
team.custis.ru/2009/07/kanban-vs-scrum.html
Очень напрягали большие потери времени на планирование в SCRUM. Тут прям сказка, нужно попробовать как на практике
только не забывайте про закон Паркинсона ;-)
что делать с мелкими фичами с точки зрения маркетинга?
С какими, например?
Общий случай — включать их в более крупные фичи.
например, рефакторинг. если включить его вкрупную маркетинговую фичу, то у тестеров добавится мороки при её тестировании, а неизбежно возникающие при рефакторинге ошибки будут тормозить релиз той фичи…
Про рефакторинг — это целый отдельный разговор. Кто-то делает его постоянно про разработке любой фичи, считая, что тронул код — прорефакторь его.
Кто-то выделяет специально время на него — это уже может быть вне канбана. Просто раз в полгода на 2 недели все делают рефакторинг.
А можно и фичу такую завести и назвать ее как-нибудь типа «Улучшение надежности, стабильности и поддерживаемости кода».

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

Да это в любой деятельности работает: в логистистике, в производстве, в делопроизводстве и так далее…
не вступая в дискуссию по процессам (хотя я думаю, что канбан — это больше философия)
поделюсь следующей информацией.
Широко известный в узких кругах Nate Kohari — автор ninject.org, mvp, ex-Telligent, вместе со своей женой phd по industrial/organizational psychology запустил новый стартап</>. Речь идет об инструменте ведения проектов по Lean Kanban. На сайте можно попробовать канбан инструменты, хотя бесплатно там только 1 проект и 1 пользователь. Также вот здесь есть хороший подкаст Nate Kohari with Steve Hanselman на тему практического применения канбан и того инструмента, который сделал Nate.

>>В-третьих, можно вычислить время на выполнение усредненной задачи.
Да уж, средняя температура по больнице.

>>А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.
С этими цифрами ничего нельзя сделать.
Использую (веб-дев) близкую к канбану технику. Отличия:
1) фичи сгруппированы по сущностям системы
2) У каждой фичи есть предварительная оценка. Если оценка сильно различается с реальным временем — проводится анализ.
3) Написание теста перед разработкой. Собственно окончание разработки — успешное прохождение теста. Нормально, если перед разработкой фича может быть возвращена в область тестирования (добавить-убрать)
4) вместо доски — сайт с тикетами, за счет автоматизации идет контроль кто, сколько, чего делает, ну и еще несколько приятных фич для разработчиков.
5) Ежедневный и недельные циклы деплойментов.

В разработке лежит проект для веба, может когда-нить и доделаю.
1. >«Если команда не хочет работать, то как ее не контролируй, она провалит проект.»
Метлой к чертям и набираем команду, которая получает фан ) В действительности, по-моему, команда для менеджера — это тыл, если он слаб или в тылу предатели — нужно срочно поправлять дело.

2. И еще я думаю, нужно принять во внимание внутреннюю дисциплину японцев, капитализм запада, расхлябанность и лень русского народа с исторически сложившимися восприятием барин-холоп в вперемешку с моделью социализма. К примеру, модель Йордона по мотивации, удержанию и повышению результативности сотрудников, которой он делился на семинаре с русскими IT управленцами в 2008, во многом сомнительна для русских IT компаниях.
> Если менеджер верит команде, то зачем иметь оценку времени?

Можно верить команде, то есть быть уверенным, что разработчики и тестеры будут работать на максимуме способностей и выполнять задачи очень-очень быстро, но как это избавляет от необходимости знать хотя бы приблизительные сроки завершения работы по конкретной задаче? Это ведь не для формального контроля нужно, а для выполнения менеджером своих прямых обязанностей: общения с заказчиками, которых мало волнуют особенности внедрённых технологических процессов; или подготовки к публичному, маркетинговому запуску новой фичи.
Отличная статья, благодарю!
Наконец-то получил «волшебный пинок» для того, чтобы повесить доску в доступное место и визуализировать процесс. Осталось подобрать приложение для того, чтобы удалённые разработчики видели похожую доску, а именно — список задач. Пока используется agilo, но есть мысли уйти от него.
Sign up to leave a comment.

Articles