Комментарии 10
Проблема в том, что все эти примеры с автомобильным движением, пробками, командами типа "Газмяс" и прочее оторваны от реальных программных проектов. Серьёзно любую методологию управления проектами можно обсуждать только после того, как она опробована в жизни на реальном проекте.
При таком обсуждении интересуют не общие слова о ценностях и не формальная схема типа "потока работ" — это может быть интересно разве что студентам, а не профессионалам, поучаствовавшим в десятках проектах. Интересна специфика, которая может свидетельствовать как за, так и — главное — против обсуждаемой методологии ведения проектов.
К таким специфичным деталям относятся информация о продукте, сложность проекта, время проекта, размер команды, междисциплинарное взаимодействие (сколько и каких специалистов было задействовано на проекте, как они взаимодействовали). Например, при создании видеоигры в работе над проектом участвуют люди совершенно разных специальностей: программисты, продюсеры, гейм-дизайнеры, моделлеры, аниматоры, 2Д-художники, технические аниматоры, аудиодизайнеры, инженеры по качеству и т.д. и т.п. Специальностей будет больше, чем при создании бизнес-софта. Как построено взаимодействие между этими людьми? Как они находят общий язык между собою? Как методология помогает в этом?
А примеры с дорожным движением — это для детей.
При таком обсуждении интересуют не общие слова о ценностях и не формальная схема типа "потока работ" — это может быть интересно разве что студентам, а не профессионалам, поучаствовавшим в десятках проектах. Интересна специфика, которая может свидетельствовать как за, так и — главное — против обсуждаемой методологии ведения проектов.
К таким специфичным деталям относятся информация о продукте, сложность проекта, время проекта, размер команды, междисциплинарное взаимодействие (сколько и каких специалистов было задействовано на проекте, как они взаимодействовали). Например, при создании видеоигры в работе над проектом участвуют люди совершенно разных специальностей: программисты, продюсеры, гейм-дизайнеры, моделлеры, аниматоры, 2Д-художники, технические аниматоры, аудиодизайнеры, инженеры по качеству и т.д. и т.п. Специальностей будет больше, чем при создании бизнес-софта. Как построено взаимодействие между этими людьми? Как они находят общий язык между собою? Как методология помогает в этом?
А примеры с дорожным движением — это для детей.
2 день обучения был практически полностью посвящен разбору реальных примеров компаний, в которых работают участники тренинга. На том тренинге, где побывал я, в одной группе разбирался пример одной известной интернет-компании с участием самого генерального директора этой компании, а в другой группе — пример одного прогрессивного государственного ведомства. Примеры реальные и масштабные. По разумеющимся причинам приводить детальное описание этой части тренинга я не могу.
А про эффективность наглядных примеров как для детей, так и для профессионалов с 10 проектами за плечами, хорошо сын божий сказал:
А про эффективность наглядных примеров как для детей, так и для профессионалов с 10 проектами за плечами, хорошо сын божий сказал:
В тот день, выйдя из дома, Иисус сидел у моря. И собралось к нему великое множество людей, так что он вошёл в лодку и сел, а весь народ стоял на берегу. И рассказывал им многое в наглядных примерах, говоря: "Вот, вышел сеятель сеять..." Тогда подошли к нему ученики и сказали: "Почему ты говоришь с ними наглядными примерами?" В ответ он сказал: "Вам дано понимать священные тайны небесного царства, а им не дано. Ибо тому, кто имеет, будет дано больше, и будет у него изобилие, а у того, кто не имеет, будет отнято даже то, что он имеет. Потому и говорю с ними наглядными примерами, что они, глядя, смотрят впустую, и, слыша, слышат впустую, и не постигают смысла. И на них исполняется пророчество Исаии, которое гласит: "Слыша, услышите, но не постигнете смысла, и, глядя, будете смотреть, но не увидите".;-)
© От Матфея, стих 13
Но порог вхождения у Канбан ниже? Ведь его начинают применять вместе с разработчиками и другие подразделения компаний…
Спорное заявление, учитывая что в разработку Канбан пришел из производства. Для разъяснения не нужно даже выдумывать примеры: ящики с бирками (собственно «канбанами») на производственных участках Toyota отлично это иллюстрируют.
Спорное заявление, учитывая что в разработку Канбан пришел из производства. Для разъяснения не нужно даже выдумывать примеры: ящики с бирками (собственно «канбанами») на производственных участках Toyota отлично это иллюстрируют.
На заводах концерна Тойота используется Toyota Production System (производственная система Тойота), а вовсе не канбан в том виде, в котором его пытаются поженить с ИТ-отраслью. Использование же общего названия "канбан" ни о какой похожести систем менеджмента не говорит.
Следует также понимать, что Toyota Production System разработана для массового или крупносерийного производства, а разработка программного обеспечения — это даже не мелкосерийное, а штучная разработка (часто на заказ).
Следует также понимать, что Toyota Production System разработана для массового или крупносерийного производства, а разработка программного обеспечения — это даже не мелкосерийное, а штучная разработка (часто на заказ).
Какая разница. Можно еще больше указать различий между автомобилем и ПО, но это все дальше уводит от сути.
Общее название и призвано указать на общую суть.
Естественно есть различия, но цель одна — оптимизировать работу потока.
И бесполезно слушать тренеров, какими бы они не были гуру, пока суть всего этого не понятна.
Тот же Голдратт упоминается в статье, во всех своих книгах он говорит о том, что нужно упрощать и доходить до сути, но нет, мы смотрим на то что отличается игнорируя общее...
Общее название и призвано указать на общую суть.
Естественно есть различия, но цель одна — оптимизировать работу потока.
И бесполезно слушать тренеров, какими бы они не были гуру, пока суть всего этого не понятна.
Тот же Голдратт упоминается в статье, во всех своих книгах он говорит о том, что нужно упрощать и доходить до сути, но нет, мы смотрим на то что отличается игнорируя общее...
Весьма занятная статья. В рамках этой статьи я бы хотел поднять пару действтиельно интересных для меня вопросов.
Вместо предисловия:
… есть владелец продукта и Скрам-мастер, прилежно проводятся встречи, есть спринты. Но при этом нарушают основополагающие принципы эмпиризма: прозрачность… и т.д.
Это означает только то, что у команды не внедрён scrum и команда не понимает базовых принципов agile (http://www.agilemanifesto.org/). И Kanban не будет серебряной пулей в этом случае. Бардака будет даже больше.
Дальше больше.
Как правильно отметил топикстартер, Kanban — это пара принципов и 4 правила. Четвёртое — придумайте свои правила сами.
И вот тут-то и начинается всё самое интересное.
Meetings? В Kanban нет ни слова о том, что нужно проводить Retro, Daily Standup и т.д. Но, если мы обратимся к Agile-практикам, то мы увидим, что практика проведения данных мероприятий рекомендована для всех команд, которые практикуют Agile.
Таким образом, внедрять Kanban не имея хорошего бэкграунда и понимая принципов и всей базы Agile и проектного управления — не стоит.
Kanban не предполагает оценки задач. Простите, но как же тогда отслеживать control flow — график же будет неравномерным из-за разброса стоимости задачи!
«Приведи их к одному размеру, Люк» — лышен нам голос из зала. Но, подождите, ведь практика scrum нам говорит о том, что задачи с разной оценкой всё-равно будут. А если резать крупные задачи на ещё более мелкие, то как мы в итоге соберём нужную функциональность — у нас увеличивается плотность потока, но снижается % законченности задачи. Непорядок.
«Введи оценку в SP» — говорит тот, что постарше. И, да, в его словах есть смысл. Оценка действительно решает многие проблемы с Control flow, но нужно быть готовым к тому, что поток начнёт двигаться неравномерно — ряд задач будут проскакивать быстро, а другие будут ползти очень медленно.
Таким образом, внедрять Kanban с командой, которая не умеет отлично оценивать — гиблое дело.
Wrong way, задача!
Kanban — прекрасный процесс, если он движется в одном направлении. Но что делать, если задача должна вернуться назад? Например, на этапе QA найдены ошибки и задача должна вернуться назад в разработку?
«DevOps — и нет проблем!» — слышен бодрый голос из зала. Да, и это прекрасный выход! Таким образом процесс у нас всегда будет идти в одном направлении, теоретически… Но, подождите, почему у нас DevOPS-команда такая же большая, как и команда основной разработки? Где, чёрт возьми, оптимизация?
«Используй тесты, Люк» — говорит седовласый участник дискуссии. Да, это действительно поможет сократить количество задач, которые будут возвращаться. Не исключить, но существенно сократить, при условии, что культура написания тестов хорошо развита.
Остаётся открытым вопрос как организовать процесс таким образом, чтобы задачи не возвращались. Т.к. любое движение назад — это всегда заваливание WIP-Limits причём сразу нескольких этапов — того, на который вернули, предыдущего, т.к. на него вернут те задачи, которые разрабы отложат, чтобы решить вернувшуюся.
В итоге, стройный Kanban-ряд будет сломан.
Таким образом, Kanban очень сильно подвержен порождению хаоса в случае возврата задачи на предыдущие этапы. Переброс «свободных специалистов» (например, разработчиков в помощь тестерам) — не решает проблему в комплексе т.к., как мы выяснили на этапе 1, поток движется неравномерно и лимиты будет очень сложно спрогнозировать.
Expedite за Expedit'ом. И вот мы подошли к самой интересной части. Мы имеем — заваливаемые этапы работы из-за возвращения задач и неравномерную скорость движения потока из-за разного объёма задач. В итоге, наш Backlog может начать плавать — из-за того, что в работе находятся большие задачи и нет возможности взять ещё одну большую. И, как результат, начинают появляться Blocker — задачи «ну они же маленькие», которые ещё больше заваливают основной процесс. В итоге, может появиться задачи, которые залипнут на доске очень и очень долго.
Подытожим.
Kanban — это сложная методология, которая в процессе внедрения потребует намного больше знаний и мотивации у команды, чем Scrum. Маловероятно, что получится внедрить Kanban на мало-мальски технически сложном проекте, если команда недостаточно зрелая.
«А зачем нам вообще Kanban, Зин?» — спросит читатель.
На самом деле, Kanban — это отличная практика, если вы хотите построить у себя CI.
Но, поскольку Continious Integration — достаточно сложная инжинерная практика, то и сам Kanban выходит непростым.
Я бы расставил этапы зрелости команды в таком порядке:
code and fix, waterfall, code and fix, scrum, scrumban, #noestimates.
А статья, конечно, замечательная… Вот только ответов на ключевые вопросы в ней нет.
Вместо предисловия:
… есть владелец продукта и Скрам-мастер, прилежно проводятся встречи, есть спринты. Но при этом нарушают основополагающие принципы эмпиризма: прозрачность… и т.д.
Это означает только то, что у команды не внедрён scrum и команда не понимает базовых принципов agile (http://www.agilemanifesto.org/). И Kanban не будет серебряной пулей в этом случае. Бардака будет даже больше.
Дальше больше.
Как правильно отметил топикстартер, Kanban — это пара принципов и 4 правила. Четвёртое — придумайте свои правила сами.
И вот тут-то и начинается всё самое интересное.
Meetings? В Kanban нет ни слова о том, что нужно проводить Retro, Daily Standup и т.д. Но, если мы обратимся к Agile-практикам, то мы увидим, что практика проведения данных мероприятий рекомендована для всех команд, которые практикуют Agile.
Таким образом, внедрять Kanban не имея хорошего бэкграунда и понимая принципов и всей базы Agile и проектного управления — не стоит.
Kanban не предполагает оценки задач. Простите, но как же тогда отслеживать control flow — график же будет неравномерным из-за разброса стоимости задачи!
«Приведи их к одному размеру, Люк» — лышен нам голос из зала. Но, подождите, ведь практика scrum нам говорит о том, что задачи с разной оценкой всё-равно будут. А если резать крупные задачи на ещё более мелкие, то как мы в итоге соберём нужную функциональность — у нас увеличивается плотность потока, но снижается % законченности задачи. Непорядок.
«Введи оценку в SP» — говорит тот, что постарше. И, да, в его словах есть смысл. Оценка действительно решает многие проблемы с Control flow, но нужно быть готовым к тому, что поток начнёт двигаться неравномерно — ряд задач будут проскакивать быстро, а другие будут ползти очень медленно.
Таким образом, внедрять Kanban с командой, которая не умеет отлично оценивать — гиблое дело.
Wrong way, задача!
Kanban — прекрасный процесс, если он движется в одном направлении. Но что делать, если задача должна вернуться назад? Например, на этапе QA найдены ошибки и задача должна вернуться назад в разработку?
«DevOps — и нет проблем!» — слышен бодрый голос из зала. Да, и это прекрасный выход! Таким образом процесс у нас всегда будет идти в одном направлении, теоретически… Но, подождите, почему у нас DevOPS-команда такая же большая, как и команда основной разработки? Где, чёрт возьми, оптимизация?
«Используй тесты, Люк» — говорит седовласый участник дискуссии. Да, это действительно поможет сократить количество задач, которые будут возвращаться. Не исключить, но существенно сократить, при условии, что культура написания тестов хорошо развита.
Остаётся открытым вопрос как организовать процесс таким образом, чтобы задачи не возвращались. Т.к. любое движение назад — это всегда заваливание WIP-Limits причём сразу нескольких этапов — того, на который вернули, предыдущего, т.к. на него вернут те задачи, которые разрабы отложат, чтобы решить вернувшуюся.
В итоге, стройный Kanban-ряд будет сломан.
Таким образом, Kanban очень сильно подвержен порождению хаоса в случае возврата задачи на предыдущие этапы. Переброс «свободных специалистов» (например, разработчиков в помощь тестерам) — не решает проблему в комплексе т.к., как мы выяснили на этапе 1, поток движется неравномерно и лимиты будет очень сложно спрогнозировать.
Expedite за Expedit'ом. И вот мы подошли к самой интересной части. Мы имеем — заваливаемые этапы работы из-за возвращения задач и неравномерную скорость движения потока из-за разного объёма задач. В итоге, наш Backlog может начать плавать — из-за того, что в работе находятся большие задачи и нет возможности взять ещё одну большую. И, как результат, начинают появляться Blocker — задачи «ну они же маленькие», которые ещё больше заваливают основной процесс. В итоге, может появиться задачи, которые залипнут на доске очень и очень долго.
Подытожим.
Kanban — это сложная методология, которая в процессе внедрения потребует намного больше знаний и мотивации у команды, чем Scrum. Маловероятно, что получится внедрить Kanban на мало-мальски технически сложном проекте, если команда недостаточно зрелая.
«А зачем нам вообще Kanban, Зин?» — спросит читатель.
На самом деле, Kanban — это отличная практика, если вы хотите построить у себя CI.
Но, поскольку Continious Integration — достаточно сложная инжинерная практика, то и сам Kanban выходит непростым.
Я бы расставил этапы зрелости команды в таком порядке:
code and fix, waterfall, code and fix, scrum, scrumban, #noestimates.
А статья, конечно, замечательная… Вот только ответов на ключевые вопросы в ней нет.
Все верно, но задачи по Кабан-доске могут двигаться только вперед. Это основа вытягивающей системы задач, вместо проталкивающей. Задача из столбца тестирования не возвращается обратно, вместо этого разработчики подключаются к этой задаче, переключаясь с задач в столбце разработка. Столбцы доски описывают стадию задачи, но не являются разграничением зон ответственности функциональных специалистов.
А так, да, чаще всего вначале внедряется, так называемый, прото-Канбан.
В задачи этой заметки, конечно, не входило рассмотрение всех вопросов теории Кабан.
А так, да, чаще всего вначале внедряется, так называемый, прото-Канбан.
В задачи этой заметки, конечно, не входило рассмотрение всех вопросов теории Кабан.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Теория, игра и практика Канбан — Certified Kanban/Lean Training