Recommended
Recommended
More Related Content
Viewers also liked
2 seminar scrum vs kanban_2.0
- 17. Даниил Арасланов 18 • Быстрее в 14 раз • В 3 раза производительнее • Легче планировать • Меньше стресса • Лучше качество
- 19. Даниил Арасланов 20 • Фокусирование на старте больше, чем на финише • Не ограничено WIP • Фокусирование на постоянной загрузке людей (страх простаивания) • Принятие «причины» и решение симптомов вместо проблемы
- 43. Сходства • Оба – и Lean, и Agile. • Оба используют вытягивающие системы планирования. • Оба ограничивают НЗР. • Оба используют прозрачность для обеспечения улучшения процесса. • Оба ориентированы на ранние и частые поставки продукта. • Оба полагаются на самоорганизующиеся команды. • Оба требуют деления задач на более мелкие. • В обоих случаях план релиза постоянно оптимизируется на основе эмпирических данных (производительности/ времени выполнения задачи).
- 49. 1. Знай свою цель • Аджайл, Лин, Скрам, Канбан 2. Никогда не вини инструмент • Инструменты не бывают успешными/плохими. Люди бывают. • Не бывает хороших или плохих инструментов. Только хорошие или плохие решения Когда, Где, Как и Зачем использовать какой инструмент. 3. Не ограничивай себя 1 инструментом • Расширяй свои горизонты • Сравнивай для понимания а не для осуждения 4. Экспериментируй и наслаждайся процессом • Не беспокойся о том, чтобы сразу сделать все правильно – не получится • Твой процесс не важен. Важен твой процесс совершенствования твоего процесса.
- 50. • Вопросы и ответы • Опрос 1 • Опрос 2
Editor's Notes
- Давайте поговорим сегодня о СКРАМ и КАНБАН.
- Я начинал как аналитик-консультант по таким малоизвестным продуктам как «Летограф», «Виртуоз», «Оптима WF». Затем я эволионировал в ПМ, Тимлида и Скрам Мастера. Более 4х лет занимаюсь СКРАМ, Канбан, Аджайл. За это время появились кое-какие практические наработки. Было вовлечено много людей в эту тему, запущены команды по разработке СРМ, Шарпоинт, Веб-сайтов и т.д. Мой опыт показал, что эти методики/подходы СКРАМ, Канбан, Аджайл действительно хорошо работают не только в Силиконовой долине Сан-Франциско, но даже в Киеве в Шевченковском районе тоже, например. Скрам, например, помог мне вытянуть 1 проект, который я тогда называл «падающий труп» и не похоронить его, а запустить в ПРОДакшен по всей Украине. Я хотел бы поделиться с Вами своим опытом. Потому что… В свое время я натыкался на грабли и если бы кто-то мне рассказал вот такие вещи я бы был ему очень благодарен.
- Прояснить Kanban и Scrum путем их сравнения … так, чтобы Вы могли понять как эти штуки можно использовать в вашем контексте/ситуации/среде/окружении
- Это книги по теме. Собственно данная презентация построена по 2й книге. И, если Вы заинтересуетесь, то в конце я дам ссылку на нее. Отдельно я хотел бы высказать слова благодарности Хенрику Книбергу, автору этих замечательных книг, без которого не было бы и этой презентации. По сути эта презентация – это выжимка из книги Книберга с некоторыми дополнениями/изменениями.
- Целевая аудитория люди знающие Scrum, но не знакомые с Kanban Незнакомые со Scrum Сколько людей знаю Скрам? Сколько практиковали Скрам? -- Хорошо, давайте попробуем описать СКРАМ и КАНБАН так, чтобы вложиться в сотню слов. Коротко о СКРАМ: Разделите Вашу организацию на маленькие, кросс-функциональные, самоорганизующиеся команды. Разделите Вашу работу на маленькие, конкретные компоненты. Отсортируйте этот список по приоритетам и оцените относительный объѐм работы по каждому элементу. Разделите время на короткие итерации фиксированной длины (обычно 1-4 недели) так, чтобы после каждой итерации проводилась демонстрация потенциально готового к использованию кода. Оптимизируйте план релиза и корректируйте приоритеты совместно с клиентом, основываясь на данных, получаемых при рассмотрении релиза после каждой итерации. Т.е.. После 1го спринта мы уже увидим работающий функционал, не весь, а кусочек. То есть мы едим слона по частям. Это очень здорово. Оптимизируйте процесс с помощью проведения ретроспективы после каждой итерации. Итак, вместо большой команды, которая долго работает над чем-то большим, у нас получается небольшая команда, которая короткими итерациями работает над небольшими кусочками. Но с регулярной интеграцией, чтоб видеть целостность картины. 108 слов ... почти уложились. Более подробную информацию можно найти в книге "Scrum и XP: заметки с передовой"
- Это чек-лист, смотря на который Вы можете понять насколько Вы близки к СКРАМу
- Сколько людей практиковали/практикуют Kanban? Простейшую Канбан систему я встретил в Японии, в Токио в громадном императорском саду. Когда Вы входите вам дают карточку. Вам не надо за нее платить. При выходе вы ее просто возвращаете. Зачем? Для того, чтобы понимать сколько людей в саду сейчас. Простейшая система. Администрация парка просто ограничивает количество карточек и, когда они заканчиваются больше никого не пускает. 1 выходит > 1 может зайти. Простейший способ регулирования потока. Это может быть названо Канбан-системой.
- Кто-нибудь знает японский? Нет? Отлично! Тогда я могу рассказывать дальше ) Канбан буквально означает «визуальная карточка». Сигнальная система Сильно визуализирована Вводит ограничения
- Канбан прямо у Вас в кармане: Высокая степень визуализации Используется для регулирования потока Имеет ограничение. И она должна быть ограничена, иначе будем иметь проблемы )
- Канбан был «вдохновлен» Тойотой Тойота использовала систему Канбан. Они использовали Канбан для управления материальным потоком между различными частями организации. Канбан в разработке ПО отличается. Он вдохновлен той же идеей, но не является прямой «копией» Канбана в стиле Тойоты. Визуализируй поток. И стадии потока, шаги которые есть в процессе И, конечно, что в данный момент внутри каждой стадии Ограничь WIP (work in progress). Это то, что отличает Канбан Измеряй и оптимизируй поток. Нам нужно измерять сколько времени задача была на доске. Например когда карточка попадает на доску мы отмечаем дату и когда доходит до конца-вторую дату. Отслеживаем это. Рисуем контрольный график и это дает нам среднюю цифру (например 12). **Анализируем, может быть мы где-то застряем на каком-то этапе.** Канбан не дает тебе каких либо других правил. Некоторые тебе нужно самому установить. Их обычно называют «политики, правила»: Определи правила (definition of Done, WIP ограничения и т.д.). Например DoD, т.е., что мы имеем ввиду, когда говорим, что фича сделана разработчиками, (т.е. когда перемещаем картоку вправо)? Или, к примеру, когда мы переносим из Deploy > Done, что это означает, в продакшене или тестовой среде или готово к переносу на продакшен? Эта политика говорит, например, что мы имеем только 3 штуки в разработке в каждый момент времени. Не больше этого, т.к. это превысит нашу «емкость», мощность и т.д.
- Канбан был «вдохновлен» Тойотой Тойота использовала систему Канбан. Они использовали Канбан для управления материальным потоком между различными частями организации. Канбан в разработке ПО отличается. Он вдохновлен той же идеей, но не является прямой «копией» Канбана в стиле Тойоты. Визуализируй поток. И стадии потока, шаги которые есть в процессе И, конечно, что в данный момент внутри каждой стадии Ограничь WIP (work in progress). Это то, что отличает Канбан Измеряй и оптимизируй поток. Нам нужно измерять сколько времени задача была на доске. Например когда карточка попадает на доску мы отмечаем дату и когда доходит до конца-вторую дату. Отслеживаем это. Рисуем контрольный график и это дает нам среднюю цифру (например 12). **Анализируем, может быть мы где-то застряем на каком-то этапе.** Канбан не дает тебе каких либо других правил. Некоторые тебе нужно самому установить. Их обычно называют «политики, правила»: Определи правила (definition of Done, WIP ограничения и т.д.). Например DoD, т.е., что мы имеем ввиду, когда говорим, что фича сделана разработчиками, (т.е. когда перемещаем картоку вправо)? Или, к примеру, когда мы переносим из Deploy > Done, что это означает, в продакшене или тестовой среде или готово к переносу на продакшен? Эта политика говорит, например, что мы имеем только 3 штуки в разработке в каждый момент времени. Не больше этого, т.к. это превысит нашу «емкость», мощность и т.д.
- Когда мы говорим об этих вещах мы сравниваем. Когда мы сравниваем нам нужно быть осторожными. Мне кажется, хорошей метафорой будет «инструменты». Мы можем посмотреть на эти «инструменты». Есть много определений, что такое «инструмент», но одно базовое: это – «что-то, что помогает выполнить задачу или достигнуть цели. Что-то, что Вы используете, чтобы выполнить задачу или достигнуть цели. Так что Скрам и Канбан это инструменты, которые Вы можете использовать для достижения чего-то. Вот Вилка – тоже инструмент. А вот другой инструмент – нож. Кто-нибудь имеет любимый из них? Кто-нибудь скажет, что вилка лучше инструмент, чем нож? Никто? Все думают, что нож лучше инструмент, чем вилка? …Смех… Это не корректный вопрос. Мне нужно уточнить, смотря что я собираюсь делать. Фактически, в некоторых случаях, они лучше всего работают в паре (съесть отбивную, например). А в некоторых случаях они вообще не помогут, например с супом, мне нужен ДРУГОЙ инструмент. Итак, нам нужно подумать с чем мы будем сравнивать их. Если СКРАМ хорош, то в каком контексте и в сравнении с чем? Это должны быть последующие вопросы. Вилка очень хороший инструмент для чистки зубов: В сравннении с зубной щеткой? В сравнении с поварешкой? Как видим, все относительно. Так что давайте сравнивать для понимания, не для осуждения.
- Есть несколько осей сравнения. Мне нравится эта, т.к. она достаточно показателен. Директивный / адаптивный. Директивный означает много правил которые говорят Вам что делать. Адаптивный - Вы сами принимаете правила. Итак, давайте расположим СКРАМ где-то здесь посередине, с его 9-10 практиками: Скрам Мастер, Продукт Овнер, Ежедневный СКРАМ и т.д. Их не так много. КАНБАН будет чуть правее, т.к. у него правил еще меньше: Визуализируй Ограничь WIP Измеряй и оптимизируй поток КАНБАН более адаптивный. Это не означает что он лучше, просто он более гибкий. Может это и лучше. Вам нужно выбрать: если Вам не необходимы итерации, возможно КАНБАН будет лучше. Но если не подходят эти два и нужно быть более адаптивным, тогда выбирай Делай что хочешь Делай, что угодно лишь бы это работало. Самый гибкий подход во всем мире. В таком случае очень трудно ошибиться, верно (ведь правил-то нет)? …. Есть ценность в ограничениях. Ограничения КАНБАНА: нужно ограничить WIP и визуализировать задачи и наблюдать за потоком. СКРАМ говорит: тебе нужно работать спринтами, кто-то должен выполнять роль ВладельцаПродукта. Это разновидности ограничений. И как с любым инструментом, это ограничение добавляет ценности данному инструментом и это очень интересно. ХР более директивен. включает в себя большую часть СКРАМА + еще кое-что. Инженерные практики, такие как CI, TDD. Вы можете не обязательно всем им следовать, но тем не менее это означает, что ХР более директивный процесс. Давайте шагнем дальше по шкале. У нас есть RUP (Rational Unified Process). …смех… он еще больше. Я устал считать после 120 правил ). Он огромный! Всевозможные предписания в нем есть. И они все взаимосвязаны. Это определяет какие роли какие встречи проводят и какие артефакты создают и т.д. Конечно здесь большая разница и Вам нет необходимости использовать все это. СКРАМ и РУП как бы противоположности. РУП дает Вам слишком много. СКРАМ дает слишком мало и Вам нужно будет восполнить недостающее. СКРАМ не говорит как правильно писать код. СКРАМ не говорит как делать кофе, но это не значит, что Вы не будете пить кофе и писать ужасный код, верно? Так что такие вещи Вы возможно добавите в СКРАМ. Одно из основных различий между СКРАМ и РУП в том, что в РУП вы получаете сразу много всего и Вам надо избавиться от лишнего. А в СКРАМ – слишком мало, и надо добавить недостающее. <…> В СКРАМЕ Вы делаете это адаптивно, Вам не нужно решать наперед чтобы нам добавить в СКРАМ. Когда чего-то не хватает, Вы добавляете это чуть позже. РУП труден, потому что Вам нужно решить наперед, Вы конфигурируете свой РУП-процесс в начале проекта. И тут очень важно знать, чтобы не ошибиться и не сделать плохой процесс. Вы можете конфигурировать ХР с РУП или СКРАМ с РУП. Но большинство команд используют тяжеловесный процесс РУП, т.к. они с самого начала установили такой набор правил. Подбирайте и сочетайте инструменты так, как вам удобно! Например, я с трудом могу себе представить успешную Scrum-команду, которая не использует большинство практик XP. Многие Kanban-команды используют ежедневные пятиминутки, а это Scrum-практика. Некоторые Scrum-команды описывают задачи из backlog-а в виде Use Case – сценариев использования (практика RUP), или ограничивают размер очередей задач (практика Kanban). Что угодно, лишь бы работало! Об этом красиво сказал Миямото Мусаси (легендарный самурай 17-го века, прославившийся техникой фехтования двумя мечами) - Миямото Мусаси «Вам не следует иметь любимого оружия. Владеть каким-то одним оружием очень хорошо, тогда как другими вы владеете плохо – такой же недостаток, как и не владеть этим оружием вообще.». Внимательно относитесь к ограничениям каждого из инструментов. Например, если вы используете Scrum и решили отказаться от использования ограниченных во времени итераций (или любой другой основной практики Scrum), то не говорите, что вы используете Scrum. Scrum сам по себе и так достаточно минимизирован, если вы удалите что-то и по-прежнему будете называть это Scrum, то слово станет бессмысленным и непонятным. Назовите это как-нибудь вроде "по мотивам Scrum-а" или "подмножество Scrum", или вообще "Scrum-ное"
- Вот пример моего видения этого. Есть разные наборы инструментов, некоторые пересечения и общее пересечение. И они все соответствуют этим принципам. Лин, Аджайл, ТОС, Системное мышление, как пакет мыслительных процессов эти фреймворки взаимодействуют прекрасно друг с другом.
- Любой инструмент можно использовать неправильно. Это может привести к мысли, что старый инструмент был лучше. Только потому, что он понял, что новый инструмент работает по другому. Ок, это было немного про сравнение.
- Многие команды, использующие КАНБАН начинают с визуализации происходящего, что является неплохим стартом. И они не должны остановиться на этом. Следующим шагом нужно ограничить WIP, т.к. это поможет работе. Я бы хотел привести пример этого. Мне кажется это лучший способ. Сколько времени нужно, чтобы написать имя? Чье-то имя.
- Вот что происходит. Вы пишете все имена одновременно потому что вы следуете этим правилам. Написание всех имен одновременно приводит большим ожиданиям Заказчика (все основное время он ждет). Если мы следуем вот этим правилам мы работаем только над 1 клиентом одновременно. Т.е. мы займемся Георгием только тогда, когда закончим всех предыдущих клиентов. И это приводит вот к чему. 4-5 сек на имя.
- Вот тоже самое можно изобразить на временном графике. Настоящая разница может быть разительной: Как можно в 14 раз быстрее написать чье-то имя просто из-за другого подхода? Эти кусочки в 14 раз короче тех. Это длина проекта. И также в 3 раза продуктивнее потому, что мы все проекты закончили вот здесь. Так что мы можем взять еще 10 других клиентов. Или сделать еще 2 итерации для этих клиентов. И, конечно, планирование намного легче. Через 10 секунд к моменту начала 3го проекта мы уже закончили 2 предыдущих и знаем сколько времени занимает проект. Мы можем планировать. А там мы не знаем ничего через 10 секунд. Мы просто гадаем, предполагаем. И, конечно, меньше стресса. Как Вы думаете? Может меньше стресса? Верно, делая так? И, лучше качество. Это довольно очевидно при наблюдении. Вот например допущена ошибка в Ринат (притом, что ошибка была замечена не мной, а Ринатом уже после проведения игры).
- Вы можете нарисовать такие картинки для своих проектов. Можно оглянуться и нарисовать вот такое. Проект А стартанул в янв и до … и т.д. И мы можем посмотреть когда мы реально работали над проектом, двигали его вперед. Можем нарисовать такие кубики тут, верно? И вы можете начать обсуждать «Что случится, если мы попытаемся сфокусироваться на вот этом 1 проекте и добьем его до конца полностью? Может иногда мы будем отвлекаться, но основное время посвятим ему. И после завершения возьмем проект В, затем С. Все тот же эффект. Намнооого быстрее. И, если уж начистоту, без привлечения дополнительных специалистов. Лучше качество и Меньше стресса. Конечно, в этом примере, что мы будем делать здесь в промежутке, когда мы стоим и ждем возвращения заказчика? Что делать? Может быть мы используем этот простой для чего то полезного, чегото нового, поможем другой команде. Или мы решили, что лимит WIP будет 2 и тогда мы можем делать здесь еще Фоновый проект. проект D. Так что в моменты простоя мы идем и делаем проект D, затем продолжаем работу над Главным проектом. WIP лимит не обязательно должен быть 1. Но все лучше, чем отсутствие лимитов вообще. Быстрый вопрос: знакома-ли данная (верхняя) ситуация кому-нибудь из Вас? Поднимите руку. Ок, этого достаточно. Это очень дешевый высокоефективный способ улучшить процесс. Просто ограничить WIP.
- Еще важный момент. Если мы посмотрим на эти проекты. Каждый проект вот здесь начинается раньше, а заканчивается позже. Значит в основе лежит какое-то предположение, что если мы раньше начнем проект, то раньше и закончим. Раньше сядешь раньше выйдешь. Но это упражнение демонстрирует, что в действительности все может быть наоборот. Каждый этот проект, кроме первого стартует в позже (на картинке плохо видно) и заканчивается намного раньше. ------ Хорошо, так почему мы делаем это? Что мы делаем такого, что наши проекты в 14 раз длиннее в очень простом проекте типа «Написать имя»? Прибегает сейл и кричит «почему до сих пор не начали делать проект? Давайте бегом!». Ну и таких сейлов 2-3 и проектов у каждого 2-3. Т.е. сейлы давят на то чтобы мы начинали быстрее… но не на то, чтобы быстрее закончить. Это «Фокусирование на старте больше, чем на финише». Мы одновременно пишем код по 1 проекту+еще по 1 проекту+строим архитектуру по третьему проекту+еще нужно тестировать еще 1 задачу по 1 проекту. Не ограничено WIP, конечно На нас наезды «Чего сидишь без дела? Тебе работу придумать?». Это же ужасно, компания платит деньги за работу а не за сидение!!! Фокусирование на постоянной загрузке людей (страх простаивания). Разработчик был очень занят когда писал 5 имен одновременно. Здесь же может быть простой. Если мы думаем, что простой очень плохо, то это очень быстро приводит к многозадачности. Так что нужно понять, что простой это очень хорошая штука. Есть книга «Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency» Тома Демарко которая много говорит как раз об этом. Когда мы каждую неделю чистим место в логах на сервере, то, может быть стоит задуматься а почему так, устранить причину и больше не мучаться? Т.е, конечно, принятие «причины». Что-то вызывает это. И нам нужно бросить вызов этой причине, не просто принять ее как данность. > вот пример картинка с вычерпыванием воды
- Вычерпывание воды Это типичный пример принятия причины того, что в лодке вода. Бросьте вызов этому. Вы можете дойти до причины «Дыра в лодке», которая приводит к тому, что много наших проектов не укладываются в сроки. Конечно, можно копнуть глубже и найти причину Дыры в лодке ), но для примера этого достаточно.
- Я покажу небольшое ДЕМО. Есть 2 сценария «Одного дня в стране КАНБАНИИ»: 1 солнечный день и 1 дождливый день. > Давайте начнем с солнечного дня.
- Я могу немного упростить систему КАНБАН здесь. Просто здесь какой-то беклог который мы когда-то должны сделать, нет лимитов, ограничений. Это просто куча идей. И вот ВладелецПродукта решает (Впродукта я называю человека или группу людей которые устанавливают приоритеты) что А и В 2 самые важные штуки. Может быть на основании отслеженного времени выполнения мы изучили, что в среднем требуется 8 дней для прохождения доски карточкой. Так что единственный вопрос, о котором должен думать Впродукта – «какие 2 штуки я хочу сделать в следующие 8 дней?». Это единственный вопрос. Ок, эти две. Команда начала работу и перетащила карточку А вправо. Когда А перешло в Done взяла в работу В. И тут срабатывает триггер: какие 2 штуки нужно выбрать в Next? И Впродукта говорит: «ок, С и D» будут следующими. И А идет в In production / B в Done / C бурут в работу. Все работает. В этом примере Вам нет необходимости в ограничении WIP. Все работает, нет проблем. Это называется “single piece flow” поток единичного изделия. Вы можете представить себе заказчика здесь справа, который вытягивает и вытягивает карточки слева-направо. Я подразумеваю Пменеджера или кого-либо как заталкивающего штуки в систему слева-направо. > А теперь давайте рассмотрим более интересный случай.
- А теперь давайте рассмотрим более интересный случай. > Дождливый день в стране КАНБАНИИ Итак, у нас есть 2 кроссфункциональные команды девелоперов и тестеров и несколько человек в продакшене. И PO решает, что эти 2 А и В штуки самые важные сейчас. Ок. Эти 2 товарища группируются (возможно это дев+тестер) чтобы сделать А. Остальные 2 решают, что пока не будут вмешиваться в А, т.к. итак уже 2 человека работают над одной фичей и будет хуже. Ок, это их решение как лучше организовать команду. Так что они решают начать работу над В. Все хорошо, потому что лимит в DEV = 3. Пока что все идет хорошо. Время подумать, что будет следующим по-ходу. И сейчас А переходит в Done, так что эти двое начинают переносить А в продакшен. Далее первая пара берут в работу С. Все ок, т.к. лимит = 3. Они закончили кодить и тестить, отдали фичу и «давай следующую» С. В следом тоже переходит в Done. И тут в А что-то пошло не так они не могут перенести ее в продакшен. Может быть произошел сбой или конфликт или какая-то ошибка, кто знает. Что происходит теперь? Может быть они решают разделиться – один переносит В в продакшен, другой борется со сбоем или чем-то в А. И тут возникает интересный момент: что будет нормальной реакцией по-умолчанию, какой следующий шаг свободной пары человек? Да, у нас есть D на подходе и мы готовы брать следующую фичу, т.к. уже сделали А и В. А то, что там не получается у когото-то это не наши проблемы. Но сейчас эта штука останавливает нас как проблема на ежедневном стендапе. Погоди-ка минутку, если мы вытащим новую фичу это разобьет наше гораничение WIP которое мы установили. Так что здесь наеврное что-то не так. Так что лучше пойти помочь ребятам в продакшене. И это хорошо. Это как будто у нас в принтере заело бумагу. Не пихайте туда новую бумагу, остановите печать и устраните замятие. И затем мы можем продолжить печать. Так что это произошло заедание бумаги в принтере. И, возможно, мой первый вопрос будет «как я могу помочь» и мне ответят «у меня тут куча ошибок сыпется в логе объясни мне что это значит?». Кто знает, может быть что-то в моем коде вызвало эту ошибку. С готово. Отметим, что «3» относится к обоим колонкам, так что С может перейти в DONE без каких-либо проблем. Но возникает новая проблема в том же месте но уже с В. Может сломался билд-сервер, кто знает. И опять у этих 2х не остается выбора, т.к. проблема сказывается на них тоже. Они не могут взять что-либо в работу из-за лимита = 3. Так что они присоединяются и пытаются чем-либо помочь. И через некоторое время даже Powner не может заказать что-либо еще, т.к. уже есть D и E и ограничение =2. Так что он тоже заблокирован и приходит к ребятам и спрашивает «Чем я могу помочь?», если, конечно, он хороший Powner. Приходит и спрашивает «Чем я могу помочь?». Звучит фантастично, правда? «Чем я могу помочь?». Не «Вы, идиоты, поторопитесь!» )). И, конечно, Powner не очень технарь, но он и не должен быть им. Вероятно он может помочь другим способом. Может у него есть деньги и он может купить новый билд-сервер, может протолкнуть решение проблемы со стороны заказчика, он может найти кого-то супер-спеца в помощь, он может купить пицу ребятам…все что угодно, ведь так?! Итак, это срабатывает как триггер для совместной работы и когда все вместе решают проблемы система разблокируется и мы будем двигаться на удивление быстро. Так что выявление пробьлемы и ее устранение происходит очень быстро. И если проблема будет повторяться мы проведем Анализ Перво-причин и найдем способ сделать так, чтобы она больше не повторялась вообще или реже. Система разблокируется и можно брать следующее. И так далее… Это КАНБАН в действии. Это увеличивает желание людей помогать другим людям за пределами своих владений.
- Ок. Это все про развитие.
- Эти доски не появляются внезапно. Они постоянно эволюционируют. Я могу Вам привести пример. Итак, вот команда и они подумали: «Как мы визуализируем то, что мы делаем?». Они повесили на стену карточки с текущими задачами. Не обращайте внимания на детали. И они решили добавить на стену DoD – это хорошая идея помнить всегда о том как мы узнаем что что-то готово. И, возможно мы решаем отслеживать что происходит после нас. Может люди тестируют после нас на пути к продакшену. Возможно неплохо видеть полную картину. И, чтобы упростить передачу по потоку они решили разбить колонки на “текущее” и «сделано». Так что эти люди знают свой пул задач. И, возможно, через нкоторое время они осознали, что когда мы заканчиваем работу и готовы брать следующую, а POwnera нет на месте (он на встрече с клиентом), то что нам делать? Ждать? Или мы сделаем небольшой буфер здесь. Только на 1 штуку, которую POwner приготовил нам. Так что в случае, когда его нет рядом мы можем взять ее в работу. Так что маленький входящий буфер здесь. И. возможно, мы решили мониторить даты. Мы просто пишем дату здесь на верху карточки и когда карточка дойдет до конца доски мы будем знать сколько времени на нее потратили. Для анализа. Очень полезно. И, возможно, пока мы делали это мы удивились: «Почему так долго делали эту фичу, целый месяц? Ведь там максимум 5 дней работы! Почему это заняло целый месяц?». Такие вопросы возникают и могут быть очень полезными. Может быть дело в том, что у нас скапливается много недоделанных фич в колонке «текущее». Может где-то есть ограничение-бутылочное горлышко. Так что это приводит нас к ограничению WIP. Это означает меньше заданий внутри системы. Это для более быстрого потока. Теперь это – КАНБАН система. И, возможно, мы хотим знать что происходит с нами до нас. И мы хотим видеть подъэтапы задач. Это похоже на СКРАМ. Мы хотим взять этот поток ФИЧ, ИСТОРИЙ и конкретизировать его в тасках: написать код, создать таблицу в базе данных… Так что этот процесс анализа берет какую-то фичу, разбивает ее на таски и затем решает какие критерии выхода из Анализа (DoD) для этой фичи. Это похоже на тест. Мы проясняем этот момент. Эта картина похожа на вычистку всего входящего в систему, в данном случае Анализа. Итак, сейчас у нас здесь поток светло-желтых карточек, которые попадают в Анализ и дополняются оранжевыми карточками > падает сюда (DoD) оранжевые карточки убираются, т.к. они больше не понадобятся > затем светло-желтая карточка перепрыгивает в Разработку и т.д. Конечно, будет полезно видеть, что уже сделано и какие есть блокировки. Возможно мы бы добавили еще 1 уровень визуализации. И вот здесь в Приемке стадия принятия заказчиком Клиент может найти что-то, что ему не нравится. И тогда мы замораживаем светло-желтую карточку здесь и работаем с ней как с задачей. После того как мы ее пофиксили она готова, принимается Заказчиком и идет дальше по доске. Если это случается слишком часто нам нужно провести Анализ Перво-причин и устранить проблему. Сейчас много всего на доске и вы пошли на southpark studios.com создали аватары для каждого члена команды и теперь видите кто нам чем работает. Очень просто. Возможно, мы сталкиваемся с жесткими сроками. Эта фича должна быть сделана к 15-10-2015 иначе Вы что-то упустите. Это жесткий срок здесь и мы постоянно мониторим это на карточке. И список правил «Что брать первым?» который проясняет правила, т.к. они неочевидны. Когда я закончил работу со своей задачей, что я должен брать следующее? Если я вижу жесткий срок я беру ее в работу или же самую старую фичу (по дате на карточке). Это очень просто. Мы можем добавить еще одно измерение – правило на приоритеты, когда одна фича немного важнее остальных. Тогда будет правило: «Если видишь фичу со звездочкой бери ее первой». Иначе бери самую старую фичу. В идеале у нас не возникает неожиданностей, но иногда это случается. Типа «сервер упал». И нам нужно его поднимать. Мы не планировали это, но мы не можем ждать, нужно сделать это немедленно. Тогда мы добавляем еще один «слой» 2 здвезды, который означает «Сделай прямо сейчас или умри!». Возможно у нас есть звоночек возле доски и когда появляется что-то с 2мя здездочками мы набрасываемся на эту фичу и делаем ее. Если это случается очень редко, это не есть проблема. Доски выглядят разнообразно. Это просто пример всевозможных паттернов/шаблонов которые мне встречались в разных местах, которые я смешал на одной доске для примера. Итак, это все эволюционно.
- Другой эволюционный момент это ограничение WIP. Эксперименты с ним. Нет жестких правил какое число там должно быть. Но есть способ понять велико-ли или слишком мало число. Вы можете использовать эту рекомендацию для постоянного обновления WIP. Итак, елси слишком маленький лимит WIP. Люди бездействуют. Они не могут ничего делать, т.к. лимит=1. И это приведет к замедлению потока. Т.к. некоторые люди не могут работать, поток сделанных фич медленнее, чем мог бы быть. Слишком высокий лимит WIP. Мы увидим, что простаивают задачи, а не люди. Люди не простаивают. И опять же медленный поток из-за этого. И недостаток места на доске. Правильный лимит WIP. Задачи простаивают очень редко, у Вас очень хороший поток Люди простаивают время от времени. Помним, что простой – это хорошо. Иногда люди должны простаивать, чтобы в это время сделать что-то полезное. Быстрый поток.
- Это просто рекомендации. Экспериментируйте с доской. И не пытайтесь разобраться во всех этих штуках. Дайте им выработать свое. Команды вдохновляют друг-друга как ни крути. Как правило не нужно стандартизировать эти вещи.
- СКРАМ предписывает роли, КАНБАН - нет. Это не значит, что Вам не нужен POwner в КАНБАНе, просто Вы не обязаны. Это Вы сами решаете быть ему или нет и если да, то что это значит.
- Спринт содержит 4 элемента: 1Планирование и фиксирование 2Обзор и 3 выпуск 4Ретроспектива Мы планируем и фиксируем что-то, мы выпускаем и ревьювим что-то и затем у нас встреча по совершенствованию процесса. 4 цикла и каждый раз мы повторяем все эти шаги заново. Это очень просто но, может быть, не всегда подходит. КАНБАН команда1 может, конечно, делать тоже самое. Никто не запрещает КАНБАН команде иметь спринты. Но они не обязаны. И эта КАНБАН команда2 решает делать ретроспективы каждые 4 недели. Планирование каждые 2 недели. И релизить каждую пятницу (они просто берут все что сделано и релизят каждую пятницу). В данном случае они разделили эти разные циклы. Эта КАНБАН команда3 более ситуативна. Рестроспективы каждые 4 недели – хороший способ оглянуться назад на свой процесс с уровня 10000 относительно процесса. Но в этом случае планирование происходит по требованию. Когда нужно тогда они и планируют. Т.е. закончились задачи они собираются и планируют следующие. Также Заказчик или POwner может инициировать встречу по планированию когда изменяются приоритеты. По ситуации. Тоже самое с релизами. В этом случае они тоже происходят по требованию. Они релизят, когда удобно или когда достаточно набрали. КАНБАН предоставляет такие опции.
- Еще одно различие, или, еще одно сходство: СКРАМ ограничивает WIP, но ограничивает во временных рамках. Мы знаем, что наша произ-ть = 15. Тогда мы знаем, что мы можем взять ровно столько-же в спринт. Спринт ограничивает количество элементов над которыми мы фокусируемся. КАНБАН ограничивает на другом уровне, (по статусу задачи). Вы можете комбинировать долгосрочные задачи, Вам не обязательно их дробить на кусочки, которые влезут в спринт. Он комбинирует большие фичи с второстепенными задачами. Это нормально. Есть, конечно, недостатки в таком подходе, но КАНБАН не запрещает этого. Вы можете миксовать эти вещи и ограничивать на это уровне. Ограничение в смысле «над сколькими элементами мы работаем к каждый момент времени?». В СКРАМЕ это будет звучать «над сколькими элементами мы можем работать в течение времени отведенного на спринт?».
- Хорошо, давайте посмотрим что у нас еще есть. Да, это римейк предыдущего слайда. Вы это можете видеть. Kanban ограничивает НЗР по статусу задачи, Scrum – по итерациям. Вы увидите здесь, что нет огромной разницы между СКРАМ и КАНБАН досками. Больше зависит от поведения команды. Но вот это будет различием.
- А здесь важное различие. СКРАМ не приветствует изменение в середине итерации. Мы поговорим об этом через минуту, а пока забежим вперед. > --- Предположим, что наша Scrum-доска выглядит так: Что делать, если появляется некто, кто хочет добавить Е на нашу доску? Scrum-команда, как правило, говорит что-то вроде "Нет, извините, мы обещали выполнить только A + B + C + D в этом спринте. Но вы легко можете добавить E в Product Backlog. Если же Product Owner решит, что у этой задачи высокий приоритет, мы возьмем ее в следующий спринт". Спринт правильной длины дает команде возможность сфокусироваться и хоть что-то завершить, и в то же время позволяет Product Owner-у изменять и регулярно обновлять приоритеты. А что сказала бы Kanban-команда? Kanban может сказать "Да, пожалуйста, добавляйте Е в колонку "В планах". Но в этой колонке может быть не больше двух элементов, так что в этом случае вам придется убрать C или D. Сейчас мы работаем над А и В, но как только у нас появится возможность, мы возьмем верхний элемент из колонки "В планах". Таким образом, время реакции (время, которое необходимо, чтобы отреагировать на изменение приоритетов) Kanban-команды – это время до того момента, когда освободится место в соответствующей колонке, согласно принципу "один элемент ушел – один пришел" (ограничение незавершенного производства). В Scrum-е время реакции в среднем составляет половину длины спринта. В Scrum-е Product Owner не может трогать Scrum-доску, так как команда взяла на себя обязательства по конкретному набору элементов на итерацию. В Kanban-е вы должны установить собственные правила для тех, кому разрешено изменять то, что на доске. Как правило, Product Owner-у дается крайняя левая колонка вроде "В планах" или "Готово к работе (Ready)", или "Backlog", или "Предложение (Proposed)", где он может вносить какие угодно изменения. Тем не менее, эти два подхода не взаимоисключающие. Scrum-команда может разрешить Product Owner-у менять приоритеты в середине спринта (хотя чаще это рассматривается как исключение). И Kanban-команда может решить добавить ограничения на то, когда приоритеты могут быть изменены. Kanban-команда может даже принять решение об использовании ограниченных по времени итераций с фиксированными обязательствами, точно также как в Scrum-е.
- В СКРАМ доска принадлежит 1 команде на 1 спринт. Вот здесь типичное начало спринта, середина спринта и конец спринта. Когда спринт закончился, доска очищается – все элементы убираются. В КАНБАНЕ доска, как правило, штука постоянная – вам не нужно ее обновлять, чтобы начать все сначала. . Это более постоянная вещь, которая принадлежит общему «потоку создания ценности». В каждый взятый день доска будет выглядеть как-то так. Нет необходимости начинать все с начала. В этом и недостатки и преимущества одновременно (в отсутствии необходимости начинать заново).
- Другой важный момент вот этот. СКРАМ предписывает кросс-функциональные команды. Так что модель СКРАМ такова: вот кросс-функциональная команда, которая обладает всеми необходимыми навыками/скиллами для выполнения всех задач. Каждый может работать в любой колонке. Это не означает, что каждый должен знать все. Это значит, что мы разделяем ответственность, что мы должны быть готовы делать что-то больше, чем своя личная работа. Т.е. все взаимосвязаны друг с другом. КАНБАН опять же не предписывает так много. Он открыт для специализации. Так что возможно Вы решили иметь 2х людей сфокусированных на этом и также они могут делать немного того. Этот сфокусирован на этом, но также может делать немного того. Тут кросс-функциональная команда, которая делает большинство задач вместе – это очень похоже на СКРАМ. А здесь у нас есть специалист и т.д. Вы можете больше комбинировать. Это также упрощает внедрение КАНБАН когда у Вас есть замкнутый цикл от начала и до конца, от концепта и до продакшена. Т.к. обычно очень тяжело иметь кросс-функциональную команду, которая бы делала все это. Другой важный момент в этом – (это, по моему-мнению, лучшая сумма всех различностей) КАНБАН более эволюционен. Бери то, что у тебя уже есть и начинай визуализировать, начинай ограничивать WIP и это запускает процесс эволюции. СКРАМ более революционен. Вам нужно менять всякие штуки. У Вас должны быть кросс-функциональные команды, работать спринтами, вы должны разбивать фичи чтобы они влезали в спринт. Всевозможные изменения необходимы в случае со СКРАМОМ. Так что лично как консультант, одно из самых важных, и, по моему мнению, тяжелых решений когда я прихожу к кдиенту это – мы имеем дело с эволюционным или революционным случаем. Что им нужно? Так как это радикально влияет на подход.
- Вот еще одно различие про оценку. СКРАМ как и большинство AGILE методов имеет модель как производить оценку и планирование. Модель такова: измеряем пр-ть и каждый раз вы изучаете свою пр-ть и можете планировать на основании этого. Мы можем сделать 8 элементов за спринт и Вы можете начать планировать какие именно 8 элементов Вы хотите сделать в следующем 10м спринте. В КАНБАНЕ Вы можете это делать, если вам нравится, но Вам этого не навязывают. Вы можете точно также выбрать любую другую модель. Это важная мысль. Если я делаю КАНБАН, если у меня доска наподобие этой, ничто не говорит что я не могу использовать эту модель оценки СКРАМ. Может быть я решил что хочу измерять пр-ть на этой доске. Она состоит в том сколько элементов перепрыгивает через эту линию в DONE каждую неделю. Вам не нужны спринты для измерения пр-ти. Итак, сколько поинтов в неделю. И мы можем использовать это для планирования, например.
- Этот список важных, я бы сказал, типичные плохие причины остановки СКРАМа и перехода к КАНБАН. Я сталкивался с некоторыми командами, которые говорят «вы знаете, нам не нравится так много оценивать». Кто-нибудь из Вас сталивался с таким? Так что вы хотите использовать КАНБАН потому что там нет оценки. Неправы в обоих случаях. КАНБАН не предписывает оценку. Но и не запрещает. Это проще. СКРАМ вроде бы обязует, но на практике есть разные способы сделать это, Вы можете выбрать свой уровень детализации. Итак, фичи: Первый способ – просто посчитать количество фич. Некоторые команды делают это. Количество фич за временной интервал. Некоторые оценивают как футболки (t-shirt size) Некоторые оценивают в стори поинтах – это стандартная можель AGILE, верно? Некоторые оценивают в днях. Задачи: Некоторые не используют разбивку на задачи. Некоторые разбивают, но не оценивают а просто считают количество. Кто-то разбивает на задачи и оценивает в днях Кто-то разбивает на задачи и оценивает в часах Это типичный СКРАМ, но это не значит, что Вы обязаны делать так же. Если Вам не нравится оценка, тогда не делайте. Если Вам кажется, что оценка занимает слишком много времени, делайте ее менее точной, например.
- Ок, небольшой пример масштабирования. На что может быть похожа комбинация СКРАМ+КАНБАН.
- Давайте скажем, что у нас игровая компания (по разработке игр), которая имеет несколько игровых команд. Они создали КАНБАН доску для уровня всего портфеля проектов. Которая показывает: следующая команда займется вот этим; 3 игры в разработке: Пакман, Понг, Донкеи Конг и находятся сейчас на разных этапах (в смысле зрелости, насколько они близки к резизу сейчас); Зорк на стадии релиза и возможно уже прошел интеграцию А эти игры были сделаны в прошлые месяцы А что, если я захочу узнать все детали Пакмана? Я хочу знать как они это делают. Эта доска обновляется всего раз в неделю, не чаще. Группа ПМ или СКРАМофСКРАМ собираются у этой доски каждую неделю чтобы принять решения. Если я хочу узнать детали этой команды – иду и навещаю их. Может быть они делают СКРАМ может КАНБАН, может они делают СКРАМБАН. Это как бы двух-уровневая система.
- Общие причины для СКРАМ команд попробовать КАНБАН. Во многих случаях это реально им помогает. Важный момент – не выбрасывайте СКРАМ совсем только потому, что нашли КАНБАН и он Вам понравился. Остановитесь на том, что есть и изменяйте эволюционно, примеряйте. Самый общий случай, например: мы делаем СКРАМ здесь, в Разработке. И начинаем использовать СКРАМ везде. И вот здесь, в Операционном отделе тоже вдохновились «давайте мы тоже хотим СКРАМ». Так что они начали и потом поняли, что это лучше, чем было, но он не совсем хорошо для наших нужд. Спринт не очень уместен нам. Мы не можем планировать даже на неделю нашу работу. Так что мы отказываемся от спринтов. Но, что будем иметь теперь вместо этого? КАНБАН в таком подходит отлично. Это общий случай. Другой общий случай: Унас есть здесь СКРАМ команда и они осознают, что мы очень быстрые сейчас. Но что происходит перед этой командой? Создание беклога продукта, например, Концепт, все, что может быть до разработки. И все, что может быть после: задачи по переносу в Продакшен и т.д. Так что только часть из всего потока управляется СКРАМ. Общий случай – оставить СКРАМ команду как есть и начать использовать КАНБАН для визуализации всего потока. И восполним пробел. Обычно это лучше.
- Сходства Оба – и Lean, и Agile. Оба используют вытягивающие системы планирования. Оба ограничивают НЗР. Оба используют прозрачность для обеспечения улучшения процесса. Оба ориентированы на ранние и частые поставки продукта. Оба полагаются на самоорганизующиеся команды. Оба требуют деления задач на более мелкие. В обоих случаях план релиза постоянно оптимизируется на основе эмпирических данных (производительности/ времени выполнения задачи).
- Сходства Оба – и Lean, и Agile. Оба используют вытягивающие системы планирования. Оба ограничивают НЗР. Оба используют прозрачность для обеспечения улучшения процесса. Оба ориентированы на ранние и частые поставки продукта. Оба полагаются на самоорганизующиеся команды. Оба требуют деления задач на более мелкие. В обоих случаях план релиза постоянно оптимизируется на основе эмпирических данных (производительности/ времени выполнения задачи).
- Вы можете скачать книгу для более детального погружения… В книге во 2й части Вы найдете хороший пример практического применения Канбана, например.
- Подумайте о том, если не работает, может потому, что мы используем инструмент неправильно или используем неправильный инструмент. Это вероятно, не в инструменте дело. Помните об этом.
- Сюхари (яп. 守破離 сюхари?, от яп. 守 — «соблюдать», 破 — «прорываться» и 離 — «отделяться») — концепция японских боевых искусств и описание этапов обучения, согласно которым существует понятие о трёх ступенях. Три шага мастерства в боевом искусстве появились в Китае и повлияли на японские боевые искусства. Иногда применяется для других японских дисциплин, например для го. Сю (яп. 守 сю?, от яп. 守 — «соблюдать») — первая ступень, означающая, что надо заучивать всё точно так, как показывает учитель. Требуется много лет тренироваться, иначе не будет базы для перехода на следующую ступень. Ха (яп. 破 ха?, от яп. 破 — «прорываться») — вторая ступень, согласно которой нужно освободиться от правил, где правил нет, а есть естественный ход вещей. Многие пробуют делать это слишком рано, поскольку переоценивают свои возможности. Ри (яп. 離 ри?, от яп. 離 — «отделяться») — третяя ступень, означает подняться над всем, что изучалось раньше, создать более высокие и более общие принципы. Но в СКРАМе есть вещи которые возникают иногда когда мы забываем об этом: Стадии обучения. Это из боевых искусств. Когда Вы на стадии обучения Шу – просто следуй правилам, делай то, чему что говорит учитель. Понятно? На стадии Ха – начинайте менять правила, экспериментируйте. На стадии Ри – не обращайте внимания на правила. Если вы едете на велосипеде Вы вероятно на уровне Ри. Вы знаете как правильно вести велосипед и как добраться из пункта А в пункт Б.
- И самое главное: избегайте догмы. Это случается часто. Это бессмысленно. Например, «ограничь WIP иначе ты будешь плохим человеком». Или «прочь, отойди от нас, мы в середине спринта». «заходи через 3 недели». Тогда может быть уже поздно.
- И несколько навыков, без которых не обойтись в завис-ти от типа использ.процесса: Разбиение системы на кусочки и поиск путей для маленьких деливераблсов. Это поможет для СКРАМа КАНБАНа и любого Аджайл метода. ПО. Написание хорошего кода. Без этого не обойтись. Ретроспективы. Назовите как хотите, но у Вас должны быть встречи, на которых вы говорите о процессе, смотрите на систематические ошибки, анализируете первопричины, и совершенствуете его. Потому что СКРА и КАНБАН оба очень эволюционны.
- Я могу подрезюмировать. И смогу сказать «Done”.
- Спасибо Вам и спасибо Генрику!