🪴 Quartz 4.0

Agile (Scrum, Kanban, Lean)

Dec 24, 202426 min read

Введение

Agile

Agile - это подход, который позволяет оптимизировать процессы работы над продуктом. Он сильно вжился в процессы больших команд разработки и положительно на него влияет.

  • Влияние на бизнес: Agile способствует успешному ведению бизнеса благодаря улучшению командной работы.
  • Личный опыт: Реальные примеры облегчения рабочих процессов и уменьшения ошибок с внедрением Agile.
  • Примеры успеха: Успешное завершение крупных проектов, в том числе ФБР и Agile-трансформация Сбербанка под руководством Германа Грефа, подчеркнувшего важность скорости.

Agile включает в себя ежедневные встречи, спринты, ретроспективы, автоматические тесты приложения.

Agile внедряют для оптимизации процессов

Модель Кеневин

Введение

Разработал модель Дэйв Сноуден, сотрудник IBM (1999) с целью анализа и принятия решений руководством. Сама модель предлагает разные способы решения задач на основе “среды обитания” (Cynefin)

Категории задач по модели Кеневин

Всего модель описывает 5 разных категорий задач, которые могут попасться нам как на работе, так и в целом в жизни:

  1. Простые задачи
    • Четкие причинно-следственные связи. Есть конкретные инструкции к решению проблем.
    • Подход: Ощути, категоризируй, реагируй
    • Примеры: работа официанта, строителя
  2. Сложные задачи
    • Скрытые причинно-следственные связи. Сразу неясно, как можно решить проблему.
    • Подход: Ощути, проанализируй, реагируй
    • Примеры: строительство дома, медицинское лечение
  3. Запутанные задачи
    • Неоднозначные и непредсказуемые связи. Есть общая идея того, что нужно реализовать, но как и в какой последовательности сделать - сразу неясно.
    • Подход: Попробуй, ощути, реагируй
    • Примеры: стартапы, инновационные проекты
  4. Хаотичные задачи
    • Отсутствие явных причинно-следственных связей. В данном случае пытаются выявить хоть какие-то связи.
    • Подход: Действуй, ощути, реагируй
    • Примеры: научные лаборатории
  5. Неопределенность
    • Неясность принадлежности к категории. Нужно определить, в какой области ты находишься прямо сейчас.
    • Подход: Сначала определи область

Применение модели

Данная модель позволяет определить нам, подходит ли Agile к данном проекту. Для различных проектов мы можем применять различные методы менеджмента команды:

  • Запутанные проекты требуют наличия гиоптез и их проверки, что предоставляет нам Scrum внутри Agile
  • Сложные проекты на зрелых стадиях не требуют сложных решений и проверки гипотез - им достаточно будет следить за задачами через Kanban
  • Системы мотивации: OKR для запутанных, KPI для сложных проектов
  • В простых проектах можно накладывать задачи по системе Waterfall (то есть друг за другом), а в более сложных раскидывать задачи по PMI, Prince2 и PMBook

Проекты могут менять свою область

  • Проекты могут менять категории в зависимости от изменения причинно-следственных связей
  • Пример: стартап переходит от запутанной к сложной области

Заключение

Модель Кеневин – ключевой инструмент для понимания и управления различными типами задач в Agile-практиках, позволяющий выбрать наиболее эффективный подход к решению задач и управлению проектами.

Agile-манифест

Agile - это философия, основанная на Манифесте Agile, включающем в себя четыре ценности и двенадцать принципов.

11 февраля 2001 года: В штате Юта, семнадцать экспертов разработали Аджайл-манифест. Созданы четыре ценности и двенадцать принципов Agile.

Ценности Agile:

  1. Люди и взаимодействия важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

12 Принципов Agile:

  1. Удовлетворение требований заказчика через раннюю и регулярную поставку продукта.
  2. Приветствие изменений требований, даже на поздних стадиях разработки.
  3. Частая поставка работающего продукта.
  4. Ежедневная работа разработчиков и бизнеса вместе.
  5. Поддержка мотивированных профессионалов.
  6. Непосредственное общение как эффективный способ обмена информацией.
  7. Работающий продукт как основной показатель прогресса.
  8. Поддержание устойчивого процесса разработки.
  9. Внимание к техническому совершенству и качеству.
  10. Простота и минимизация лишней работы.
  11. Развитие требований и решений через самоорганизующиеся команды.
  12. Регулярный анализ и улучшение эффективности.

Ключи к пониманию Agile:

  1. Коммуникация: Центральная роль общения и командного взаимодействия. Примерно 10% из 80ичасового спринта отведено на общение разработчиков и менеджеров, чтобы понимать свои задачи. Очень важны фасилидация и коучинг коллег. Отвечает за принципы 4, 5, 6, 8, 11, 12.
  2. Эмпиризм: Способность адаптироваться и изменять стратегию, основываясь на опыте. Отвечает за принципы 1, 2, 3, 4, 9, 12.
  3. Контроль качества: Высокие стандарты качества и их поддержание. Отвечает за принципы 1, 4, 7.

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

