Бас Водде
Масштабированный скрам. Как организовать гибкую разработку в крупной компании
Учимся видеть системную динамику
Статическая сложность против динамической сложности
Многие из нас, особенно инженеры и финансисты, обучены хорошо справляться со статической сложностью – решением таких задач, как анализ и управление информацией (требованиями, финансовыми данными и пр.), разбивка сложных структур на более простые и т. д., то есть со сложностью статического, информационного или структурного характера.
Почему большие программные системы имеют тенденцию деградировать, несмотря на то что на работу с дефектами тратится все больше и больше времени? Что может случиться, если США вторгнутся в Ирак? Чтобы увидеть динамику, стоящую за этими вопросами, требуется анализ комплексной динамики.
В отличие от обучения статическому анализу, многие из нас не получают формального образования в области анализа динамической сложности[7], особенно динамики рабочей среды. Возможно, причина этого – в распространенном мнении, что здесь достаточно полагаться на здравый смысл. Но Форрестер продемонстрировал, что «здравый смысл» не справляется с комплексными системами, и показал, что обучение людей формальным методам, в частности таким, как использование моделей системной динамики, визуализированных в виде диаграмм потоков [Forrester61], позволяет улучшить их способность к системному мышлению в рабочей среде.
Диаграмма потоков охватывает материальные, финансовые и информационные потоки, метрики (переменные, имеющие количественные значения, такие как финансовые средства или количество дефектов), последствия решений и правил, а также причинно-следственные связи. Популярное упрощение – диаграмма причинно-следственных циклов, которая фокусируется на действующих в системе причинно-следственных отношениях и петлях обратной связи [Sterman00]. Существует несколько вариантов нотаций таких диаграмм; во всех них присутствуют метрики (количественные переменные), причинно-следственные связи и задержки (отложенные эффекты). Вайнберг [Weinberg92] называет это диаграммой влияний.
Первый закон построения диаграмм: моделируйте, чтобы обсуждать
Чтобы научиться видеть системную динамику, используйте диаграммы причинно-следственных циклов, которые в идеале следует нарисовать на доске совместно с коллегами в ходе ретроспективы спринта. Но прежде чем двигаться дальше, давайте рассмотрим первый закон построения диаграмм:
Основная ценность диаграмм заключается в дискуссии, возникающей в процессе их построения: мы моделируем, чтобы инициировать обсуждение.
Когда группа собирается, чтобы нарисовать на доске диаграмму причинно-следственных связей (рис. 2.1), основная ценность состоит в обсуждениях и общем понимании, которое зарождается в ходе построения модели. Визуализация в виде наглядной диаграммы также важна, чтобы сделать идеи конкретными и однозначными – явно отобразить ментальные модели, которые есть у участников, – потому что слова сами по себе могут быть расплывчатыми и неправильно интерпретируемыми. Тем не менее сама диаграмма вторична по отношению к тому, что люди уносят с собой: новые идеи и более глубокое понимание, пересмотренное в результате обсуждения.
Базовые проблемы и простые удобные инструменты
С годами мы овладели очень продвинутыми, сложнейшими приемами анализа и разработки решений в области инженерии, менеджмента и т. д. Поначалу мы были вдохновлены этими инструментами и стремились применять их и обучать им других людей при любом случае, пока в ходе реальной работы не поняли, что:
подавляющее большинство проблем в бизнесе (в том числе в разработке) носят настолько базовый характер[8], что ключевым решением является обучение и планомерное использование простых и удобных инструментов мышления и действия.
Простота. Книги и курсы по моделированию системной динамики и построению диаграмм причинно-следственных циклов имеют тенденцию чрезмерно все усложнять, предлагая забираться в такие дебри, как концепция архетипов, описанная в «Пятой дисциплине», компьютерное моделирование, нелинейные уравнения и т. д. На практике это только отпугивает людей от использования этого, в сущности, очень простого инструмента: вам нужно всего лишь встать у доски, обсудить со своими коллегами, какие причинно-следственные связи и петли обратной связи действуют в вашей системе, и отобразить их в виде диаграммы на доске.
Когда вы выбираете инструменты мышления или действия для использования в рабочей среде, помните слова Вольтера:
«Le mieux est l'ennemi du bien» («Лучшее – враг хорошего»).
Удобство. Существует множество изощренных инструментов мышления и действия, которые так любят теоретики, но которые почему-то никак не приживаются на практике. Вместе с тем практики скрама или экстремального программирования (XP), будучи раз внедренными, становятся очень «липкими». Почему? Во-первых, они быстро приносят реальную отдачу: у них привлекательное соотношение затрат и выгод и их внедрение быстро окупается. Во-вторых, эти практики не требуют мучительных усилий; большинство людей, которые их используют, говорит, что применяет их с интересом и даже с удовольствием (и, разумеется, с пользой). Люди есть люди: они предпочитают делать то, что им нравится.
Удобство и простота инструментов особенно важны в крупномасштабных разработках, так как устойчивое внедрение практик и процессов становится тем труднее, чем больше размер группы. Ваши инструменты должны привлекать людей, как яркие ароматные цветы притягивают к себе пчел.
Диаграммы причинно-следственных циклов
В этой книге мы будем не раз обращаться к диаграммам причинно-следственных циклов, потому что они помогают увидеть динамику того, что происходит при крупномасштабной разработке в больших группах. Уже только по одной этой причине полезно разобраться в этих диаграммах. Чтобы они были еще полезнее, мы рекомендуем:
Попробуйте… чертить диаграммы причинно-следственных циклов на групповых встречах, чтобы увидеть системную динамику.
Попробуйте… чертить диаграммы причинно-следственных циклов на доске вместе с коллегами
Практическая ценность этого совета намного важнее, чем может показаться на первый взгляд. Фраза «нам нужно системное мышление» слишком расплывчата и малоэффективна. Но, если вы со своими коллегами сделаете своей привычкой вместе вставать у большой доски и рисовать диаграммы причинно-следственных связей, это будет уже конкретная практика, которая превратит абстрактный призыв к системному мышлению в реальный системный подход – с потенциально далекоидущими последствиями.
Приведенные далее примеры могут показаться «теоретическими», когда они изложены на бумаге. Но представьте, что эти диаграммы были составлены вами в процессе живого общения с коллегами, когда вы вместе стояли у доски и горячо обсуждали каждый момент. Именно так мы рекомендуем применять системное мышление на практике.
Конкретный совет по построению диаграмм. Мы начинаем с того, что записываем на стикерах задействованные переменные, например «скорость разработки фич» или «количество дефектов», и размещаем стикеры на доске. Затем проводим между стикерами линии причинно-следственных связей. В процессе построения модели всегда приходится много переписывать, стирать, перерисовывать. Самый важный результат таких сессий – совместное понимание. Некоторые участники захотят сфотографировать то, что получилось на доске.
Нотации и примеры
Диаграммы причинно-следственных циклов содержат много элементов; вот список наиболее типичных и полезных, которые будут рассмотрены дальше в сценарии:
● переменные;
● причинно-следственные связи;
● обратные эффекты;
● ограничения;
● цели;
● реакции;
● «быстрые решения»;
● эффекты взаимодействия;
● сильные эффекты;
● отложенные эффекты;
● петли положительной обратной связи.
Далее приведен упрощенный сценарий разработки диаграммы для конкретной организации. Не рассматривайте это как общий случай.
Переменные. Диаграммы причинно-следственных циклов включают переменные (или метрики), такие как скорость разработки (поставки) новой функциональности и количество дефектов. Переменные имеют измеримую величину.
Причинно-следственные связи. Один элемент может влиять на другой, например увеличение скорости разработки может вести к увеличению количества дефектов; то есть чем больше объем нового кода, тем больше дефектов.
Скорость разработки
Уже на этом этапе можно столкнуться с законом Вайнберга‒Брукса и ловушкой причинно-следственной связи. Нарисовать схему легко; совсем другое дело – построить ее с правильным пониманием. Например, рассмотрим взаимосвязь между количеством разработчиков и скоростью разработки.
Природа некоторых причинно-следственных связей не всегда очевидна. Но людям свойственно делать поспешные выводы, что рост числа разработчиков ведет к ускорению разработки. Однако увеличение команды, особенно на поздних стадиях разработки, способно, наоборот, уменьшить скорость (подпункт «Закона Брукса» [Brooks95]). Кроме того, большое число плохих программистов может существенно замедлить работу, и часто бывает, что их удаление из группы хорошо сказывается на общей скорости.
Обратные эффекты. Эффект причинно-следственной связи может быть не только прямым, но и обратным: например, рост A ведет к росту Б, и наоборот. Обратный эффект обозначен на диаграмме символом «О» рядом с линией. Допустим, что увеличение количества дефектов создает препятствия для дальнейшей разработки, что, как следствие, замедляет скорость поставки новой функциональности, потому что люди тратят больше времени на исправление ошибок или поиск обходных путей.
Ограничения. Если только вам не удастся найти людей, готовых работать бесплатно, у вас есть ограничение на количество разработчиков, которых вы можете нанять исходя из имеющегося бюджета.
Ограничения – это не причинно-следственные связи. Увеличение бюджета не ведет напрямую к увеличению числа разработчиков.
Цели и реакции. Люди, группы и системы имеют цели – например, увеличить скорость разработки. Цели создают давление, побуждая людей реагировать (действовать) с намерением достичь этих целей. Но, принимая во внимание закон Вайнберга‒Брукса и ловушку причинно-следственной связи, следует быть осторожными в своих предположениях о том, какие действия могут пойти на пользу в данной ситуации. Итак, добавим в нашу схему цель и реакции, которые она запускает:
Цель, подкрепленная вознаграждением, побуждает людей не только действовать, но и создавать видимость действий и достижений посредством дисфункции измерения, которая порождается предложенной системой вознаграждения. И дисфункция измерения может быть прямо пропорциональна воспринимаемой ценности вознаграждения, потому что люди мотивированы получить вознаграждение, а не улучшить систему [Austin96]. Давайте посмотрим, как вознаграждение может привести к снижению производительности системы. Системная динамика может выглядеть так:
Интересно, что вся эта системная динамика возникла из-за введения вознаграждения, причем между верхней частью модели и ее нижней частью пока нет явной взаимосвязи.
Словом, нет никаких гарантий того, что введение вознаграждения обусловливает увеличение скорости разработки – или даже влияет на нее.
Отказ от такой системы вознаграждения – фундаментальное решение, которое позволяет устранить корневую причину этой дисфункции. Другая, пусть более поверхностная, но тем не менее работоспособная контрмера – использование управленческой командой принципа бережливого менеджмента «пойди и посмотри»:
«Быстрые решения». Одно из трудных и медленных решений для увеличения скорости разработки – улучшить человеческий ресурс: нанять сильных разработчиков, расширить обучение и коучинг имеющейся команды, уволить слабых сотрудников. Альтернатива – достичь цели быстро и с наименьшими усилиями за счет «быстрого решения» или так называемого квик-фикса (quick fix). Иногда быстрое решение работает как в краткосрочной, так и в долгосрочной перспективе и действительно улучшает систему. Но иногда это не удается, и тогда получается как в поговорке: «Быстрее – значит медленнее». Например, если стоит цель увеличить скорость поставки новой функциональности, первое, что обычно приходит в голову людям, – увеличить количество разработчиков. Согласно их предположению, это самый быстрый и простой способ решить проблему со скоростью разработки. Итак, добавим в нашу схему это «быстрое решение» (символ БР):
Эффекты взаимодействия. Бюджет ограничивает наем новых сотрудников. Одно из трудных и медленных решений – найти способы увеличить бюджет. Быстрое и простое решение – нанять намного более дешевых разработчиков. В этом случае бюджет оказывает эффект взаимодействия, влияя на другие причинно-следственные связи. Когда принимается решение нанять дополнительных разработчиков, недостаточный бюджет вынуждает вас нанимать наиболее дешевых.
Просто провести (обратную) причинно-следственную связь напрямую от бюджета к коэффициенту найма очень дешевых разработчиков не совсем правильно, так как, по сути, это будет означать, что уменьшение бюджета ведет к увеличению найма очень дешевых разработчиков. Мы же хотим показать эффект взаимодействия – а именно то, что причинно-следственная связь A влияет на причинно-следственную связь Б. Чтобы графически показать это, мы проводим линию обратной причинно-следственной связи от бюджета к линии быстрого решения (БР), которая в результате раздваивается на коэффициент найма обычных и очень дешевых разработчиков:
Сильные эффекты. Нам доводилось работать и с очень крутыми, но недорогими разработчиками, и с очень дорогими, но ужасными. Но, как правило, вы получаете то, за что платите, – нанимая разработчиков из большого пула дешевой рабочей силы, вы получаете в среднем гораздо более низкий уровень квалификации, чем при найме из пула дорогих. В нашей модели мы хотим показать, что наем очень дешевых разработчиков резко увеличивает долю слабых (низкоквалифицированных) разработчиков в группе. Чтобы показать такой сильный эффект в модели, мы используем толстую линию:
Отложенные эффекты. Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации – ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков – наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с бо́льшим количеством дефектов, что дополнительно тормозит всю систему.
Но все эти влияния проявляются не немедленно, а с некоторым запозданием. Например, если вы наймете много слабых разработчиков, пройдет относительно много времени, прежде чем начнут ощущаться последствия их плохой работы / некачественного кода. Соответственно среднее снижение скорости поставки новой функциональности (вызванное сильным влиянием разброса квалификации программистов) произойдет не сразу, а спустя какое-то время.
Чтобы показать такое отложенное воздействие, мы используем на модели линию с двойной чертой:
Отложенный характер эффектов негативно влияет на способность системы к обучению и коррекции. Если результат или случайное следствие какого-либо действия проявляется с большой задержкой во времени, люди часто не видят (причинно-следственной) связи между ними, не понимают, что именно A повлияло на Б или, еще сложнее, что A повлияло на Б, а Б в ответ повлияло на А.
Следовательно, люди не учатся и не исправляют ошибки – в правилах, управленческих действиях, инструментах и т. д. Именно из-за отложенных эффектов постепенное улучшение через практику бережливого подхода кайдзен может занимать длительное время: чтобы увидеть, улучшается ли что-то и как, требуется терпение и способность проникать в суть вещей.
Петли положительной обратной связи. Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.
Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль – последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом.
Попробуйте… увидеть в системе петли положительной обратной связи.
По мере того как уходит все больше крутых разработчиков, которые могли бы создавать отличный код и обучать других, у слабых разработчиков становится все меньше возможностей для обучения. Процент слабых разработчиков растет, а качество кода и производительность падают все ниже. Код становится все более грязным, запутанным, с большим количеством повторений, что снижает способность группы быстро реализовывать новую функциональность. Падение скорости реализации новой функциональности вынуждает нанимать еще больше дешевых разработчиков. Короче, в системе создается множество самоусиливающихся петель положительной обратной связи.
Подсказка: чтобы выявить петли положительной обратной связи, найдите циклы с четным количеством причинно-следственных связей с обратным эффектом. В модели выше мы видим пять таких петель.
Заключение
Приведенный сценарий – это только пример. Диаграмма причинно-следственных циклов позволяет наглядно представить сложную и неявную динамику системы рабочей среды. Лучше всего составлять ее на доске вместе с группой.
Учимся видеть ментальные модели
Приведенная выше диаграмма отражает не только реальные причинно-следственные связи, но и предположения людей о таких связях – ментальные модели, которые могут быть ошибочными. Необходимо отметить, что на человеческое восприятие причин и следствий влияет временно́й интервал между ними (отложенный эффект) и качество обратной связи в системе.
Цель выявления ментальных моделей в том, чтобы улучшить наш метакогнитивный навык видеть и подвергать сомнению собственные предположения и логические цепочки. Не ошибаемся ли мы в нашей логической схеме? Другая цель в том, чтобы узнать и обсудить (не пытаясь оскорбить чужую точку зрения) ментальные модели наших коллег.
Попробуйте… выявлять ментальные модели и предположения через совместную разработку диаграмм причинно-следственных циклов.
Увидеть ментальные модели – только первый шаг; второй, гораздо более трудный шаг – изменить их. Это искусство не входит в тематику данной книги, хотя успешное внедрение масштабированного скрама требует изменений в привычном образе мышления и выработки совместного понимания в большой группе.
Совет: чтобы выявить ментальные модели (предположения, убеждения, цепочки умозаключений и т. д.), связанные с системной динамикой, в ходе построения модели задавайте наводящие вопросы и записывайте ответы. Например: «Давайте поговорим о предположениях, стоящих за этой моделью. Что именно и почему заставляет нас так считать?»
Ответы записывайте на доске рядом с соответствующими элементами модели, например:
Пример: динамика «быстрее – значит медленнее»
Теперь, когда мы разобрались с тем, что такое «быстрые решения», отложенные эффекты, петли положительной обратной связи и ментальные модели, давайте рассмотрим интересную ситуацию, когда «быстрое решение» ведет сначала к кажущемуся краткосрочному улучшению какой-либо переменной, а затем к отложенному ухудшению той же переменной, – то есть динамику «быстрее – значит медленнее». Такая динамика часто встречается в рабочей среде и ведет к снижению производительности. Поэтому она заслуживает отдельной иллюстрации.
История Microsoft Word и секретного инструментария разработчика – классический пример динамики краткосрочного «улучшения» с последующим долгосрочным ухудшением. Речь идет о первом релизе Microsoft Word для Windows [Spolsky04]. Программа была выпущена на несколько лет позже, чем ожидалось. Почему? Потому что менеджеры старались соблюсти первоначально составленный график и давили на разработчиков, чтобы уложиться в срок.
Эта история показывает, почему склонность принимать желаемое за действительное рассматривается в бережливом подходе как один из факторов потерь. В нашем случае принятие желаемого за действительное выражалось в попытке строго следовать первоначальному графику, в основе чего лежало неправильное предположение (движимое все тем же соблазном принимать желаемое за действительное), будто исходные оценки проекта являются не оценками, а обязательствами, – распространенное заблуждение, которое часто ведет к деградации системы.
Рис. 2.2. иллюстрирует базовую динамику того, что происходит, когда менеджеры давят на людей с целью соблюсти первоначальный график, и почему такое «быстрое решение» проблемы медленного прогресса в краткосрочной перспективе вроде бы ускорило работу команды, но в долгосрочной – замедлило ее еще больше. В этой модели мы частично опустили более глубокую динамику, которая будет рассмотрена дальше и представлена на рис. 2.3.
Итак, в качестве «быстрого решения» менеджеры Microsoft уговаривали, подкупали (обещанием премий) и угрожали разработчикам Word, чтобы те уложились в первоначальный график. В результате разработчики вполне предсказуемо прибегли к своему секретному инструментарию – множеству практик, известных как «грязные хаки», которые ведут к написанию грязного кода (без тестов, без инспекции, с игнорированием известных дефектов, копипастом, плохим дизайном и т. д.), чтобы быстрее выпускать новую функциональность. Как видите, у разработчиков тоже есть «быстрые решения» своих проблем.
Поначалу казалось, что эта тактика обладает магическим действием. Чем настойчивее менеджеры давили на разработчиков, тем активнее те использовали свой секретный инструментарий и тем быстрее выпускались «фичи», что усиливало убеждение менеджеров, будто давление на разработчиков помогает. Но у этого обманчивого ускорения имелся отложенный эффект в виде долгосрочного замедления разработки (мы рассмотрим это чуть дальше). Развитие негативной динамики первое время оставалось незамеченным, поскольку последствия использования секретного инструментария проявились не сразу и руководство считало, что менеджерам не нужно самим быть опытными разработчиками, чтобы разбираться в деталях исходного кода или же регулярно проверять его состояние.
Более глубокий анализ системной динамики, который показывает, по какой причине разработка замедлилась в долгосрочной перспективе и почему первая версия Word для Windows была выпущена на несколько лет позже ожидаемого срока, представлен на рис. 2.3.
Естественно, значительный объем грязного кода в конечном итоге замедлил разработку. Хуже того, разработчики игнорировали постоянно растущий список открытых дефектов, генерируя вместо этого все больше новой функциональности. Это вело к тому, что между моментом возникновения дефекта и его устранением проходило все больше времени. Это в свою очередь значительно увеличило вариативность и время/усилия на устранение дефекта из-за усугубляющего негативного воздействия долгоживущей ошибки (например, из-за обходных решений и сильной связанности), а также потому что разработчики со временем забывали детальный контекст связанного с дефектом кода и, следовательно, им требовалось восстановить в памяти этот контекст, вокруг которого к тому времени оказалось еще больше грязного запутанного кода.
Проницательный читатель мог заметить несколько петель положительной обратной связи, которые усиливали этот цикл деградации; неудивительно, что при такой динамике продукт был выпущен на несколько лет позже, чем предполагалось.
Решение? Использовать принципы бережливого подхода «остановись и исправь» и «пойди и посмотри». Во-первых, когда возникают проблемы, вместо того чтобы пытаться двигаться быстрее, менеджер-учитель побуждает людей замедлиться, понять системную динамику и корневые причины и устранить их – чтобы улучшить систему. Двигаясь медленнее, Toyota – чемпион бережливого мышления – стала одной из самых быстро развивающихся компаний в мире. Во-вторых, менеджерам нужно пойти туда, где делается реальная работа, и посмотреть, что происходит. «Реальная работа» в программировании – это код; следовательно, менеджеры первого уровня должны быть квалифицированными программистами, которые способны оценить качество кода и должны делать это регулярно.
Когда релиз все-таки состоялся, люди в Microsoft наконец-то провели ретроспективу и проанализировали произошедшее. Результатом стало принятие компанией политики «ноль дефектов», которая требует в первую очередь исправить все известные дефекты в разрабатываемом коде – свести список открытых дефектов к нулю – и только затем приступать к работе над новой функциональностью.