Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Заинтересованным советую попробовать канбан в деле.
Пробую.
Как я понял, если расценивать карты как отдельные задачи, то можно назначать их определённым исполнителям. И можно смотреть, какие карты/задачи есть у исполнителя. Но при этом довольно трудно отслеживать скорость его работы, т.е. количество задач, сделанных за неделю, или тем более назначать задачам сложность или ресурсоёмкость и измерять эффективность работника.
Для таких целей какие инструменты используются?
Как я понял, если расценивать карты как отдельные задачи, то можно назначать их определённым исполнителям. И можно смотреть, какие карты/задачи есть у исполнителя. Но при этом довольно трудно отслеживать скорость его работы, т.е. количество задач, сделанных за неделю, или тем более назначать задачам сложность или ресурсоёмкость и измерять эффективность работника.
Для таких целей какие инструменты используются?
Или pintask.me (статья).
тему как будто палочкой потыкали :) пишите смелее
«разпиаренных» => распиаренных
«серебренная» => серебряная
Скажу от себя, что Канбан плохо подходит для клиентской поддержки. Казалось бы, он даёт инструмент для быстрого реагирования, но зато полностью отбирает возможность получить какую-либо определённость в сроке исполнения задачи, потому что любая работа может быть сдвинута на неопределённый срок другими задачами.
Да и в целом, я бы не стал называть Канбан методологией. Это скорее удобная практика, которую можно применять в подходящих случаях.
«серебренная» => серебряная
Скажу от себя, что Канбан плохо подходит для клиентской поддержки. Казалось бы, он даёт инструмент для быстрого реагирования, но зато полностью отбирает возможность получить какую-либо определённость в сроке исполнения задачи, потому что любая работа может быть сдвинута на неопределённый срок другими задачами.
Да и в целом, я бы не стал называть Канбан методологией. Это скорее удобная практика, которую можно применять в подходящих случаях.
Как это отбирает определенность? Вы же замеряете lead time для классов задач. По каждому классу прогноз и будет очень точный. При достаточной статистике, конечно. Не через неделю, после того, как доску повесили.
Если я правильно понимаю вашу терминологию, lead time — это статистика, показывающая, в среднем, как долго задача добирается до статуса (in-progress? completed?). В любом случае, статистика — это вероятностная величина. Её нельзя пообещать клиенту, которому, например, надо запустить лэндинг к четвергу, потому что у него стартует реклама по телевизору, которая стоит дороже чем вся ваша команда с её канбаном.
Lead time — время, за которое задача проходит через систему, от приема в работу, до завершения. Не знаю, откуда вы знаете, сколько стоит моя команда, но если вы просто поглядываете, сколько там у вас в среднем на задачу уходит и ничего не предпринимаете для повышения предсказуемости процесса, то это не канбан, а… хроника пикирующего бомбардировщика.
А если вы беклог формируете из «лендингов к четвергу», то вы сам себе злобный буратино и никакой канбан со скрамом вам не помогут.
А если вы беклог формируете из «лендингов к четвергу», то вы сам себе злобный буратино и никакой канбан со скрамом вам не помогут.
Когда я говорил «ваша команда», то имел в виду не вас, а некоторую абстрактную команду, использующую канбан, равно как и пример заказчика с телевизором тоже выдуман из головы, не принимайте на свой счёт.
Лично я, пока участвовал в организации работы отдела разработки, предпринял для повышения предсказуемости следующее — предложил избавиться от канбана и внедрить старое-доброе планирование работы по дням недели, что впоследствии очень хорошо сказалось как на предсказуемости результатов, так и на производительности труда, и на прозрачности всего процесса в целом.
Лично я, пока участвовал в организации работы отдела разработки, предпринял для повышения предсказуемости следующее — предложил избавиться от канбана и внедрить старое-доброе планирование работы по дням недели, что впоследствии очень хорошо сказалось как на предсказуемости результатов, так и на производительности труда, и на прозрачности всего процесса в целом.
Вы спрашиваете, что такое lead time, сомневаетесь в WIP — извините, но кажется у вас не было канбана.
Вы почему-то не настроены на продуктивную беседу. Возможно я не владею нативной терминологией этой практики, но это не мешает рассуждать в общем.
В компании, куда я пришёл заниматься организацией деятельности, использовалось нечто, что они называли канбаном. У них были карточки с ограничением количества в работе и прочие вещи. А компании нужна была прозрачность и понимание того, в какой день какая задача будет готова. Всю эту систему мы заменили на планирование по дням, потому что, как мне кажется, система подобная канбану такого дать не может, у неё другие преимущества.
Вы мне пытаетесь доказать, что в канбане можно гарантировать исполнение какой-то задачи в конкретный день. Я и спрашиваю вас, как? Статистические значения здесь не годятся, потому что сроки бывают жёсткими.
В компании, куда я пришёл заниматься организацией деятельности, использовалось нечто, что они называли канбаном. У них были карточки с ограничением количества в работе и прочие вещи. А компании нужна была прозрачность и понимание того, в какой день какая задача будет готова. Всю эту систему мы заменили на планирование по дням, потому что, как мне кажется, система подобная канбану такого дать не может, у неё другие преимущества.
Вы мне пытаетесь доказать, что в канбане можно гарантировать исполнение какой-то задачи в конкретный день. Я и спрашиваю вас, как? Статистические значения здесь не годятся, потому что сроки бывают жёсткими.
Вы пришли на новое место, где система была «установлена», но, я так понял, задачи не решала. Вы систему заменили на свою. И это понятно — вам нужны были результаты, но добиться их установленной не вами системой вы не могли. Если меня попросят свалить дерево и дадут бензопилу и топор — я начну рубить топором, потому что бензопилу не разу в жизни не заводил и не знаю сколько времени на запуск уйдет, и запустится ли она вообще.
Но это не дает вам права заявлять, что канбан не подходил для вашей компании. Он не подошел лично вам. Никто не показал вам, как пользоваться бензопилой, а на чтение инструкций времени, скорее всего, не было. Но бензопила не стала от этого хуже — даже начинающий пильщик обгонит ваш топор. И, продолжая аналогию, чем больше дерево, тем явнее преимущество.
Но это не дает вам права заявлять, что канбан не подходил для вашей компании. Он не подошел лично вам. Никто не показал вам, как пользоваться бензопилой, а на чтение инструкций времени, скорее всего, не было. Но бензопила не стала от этого хуже — даже начинающий пильщик обгонит ваш топор. И, продолжая аналогию, чем больше дерево, тем явнее преимущество.
Про задачи с дедлайнами. Как вы сейчас определяете, будет ли задача сдана в срок?
Сейчас в этой компании задачи от клиента формализованы менеджером или разработчиком и оценены разработчиком в часах. Планирование по дням позволяет запланировать работу по задаче на определённый день. Оставшийся риск в этой схеме — это риск неправильной оценки задачи разработчиком. (Практики снижения этого риска уже выходят за рамки обсуждения, конечно они тоже применяются.) Таким образом, мы проблему решили: существует план, по плану задача в четверг, значит она будет в четверг, и любые движения без предварительных согласований невозможны.
В канбане это гораздо сложнее устроить. Если тебе нужно, чтобы задача была во что бы то ни стало сделана к конкретному дню, тебе нужно постоянно играть с приоритетами, повышая их, по мере приближения дедлайна. И это всё равно не гарантирует выполнения в срок (потому что всё, что уже висит на доске, может затянуться).
Плюс ко всему, когда в компании несколько инициаторов задач и несколько бэклогов, а отдел разработки один, тогда ещё появится и проблема дележа приоритетов (или ресурсов).
В канбане это гораздо сложнее устроить. Если тебе нужно, чтобы задача была во что бы то ни стало сделана к конкретному дню, тебе нужно постоянно играть с приоритетами, повышая их, по мере приближения дедлайна. И это всё равно не гарантирует выполнения в срок (потому что всё, что уже висит на доске, может затянуться).
Плюс ко всему, когда в компании несколько инициаторов задач и несколько бэклогов, а отдел разработки один, тогда ещё появится и проблема дележа приоритетов (или ресурсов).
В канбане это гораздо сложнее устроить. Если тебе нужно, чтобы задача была во что бы то ни стало сделана к конкретному дню, тебе нужно постоянно играть с приоритетами, повышая их, по мере приближения дедлайна.
Это совсем не так. ;] Канбан вообще ничего почти не предписывает, он накладывается на ваш существующий процесс. Это просто инструмент для анализа и изменения существующего процесса. Следуй минимуму правил, а дальше используй «плагины» к канбану по необходимости. Зачем «играть» какими-то «приоритетами»? Если у вас есть задачи со сроком поставки — крупно дедлайн на каждой надпишите да выделите их в отдельный класс, поставьте лимит и применяйте к ним свои правила (policy). Ну, может, покрасьте их карточки в какой-нибудь оранжевый для наглядности.
И это всё равно не гарантирует выполнения в срок (потому что всё, что уже висит на доске, может затянуться).
А если задачу не повесить на доску — она не затянется? Почему?
Плюс ко всему, когда в компании несколько инициаторов задач и несколько бэклогов, а отдел разработки один, тогда ещё появится и проблема дележа приоритетов (или ресурсов).
А сейчас почему проблемы нет?
Задачи со сроками могут быть не крупными проектами, а небольшими работами на три-четыре часа. Выделять под это собственный канбан и резервировать людей бессмысленно. Можно написать крупно дедлайн, но кому будет до него дело, если люди смотрят на те задачи, которые висят «в процессе».
По поводу «висят на доске» — видимо мы друг друга не поняли. Я имел в виду, что даже если вы ставите задачу в бэклог с высоким приоритетом, до неё может не дойти дело, поскольку исполнители уже заняты задачами «в процессе», которые там двигаются в тестирование и обратно. Вот эта неопределённость и мешает.
Почему планирование по дням помогает решить проблемы с дележом ресурсов? Потому что при таком подходе проще отследить, кто именно загрузил отдел работой в прошлом, в настоящее время, и в будущем. Это наглядно видно по календарю, а значит с этим можно работать. Менеджеры могут буквально до часов делить ресурсы отдела на следующую неделю и это легко контролируется.
По поводу «висят на доске» — видимо мы друг друга не поняли. Я имел в виду, что даже если вы ставите задачу в бэклог с высоким приоритетом, до неё может не дойти дело, поскольку исполнители уже заняты задачами «в процессе», которые там двигаются в тестирование и обратно. Вот эта неопределённость и мешает.
Почему планирование по дням помогает решить проблемы с дележом ресурсов? Потому что при таком подходе проще отследить, кто именно загрузил отдел работой в прошлом, в настоящее время, и в будущем. Это наглядно видно по календарю, а значит с этим можно работать. Менеджеры могут буквально до часов делить ресурсы отдела на следующую неделю и это легко контролируется.
Мы действительно во многом друг друга не понимаем. Как вам удается с точностью до часов распланировать работу команды, но при этом испытывать «неопределенность» по поводу сроков завершения работы «прогрессе»?
Если вы заранее способны предсказать человеко-часы на задачу, что вам мешает посчитать когда закончится задача в прогрессе и команда возьмет сверху стопочки задачу с дедлайном?
Если вы не знаете, сколько времени уйдет на каждую задачу (что ближе к истине), то на чем основывается почасовой план распределения ресурсов? И выдерживается ли он вообще?
Если вы заранее способны предсказать человеко-часы на задачу, что вам мешает посчитать когда закончится задача в прогрессе и команда возьмет сверху стопочки задачу с дедлайном?
Если вы не знаете, сколько времени уйдет на каждую задачу (что ближе к истине), то на чем основывается почасовой план распределения ресурсов? И выдерживается ли он вообще?
Посчитать все задачи в процессе можно, но когда задач много, это неудобно. Всякий раз пересчитывать, прикидывать, успеют или нет… Это непрозрачно.
План по часам в целом выдерживается. Не вижу ничего сверхъестественного в том, что человек способен оценить время, необходимое на работу, тем более что сложные блоки раскладываются на более простые, которые уже и оцениваются. Исследовательские задачи в которых вообще ничего непонятно можно искусственно ограничивать оценкой (т.е., время в таком случае важнее результата). Это даёт управляемость процесса, нет такого, что все люди вдруг заняты, и некому сделать что-то срочное.
В то же время эта система защищает разработчиков от перегруза, когда всем всё надо сделать срочно. Есть план — в нём и разбирайтесь, кому из вас нужнее. Это хорошо влияет на качество.
Естественно, в этой схеме предусмотрены действия, что делать если человек ошибся с оценкой и как максимально безболезненно осуществлять перепланировку.
В целом я не пытаюсь доказать, что такая система однозначно лучше канбана. Она просто лучше в определённых условиях, когда есть много проектов, много задач, требуется быстрое реагирование и соблюдение каких-то локальных сроков.
План по часам в целом выдерживается. Не вижу ничего сверхъестественного в том, что человек способен оценить время, необходимое на работу, тем более что сложные блоки раскладываются на более простые, которые уже и оцениваются. Исследовательские задачи в которых вообще ничего непонятно можно искусственно ограничивать оценкой (т.е., время в таком случае важнее результата). Это даёт управляемость процесса, нет такого, что все люди вдруг заняты, и некому сделать что-то срочное.
В то же время эта система защищает разработчиков от перегруза, когда всем всё надо сделать срочно. Есть план — в нём и разбирайтесь, кому из вас нужнее. Это хорошо влияет на качество.
Естественно, в этой схеме предусмотрены действия, что делать если человек ошибся с оценкой и как максимально безболезненно осуществлять перепланировку.
В целом я не пытаюсь доказать, что такая система однозначно лучше канбана. Она просто лучше в определённых условиях, когда есть много проектов, много задач, требуется быстрое реагирование и соблюдение каких-то локальных сроков.
А как вы вообще можете гарантировать испольнение какой-то задачи в конкрентый день?
Приоритезация и дисциплана — без этого при любом подходе сроки будут продалбываться
Приоритезация и дисциплана — без этого при любом подходе сроки будут продалбываться
Дисциплина — это исполнение правил. Если правила разрешают возить задачу из тестирования в разработку и обратно, в то время, пока в бэклоге лежит срочная задача — то никакая дисциплина не поможет.
а еще есть приоретизация и здравый смысл.
в бизнесе всегда все срочно и важно. если бездумно хватать задачи из беклога — легко оказаться в ситуации когда все почти готово, но из-за «почти» — ничего еще не работает.
в этом плане канбан очень хорошо показывает что «окей, мы сейчас вот эту срочную задачу возьмем, но тогда этунадо одну из этих вернуть в начало». и в этом момент может оказаться, что для бизнеса закончить ту задачу, которую возят из разработки в тестирование — важнее, чем взять в разработку еще одну новую.
в бизнесе всегда все срочно и важно. если бездумно хватать задачи из беклога — легко оказаться в ситуации когда все почти готово, но из-за «почти» — ничего еще не работает.
в этом плане канбан очень хорошо показывает что «окей, мы сейчас вот эту срочную задачу возьмем, но тогда этунадо одну из этих вернуть в начало». и в этом момент может оказаться, что для бизнеса закончить ту задачу, которую возят из разработки в тестирование — важнее, чем взять в разработку еще одну новую.
Так поменяйте правила-то. Договоритесь, например, что задача с дедлайном требует переключить на себя внимание. Вдобавок WIP составной сделайте — 3 обычных и 1 со сроком.
Ошибки поправил.
По поводу того, что любая задача может быть сдвинута — в классическом Kanban такого происходить не должно. Возвращаясь к аналогии с производством автомобилей — производственная станция не может прекратить производство зеркала без существенных потерь времени, поэтому из «in progress» путь в backlog должен быть только один — задача заблокирована и не может быть выполнена.
Правомерность использования термина «методология» применительно к Kanban я планирую рассмотреть в продолжении статьи.
По поводу того, что любая задача может быть сдвинута — в классическом Kanban такого происходить не должно. Возвращаясь к аналогии с производством автомобилей — производственная станция не может прекратить производство зеркала без существенных потерь времени, поэтому из «in progress» путь в backlog должен быть только один — задача заблокирована и не может быть выполнена.
Правомерность использования термина «методология» применительно к Kanban я планирую рассмотреть в продолжении статьи.
Везде пишут, что канбан был придуман для управления manufacturing, в смысле серийным производством, где про выработку каждой отдельной штуковины известно все — время, цена, и качество. Управляемой величиной является объем производства (или заказов наружу) штуковин, необходимых для удовлетворения нужд конвейера.
В процессах разработки (development), примеры из которого приводятся в статье, время, качество и цена штуковин являются сильно переменными величинами. Т.е. ставя задачу Васе сделать формы авторизации и регистрации, вы переживаете совсем не о том, что он сделает 20 форм регистрации, а форм авторизации всего 10, в то время как на конвейере у вас 15 сайтов. Скорее всего это один сайт, одна форма регистрации и одна форма авторизации, а то чем вам приходится управлять — это неопределенность, что же на самом деле сделает Вася, когда, сколько вам это будет стоить. При попытке притянуть сюда канбан, какая-то методология тоже получается, но это уже (имхо) совсем не похоже на канбан. Может просто пример неудачный или я совсем запутался.
В процессах разработки (development), примеры из которого приводятся в статье, время, качество и цена штуковин являются сильно переменными величинами. Т.е. ставя задачу Васе сделать формы авторизации и регистрации, вы переживаете совсем не о том, что он сделает 20 форм регистрации, а форм авторизации всего 10, в то время как на конвейере у вас 15 сайтов. Скорее всего это один сайт, одна форма регистрации и одна форма авторизации, а то чем вам приходится управлять — это неопределенность, что же на самом деле сделает Вася, когда, сколько вам это будет стоить. При попытке притянуть сюда канбан, какая-то методология тоже получается, но это уже (имхо) совсем не похоже на канбан. Может просто пример неудачный или я совсем запутался.
Согласен, пример натянутый. В реальной жизни в данной ситуации возможно более подойдет другая методология. В продолжении я планирую расписать Kanban применяемый на Toyota, «книжный» вариант для разработки ПО, и примеры из реальной жизни, где Kanban пришелся к месту. (В основном — это команды автоматизации тестирования, «обслуживающие» несколько отдельных групп тестирования)
Всё верно.
В командах, разрабатывающих ПО, практика канбана чаще сводится к тому, что это, дескать, очень наглядно: в любой момент видно, как много задач мы сделали, и как много ещё предстоит сделать. Хотя очевидно, что если команда использует хоть что-то похожее на учёт задач, то всё то же самое достигается одним простейшим отчётом.
В командах, разрабатывающих ПО, практика канбана чаще сводится к тому, что это, дескать, очень наглядно: в любой момент видно, как много задач мы сделали, и как много ещё предстоит сделать. Хотя очевидно, что если команда использует хоть что-то похожее на учёт задач, то всё то же самое достигается одним простейшим отчётом.
О как раскритиковали. Давайте теперь посмотрим на канбан с другой стороны. Вообще-то канбан — это бирка-карточка, которая крепится к детали. Движение карточек по сути отражает потребности производства.
Основная идея канбана (производственного) в том, что канбан возвращается по мере необходимости, чем достигается не только избавление от затоваривания ненужным, но и скорость отоваривания нужным. Следует отметить, что поставщики вынуждены затовариваться чтобы соответствовать Тойоте, в то время как она сама работает практически без муды на гембе (без лишнего на площадке). То есть система заказ-поставка перевернута в поставку-заказ.
Почему ИТ-канбан всё-таки канбан (методологией вообще громко что-то называть, неважно канбан это, скрум или даже RUP — все это сборники практик). Представьте себе стандартный усредненный процесс разработки
Это не конвейер, но канбан — карточка — и не требует конвейера, канбан это средство коммуникации в производстве. В чем проблема приведенного процесса? В том что ошибки накапливаются как снежный ком, при переходе с этапа на этап. Самый простой способ это устранить — это возвращать канбан в случае чего его отправителю, то есть сделать его таким
Вот вам и канбан. Благодаря обратным стрелкам заказ-поставка превращается… в поставку-заказ.
Почему ограничивают число задач в работе? Для того, чтобы они всё-таки проходили до конца. Если не ограничивать число задач, то тогда lead time будет непредсказуем — просто потому что задачи могут гулять бесконечно между статусами, всё новые и новые. Конечно, поскольку число задач конечно, процесс выйдет из тупика :) но за какое время — как раз-таки и не предскажешь. А при наличии лимитов lead time более-менее надежен, а его значения — путь к оптимизации (третья «заповедь» ИТ-шного канбана).
Это почему плохо она работает с командами больше 5 человек? Работаем вдесятером по канбану. Чтобы визуализация не захламлялась, как раз лимиты годятся. Это почему плохо она работает с кросс-функциональными командами? Как раз наоборот. Трекается как фича, так и её переходы. Канбан не годится для долгосрочного планирования точно так же как и любой другой agile-процесс, потому что это способ организации процесса. Однако прогнозы на его основе возможны (как и в скраме в том же).
Вобщем не согласен с тем, что канбан — это вспомогающий процесс для очень мелких команд. Канбан — это процесс, который позволяет иметь высокое качество при самых быстрых сроках (в том же скраме например исправления могут уйти только на следующую итерацию, а в канбане — мгновенно). И еще — канбан всем понятен. Ладно, больше не буду уже писать, и так много уже сказал.
Основная идея канбана (производственного) в том, что канбан возвращается по мере необходимости, чем достигается не только избавление от затоваривания ненужным, но и скорость отоваривания нужным. Следует отметить, что поставщики вынуждены затовариваться чтобы соответствовать Тойоте, в то время как она сама работает практически без муды на гембе (без лишнего на площадке). То есть система заказ-поставка перевернута в поставку-заказ.
Почему ИТ-канбан всё-таки канбан (методологией вообще громко что-то называть, неважно канбан это, скрум или даже RUP — все это сборники практик). Представьте себе стандартный усредненный процесс разработки
Сбор требований -> Анализ и проектирование -> Разработка -> Тестирование -> РазвертываниеЭто не конвейер, но канбан — карточка — и не требует конвейера, канбан это средство коммуникации в производстве. В чем проблема приведенного процесса? В том что ошибки накапливаются как снежный ком, при переходе с этапа на этап. Самый простой способ это устранить — это возвращать канбан в случае чего его отправителю, то есть сделать его таким
Сбор требований <--> Анализ и проектирование <--> Разработка <--> Тестирование <--> РазвертываниеВот вам и канбан. Благодаря обратным стрелкам заказ-поставка превращается… в поставку-заказ.
Почему ограничивают число задач в работе? Для того, чтобы они всё-таки проходили до конца. Если не ограничивать число задач, то тогда lead time будет непредсказуем — просто потому что задачи могут гулять бесконечно между статусами, всё новые и новые. Конечно, поскольку число задач конечно, процесс выйдет из тупика :) но за какое время — как раз-таки и не предскажешь. А при наличии лимитов lead time более-менее надежен, а его значения — путь к оптимизации (третья «заповедь» ИТ-шного канбана).
- данная методология плохо работает с большими командами (больше 5 человек);
- в чистом виде, Kanban плохо работает с кросс-функциональными командами. Т.е. в отличие от Scrum, тяжело совместить тестирование и разработку в одной команде. Более удачной мыслью является разбить процесс на «станцию» разработки и «станцию» тестирования с отдельными руководителями и backlog-ами;
- ввиду своей истории и специфики, Kanban не предназначен для долгосрочного планирования
Это почему плохо она работает с командами больше 5 человек? Работаем вдесятером по канбану. Чтобы визуализация не захламлялась, как раз лимиты годятся. Это почему плохо она работает с кросс-функциональными командами? Как раз наоборот. Трекается как фича, так и её переходы. Канбан не годится для долгосрочного планирования точно так же как и любой другой agile-процесс, потому что это способ организации процесса. Однако прогнозы на его основе возможны (как и в скраме в том же).
Вобщем не согласен с тем, что канбан — это вспомогающий процесс для очень мелких команд. Канбан — это процесс, который позволяет иметь высокое качество при самых быстрых сроках (в том же скраме например исправления могут уйти только на следующую итерацию, а в канбане — мгновенно). И еще — канбан всем понятен. Ладно, больше не буду уже писать, и так много уже сказал.
То есть, вы говорите, что главный профит здесь заключается в том, что суммарное количество карточек на всех этапах процесса ограничивается, таким образом, вы не можете окончательно завалить отдельный этап работой, из-за которой всё станет совсем непредсказуемо. Правильно?
То есть, если, например, в приведённой схеме «Сбор требований <--> Анализ и проектирование <--> Разработка <--> Тестирование <--> Развертывание» этап тестирования перегружен, то аналитик не может взять себе новых задач и будет сидеть без дела?
То есть, если, например, в приведённой схеме «Сбор требований <--> Анализ и проектирование <--> Разработка <--> Тестирование <--> Развертывание» этап тестирования перегружен, то аналитик не может взять себе новых задач и будет сидеть без дела?
Где я такое сказал. Профит в том, что карточки ходят туда-сюда, это и наглядно, и контролируется лимитами. Ограничивается вообще-то каждый этап, а не все вместе.
Ну фактически так и будет. Пробка накопится, по цепочке: мы завалим тестирование, потом остановится разработка, потому что она не сможет ничего передать вперёд, потом аналитика, потому что ей тоже некуда передавать задачи вперёд и всё, все сидят и ждут.
Тут ниже уже фактически ответили, я добавлю. Такое может случиться в любом процессе. И при обычном последовательном планировании разработчики тоже могут курить, пока идет тестирование.
Канбан точно так же как и обычный проект нужно организовывать. Если каждая задача будет дефектна, то тут ни канбан, ни что-либо еще не поможет. Если для 10 разработчиков взять 1 тестировщика, то тут ни канбан, ни что-либо еще не поможет.
Чтобы такого не происходило, следует подбирать лимиты не только исходя из скоростей, но и исходя из уровня качества на выходе каждого этапа. Если такое произошло, следует не только поменять лимиты, но и разобраться с технологией — почему столько дефектов, ведь никто управление в случае канбана не отменяет (и уже на основе результатов разборок менять лимиты).
Сами скорости для установки лимитов даже не очень обязательно знать. Важно знать относительные скорости. Например, аналитик разбирается с фичей в два раза быстрее, чем она делается, точно так же и тестирование фичи занимает половину времени разработки. Тогда исходя из количества имеющихся человек можно выставлять лимиты. В случае возврата карт, они будут делаться первыми, так как у них приоритет был изначально выше.
Канбан точно так же как и обычный проект нужно организовывать. Если каждая задача будет дефектна, то тут ни канбан, ни что-либо еще не поможет. Если для 10 разработчиков взять 1 тестировщика, то тут ни канбан, ни что-либо еще не поможет.
Чтобы такого не происходило, следует подбирать лимиты не только исходя из скоростей, но и исходя из уровня качества на выходе каждого этапа. Если такое произошло, следует не только поменять лимиты, но и разобраться с технологией — почему столько дефектов, ведь никто управление в случае канбана не отменяет (и уже на основе результатов разборок менять лимиты).
Сами скорости для установки лимитов даже не очень обязательно знать. Важно знать относительные скорости. Например, аналитик разбирается с фичей в два раза быстрее, чем она делается, точно так же и тестирование фичи занимает половину времени разработки. Тогда исходя из количества имеющихся человек можно выставлять лимиты. В случае возврата карт, они будут делаться первыми, так как у них приоритет был изначально выше.
Именно что без дела. Чтобы вам видно было, где у вас боттлнек, вокруг которого оптимизировать надо.
Это хорошая система на производстве, но в проектах ПО может так оказаться, что в один момент бутылочное горлышко будет на тестировании (делаем что-то, сложное в тестировании), а через месяц уже в разработке.
Поэтому удобнее разделить группы по специализации. Получается своеобразный аналог производственной линии с гибкой связью. К примеру, есть группа разработки, которая производит фичи со скоростью 6 фич в неделю. Эти фичи переходят в группу тестирования, которая тестирует со скоростью 4 фичи в неделю. На выходе «главный конвейер» (к примеру билд-инженеры) ожидают 5 фич в неделю. «Затык» становится сразу очевиден (по каким-то причинам тестирование идет медленнее чем ожидается, а разработка быстрее) и эту проблему можно решить достаточно оперативно.
Я встречал «жесткий» Канбан, в котором состояние «в разработке» разбито на состояния «в разработке», «в тестировании», однако такой подход вносит следующие трудности:
— как задавать «лимит»? для каждого состояния в отдельности, или для всех одинаковый? В любом случае, возможна ситуация что разрабатывать будут быстрее чем тестировать (или тестировать быстрее чем деплоить, и т.д.), что в итоге лишь усложнит процесс управления.
— в идеале, все задачи должны быть разбиты на «равные куски» работы, с каким-то определенным временем на выполнение. И для каждого этапа работы обычно эти куски различные. С возрастанием количества состояний падает прозрачность процесса.
Возможно это субъективные критерии, но мой опыт показал что разделение команд на разные Канбан-доски принесло позитивные изменения.
Любая методология должна прежде всего упрощать процесс разработки, а не поддерживать сама себя. Если какая-то методология не помогает — значит что-то не так :)
Я встречал «жесткий» Канбан, в котором состояние «в разработке» разбито на состояния «в разработке», «в тестировании», однако такой подход вносит следующие трудности:
— как задавать «лимит»? для каждого состояния в отдельности, или для всех одинаковый? В любом случае, возможна ситуация что разрабатывать будут быстрее чем тестировать (или тестировать быстрее чем деплоить, и т.д.), что в итоге лишь усложнит процесс управления.
— в идеале, все задачи должны быть разбиты на «равные куски» работы, с каким-то определенным временем на выполнение. И для каждого этапа работы обычно эти куски различные. С возрастанием количества состояний падает прозрачность процесса.
Возможно это субъективные критерии, но мой опыт показал что разделение команд на разные Канбан-доски принесло позитивные изменения.
Любая методология должна прежде всего упрощать процесс разработки, а не поддерживать сама себя. Если какая-то методология не помогает — значит что-то не так :)
Заведение лишней доски — это создание дополнительного проекта. Это означает, что чтобы фича прошла из бэклога в деплой, необходимо знать два лид тайма, и управлять двумя наборами лимитов. И это не решает вобщем-то вопрос с пробками, пробки могут образовываться и в этом случае так же. Большей управляемости переходом разработка-тестирование (и наоборот) можно достичь и дополнительными статусами. Прозрачность конечно падает при искусственных состояниях, но мы тут рассматриваем какой-то совсем плохой случай — когда команда не справляется. Чтобы команда справлялась, необходим как раз менеджер, который выстроит процесс.
Да, фактически это и есть создание дополнительного проекта. Возможно мое мнение предвзято — я привык работать на больших проектах, которые было бы удобнее «разбить» на несколько поменьше.
По поводу применимости Канбана к большим проектам, возможно все упирается в психологию малых групп — формальная группа численностью более 8 человек стремится к разбиению на две неформальных. Ну или принцип Паркинсона — кабинет численностью более 5 человек теряет эффективность :)
Конечно, это не значит что большой проект нежизнеспособен. Просто с моей точки зрения, управлять двумя небольшими прозрачнее и удобней чем одним большим.
По поводу применимости Канбана к большим проектам, возможно все упирается в психологию малых групп — формальная группа численностью более 8 человек стремится к разбиению на две неформальных. Ну или принцип Паркинсона — кабинет численностью более 5 человек теряет эффективность :)
Конечно, это не значит что большой проект нежизнеспособен. Просто с моей точки зрения, управлять двумя небольшими прозрачнее и удобней чем одним большим.
Ну так это и есть сигнал вам — ваша система несбалансирована для такой сильной вариации задач. Либо вы смиряетесь с этим, увеличив WIP. Либо, если вам важно повысить производительность (а это не всегда самое важное), принимаете меры. В вашем случае — тестировать силами девелопмента при необходимости, например. Automation, все дела.
Если система не сбалансирована для такой вариации задач, почему не выбрать вариант «переработать систему»? Разделение на специализированные команды — один из вариантов, и он работает. Automation не решает проблем тестирования, и в случае если тест повторяется не более 3 раз (примерная эмпирическая цифра), то усилия на автоматизацию могут не окупиться.
Дополнительный пример из жизни это специализированные задачи де-факто, которые не требуют тестирования или девелопмента. Пример для задач которые не требуют девелопмента — интеграционное тестирование с новой версией сервиса, от которого зависит наше приложение. Такая задача «минует» фазу разработки и не будет отвлекать людей от их дел :)
Конечно, этот вариант не единственный. Возможно, специфика проектов, на которых я работал не типична для большинства других проектов. Но пока единственной слабой стороной такого решения мне видится необходимость заведения лишней доски :)
Дополнительный пример из жизни это специализированные задачи де-факто, которые не требуют тестирования или девелопмента. Пример для задач которые не требуют девелопмента — интеграционное тестирование с новой версией сервиса, от которого зависит наше приложение. Такая задача «минует» фазу разработки и не будет отвлекать людей от их дел :)
Конечно, этот вариант не единственный. Возможно, специфика проектов, на которых я работал не типична для большинства других проектов. Но пока единственной слабой стороной такого решения мне видится необходимость заведения лишней доски :)
Тут зависит от того, как поставить процесс «сидения без дела».
Если одно звено плюет в потолок, пока остальные пашут — это одно.
Но ведь всегда есть разные вещи, которые откладыавются потому что на них времени нет.
У тестеров завал? Значит разработчики пока могут технический долг отдать. Или юнит-тесты написать.
Главное принять тот факт, что 100% загрузка всех — это не всегда хорошо
Если одно звено плюет в потолок, пока остальные пашут — это одно.
Но ведь всегда есть разные вещи, которые откладыавются потому что на них времени нет.
У тестеров завал? Значит разработчики пока могут технический долг отдать. Или юнит-тесты написать.
Главное принять тот факт, что 100% загрузка всех — это не всегда хорошо
Воистину.
Это хорошие, правильные рассуждения, но многое зависит от бизнес-модели. Где-то такая вот работа по техническому долгу, рефакторинг, увеличивает издержки по проекту, которые не будут покрыты заказчиком, и это очень печалит менеджеров, которые получают премию за рентабельность :)
на эту тему буквально на днях Максим Дорофеев свой доклад выкладывал.
там очень простой и наглядный пример, где желание менеджера загрузить всю команду на 100% прибыль отрицательной. Поэтому рентабельность надо еще правильно просчитать :)
там очень простой и наглядный пример, где желание менеджера загрузить всю команду на 100% прибыль отрицательной. Поэтому рентабельность надо еще правильно просчитать :)
Это он немного про другое — про утилизацию. А техдолг и рефакторинг вполне можно с некоторым усилием в деньги перевести и позакомить с начальством.
Фактически, когда вы предлагаете занять разработчиков рефакторингом или юнит-тестами — это тоже просто способы занять их на 100%. Вопрос только в том, кто за это заплатит в конечном счёте :)
Хорошая онлайн доска http://leankit.com/
Ограничиваться только Канбаном в управлении командой веб-разработчиков, довольно сложно, и даже рисковано. Хотя, конечно, все зависит от команды.
На мой взгляд он всего лишь один из инструментов, довольно высокоуровневый, предназначенный, в первую очередь, для управления самим процессом «производства» и хорошо подходит для команд, построивших конвеер разработки (например, разработка сайтов на потоке).
На мой взгляд он всего лишь один из инструментов, довольно высокоуровневый, предназначенный, в первую очередь, для управления самим процессом «производства» и хорошо подходит для команд, построивших конвеер разработки (например, разработка сайтов на потоке).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методология Kanban: введение