Эмпиризм

Эмпиризм - это философское направление, согласно которому знание или обоснование исходят только или главным образом из чувственного опыта.

Опыт - источник знания, единственный критерий истины и основание всякой науки.

Рационализм - это уже противоположное эмпиризму направление, когда за основу берётся автономность разума от чувств и приоритетом является разум в познании. Порядок и связь идей в разуме соответствует порядку и связи вещей в мире.

Эмпиризм в Agile

Эмпиризм (опыт) стоит в основе Agile, делая его подходы гибкими и позволяя быстро адаптироваться к изменениям, благодаря чему Agile и получает своё название — “гибкий”.

В Agile значительное место занимает адаптация к изменениям, что предполагает пересмотр первоначальных планов в пользу нового опыта и требований.

Сам по себе план редко когда сбывается и поэтому главное - уметь подстраивать план под новую действительность, когда задачи и приоритеты меняются.

  • Принципы гибкого подхода:
    1. Удовлетворение потребностей заказчика через регулярную и раннюю поставку.
    2. Поддержка изменения требований на любых этапах.
    3. Ежедневное сотрудничество между разработчиками и заказчиками.
    4. Внимание к техническому совершенству и качеству.
    5. Командная оценка эффективности работы и адаптация процессов.

Особенности каскадной модели (Waterfall)

Agile предлагает итеративную модель разработки, противопоставляясь каскадной модели (водопад), что позволяет быстрее реагировать на изменения и уменьшает бюрократизацию рабочего процесса.

Разработал данную модель Уинстон Ройс. Эта модель подходит для простых и быстрых проектов в заказной разработке. Но для сложных проектов она не подходит, потому как в них существует кратно большее количество неизвестных переменных.

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

Но у этой модели есть критические недостатки, которые не дают воспользоваться ей в больших проектах:

  1. В конце у нас получается не то, что нужно, потому что все требования были приняты в самом начале пути
  2. Слишком поздно идёт тестирование продукта
  3. Очень тяжело попасть в сроки и бюджет (так как внести правки становится сложно)
  4. Внесение самих изменений - это проблема, так как в начале такой функционал не предусматривался

Цикл Деминга-Шухарта

Agile использует итерационные циклы, основанные на эмпирическом цикле Деминга-Шухарта (Plan-Do-Check-Act), улучшая гибкость и эффективность процессов.

Сама по себе итеративная модель основана на цикле ДШ, но включает в каждом этапе те же самые этапы из вотерфола

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

Во все эти этапы так же включены петли обратной связи для своевременного взаимодействия и планирования дальнейших работ командой.

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

Столпы эмпиризма в Agile

Эти столпы - это минимальный набор требований, без которых эмпиризм, а в этом случае и Agile, не будут работать.

  1. Прозрачность — делаем рабочий процесс видимым для всех участников.
    • Таблицы, графики, схемы, документация, честное и открытое общение, фиксация договорённостей
  2. Инспекция — регулярная проверка прогресса и выявление отклонений.
    • Ежедневные встречи, планирование, демонстрация, ретроспектива, обзор рисков
  3. Адаптация — корректировка процессов с целью минимизации отклонений.
    • По результатам инспекции будет произведён процесс адаптации с теми же методами из инспекции

Заключение:

Эмпиризм в Agile служит фундаментом для создания гибких и эффективных рабочих процессов, позволяя командам быстро адаптироваться к изменяющимся требованиям и реализовывать проекты с оптимальными результатами.

Спиральная модель. Time to Market. Rational Unified Process

Спиральная модель

Данная модель опирается на потребность в изготовлении раннего прототипа, тестирования и выпуска в маркет. Здесь находится достаточно большое количество шагов, на которых мы просто проверяем прототипы и анализируем потребности в разработке фичей, что сильно замедляет процесс разработки.

Но из основных недостатков можно выделить:

  1. Тестирование реального продукта происходит на позднем этапе
  2. Частые промахи по срокам и бюджету
  3. Долгий Time to Market (TTM)
Rational Unified Process (RUP)

RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.

Плюсы:

  1. Ранняя идентификация и устранение рисков
  2. Концентрация на выполнении требований заказчика
  3. Изменения в продукте от заказчика Ожидаются
  4. Компонентная архитектура, которая реализуется и тестируется на ранних стадиях
  5. Постоянное обеспечение качества на всех этапах разработки продукта
  6. Работа в сплочённой команде с ключевой ролью у архитекторов

