Комментарии 17
Единственная проблема — замена Kanban на XYZ аргументацию не изменяет. Если хотите реально что-то доказать — берёте статистику публичных компаний, которые применяют Kanban и которые не применяют и смотрите кто больше денег зарабатывает.
> кто больше денег зарабатывает.
только при том (нереальном) условии, что компании в полностью идентичных условиях. Включая работающих людей, которые одинаково умные, трудолюбивые и т.д.
только при том (нереальном) условии, что компании в полностью идентичных условиях. Включая работающих людей, которые одинаково умные, трудолюбивые и т.д.
Обычно при применении любых подходов, такое сравнение компаний не корректно. Потому что они могут расти вопреки применения каких либо методов. Яркое отличие Канбан от трансформационных моделей, как раз в том, что не возникает пропасть потери производительности и всегда можно откатиться назад.
Опять же — в вашем комментарии можно Канбан заменить на XYZ и ничего не изменится. Если бы вы предложили какую-то модель процесса, а затем показали, что
- Модель описывает широкий класс процессов.
- Альтернативные модели ей не противоречат. То есть нельзя предложить другую модель, которая также хорошо согласуется с реальностью, но приводит к противоположным выводам.
- Канбан, в рамках этой модели является в некотором смысле оптимальным.
Вот тогда дифирамбы Канбану были бы обоснованы. У меня же возникает ощущение, что процесс просто должен быть, а какой процесс не важно. Это согласуется с моими наблюдениями, а также с chaos report который также не находит существенной корреляции между процессом и успехом проекта.
Давайте будем сравнивать подходы тогда. Хотя этого хотелось бы избежать.
Например Scrum, LeSS, SAFE нельзя у себя запустить без перестроения орг структуры компании. Обычно запуски этих подходов всегда характеризуются так называемым «Flip», когда вы после некоторых активностей в понедельник начинаете жить по другому. У вас появляются новые роли, новые активности, новые системы координат. По большому счету вы должны забыть о том что было вчера и начать жить с нового листа веря в светлое будующее.
Очень часто за такими событиями начинается волна сопротивления людей и куча статей и материалов описывает как надо бороться и переживать это сопротивление.
Канбан идет эволюционным путем. Что качественно отличается. Он не требует «Flip» и ярко показывает — не меняйте текущую систему ролей и не вводите новые активности.
В этом самое главное отличие.
Например Scrum, LeSS, SAFE нельзя у себя запустить без перестроения орг структуры компании. Обычно запуски этих подходов всегда характеризуются так называемым «Flip», когда вы после некоторых активностей в понедельник начинаете жить по другому. У вас появляются новые роли, новые активности, новые системы координат. По большому счету вы должны забыть о том что было вчера и начать жить с нового листа веря в светлое будующее.
Очень часто за такими событиями начинается волна сопротивления людей и куча статей и материалов описывает как надо бороться и переживать это сопротивление.
Канбан идет эволюционным путем. Что качественно отличается. Он не требует «Flip» и ярко показывает — не меняйте текущую систему ролей и не вводите новые активности.
В этом самое главное отличие.
Например Scrum, LeSS, SAFE нельзя у себя запустить без перестроения орг структуры компании.
Можно, причем каждый из этих процессов, а также все вообще процессы в истории, предполагают постепенное внедрение, без всяких там перестроений орг. структуры на старте. Спросите любого консультанта по Scrum и он вам все ушы прожужжит о том, как классно Scrum внедряется без всяких перестроений, так что оооооп! и уже scrum, даже удивиться не успеете.
Можно я вначале уточню, а потом дам комментарий. Расскажите пожалуйста процедуру как у вас оооп и Scrum? Какая последовательность действий. Например я руководитель отдела разработки в небольшой компании (100 человек) и руковожу всей разработкой.
Disclaimer — Я не занимаюсь Scrum и его не использую.
Вот одна из первых ссылок в гугле — www.williamspublishing.com/PDF/978-5-8459-1731-7/part.pdf Цитата
Вот еще — leadstartup.ru/db/agile-transformation-issue
Вот еще одно, оформленно как исследование — www.researchgate.net/publication/261861292_Growing_into_Agility_Process_Implementation_Paths_for_Scrum Там даже картинка есть.
Покопавшись немного я могу подобного нарыть для любого процесса. И все будут gradual implementation, avoid disruption, positive transformation, continuous improvement и прочая. Все эти buzzwords без каких-либо обоснований звучат примерно с начала 20 века. Хотя к чести наших прадедов, «научная организация труда» хотя бы пыталась подвести эксперимент. Но, кажется, к 60м консультантам надоело искать истину, но захотелось бабла быстро и сейчас и понеслась.
Вот одна из первых ссылок в гугле — www.williamspublishing.com/PDF/978-5-8459-1731-7/part.pdf Цитата
Постепенный переход к использованию Scrum можно выполнить без реорганиза- ции
Вот еще — leadstartup.ru/db/agile-transformation-issue
Как правильно внедрить Agile
Любая аджайл–трансформация должна быть комплексной и постепенной. Она затрагивает стратегию, структуру, людей, процессы и технологию. Нужны постепенность и итерационность, потому что не всё может быть спланировано заранее.
Вот еще одно, оформленно как исследование — www.researchgate.net/publication/261861292_Growing_into_Agility_Process_Implementation_Paths_for_Scrum Там даже картинка есть.
Покопавшись немного я могу подобного нарыть для любого процесса. И все будут gradual implementation, avoid disruption, positive transformation, continuous improvement и прочая. Все эти buzzwords без каких-либо обоснований звучат примерно с начала 20 века. Хотя к чести наших прадедов, «научная организация труда» хотя бы пыталась подвести эксперимент. Но, кажется, к 60м консультантам надоело искать истину, но захотелось бабла быстро и сейчас и понеслась.
В статье так и не дали ответ на то, что декламировалось в заголовке. А было так интригующе…
Для начала стоит сказать, что это лишь первая статья серии. Попробую выжимку сухую из статьи дать в нескольких предложениях. Ответ есть, но может быть немного размазан по тексту.
Экономический плюс в том, что вы экономите на менеджменте и количестве координационных затрат. И чем больше у вас компания, тем больше эти суммы. Второй пласт доходов заключается в более быстрой скорости возврата инвестиций — выгода начинает накапливаться и расти быстрее.
Экономический плюс в том, что вы экономите на менеджменте и количестве координационных затрат. И чем больше у вас компания, тем больше эти суммы. Второй пласт доходов заключается в более быстрой скорости возврата инвестиций — выгода начинает накапливаться и расти быстрее.
>чем больше у вас компания, тем больше эти суммы
А можно пруф? И было бы очень интересно понять, каким образом он получен.
Вот я скажем спрашивал, какой эффект в моей компании получен от внедрения agile. Ответ был примерно такой — мы получили сокращение time to market, причем значительное. При почти столь же значительном одновременном росте затрат. Ну т.е. да, быстрее внедрять получается, а вот чтобы еще и дешевле — вообще нифига (что меня лично нисколько не удивляет, потому что обмануть природу нельзя).
Так что я бы сказал, что подобные обобщения на всех — вообще маркетинговый буллшит, не более. Как это обычно и бывает.
А можно пруф? И было бы очень интересно понять, каким образом он получен.
Вот я скажем спрашивал, какой эффект в моей компании получен от внедрения agile. Ответ был примерно такой — мы получили сокращение time to market, причем значительное. При почти столь же значительном одновременном росте затрат. Ну т.е. да, быстрее внедрять получается, а вот чтобы еще и дешевле — вообще нифига (что меня лично нисколько не удивляет, потому что обмануть природу нельзя).
Так что я бы сказал, что подобные обобщения на всех — вообще маркетинговый буллшит, не более. Как это обычно и бывает.
Канбан метод, это совсем не про Agile. И это очень частое заблуждение. Канбан не требует введения новых ролей (таких как Scrum master, Product Owner, RTE ....). Чем больше компания, тем больше управленцев и координирующих деятельность ролей — те, которые занимаются стыковкой между подразделениями и людьми. Пруфа нет, но давайте посчитаем на пальцах. Если мы используем Scrum, то у нас на 9 человек команды разработки нужно как минимум 2 дополнительные роли. Допустим что на 2 команды 2 человека совмещают эти роли. У нас например 50 команд. Значит что 25 новых человек, которых чаще всего в компании нет нужно нанять. С ростом количества команд так же возникают директора по направлениями, тимлиды, руководители технологий определенных и так далее. Вот и происходит рост менеджмента.
Используя Канбан, вам не требуется нанимать людей в новые роли — вы прокачиваете менеджерские скилы у имеющихся руководителей. Так же вы не ограничены ограничением в 9 человек, потому что вы управляете потоком рабочих элементов, для упрощения назовем их задачами. Через применения инструментов и практик вы получаете короткие каденции для синхронихации, предсказуемую поставку этих задач и увеличение количества выпускаемых задач в единицу времени. Это вполне конкретные цифры, которые можно считать. Каждая задача несет некоторый доход.
Используя Канбан, вам не требуется нанимать людей в новые роли — вы прокачиваете менеджерские скилы у имеющихся руководителей. Так же вы не ограничены ограничением в 9 человек, потому что вы управляете потоком рабочих элементов, для упрощения назовем их задачами. Через применения инструментов и практик вы получаете короткие каденции для синхронихации, предсказуемую поставку этих задач и увеличение количества выпускаемых задач в единицу времени. Это вполне конкретные цифры, которые можно считать. Каждая задача несет некоторый доход.
>Канбан метод, это совсем не про Agile.
А я и не говорил что они идентичны. Я лишь сказал, что известный мне опыт внедрения других «похожих» методик дает вполне объяснимые результаты — т.е. баланс между сроками, стоимостью и качеством вполне себе соблюдается, или сдвигается в предсказуемую сторону. И никогда не сдвигается так, чтобы одновременно улучшалось скажем качество и цена и сроки. Не бывает тут чудес, никогда.
>вы прокачиваете менеджерские скилы у имеющихся руководителей
Кхм. Ну вот давайте посмотрим на меня. Я разработчик, но последние полгода складывается так, что я еще и выполняю роль PO. Вы можете называть это словами «прокачивать мои менеджерские скилы» — но по факту это означает, что я меньше времени имею на то, чтобы разрабатывать код и продумывать его архитектуру, и больше на всякую административную ерунду, которая сопровождает новую дополнительную роль. И ничего хорошего из этого не вытекает вообще.
Тот факт, что в некоторых сложных проектах можно обойтись без людей, которые бы все координировали, у меня вообще вызывает серьезные сомнения.
В общем, я не хочу сказать, что тут вообще все ерунда в статье у вас написана, ни в коем случае. Я лишь хочу сказать, что как правило все чуть сложнее. И зависит от того, что у вас за проекты вообще.
А я и не говорил что они идентичны. Я лишь сказал, что известный мне опыт внедрения других «похожих» методик дает вполне объяснимые результаты — т.е. баланс между сроками, стоимостью и качеством вполне себе соблюдается, или сдвигается в предсказуемую сторону. И никогда не сдвигается так, чтобы одновременно улучшалось скажем качество и цена и сроки. Не бывает тут чудес, никогда.
>вы прокачиваете менеджерские скилы у имеющихся руководителей
Кхм. Ну вот давайте посмотрим на меня. Я разработчик, но последние полгода складывается так, что я еще и выполняю роль PO. Вы можете называть это словами «прокачивать мои менеджерские скилы» — но по факту это означает, что я меньше времени имею на то, чтобы разрабатывать код и продумывать его архитектуру, и больше на всякую административную ерунду, которая сопровождает новую дополнительную роль. И ничего хорошего из этого не вытекает вообще.
Тот факт, что в некоторых сложных проектах можно обойтись без людей, которые бы все координировали, у меня вообще вызывает серьезные сомнения.
В общем, я не хочу сказать, что тут вообще все ерунда в статье у вас написана, ни в коем случае. Я лишь хочу сказать, что как правило все чуть сложнее. И зависит от того, что у вас за проекты вообще.
Канбан метод, это совсем не про Agile.
Он есть в Waterfall, в RUP или в иных процессных методологиях? Или может это в чистом виде предельный случай Agile, когда итерация совпадает с User Story?
Если мы используем Scrum, то у нас на 9 человек команды разработки нужно как минимум 2 дополнительные роли.
Не появляются две дополнительные роли. Две традиционные роли трансформируются в две новые роли. Руководитель проекта/продукта/бизнес-аналитик становится Product Owner, а тимлид — Scrum master.
Про обман с заголовком здесь уже писали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рентабельность инвестиций в Канбан. Часть 1