Курс про Команду. Проектное управление. Вводная часть + Канбан
Рассказывает Иван Селиховкин.
Что такое проект?
В проекте одновременно есть две вещи - конечность и высокая неопределённость.
Если какой-то одной нет - то это операционное управление, а не проект.
Чем чаще делаешь какое-то действие - тем менее это проект и более операционное управление. (приготовить яичницу в первый раз - проект, в 100500й - не проект)
Пример:
+ Сборка чего-то на конвейере - не проект (собирали, собираем, и будем собирать - всё более-менее понятно)
+ Запуск нового конвейера - проект (хз как оно взлетит, кто это сделает, но к нужной дате готово должно быть)
Что такое управление проектом?
Надо "попасть в треугольник" - Сроки, стоимость, содержание работ. Если попали - проект успешен.
Если не попали - не успешен. И причины тут совершенно не важны.
Важно, чтобы кроме "попадания в треугольник" - ещё и ключевые заинтересованные стороны были довольны.
(Это и заказчик, и какие-то люди внутри компании, и, частичто, кончный пользователь, и команда - всегда по-разному, но точно более одного человека).
Классический проектный метод (PMI)
Инициация - фиксируются сроки, стоимость, содержание работ - устав проекта.
Внутри - будут наполняться все остальные планы.
Важно, что планы - не от начала-до-конца, а итеративно. (Высокая неопределённость - всё может поменяться, придётся переписывать весь план)
Вначале - расписываем подробно только несколько шагов, потом - следующие несколько. И так до конца. Это называется "метод набегающей волны".
Фокус - на достижении цели (попали в "треугольник" и "ключевые люди" довольны)
Скрам
Идея в том, что команда берёт задачи из беклога и уходит на "спринт" (от 1 до 4х недель) - в это время их трогать нельзя, люди работают.
Затем сдают работу, берут следующую кучку задач, опять уходят на спринт. Повторять до победы.
Заказчик - отвечает за наполнение беклога.
НО. Тут сложно с конечностью. Когда закончат - да ХЗ.
Работает в случае, когда сроки не важны, зато важна результативность - команда регулярно выдаёт работающие\завершенные задачи.
Фокус - на проверке гипотез. Так попробовали, сяк попробовали, выбираем варианты и с ними работаем. Самоорганизация.
Канбан
Главное в методе - доска.
Тоже есть список "хотелок" (беклог) и отслеживается перемещение задач по статусам от "хочу" до "готово".
Следим за потоком, визуализируем процесс, понимаем у кого и сколько работы (не так опираемся на самоорганизацию), можем собирать метрики.
НО. Тоже с конечностью плохо.
ХЗ когда будет готово всё, ХЗ сколько будет стоить. (Можем давать только примерные оценки вида "от начала работы над задачей такого вида и до "готово" - обычно проходит от Х до У дней")
Фокус - на совершенствовании потока. Чтобы никто не перегружался и не простаивал.
Чем больше связей между задачами в беклоге - тем хуже работают Скрам и Канбан.
Канбан.
Почитать: Девид Андерсон "Канбан - краткое руководство".
В основе метода - канбан доска.
Несколько колонок, каждая с делением на "в работе" и "готово".
Например: Запросы и идеи \ Аналитика \ Разработка \ Тест \ Готово.
Задачи двигаются слева направо.
визуализация
- все ключевые стадии работы над задачами отображены в колонках (мельчить не надо)
- кол-во колонок можно менять
- добавлять новую имеет смысл там, где "больно" (если где-то задачи тормозят - смотреть детальнее)
равномерность
- если видно, что где-то на доске образовалась пустота - там проблема
- работа команды должна быть предсказуемой
- нельзя двигать задачи назад!
- ускорять - не надо, надо подобрать оптимальную скорость
Роли в Канбан
Обязательных нет, но удобно выделить две.
- Менеджер сервиса поставки (delivery manager\flow master) - следит за равномерностью, устраняет препятствия на пути потока (хорошо бы - имеет на это полномочия), собирает метрики.
- Менеджер сервиса запросов (request manager\фасилитатор\Product owner) - отвечает за наполнение беклога и расстановку приоритетов
Идеально - когда они работают в партнёрстве.
WIP (Work in Progress) Limit
По каждому столбцу доски - есть такой WIP-лимит.
Это количество незаконченной работы (сумма "в работе" и "сделано")
Нельзя брать в работу задачу, если лимит кончился.
Ваще нельзя, никак. Пойди поспи. Или сделай то, до чего давно руки не доходили (тут почитать, там поковырять...)
Почему нельзя брать ещё - раз свободен?
- вырастет срок прохождения задачи через систему
- появится соблазн "выбирать" из накопившегося - какие-то задачи могут ждать слишком долго
- задачи могут устареть, находясь внутри к системе (доделаем - а уже не надо)
WIP limit - это всегда подгонка. Научного способа расчитать нет. Только подобрать под конкретную команду и конкретные задачи.
Их можно и нужно менять - подбирая идеальную скорость потока.
Декомпозиция в Канбан
Работает на уровне досок - одна для эпиков, другая для сторей (примерно так)
Что делать, с задачами, которые надо бы "назад" - например - баги?
Несколько вариантов, можно сочетать
- Под "тестированием" понимать несколько этапов - тест, багфикс, ретест (если надо - поделить колонки)
- Добавить маркер "в доработку" и всё же двигать назад (фигня)
- Закрыть задачу, но создать новую "связанную-с" - и её отправить в беклог. При этом баги - приоритетнее просто "задач".
Метрики в Канбан
В целом - очень метрикоориентированная система.
Если метрики не собираются - значит это ещё не канбан, а так "демо-версия" и "подготовительный этап"
Time To Market (TTM)
Время от попадания задачи в беклог до финала (выкатка пользователю)
Cycle Time (CT)
Время от начала работы над задачей до финала (выкатка пользователю)
Если ТТМ большой - значит беклог переполнен, или команда маленькая
Если СТ маленький - то ускорять команду не надо, они уже хорошо работают
Для подсчёта этих характеристик нужны три даты:
- дата добавления в ToDo (заведение задачи)
- дата взятия в работу (in progress)
- дата перевода в done
Эффективность потока (FE)
Эффективность = (время в работе)\ СТ
Где CT (cycle time) = время в работе + время простоя
время простоя - это когда задача завершена одним участником процесса и ждёт, пока её возьмёт другой участник.
Эта цифра очень зависит от команды и процесса.
Где-то - и 15% - уже хорошо (бюрократия, высокая формализация)
Если близко к 100% - это плохо, значит есть простои (т.е. следующий человек берёт задачу в работу сразу, как закончил предыдущий - значит ему нечего было делать)
40-60% - очень даже норм.
Service Level Aqreement (SLA)
примерная оценка вида "такого типа задачи мы делаем за такое-то время"
Как подсчитать?
Построить спекртальную диаграмму.
По одной оси - время CT (в днях), по другой - число задач, которые за такое время сделали.
В идеале - выделятся группы. Группа задач, которые занимают 2-5 дней, группа задач, которые занимают 8-12 дней, группа задач, которые занимают 16-20 дней.
Вот эти диапазоны дней по группам задач - и будут SLA.
Но может и не взлететь - и группы не выделятся. Это одно из противопоказаний к Канбану (но не критичное)
Что делать, если пришла срочная задача?
- допустимо выделить "ускоренную дорожку" на доске
- через всю доску
- эта дорожка может превышать WIP limit (уже в работе предельное число задач, но одну срочную - можно взять)
- НО. только одна срочная задача может быть в одном столбце на дорожке. (всего на дорожке - может быть больше одной, но в одном столбце - только одна)
- для срочных задач - иначе считается SLA
Cummulative Flow Diagram (CFD)
График - накопительным итогом - сколько задач прошло через статусы к какому времени.
По горизонтали - видно CT (можно оценить время между аналитикой и разработкой, или между разработкой и тестом)
По вертикали - видно WIP limit (условно) - сколько задач в системе
Если есть явные "пузыри" - значит есть проблемы.
Каденции в Канбан (они же митинги, они же встречи)
Всего - около 7
ревью стратегии, операционное ревью, ревью рисков, ревью service delivery, встреча по пополнению, канбан-встреча, встреча по планированию поставки.
но действительно критичных 2
- + Канбан встречи
- + Встреча по пополнению беклога
(и одна бонусом)
- + Ретро
Канбан-встреча
Это почти стендап. Ежедневный митинг.
- не более 15 минут (20 - предел)
- ориентировано на задачу (перебираем задачи, а не людей)
- двигаемся справа налево (сначала задачи из последней колонки, потом из пред-последней - и так до начала)
- выясняем, что сделать, чтобы продвинуть задачу вправо
Если команда большая \ задч много - делим встречи. Под-команды собирают свой статус, дальше собираются лиды под-команд.
Собрание по пополнению беклога
- Хорошо, когда беклог - это не одна колонка, а две. В одной "хочу" в другой "возьмём в работу".
- до 30 минут на встречу
- на встрече обсуждаем переход от "хочу" к "беру в работу". По факту беклог - это именно то, что взяли в работу - на что подписались.
- проводят встречу service request manager-ы
Ретро
(В канбан оно называется Операционное ревью)
Итого. Практики Канбан
- + Канбан-доска
- + WIP limit
- + Метрики (TTM, CT, FE)
- + Визуализация! (например - CFD)
- + Обратная связь (встречи)
Границы применимости Канбан
Абсолютные
- связи в беклоге (больше 10-15% - никак. лучше - меньше)
- наличие жестких дедлайнов (по всему проекту или отдельным задачам)
Относительные
- не получилось выделить SLA (не построилась спектральная диаграмма)
- нет полномочий проставить WIP limit
Чеклист применимости - чем больше пунктов, тем лучше
на основе The Kanban Litmus Test