Из недостатков можн выделить:

  1. Большой TTM
  2. Срыв сроков и бюджета
  3. Тяжеловесность фреймворка
  4. Тестирование реального продукта происходит на позднем этапе

В последствии RUP IBM переименовала в OpenUP

Обзор Extreme Programming. Ценности

Экстремальное программирование - это сбор лучших практик из программирования и максимально частое их повторение.

Эту методологию разработал Кен Бек в 1999 году.

Из примеров можно привести:

  • Написание тестов до самой реализации (TDD)
  • Запуск тестов в автоматическом режиме
  • Ревью кода других разработчиков

Для применения практик самое важное - это понимать ценности данного подхода.

  • Общение - это крайне важно на каждом этапе разработки продукта. Это самая важная ценность, которая дополняет все ценности.
  • Простота - решения должны быть простыми и решать определённые проблемы без оверинджиниринга там, где это не нужно
  • Обратная связь очень важна во время общения с заказчиком, потому что все его недовольства и пожелания нужно учитывать вовремя и эффективно
  • Смелость. Не нужно откладывать решение какой-то видимой проблемы на потом, лучше всё сделать сейчас даже если менеджер не поставил таску на решение этой проблемы
  • Уважение - нужно уважать опыт и мысли каждого члена команды

Самое важное - это понимать, для чего мы используем каждый из подходов, потому что сам по себе подход может быть не нужен для каждой конкретной ситуации.

Оптимизиации рабочего процесса

Введение Agile-подходов и практик может быть тяжело введено в разработку из-за непонимания разработчиками сути данных практик.

Проблема распространения Agile заключается в том, что практики распространяют менеджерским языком, а не языком разработчика.

Можно достаточно легко разобраться с возможностью упростить свой рабочий процесс

У нас есть определённые критерии оптимизиации процессов разработки:

  • Удобство для разработчиков
  • Вовлечённость - уменьшает текучку кадров и поднимает имидж компании за счёт более интересной подачи задачи, описания её значимости и разнообразности задач
  • Прибыльность бизнеса
  • Лояльность клиентов
  • Продуктивность разработчиков - создание условий, в которых разработчики предоставляют более ценные решения за счёт предоставления им бОльшего количества времени на разработку
  • Time To Market - сокращение времени от идеи до выхода на рынок

Далее пойдут темы, которые опишут подходы оптимизации рабочего процесса:

Автоматиизации

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

Часто разработчики автоматизируют множество действий клиента и упрощают ему жизнь, но не автоматизируют свои простые рутинные процессы, что увеличивает время разработки.

Самые простые пути автоматизации труда разработчиков:

  • Применение линтеров и форматировщиков кода для обеспечения соответствия стандартам;
  • Автоматическое тестирование вместо ручных тестов;
  • Непрерывная интеграция и развертывание (CI/CD) для облегчения процесса сборки и развертывания (потому что если разработчик будет это делать сам, то процесс будет тратить много времени и компания завяжется на сотруднике);
  • Планирование встреч для обсуждения сложных вопросов, минимизация общения через мессенджеры;
  • Создание и поддержание актуальной документации для ускорения адаптации и работы сотрудников.

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

Практические шаги к автоматизации

  1. Зафиксировать все рутинные действия в течение 1-2 недель.
  2. Придумать до трех возможных автоматизированных решений для каждой обнаруженной рутинной задачи.
  3. Выбрать и автоматизировать одну из рутин, уделяя внимание именно той, что вызывает наибольшие неудобства.

Целеполагание

Целеполагание - это постановка и достижение целей.

Целеполагание важно для оптимизации рабочих процессов, особенно в командах разработчиков, где требуется совместная работа и обсуждение целей.

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

Эффективное формирование целей уменьшает срок и ветиеватость разработки.

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

Принципы и методы

Для эффективной разработки продукта нужно сразу решить следующие вопросы:

  • Определить критерии достижения цели (по этим критериям должно быть понятно, что заказчик получил полностью удовлетворяющий его продукт)
  • Создание условий для качественной коммуникации (на коммуникацию зачастую выделяется очень мало времени на планирование, уточнение и поиск оптимального решения)
  • Декомпозиция и эмпиризм (большие цели нужно делить на более маленькие и организовать эмпирический подход)
  • Обсуждать сразу несколько вариантов решения
  • Методика SMART - специфический, измеримый, амбициозный, релевантный, ограниченный во времени подход к постановке целей.

Так же можно воспользоваться хорошим подходом 4 вопроса планирования/коучинга, на которые можно ответить в любом порядке и замкнуть круг потребностей - чего хочется достичь, почему это важно, критерии достижения, варианты решения.

Самопомощь и Самокоучинг

Так же можно задать себе 8 вопросов, которые помогут разобраться с пониманием текущих задач, глубже понять свои цели и пути их достижения:

  • Что ты хочешь сделать? (мы часто делаем то, что сами не можем назвать)
  • Зачем ты хочешь это сделать?
  • Какая личная выгода от того, что ты это сделаешь?
  • Какие твои индивидуальные способности помогут сделать это с максимальным качеством и за минимальное время?
  • Что ты будешь делать, чтобы сделать это с максимальным качеством и за минимальное время?
  • Какими должны быть условия, чтобы сделать это с максимальным качеством и за минимальное время?
  • В каком случае ты будешь максимально удовлетворён?
  • Какие твои шаги ты видишь?

В практике можно попробовать сформулировать и определить личные и командные цели.

Заключение

Целеполагание важно для оптимизации рабочих процессов, особенно в командах разработчиков, где требуется совместная работа и обсуждение целей.

Математический рассчёт

Самый банальный метод расчёта эффективности определённого выбора заключается в банальной математике.

Мы определяем, какие автомобили мы хотим производить, чтобы зарабатывать больше всего. Делим прибыль на время производства и получаем месячный результат по каждой машине. Самой выгодной является самая быстрая в производстве.

Из вышестоящей математики можно предположить, что в реальной жизни очень много переменных и для разработки большого продукта обычная математика подходить уже не будет в полной мере.

Использовать математический подход будет актуально в следующих случаях:

  • (доход - стоимость разработки) / время
    • для маленьких проектов написать код расторопно есть смысл, но если сделать быстро, то такой код будет тяжелее поддерживать и ошибок может стать больше
    • стоит выделять время на поддержку инфраструктуры приложения
  • Выгода от автотестов
    • стоит ли их писать, будут ли большими репутационные или денежные потери от ошибок
  • Agile тренер / самостоятельное внедрение
    • выгодно ли внедрять самостоятельно или через тренера для большой команды
  • Время на обсуждения или Время на исправления
    • нужно ли тратить много времени для реализации фичи, ведь если проект маленький или задачи маленькие, то выгоднее время потратить на доработки

Расширение применения расчетов

  • Введение идеи о том, что подходы, основанные на математическом подсчете, могут быть применены для улучшения различных аспектов рабочего процесса:
    • Оптимизация времени и ресурсов на поддержку кода.
    • Рациональное распределение времени на автотесты.
    • Эффективность проведения встреч и управления временем.

Практические упражнения

  • Наблюдение и сбор информации: Измерение времени, затраченного на разные типы встреч и активности в рамках рабочего процесса.
  • Анализ и оптимизация: Анализ данных о времени и предложения по его оптимизации для увеличения эффективности.
  • Решение о внедрении автотестирования: Расчет целесообразности внедрения автоматических тестов с учетом затраченного времени и ресурсов.

Заключение

Математический расчёт позволит эффективнее определять, на что стоит тратить время во время разработки продукта и сколько этого времени нужно уделять.

Управление вниманием

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

Множественные задачи и отвлекающие факторы снижают эффективность.

Сам по себе разработчик во время выполнения задачи должен учитывать множество факторов:

  • Архитектура
  • Множество способов решения задачи
  • Критерии
  • Оборудование
  • Внутренние стандарты оформления кода
  • Задач может быть множество
  • Ошибки по разным задачам могут всплывать в разные моменты времени

Психолог Джордж Миллер сделал вывод в результате своих исследований, что внимание человека способно фокусироваться ограниченно, в среднем на 5-9 объектах.

Чтобы улучшить управление вниманием, мы можем:

  1. Уменьшить количество объектов в поле нашего внимания:
    • Исключение лишних данных (иногда некоторые моменты не нужны нам для решения задачи)
    • Группировать данные и задачи
  2. Реорганизовать работу:
    • Структурировать файлы и документацию
    • Разделение задач на подзадачи
    • Оптимизация работы в команде

Так как до 9 объектов может быть в поле зрения, поэтому и любая команда может быть до 9 человек (исключая вас).

По закону Брукса, если проект не укладывается в сроки, то добавление рабочей силы увеличивает общий объём затрат:

  • Труд по перекраиванию задач, которое нарушает дальнейшую работу
  • Обучение новых людей
  • Дополнительное общение

От увеличения количества человек в команде мы не выиграем сильно, потому что сильно увеличится количество возможных связей. Сложность связей растёт нелинейно.

Вопросы для самоанализа:

  1. Проанализировать размер команды и её коммуникации. И насколько комфортно при такоим количестве участников. Как можно реорганизовать команду. Сколько человек нужно для более качественных связей.
  2. Оценить количество рабочих и личных чатов.
  3. Осмыслить количество микро- и макрозадач.
  4. Рефлексировать по желаемым изменениям в организации внимания.
  5. От чего хочется избавиться или перегруппировать.

Приоритизация

Очень важную роль в управлении командой так же забирает на себя приоритизация задач. У продукта есть множество различных интересантов в виде клиентов, которые хотят более удобный продукт, который решает их проблемы, есть бизнес, который хочет, чтобы приложение приносило деньги и есть комфорт сотрудников, которые выполняют задачи в той последовательности, в которой задачу будет решить эффективнее.

Например, нам нужно реализовать пуш-уведомления в браузерном приложении и для реализации этой задачи сначала стоит разобраться с Service Workers внутри браузера, чтобы в процессе не возникало конфликтов реализации.

Так же у бизнеса могут быть свои как тактические, так и стратегические интересы, которые могут не сходиться и противоречить друг другу.

Между всеми этими интересами нужно балансировать. И мы должны чётко понять, что не все задачи одинаково важны и выбирать задачи нужно по степени их вклада в результат.

Чтобы приоритизировать задачи, можно:

  • Использование “козырей”. Определить, где больше будет профита (тактика/стратегия).
  • Тушение пожаров. Сохранять баланс между фундаментальными и прорывными задачами для предотвращения кризисных ситуаций.
    • Фундаментальные задачи позволяют укрепить стойкость приложения и получить определённые ресурсы, на которое можно будет опереться
    • Прорывные задачи добавляют новый функционал в приложение за счёт использования новых ресурсов, чтобы достичь новые высоты
    • Между этими задачами нужно балансировать, потому что без первого достичь второго будет становиться с каждым разом всё тяжелее и тяжелее
  • Карта зависимостей. Определение связей и возможностей для их уменьшения или устранения.

Метод Эйзенхауэра

Как один из вариатов для определения срочных, важных и не очень задач, можно использовать метод Эйзенхауэра, в котором мы определяем, какие задачи можно сделать, отложить, делегировать или вовсе не делать.

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

Далее нужно соотнести все задачи по срочности и важности на графике с данными координатами

Что можно сделать для определения приоритетов

  • Выборать ключевой проект
  • Детализировать активности проекта
  • Описать зависимости между активностями
  • Применить матрицу Эйзенхауэра для организации приоритетов
  • Спланировать реализацию по приоритетам

Заключение

Приоритизация задач очень важна в управлении проектами, потому что помогает фокусироваться на ключевых задачах, которые принесут максимум профита, и оптимизировать рабочие процессы.

Инжинерные практики

Инжинерные практики - это самый популярный подход к оптимизиации рабочего процесса. Это набор поведенческих и технических решений, которые направлены на разработку продукта.

Таковыми можно назвать практики экстремального программирования (XP) или написание low-level документации (LLD).

LLD - это описание работы функций, классов, методов прямо рядом с кодом посредством комментариев (summary, json-doc) или README.

Очень часто ИП связывают с XP, но это не так. XP, как полнцоенный Agile-фреймворк, ссылается на определённые инженерные практики, но не является их олицитворением. Тот же LLD не входит в экстремальное программирование.

Ключевые Инженерные Практики

  1. Стандарты Кода: Создание и поддержка единых стандартов оформления кода
    • Использовать linters и formatties
    • Уменьшить количество недопониманий в команде
  2. Коллективное Владение Кодом: Ответственность всей команды за весь код проекта.
    • Это повышает качество кода и его поддерживаемость за счёт более компетентного ревью.
  3. Разработка Через Тестирование (TDD): Сначала пишутся тесты, затем код.
    • Позволяет сделать требования более прозрачными
    • Описывает всю будущую бизнес-логику до написания самого кода
  4. Непрерывная Интеграция (CI/CD): Автоматическая сборка, тестирование и развертывание кода.
  5. Частые и Небольшие Релизы: Согласно agile принципам.
  6. Заказчик всегда рядом: Важность ежедневной обратной связи от пользователей.
  7. Парное Программирование: Работа над кодом в паре для повышения эффективности.

Заключение

Инжинерные практики очень важны при написании продукта, так как помогают более эффективно работать команде над большим проектом и поддерживать его эффективнее.

Kanban

agilekanban

Kanban (яп. сигнал, карточка, квитанция) - это метод, который является частью многих других фреймворков. Он описывает способ распределения задач и их ведения.

История Канбана

  • Основа метода - опыт Toyota, начиная с 1926 года.
  • Toyota перешла от производства ткацких станков к автомобилям, уделяя особенное внимание постоянному улучшению процессов.
  • Важным этапом стало внедрение вытягивающей канбан-системы в 1948 году, ускоряющей производственный процесс за счёт изготовления по сигналу определённые детали для определённых моделей машин.
  • Термин «бережливое производство» (Lean Manufacturing) был введён в 1988 году Джоном Крафчиком, описывающим подобные подходы.
  • Дэвид Андерсон в 2006 году сформулировал Канбан-метод, вдохновляясь идеями бережливого производства и системой Toyota.

Ключевые принципы Канбана

  • Сервис
    • Канбан сосредоточен на поставке результатов на основе услуг
  • Поток ценности
    • Важно понимание потока ценностей от команды разработчиков
    • Важнее сосредоточение на доставке ценности, чем на выполнении задач
  • Уникальность каждого процесса
    • Подход должен быть адаптирован под процессы в компании
    • Метод должен быть подогнан индивидуально для каждого случая
  • Методология эволюционного улучшения
    • Вместо радикальных изменений, нужно делать прогресс маленькими шажками
    • Начните то, чем вы сейчас занимаетесь и улучшайте это
  • Вытягивающая канбан-система
  • Договорённости
    • На всех уровнях от разработки, менеджеров до заказчиков - все должны иметь определённые договорённости между собой по продукту

Канбан и Agile

Для того, чтобы определить сущность Kanban, нужно обратиться к терминологии. Методика, метод и методология - это научные термины, которыми описывают различные сущности.

Методика - это рецепт, алгоритм. Чётка последовательность действий для достижения результата.

Метод - способ достижения цели. Это группа возможных способов достижения результата.

Методология - это учение о поиске подходящих методов.

Фреймворк - это жёсткий набор определённых правил и методологий, которые мы применяем для достижения результата. То есть у нас есть определённый набор инструментов, из которого у нас получится определённый результат.

Kanban шире методов и принципов Agile, поэтому так же и не является Agile-методом или методологией. Его можно встроить и подстроить под эти принципы.

Заключение

Для более подробного изучения материала по Kanban и доступа к сертифицированным тренингам, можно воспользоваться Kanban University.

Так же можно почитать книги Дэвида Андерсона о Канбане и “Дао Тойота” Джеффри Лайкера для глубокого понимания метода и его истории.

Ценности

Как и у любого другого метода, у Kanban есть свои ценности, которые определяют основы этой методологии:

  1. Прозрачность - важность полной видимости всех процессов для всех участников.
  2. Баланс - равновесие всех аспектов работы: требований, возможностей команды, нагрузки и т.д. Оптимизировать нужно не отдельные участки, а брать во внимание весь процесс.
  3. Сотрудничество - основа успешного рабочего процесса, заключается в качественной командной работе.
  4. Ценность Клиента - ориентированность на нужды и приоритеты заказчика, создание ценности для него.
  5. Поток - понимание и управление потоком создания ценности, знание его этапов и влияющих на него факторов.
  6. Лидерство - принятие ответственности, умение вдохновлять и вести за собой. Это одна из важнейших ценностей kanban-метода.
  7. Понимание - знание текущего состояния процесса и направления его развития, умение различать полезное и вредное.
  8. Согласие - умение прийти к совместным договоренностям и соблюдать их.
  9. Уважение - основа всех принципов и ценностей Канбан, взаимное уважение внутри команды.

Как определить ценность:

  1. Что в команде понимают под ценностью, которую они производят?
  2. Как эта ценность может проявляться?
  3. Как эта ценность проявляется в вашей команде?
  4. Как хотелось бы, чтобы она проявлялась?
  5. Предложения по улучшению рабочего процесса.

Модель зрелости

Модель зрелости Kanban - это набор рисков, рекомендаций и практик в зависимости от текущего уровня зрелости компании.

Модель зрелости Kanban описывает эволюцию организационных процессов через семь уровней от нулевого до шестого. Эти уровни помогают компаниям ориентироваться в своем развитии и внедрении лучших практик.

ПДФ

Всего насчитывается 196 практик, количество которых продолжает расти. Эти практики касаются различных аспектов работы компании, включая организацию, взаимодействие с клиентами, управление рисками и продуктами.

Уровни Зрелости

  1. Рассеянный (0) — Отсутствие структурированных изменений и самоориентация сотрудников. Каждый сотрудник опирается на свои результаты относительно работы.
  2. Командно-центричный (1) — Визуализация работы и командная синхронизация. Компания осознаёт ценность командной работы, а сотрудники согласовывают правила.
  3. Клиента-ориентированный (2) — Фокус на ценности для клиента. Команды не участвуют в этом уровне и даже могут отсутствовать.
  4. Соответствующие предназначению (3) — Глубокое понимание потребностей клиентов и предназначения компании. Все отношения с клиентами налажены, сотрудники понимают в чём предназначение команд и компании в целом.
  5. Застрахован от рисков (4) — Стратегическое планирование, прогнозирование результатов, формированию бюджетов и снижение рисков.
  6. Рыночный лидер (5) — Узнаваемый бренд с понятным качеством и оптимизация процессов (уменьшение затрат, увеличение скорости поставки).
  7. Построен на века (антихрупкость) (6) — Гибкость и способность к быстрой адаптации.

