Кто работает в Kanban проекте?
Хотелось бы узнать, есть ли в Украине (Киеве?..) островки рая? Как полет? Как получилось внедрить?
Хотелось бы узнать, есть ли в Украине (Киеве?..) островки рая? Как полет? Как получилось внедрить?
Мы работали по Канбану, успешно. Просто решили, что Скрам на определенном этапе стал избыточным для нашего проекта, убрали спринты, планирование, вот это все.
Я даже делал доклад на IT-Jam о том, чем Канбан лучше Скрама для maintenance-проектов: www.slideshare.net/...un-using-kanban
для maintenance-проектов
Разве это не так же актуально для любых творческих проектов. А то в скраме получается задача «Найти лекарство от рака, можно ваш эстимейт»?
Разве это не так же актуально для любых творческих проектов. А то в скраме получается задача «Найти лекарство от рака, можно ваш эстимейт»?А вот не надо ставить так задачи. Задачи, не зависимо от методологии или «творчества», должны быть нормально разбиты, а то можно обойтись одной задачей «Сделать все».
Ну, я бы сказал, что зависит от проекта. И в творчестве могут быть эстимейты, особенно если помнить, что в Скраме они не в реальных часах, а просто что-то типа оценки сложности.
Канбан очень прост. Единственное что нужно в нём понимать — в чём разделение функции контроля между системой и человеком.
В этом же и его слабое место. Он прямо-таки просит: «внедрите управление по целям, ведь это так легко». И внедряют, и легко, и убийственно.
Канбан можно внедрять либо в систему управления качеством, либо в систему риск-менеджмента, либо в бюрократическую процедуру которая железобетонно не будет меняться. И не так важно что в итоге канбаном будет покрываться. Важнейший вопрос — куда он пустит корни, и соотвественно у человека с какой ролью окажутся root-права.
При этом важный аспект — root-права ни при каких условиях не должны оказаться у формального руководителя. Иначе это будет инцест — система, а не человек, будет избирать самый лёгкий путь. Наплевав на цели организации. Лишь принося ни с чем не сравнимое спокойствие и иллюзию контроля, а вместе с ними и страх его потерять.
Это всё равно что дать пассажиру порулить такси вместо того чтобы довезти куда ему надо. Формально правильно — дали порулить он доехал, но в реале сами знаете. И если с такси всё очевидно, то с более сложными процессами обязательно найдутся желающие порулить.
Внедряя канбан — нужно понимать, что это дублирующая система. Он не всегда справится с задачей. Примерно как закон не справляется с преступностью — всегда найдутся и те кто возьмёт ситуацию в свои руки. И всегда найдётся ситуация которую закон не решает. Со скрамом фокус не пройдёт — он от природы приспособлен под такие ситуации. А вот с канбаном — как же просто поначалу делать вид что их нет.
Самый ключевой вопрос, даже важнее корня: кто будет иметь право создавать канбаны. И что ему за это будет. И конечно же, кто будет иметь власть таким правом наделять или отбирать. В лучшем случае root. В худшем — будет ликвидирован корень и канбан превратится в катализатор смерти структуры вплоть до развала предприятия. Он в этой роли неимоверно хорош.
Диванная экспертиза это конечно хорошо, но хотелось бы комментариев от людей которые его внедряли, чем руководствовались.
Почему же диванная. Пусть я и не раскрываю где и как применял, но одно время у меня и права на её изменение были. В том числе брейнстормил в экспертной группе.
Почему и говорю — работает. Но палка о двух концах. Канбан всегда против человека. Держа его в руках следует помнить что это концентрат лени. И как наркотик, вызывает зависимость.
Вопрос лидам, насколько подходит канбан для маленькой команды, допустим до 5 человек.
Нужно уточнить, каких 5 человек? Заинтересованых в проекте или которым в тягость?
Сферических в вакууме, допустим возьмем обычных 5 девов, не белок в колесе, но и не совсем лентяев, которые пописали код 8 часов в день, и свалили в
Я досить довго працював (на попередній роботі) на проекті, який ми робили собі, робили, а потім якось прочитали про Канбан і зрозуміли, що десь на 80% ми по ньому і працювали :)
Мы работает в Kanban. Очень удобно. Мы с самого начала его использовали, потому проблем с внедрением не было.
Менеджеры не набежали «Как это мы не будем сидеть на шее и смотреть через плечо программистам? Нам нужен контроль и естимейт!» ?
Менеджеры не набежали «Как это мы не будем сидеть на шее и смотреть через плечо программистам? Нам нужен контроль и естимейт!» ?Хм, всегда думал что канбан как раз упрощает «контроль и естимейт».
Упрощает в разы. Все понимают что их не будет и потому все просто. Но да, меньшее количество одновременных задач все же позволяет что-то предугадывать
Куда ж без них? Вы что, работу делаете и никто не мешает? Не верю
Там как-то столы надо ставить? Вы просто с методиками Valve не путаете? )
У нас 6 состояний задач/багов/фич
QA Review — это задачи, на которые надо расписать тест кейсы, QA распрашивает дополнительную инфу если надо
Planned — задачи, которые запланированы для работы и которые надо обсудить уже разработчикам
In Progress — задачи, которые в работе у разработчика
Completed — задачи готовые для тестирования
In Testing — задачи, которые сейчас тестируют QA
Ready To Merge — задачи, которые готовы для мержинга в develop и деплоя на продакшен.
Врядли это интересовало спрашивающего. Что специфично для Kanban у вас?
Так работают почти все на самом деле, в той или иной вариации.
Что у вас специфичного, опиши в деталях как проходит рабочая неделя.
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів