Масштабированный скрам. Как организовать гибкую разработку в крупной компании

Более глубокий анализ системной динамики, который показывает, по какой причине разработка замедлилась в долгосрочной перспективе и почему первая версия Word для Windows была выпущена на несколько лет позже ожидаемого срока, представлен на рис. 2.3.

Естественно, значительный объем грязного кода в конечном итоге замедлил разработку. Хуже того, разработчики игнорировали постоянно растущий список открытых дефектов, генерируя вместо этого все больше новой функциональности. Это вело к тому, что между моментом возникновения дефекта и его устранением проходило все больше времени. Это в свою очередь значительно увеличило вариативность и время/усилия на устранение дефекта из-за усугубляющего негативного воздействия долгоживущей ошибки (например, из-за обходных решений и сильной связанности), а также потому что разработчики со временем забывали детальный контекст связанного с дефектом кода и, следовательно, им требовалось восстановить в памяти этот контекст, вокруг которого к тому времени оказалось еще больше грязного запутанного кода.

Проницательный читатель мог заметить несколько петель положительной обратной связи, которые усиливали этот цикл деградации; неудивительно, что при такой динамике продукт был выпущен на несколько лет позже, чем предполагалось.

Решение? Использовать принципы бережливого подхода «остановись и исправь» и «пойди и посмотри». Во-первых, когда возникают проблемы, вместо того чтобы пытаться двигаться быстрее, менеджер-учитель побуждает людей замедлиться, понять системную динамику и корневые причины и устранить их – чтобы улучшить систему. Двигаясь медленнее, Toyota – чемпион бережливого мышления – стала одной из самых быстро развивающихся компаний в мире. Во-вторых, менеджерам нужно пойти туда, где делается реальная работа, и посмотреть, что происходит. «Реальная работа» в программировании – это код; следовательно, менеджеры первого уровня должны быть квалифицированными программистами, которые способны оценить качество кода и должны делать это регулярно.

Когда релиз все-таки состоялся, люди в Microsoft наконец-то провели ретроспективу и проанализировали произошедшее. Результатом стало принятие компанией политики «ноль дефектов», которая требует в первую очередь исправить все известные дефекты в разрабатываемом коде – свести список открытых дефектов к нулю – и только затем приступать к работе над новой функциональностью.

Учимся видеть корневые причины

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

Попробуйте… выявлять корневые причины с помощью причинно-следственного моделирования, метода «Пять почему» и диаграмм Исикавы

Непрерывное улучшение – один из двух столпов бережливого подхода. В Toyota существует культура «останови и исправь», которая состоит в следующем:

1. Когда люди видят проблему, они останавливаются…

2. Анализируют ее, чтобы найти корневые причины…

3. Проводят эксперименты по изменению процесса, чтобы исправить проблему и улучшить систему.

Следующие простые инструменты помогают обсудить проблему и выявить корневые причины:

метод «Пять почему» (рассматривается в главе о бережливом подходе);

диаграммы Исикавы («Рыбья кость»).

Оба инструмента следует применять на групповых встречах – например, в ходе ретроспектив спринта в скраме.

Выявление корневых причин с помощью диаграмм Исикавы