Всю более подробную информацию можно черпнуть из книги Дэвида Андерсона и Теодора Божевой “Модель зрелости Канбан”, сайт kmm.plus.

Заключение

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

Роли

Роль - это набор функций, которые может выполнять один человек, группа людей или вся команда.

Нужно отметить, что не всегда отдельная роль - это отдельный человек с отдельной позицией. Роль могут выполнять разные люди в разные моменты времени. Однако в том же Scrum работу мастеринга выполняет отдельный Scrum-мастер.

В Сбербанке некоторые Kanban-роли совмещены и называются Service Delivery Lead.

В Kanban выделяют две ключевые роли: 

  • Service Delivery Manager (SDM)
  • Service Request Manager (SRM).

Service Delivery Manager (SDM)

SDM - менеджер поставки сервиса. Он отвечает за предоставление сервиса.

Задачами SDM являются:

  • Ответственность за поставку: Убедиться, что услуга или продукт доставлен заказчику.
  • Планирование, координация и контроль: Назначать задачи, проводить ежедневные собрания, контролировать препятствия и выполнение задач.
  • Коммуникация с клиентами: Строить контакты, выявлять потребности, уточнять детали.
  • Анализ рисков: Управление рисками, разработка стратегий их снижения.
  • Бюджетирование: Участие в планировании бюджета.
  • Развитие команды: Организация обучения, проведение мастер-классов, составление карты компетенций.

Выполняет эту работу, как правило: Team Lead или менеджер продукта, в Scrum - вся команда.

Service Request Manager (SRM)

SRM - менеджер запросов к сервису

Задачами SRM являются:

  • Выбор работы для команды: Определение, над какими задачами должна работать команда.
  • Коммуникация с заказчиками: Выявление потребностей, общение, установление приоритетов задач.
  • Работает с большими задачами. Декомпозиция крупных задач, управление со-зависимыми задачами, решение вопросов.
  • Определяет приоритеты. Различает степень потребности в определённых фишках от заказчиков.
  • Управляет зависимостями задач. Определяет зависимости между задачами и выстраивает последовательность и приоритеты их выполнения.

Выполняет эту работу, обычно: Клиент-менеджер, менеджер-продукта, владелец-продукта.

Реализация:

  1. Определить и записать, кто такие SDM и SRM в компании, какие их функции и задачи.
  2. Рассмотреть, как распределяются эти роли в команде, и как это влияет на работу.
  3. Как изменения в выполнении этих ролей могут улучшить рабочий процесс, командную работу и в итоге принести пользу компании.

Заключение

Рассмотрение этих ролей позволит более эффективно организовать рабочий процесс, улучшить взаимодействие между командой и заказчиками, а также способствовать лучшему пониманию и выполнению задач.

Каденции

Каденции - это очень близкое к эмпиризму из Agile понятие.

Каденции - это регулярные встречи, на которых происходят озвучивание текущей ситуации, рефлексирование и планирование действий на основе известной инфомрации.

Каденции = Петли обратной связи = Циклы обратной связи = События = Командные встречи

Качество зависит от высокого уровня прозрачности, инспекции и адаптации.

Если в scrum все события обязательны, то каденции в Kanban могут как проводиться, так и не проводиться.

Виды Встреч

Типы встреч и их аналоги в Scrum:

  1. Ежедневный Канбан (Канбан митинг) (= Ежедневный Скрам)
    • Формат: Ежедневная короткая встреча.
    • Задачи:
      • Анализ текущего потока
      • Устранение препятствий
      • Переставление задач на доске
  2. Собрание по Пополнению (Планирование Спринта)
    • Периодичность: Рекомендуется еженедельно.
    • Задачи:
      • Определение списка задач, которые берут в работу (точка принятия обязательств)
  3. Обзор Сервиса Поставки (Ревью Спринта / ретроспектива)
    • Участники: Включая конечных пользователей.
    • Цель:
      • Определить удовлетворенность клиентов
      • Определение способов улучшения сервиса.
      • В Kanban и Scrum: Анализ выполненной работы для улучшения процессов.
  4. Планирование Поставки
    • Особенность Kanban: Собрание для определения готовых к поставке задач.
  5. Уточнение Бэклога (это upstream этап)
    • Цель: подготовка работ до пополнения.
  6. Ревью Стратегии
    • Периодичность: Раз в квартал.
    • Цель: Сверка глобальных целей, адаптация дорожной карты.
    • Встречаются руководители разных уровней и «сверяют часы» по глобальным целям (верно ли идём, куда двинемся дальше), адаптируют дорожную карту
  7. Операционное Ревью
    • Цель: Улучшение координации между командами, повышение эффективности.
    • Встречаются менеджеры разного уровня, чтобы способствовать лучшему взаимодействию команд, устранению препятствий, повышению эффективности компании в целом
  8. Ревью Рисков
    • Задача: Выявляются риски и узкие места для своевременного противостояния им.

