Больше чем Agile

Анонс доклада на Международной конференции TOCICO, 16-19 июля 2017, Берлин

Докладчик: Векатиш Джаганнатха (Venkatish Jagannath, Schneider Electric Process Automation Research Center India (IRC))

Методология Agile ранее применялась для разработки программного обеспечения (ПО) Schneider Electric Engineering Workbench, но не могла дать желаемых результатов. Но типовая реализация Критической цепи не работала бы тоже! Компания внедрила новую модель потока на основе концепции Теории ограничений (ТОС), которая не только создала более гармоничную рабочую среду для команды разработчиков, но и повысила их производительность на целых 33%! Вот их история…

Введение

Schneider Electric Engineering Workbench – продукт для автоматизации технологических процессов, помогающий компаниям автоматизировать конфигурацию и разработку контрольно-измерительных приборов и систем управления браунфилд и гринфилд проектами. Ускорение разработки помогает сократить время запуска производства и тем самым повышает рентабельность и снижает риски штрафных санкций для поставщика средств автоматизации.

Требования (технические и маркетинговые) от распределенных по всему миру команд технических специалистов и маркетологов объединяют и превращают в дорожную карту поставки продуктов (новые версии программного обеспечения). Каждый продукт представляет собой предопределенный пакет функций, которые должны быть завершены до установленной даты релиза. Команда управления проектом Schneider описывает пользовательские истории для каждой функции, а затем передает их на аутсорсинг компаниям по разработке ПО.

Проблемы, вызванные применением Agile

Аутсорсинговые компании Schneider следовали методологии Agile, используя спринты (4 недели каждый) для разработки программного обеспечения. Во время каждого спринта команды разработчиков и тестеров создавали задачи для каждой пользовательской истории, писали код и тестировали его. Когда пользовательские истории завершались, создавалась демоверсия для клиента, которая подвергалась функциональному тестированию. Заключительный раунд тестирования проводился в последнем спринте релиза, который назывался «закалкой». После успешного прохождения всех функций через эти циклы испытаний, продукт объявлялся готовым к релизу. Эта методология, к сожалению, создавала ряд проблем:

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

2. Конфликты приоритетов
Поскольку экспертные ресурсы часто оказывались недоступны, чтобы не терять время в ожидании их обратной связи, команды разработчиков начинали работу над следующей пользовательской историей. Это приводило к множеству открытых задач для разработчиков. В результате возникали конфликты приоритетов – какая задача важнее.

3. Частая переделка
Тестирование было основным источником обратной связи по выявлению пробелов в проектировании и разработке. Следовательно, непрерывный «обратный поток» и переделки были неизбежны. Кроме того, поскольку решения по проектированию часто принимались независимыми командами, работающими параллельно, это вызвало конфликты в точках интеграции кода и дополнительные переделки. Engineering Workbench страдала от плохой производительности, значительных переделок (около 20%) и превышенной нагрузки (около 30%). Около половины дефектов относилась к анализу требований и проектированию.

4. Компромиссное закрытие спринта
К концу каждого спринта все работали на его закрытие. Но эти попытки закрыть спринт любой ценой принуждали к компромиссам – некоторые тесты не проводились, некоторые ошибки игнорировались, некоторые возможности переносились на следующие спринты. Поэтому некоторые функция, выходившие из спринтов были «не юзабельны» и прогнозируемость (для клиентов) графика релизов исчезала.

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

6. Недостаток надежности и качества подпортили репутацию
Из-за такой хаотической работы сроки были растянуты (релиз занимал до 10 месяцев), маркетологи часто жаловались на упущенные возможности из-за длительных сроков. Более того, несмотря на огромные усилия к концу «финального релиза» очистить «бэклог», перегрузка невыполненной работой приводила к дальнейшим компромиссам. Поэтому когда продукт, наконец, был выпущен, клиенты начали жаловаться на недостатки и остались недовольны.

Задача

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

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

Развертывание решения

1. Разделение ресурсов
Экспертные ресурсы были отключены от этапа внедрения. Им были поставлены задачи: фокусировка на понимании требований, высокоуровневое проектирование и определение программных зависимостей. Остальная команда была распределена между этапами детального проектирования, внедрения (разработки) и тестирования. Были установлены короткие фиксированные по времени встречи в течение дня, где находящиеся на разных этапах команды встречались для обсуждения и решения вопросов.

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

3. Полный комплект
Критерии входа и выхода были четко определены и применяются на всех 4 этапах – Требования, Решение и Высокоуровневое проектирование, Детальное проектирование, Внедрение & Тестирование. Чтобы уменьшить количество прогнозируемых ошибок на этапах предложения для клиента и высокоуровневого проектирования, были сделаны обязательными следующие шаги – использование прототипов для проверки понимания требований и решения, а также определение пограничных условий тестирования командой тестировщиков.

4. Активное управление задачами (Active Management Task)
Было внедрено ежедневное активное управление задачами, позволяющее выявить и устранить препятствия для потока.

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

Проблемы внедрения

1. Безысходность
Люди не верили, что можно как-то изменить ситуацию – были опробованы разные варианты, и даже популярная методология Agile не помогла.

2. Разногласия по проблеме
Поскольку аутсорсинг-партнер (поставщик программного обеспечения) работал по модели выставления счетов, многие в Schneider считали, что у них отсутствует мотивация выпускать релизы в срок. Таким образом, они не считали, что изменение методологии работы поможет.

3. Сопротивление сокращению оценочного времени работ вдвое
Ранее считались, что это увеличит прессинг и стресс команды.

Результаты

В конце года, спустя восемь месяцев после перехода на новую модель, Schneider сообщил результаты:

Более частое и быстрое удовлетворение требований заказчика (новый релиз каждые 3-4 месяца вместо 9 месяцев ранее) после внедрения TOC.
Четкое соблюдение дорожной карты продукта (изменение дорожной карты всего около 10%).
Более высокий выход в сочетании с >90% соблюдением сроков поставки.
Плотность дефектов уменьшена в 4 раза с 40% до 10% (количество переделок значительно снизилось).
Появилось время для НИИОКР – зарегистрирован 1 патент, завершены 3 инновационные разработки.
Стресса больше нет – люди из индустрии создания программного обеспечения возвращаются домой вовремя!

Уроки

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

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок