Своим практическим опытом о том, как сочетать в одной организации методы гибкой разработки и классического процесса эксплуатации услуг, с нами делится Ян Джонс (Ian Jones), консультант KPMG Australia.
В одной неназванной организации методы гибкой разработки были приняты как стандарт исполнения проектов и успешно применялись достаточное время. При реализации ITSM инициатив возникло желание использовать их и для организации процесса управления проблемами. Изначально организация использовала Scrum для координации этих работ, но этот подход показал себя не с лучшей стороны. После чего, была предпринята более успешная попытка применения "бережливой" практики Kanban.
Для того, чтобы объяснить различия между этими двумя методиками приведем небольшую таблицу.
| Kanban | Scrum | |
| Планирование работ | В объеме обрабатываемых запросов | Фиксируется объем работ для временной рамки спринта |
| Оценка трудоемкости задач | Не проводится | Проводится |
| Отслеживание прогресса | Фокус на потоке обрабатываемых запросов | Фокус на скорости выполнения работ |
| Ограничения на пул задач в работе в момент времени | Есть | Нет |
| Владелец процесса | Команда | Scrum master |
| Непрерывное совершенствование | По требованию, при возникновении дефектов | По итогам временной рамки, при ретроспективе спринта |
В силу сложности процесса диагностики проблем и того, что эта работа могла занимать как очень мало, так и очень много времени,применение Scrum существенно осложнялось как минимум с двух сторон:
- Проводить оценку задач и планирование работ для предстоящего спринта было затруднительно;
- Сам факт группировки проблем в спринты не нес практической пользы и негативно воздействовал на группу аналитиков проблем из-за непрекращающегося давления темпа спринта.
Команда предложила использовать указанную ниже структуру доски Kanban:
- Беклог
- Запланирован анализ инцидентов
- Анализ инцидентов проведен
- Публикация и корректировка
- Завершенные
При работе с этой доской использовались следующие правила:
- Члены команды убирали/откладывали работы в т.ч. из раздела "Публикация и корректировка", но не из "Завершенные", т.к.после публикации аналитиками результатов диагностики и описания мер по устранению, работы по непосредственному устранению проблемы выполняются другими ИТ-подразделениями, и сроки их работ могут сильно варьироваться.
- Аналитики стремятся не передавать проблему своим коллегам и другим сотрудникам, а вести её от начала до конца, т.к. из-за необходимости значительного погружения в предмет каждой проблемы, переключение между задачами становится неэффективным по временным затратам.
- Ограничения на количество задач в работе отслеживалось, но не были блокирующим работу фактором. Вместо этого, факт превышения порогового значения являлся поводом для эскалации и проведения переговоров с заинтересованными лицами по приоритезации выполняемых работ.
Применение принципа №5 из "Toyota Way", состоящего в построении культуры в которой нет места устранению проблем, а есть стремление получить качественный результат с первой попытки, сильно помогло команде. Визуализация потока обрабатываемых проблем и ежедневные короткие групповые совещания в форме стенд-апа позволили аналитикам выявлять сложности и недостатки в их исследованиях и совместной работе и устранять их, не откладывая на потом.
