Как стать автором
Обновить

Работа в состоянии потока: как Канбан-метод делает разработку быстрее, умнее и эффективнее

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров6.1K
Всего голосов 20: ↑8 и ↓12-2
Комментарии6
6

Комментарии 6

Среди подходов Agile канбан менее известен, чем вездесущий Scrum.

А можно уточнить, менее известен кому именно? Людям, которые провели последние 15 лет в коме и только очнулись? Попаданцам из 19 века и параллельных миров? На носу 2025 год, а вы всё ещё делаете вид, что Канбан -- это какая-то свежая и неизведанная практика. Свежей и неизведанной она была примерно 10 лет назад, а то и раньше.

По данным опроса компании Scrumtrek, практики Канбан-метода чаще всего используется параллельно со Scrum.

Было бы довольно странно, если бы компания, у которой слово Scrum буквально в названии, провела опрос и не нашла использования Scrum. Логично предположить, что они опрашивали таких же Scrum-сектантов, как и они сами. Репрезентативность выборки? Не, не слышали.

Исследование организации Kanban University показало следующие результаты применения метода: 76% респондентов заявили, что Канбан был более эффективен

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

Все эти "методологии" типа Scrum, Agile и Kanban обещают золотые горы, а в реальной жизни разбиваются о скалы суровой реальности:

В теории они должны внедряться для улучшения эффективности и тому подобных идеалистических целей. На практике они насаждаются менеджерами проектов из-за феномена, известного как FOMO (Fear of Missing Out -- в русскоязычной литературе используются такие термины, как "Синдром упущенной выгоды", "Страх упущенных возможностей" и т.п.): проще говоря, эти практики стильные, модные, молодёжные, а менеджер проекта тоже хочет себе в резюме написать, что он в эти практики умеет и даже внедрил их в коллективе австралопитеков, пишущих код на каменных клавиатурах по методогии Waterfall.

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

Я уже высказывал этот тезис в комментариях к другой статье, но повторю его здесь ещё раз: все эти практики (Agile, Scrum, Kanban и всякого рода вариации на их тему) сейчас стали де-факто стандартом в индустрии, трудно найти организацию, которая их не использует. И по удивительному совпадению именно на волне повального их внедрения индустрия оказалась в глубоком кризисе -- но это так, просто к размышлению.

Полностью разделяю сказанное. В своей практике применение этих методов свидетельствует лишь о потере контроля управленцами над процессом и отсутствие ответственности за решения.

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

Нуу и тут хотел написать ещё строк десять, но в целом понятно, что в предмете ты не особо разбираешься, зачем тратить время.

Последний абзац интересный, просишь пруфы у автора, на приведенные выводы и сам их не приводишь. Про кризис в индустрии какой-то, ещё и связываешь этт. В общем не понятно что к чему.

Пишешь, вроде интересно, но не правильно, грустно, но есть куда расти)

подбора рерсонала

Ну вот как, как могут в выстраданную статью попадать отлавливаемые любым автокорректором опечатки?

Как видим, легко )

Общей информацией про Канбан уже мало кого можно удивить, мы лет 15 уже вокруг доски так или иначе крутимся.

Но в этом вопросе интересно было бы услышать больше о вашей практике. Как именно вы используете Канбан, как декомпозируете, оцениваете и приоритизируете задачи, что делаете в случае со срочной переприоритизацией, что делаете с крупными и вялотекущими задачами, как следите за зависимостями в задачах, что делаете в случае потери исполнителя, как выстраиваете работу со связанными задачами , которые распределены на разные команды и т.д. Может раскроете больше реальной практики?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий