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

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

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров9.6K
Всего голосов 25: ↑12 и ↓13+1
Комментарии9

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

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

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

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

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

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

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

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

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

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

Не тратьте, проходите мимо.

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

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

В общем не понятно что к чему.

А вы попробуйте читать внимательно.

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

Это просто вы невнимательно читаете. Ничего страшного, подрастёте -- научитесь.

Я ни Scrum, ни Kanban методологиями не считаю (в отличие от автора статьи), и слово "методология" применительно к ним использую только в кавычках. Scrum является ничем иным, как религиозным верованием

Авто как бы то же не считает :)
Автор, четко написал что скрам это фреймворк, то есть либо методика, либо часть методики.
А канбан это метод, штука для построения методики.
Про методологию вообще речи не шло

Про методологию вообще речи не шло

Буквально во втором параграфе статьи читаем: "Обратите внимание на методологию Канбан".

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

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

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

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

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

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