Автор: Илья Павличенко.
Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.
Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
Определение Канбана.
Формальное определение этого метода можно найти в уже ставшей классикой книге Дэвида Андерсона «Kanban». Метод состоит всего лишь из пяти правил и не является методологией или Фреймворком. Я уже писал об этом в своем блог-посте «Канбан как НЕ процесс, НЕ методология, НЕ фреймворк».
Вы не можете работать в чистом «Канбане». Это просто не возможно! Большое количество компаний и команд обманывают себя, считая, что они работают в Канбане. Привожу несколько цитат от самого автора:
Вы можете работать в «старом добром» Водопадном процессе и при этом успешно пользоваться Канбаном. Одно другому не противоречит. За это на Канбан обрушивается большой поток критики со стороны Аджайл сообщества. Многие даже не считают его частью Аджайла. Канбан является техникой ограничения работы в процессе (WIP), которую можно «натянуть» на любой уже существующий в команде процесс.
Скрамбан является полноценным Скрамом, внутри которого применяется техника Канбана. Один из главных идеологов Канбана и Лина – Кори Ладас издал замечательную книгу «Scrumban». В ней он указал на слабые места Скрама и показал, каким образом, добавив Канбан, можно повысить продуктивность команды и оптимизировать поток внутри Спринта. Формула Скрамбана следующая: Scrumban = Scrum + Kanban
Глядя на формулу, становится понятно, что у команды должен быть внедрен полнофункциональный Скрам и в дополнение «навешен» Канбан. Такое сочетание является очень эффективным. Типичная СкрамБан команда использует полноценный Скрам и доску для визуализации своей работы с явно проставленными ограничениями на работу (иначе это не Канбан) в прогрессе. Зачем это нужно?
Давайте представим, что Скрам команда начала работать над ВСЕМИ элементами Беклога Спринта в первый же день сразу после планирования. Иначе выражаясь, все элементы Спринт Беклога «поехали» одновременно. Формально это никаким образом не нарушает правила Скрама. Действительно, Скрам не разъясняет, каким образом команда разработки должна доставлять выбранный на планировании функционал. Спринт - это черный ящик, в котором не видно, что происходит. На входе такого ящика – Спринт Беклог и Цель Спринта, а на выходе – Инкремент продукта (Potentially Shippable Product Increment).
Естественно, что иметь такое большое количество работы в прогрессе, не является оптимальным подходом. Это одна из многих причин, почему многие Скрам команды из Спринта в Спринт могут не приносить тот объем функционала, который они прогнозируют доставить на планировании.
СкрамБан команда эффективно решает эту проблему тем, что ограничивает работу в прогрессе. Доска преображается и уже выглядит так:
Использование Скрама и Канбана очень эффективно. С помощью Скрама мы решаем наши стратегические задачи и работаем, используя циклы обратной связи и прозрачность. С помощью Канбана решаем тактические задачи внутри Спринта и выравниваем поток.
Как утверждается в библии управления процессами (“ProcessDynamics, Modeling, andControl“, 1994), плохих процессов нет. Тем не менее, иногда процессы применяются в неверном контексте. Скрам – эмпирический процесс, построенный на принципах Бережливого Производства. Более всего он подходит для решения комплексных сложных задач и поэтому очень успешен в области разработки программного обеспечения, где больше неизвестного и неопределенного.
Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.
Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться к Канбану. На самом деле теперь ваш процесс не является даже одним из определенных Аджайл методов/фреймворков. Все, точка».
Определение Скрама.
Скрам – гибкий Фреймворк для решения сложных адаптивных проблем. Скрам очень минималистичен, прост для понимания, но чрезвычайно сложен в использовании. До недавнего времени была путаница в определении того, что же на самом деле можно называть настоящим Скрамом. После выхода Скрам Гайда, написанного Джеффом Сазерлендом в соавторстве с Кеном Швабером, вопрос был снят. Все, что описано в этом лаконичном документе, является обязательным для каждой Скрам команды.
Скрам – гибкий Фреймворк для решения сложных адаптивных проблем. Скрам очень минималистичен, прост для понимания, но чрезвычайно сложен в использовании. До недавнего времени была путаница в определении того, что же на самом деле можно называть настоящим Скрамом. После выхода Скрам Гайда, написанного Джеффом Сазерлендом в соавторстве с Кеном Швабером, вопрос был снят. Все, что описано в этом лаконичном документе, является обязательным для каждой Скрам команды.
«Роли, артефакты, события и правила Скрама не могут изменяться. Несмотря на то, что возможно использование лишь отдельных частей Скрама, результат не будет Скрамом.» (ScrumGuide, 2011)
Скрам является контейнером для других процессов, техник и методологий, и может быть использован в комбинации с ними. Очень успешным является использование Скрама с инженерными практиками XP.
«Скрам может быть использован только целиком и функционировать как контейнер для других техник, методологий и практик» (ScrumGuide, 2011)
Формальное определение этого метода можно найти в уже ставшей классикой книге Дэвида Андерсона «Kanban». Метод состоит всего лишь из пяти правил и не является методологией или Фреймворком. Я уже писал об этом в своем блог-посте «Канбан как НЕ процесс, НЕ методология, НЕ фреймворк».
Вы не можете работать в чистом «Канбане». Это просто не возможно! Большое количество компаний и команд обманывают себя, считая, что они работают в Канбане. Привожу несколько цитат от самого автора:
«Канбан не является методологией. Также Канбан - это не способ разработки программного обеспечения. Не существует процесса Канбана для разработки программного обеспечения. По крайней мере, я не знаю такого. Я никогда о таком не писал. Невозможно вести разработку с помощью одного Канбана. Метод Канбана сам по себе не содержит достаточно практик для продуктовой разработки». (Дейвид Андерсон)
Объединяем Скрам и Канбан в Скрамбан
Скрамбан является полноценным Скрамом, внутри которого применяется техника Канбана. Один из главных идеологов Канбана и Лина – Кори Ладас издал замечательную книгу «Scrumban». В ней он указал на слабые места Скрама и показал, каким образом, добавив Канбан, можно повысить продуктивность команды и оптимизировать поток внутри Спринта. Формула Скрамбана следующая: Scrumban = Scrum + Kanban
Давайте представим, что Скрам команда начала работать над ВСЕМИ элементами Беклога Спринта в первый же день сразу после планирования. Иначе выражаясь, все элементы Спринт Беклога «поехали» одновременно. Формально это никаким образом не нарушает правила Скрама. Действительно, Скрам не разъясняет, каким образом команда разработки должна доставлять выбранный на планировании функционал. Спринт - это черный ящик, в котором не видно, что происходит. На входе такого ящика – Спринт Беклог и Цель Спринта, а на выходе – Инкремент продукта (Potentially Shippable Product Increment).
СкрамБан команда эффективно решает эту проблему тем, что ограничивает работу в прогрессе. Доска преображается и уже выглядит так:
Нет плохих инструментов, есть
неверный контекст их использования
Использование Скрама и Канбана очень эффективно. С помощью Скрама мы решаем наши стратегические задачи и работаем, используя циклы обратной связи и прозрачность. С помощью Канбана решаем тактические задачи внутри Спринта и выравниваем поток.
Как утверждается в библии управления процессами (“ProcessDynamics, Modeling, andControl“, 1994), плохих процессов нет. Тем не менее, иногда процессы применяются в неверном контексте. Скрам – эмпирический процесс, построенный на принципах Бережливого Производства. Более всего он подходит для решения комплексных сложных задач и поэтому очень успешен в области разработки программного обеспечения, где больше неизвестного и неопределенного.
“Скрам, Канбан и XP – дополняющие друг друга, конкурирующие и часто конфликтующие модели. Но это не является большой проблемой. Просто мы должны быть осторожными и достаточно критичными в использовании этих моделей и знаний, которые они нам дают” (Юрген Апелло, Management 3.0)
Scrum On