Теория ограничений в Agile команде

Андрей Геоня, 2GIS 19.05.2012

Введение в Теорию ограничений

Теория ограничений (ТО) - философия управления, направленная на повышение скорости генерирования прибыли любого предприятия.

Разработанная в 1980-х гг. доктором Элияху Голдраттом.

Основные понятия ТО

● Выработка - количество продукции, произведенной за единицу времени;

● Запасы - активы, используемые в качестве сырья, материалов и т. п. при производстве продукции;

● Операционные расходы - повседневные затраты компании для ведения бизнеса.

ТО в разработке ПО

● Выработка - готовые бизнес-фичи;● Запасы - незавершенные бизнес-фичи;● Операционные расходы - все, что не несет ценности для

бизнеса, но требуется при разработке (багфиксинг, рефакторинг и т. п.).

Цель

Увеличение выработки при сохранении или снижении операционных расходов и запасов: ● Готовые бизнес-фичи ++;● Ожидающие бизнес-фичи --;● Багфиксинг, рефакторинг и т. п. --.

Команда

Команда(ы) - это система взаимосвязанных элементов. Пример зависимостей: Аналитика~>Дизайн~>Верстка~>Разработка~>Тестирование

Производительность

Производительность всей системы = производительности её "слабого звена" (ограничения): Аналитика~>Дизайн~>Верстка~>Разработка~>Тестирование

Шаги к цели

1. Найти ограничение(я) системы - "слабое звено";

2. Принять решение об эффективном

использовании ограничений; 3. Адаптировать всю команду для

работы с ограничением; 4. Увеличить пропускную способность

"слабого звена"; 5. Если ограничение перестало быть

ограничением, тогда начать все сначала.

Как найти ограничение

● Спросить у команды - провести ретроспективу; ● Проверить нагрузку на каждое "звено"; ● Определить загруженность

"звеньев" - элементы системы, идущие после "слабого звена" будут простаивать.

Как использовать ограничение?

Чтобы понять, как эффективно использовать ограничение, нужно выяснить, что ему мешает: ● Определить во время ретроспективы;● Взглянуть на процесс в целом.

Как подчинить команду ограничению

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

Как "прокачать" ограничение

● Исключить простаивание;● Улучшить качество работы перед ограничением;● Распределить обязанности "слабого звена" между членами

команды (обычно это "соседние звенья").

Грабли. Опыт нашей команды

Use case. Белоснежка и 7 гномов Тестировщик и 7 программистов

Ресурсы:● 1 тестировщик;● 7 разработчиков Проблема:● Много задач для

тестирования;● Мало пользы.

...~>Разработка(7)~>Тестирование(1)

Как мы дали QA "разгрести" буфер задач

Нет, не так:

Вот так:● Разработчики выполнили ряд исследовательских задач;● Разработчики начали декомпозировать задачи backlog-а.

Как мы исключили простаивание QA● Разработчики начали следить за буфером задач QA;● И начали поддерживать равномерный буфер, не давая ему

закончиться. Простаивание QA - это очень дорого! Буфера тестировщиков:

Как мы улучшили качество перед QA

● Перестали пропускать задачи в QA без code review;● Составили детальный checklist для code review;● Настроили уведомления Jenkins-а по commit-у;

Как мы ускорили само тестирование

● Улучшили покрытие функционала авто-тестами;● Начали группировать задачи на тестирование в

функциональные группы.

Что мы получили

● Больше нагрузку на программистов;● Меньше нагрузку на QA;● Больше готовых фич в конце спринта.

Но хочется большего1. Сократить цикл работы над фичей:● Свести тестирование фичи к одной итерации (в худшем

случае - одна итерация + одна верификация) Для этого:● Программировать по checklist-у (по готовым тест-кейсам),

тем самым улучшить качество фичи до попадания в QA 2. Привлечь пользователей к тестированию● Внедрить Continuous delivery

Литература

Контакты: Twitter: @AndreyGeonya Email:a.geonya@gmail.com

Вопросы?