Наша Канбан- трансформация не останавливается, мы идем путем постоянного улучшения с верой в светлое будущее: релизимся! У нас регулярно проходят встречи с нашими представителями бизнеса по поводу нашей Канбан-трансформации, обсуждаем возникающие вопросы и принимаем соответствующие решения. В этом посте я хочу зафиксировать наши шаги и принятые решения.
А как наша трансформация началась и продолжалась можно посмотреть тут и тут соответственно.
Технический долг
Мы решили что на нашей Канбан-доске будут жить только 2 вида карточек: ЮС и баги из продакшена. Возник вопрос: а что же делать с нашим техническим долгом в виде 100500 багов в бэклоге ТФС?
Вы спросите: а откуда они там взялись? Хороший вопрос с простым ответом. На заре создания продукта по Scrum было принято решение командой, что баги по ЮС/ регрессионные с приоритетом и критичностью 3 и 4 не мешают релизу нового функционала. А так как времени всегда не хватает, то большинство из них проваливалось после закрытия итерации в общий бэклог продукта.
Какая велась с ними работа: они регулярно актуализировались командой тестировщиков (Lean: потери по времени), им мог измениться приоритет и иногда даже брались в работу, но это не изменяло общей ситуации.
Решение: представители бизнеса проанализировали весь список багов: часть закрыли, у части был изменен приоритет и они скоро придут в работу, а часть требует участие тестировщиков для перепроверки и уточнения поведения (так как продукт постоянно развивался и развивается).
Продуктовые баги от Тех.поддержки
Для продуктовых багов от тех. поддержки у нас существует отдельный трекер, если задача с багом приходит к нам и она подтверждается, то заводится уже багов в нашем трекере (ТФС, есть доп. поле на ссылку с задачей в трекере ТП). В нашем трекере такой баг мог быть закрыт, только в случае его не воспроизведения у клиента после релиза. Сейчас такое правило стало нарушать наш поток и все WIP лимиты.
Решение: правило убираем, что баг не воспроизводится у клиента отслеживаем в трекере ТП. Для таких багов сделали уникальную раскраску карточки.
Работа с Канбан- доской
У некоторых членов команды и PO возникали вопросы по работе с онлайн Канбан- доской. Так как раньше работами по Scrum велась в том же трекере, поэтому были сложности с изменением подхода к работе.
Решение: была проведена сессия обучения, где еще раз обговорили все правила и ответили на все интересующие вопросы и дополнительно был настроен ТФС.
Кроме того, канбан-доска помогает нам явно видеть проблемы на проекте, образующиеся бутылочные горлышки и принимать действия для их устранения (если проблема с тестированием- помогает вся команда, не можем выпустить определенное изменение/проблема с ветками разработки — думаем как решить проблему).
А что дальше?
- Ждем дорожную карту проекта,
- Думаем о составе команды (сейчас состав команды динамический: с периодической ротацией),
- Развиваем и улучшаем наш Канбан.
- думаем о применении Zero Bug Policy.
Трансформация. Промежуточные итоги
- В качестве главного итога хотелось бы отметить, что люди стали организовываться вокруг работы. Все проблемы обсуждаются на стендапах.
- Если есть вопросы по новому функционалу, то после стендапов проводятся небольшие сессии планирования с участием представителей команды, так и бизнеса. Никто больше не считает их потерей времени.
- Большая (ударение на первом слоге) включенность и участие представителей бизнеса в процессе создания продукта.
- Более сплоченная командная работа.