Последним трём пунктам нет аналогов в Scrum, так как Kanban распространяется не только на команду, но и на всю организацию, а Scrum только на одну команду.

Внедрение

  1. Ежедневные Встречи: Оцените их проведение в команде.
  2. Собрание по Пополнению: Как оно организовано?
  3. Обзор Сервиса Поставки: Есть ли у вас демонстрации?
  4. Релизная Политика: Кто и как её проводит?
  5. Предложения: Ваши идеи по улучшению рабочего процесса, с учетом каденций.

Заключение

Каденции в Kanban так же важны, как и эмпиризм в Agile.

Общие практики

Каждый этап модели зрелости соотносится с 6 основными практиками канбана, описанными в книге Дэвида Андерсона.

Практики модели зрелости - это частные случаи для каждой компании.

Модель зрелости включает в себя 196 практик, организованных вокруг 6 основных практик канбана. Эти 6 практик служат основой, поверх которой развиваются более конкретные подходы для каждого уровня зрелости компании.

6 Практик Канбана

  1. Визуализация рабочего процесса
    • Использование канбан-досок для наглядного указания самой задачи и этапа её производства;
  2. Ограничение количества работы в процессе (Work in Progress - WIP)
    • Мы должны ограничивать количество незавершённой работы, чтобы увеличить скорость разработки продукта и предотвратить перегрузки на определённом этапе;
    • Каждый столбец с этапом мы делим на две части (doing|ready) и от этого уже идём дальше
    • Ограничиваем максимальное количество задач в колонке. По достижению этого максимума - дальше уже перемещать в колонку задачи нельзя
    • На ежедневных встречах SDM просматривает задачи справа налево и пытается устраить перегрузы
    • Каждый перегруз - это явное препятствие
  3. Управление потоком
    • Поток должен быть предсказуем
    • Проводите ежедневные встречи для оценки и оптимизации потока работы;
    • Используйте графики и диаграммы, в том числе накопительную диаграмму потока (CFD), для анализа эффективности; CFD
  4. Ясные правила работы (договорённости)
    • Определите и сделайте явными правила и процедуры выполнения работы;
  5. Циклы обратной связи (Каденции)
    • Внедряйте регулярные встречи для оценки рабочего процесса и выявления возможностей для улучшений;
  6. Постоянное улучшение
    • Применяйте эмпиризм и цикл Дэминга Шухарта (PDCA) для постоянного анализа и улучшения процессов.

Управление задачам

agiletasktrackertracker

Введение

  1. Введение:
    • Разработчики сталкиваются с множеством задач.
    • Задачи оцениваются, имеют статус и по ним можно прогнозировать релизы.
  2. Важность хорошего оформления задач:
    • Продуктивность команды зависит от понимания и приоритизации задач.
    • Настройка трекера задач играет ключевую роль.
  3. Что будет изучено:
    • Рассмотрение практик и приложений для улучшения менеджмента задач.
    • Улучшение навыков работы с задачами через уроки и упражнения.
  4. Структура задачи:
    • Иерархичность: Проекты, крупные задачи и подзадачи.
    • Заголовок: Краткое описание сути задачи.
    • Описание: Детализация требований.
    • Активность: Комментарии, изменения, коммиты.
    • Статус: Этапы выполнения.
    • Автор и исполнители: Ответственные лица.
  5. Дополнительные поля:
    • Произвольные поля в трекерах для удобства работы: Приоритет, метки, эпики.
  6. Упражнения:
    • Анализ текущего состояния задач в проекте.
    • Размышление о необходимых изменениях в оформлении и ходе работы с задачами.
  7. Заключение:
    • Научиться эффективно работать с задачами критически важно для успеха проектов.
    • Понимание структуры и динамики задач поможет улучшить продуктивность и сократить время на реализацию.

Трекеры задач

STATIK

Пользовательские истории

Сторипоинты

Критерии DoR DoC и AC

Приоритизация бэклога

Scrum

scrumagile

Роли

Спринт

Планирование спринта

Ежедневные встречи

Обзор спринта

Ретроспектива

Уточнение бэклога

Масштабирование Agile

Kanban

Nexus

LeSS

Sbergile

SAFe

Заключение

Текущий стек различных подходов уже подходит для разработчиков и позволяет свободно ощущать себя в Agile-методологиях

Для развития в сторону менеджера стоит изучить аспекты Agile через восемь компетенций Agile Coach / дополнительные тренинги.

Менеджерство

Можно попробовать взглянуть на Agile-коучинг с точки зрения “Системы 8-и компетенций Agile-коуча” Лисы Адгенс.

Популярные тренинговые центры по Agile:

Graph View

Backlinks