Кристиан Вервейс: О сложности или зачем вам Скрам? 

Предисловие переводчика 

Предупреждение: Это лонгрид и это достаточно серьезный текст, далекий от большинства “простеньких” объяснений, которые вы могли прочитать на русском про Скрам и Эджайл.  

Оригинал статьи находится тут.

Статья входит в список scrum.org рекомендованного к изучению для подготовки к экзамену PSM III.

Важность таких статей сложно переоценить. Судя по ошибкам, которыми делятся команды, и по некоторым комментариям, немалое число людей, пытающихся применить Agile, на самом деле не пошло дальше материалов типа “строим Скрам за 5 дней”, которые больше сосредоточены на элементарных практиках, а не на причинах и не на основополагающих принципах Скрам и Эджайл. Я сам, как руководитель, изначально столкнулся именно с такой, “от сохи”, реализацией Скрама, но, к счастью для себя, не сделал “обоснованный” вывод что весь этот ваш Скрам - это очередная подделка и модная глупость, а полез разбираться откуда и зачем есть пошел Эджайл и прочие Скрамы. Честно скажу - объем “открытий чудных” был намного больше ожидаемого, несмотря на годы опыта в управлении проектами, накопленные к тому моменту. Так что, надеюсь, что перевод достаточно важной для понимания Скрам статьи будет полезен почтенной публике, и, конечно же, я сам, как сертифицированный Скрам-мастер и человек преподающий Скрам и Эджайл (я помню, коач слово ругательное, буду рад ответить на все вопросы. 

Предисловие

Разработка ПО и продуктов никогда не была чем-то простым, если, конечно же, исключить проекты длиной в пару дней, в которые вовлечены пяток человек. В целом же, все проекты можно рассматривать как сложные. Под сложностью я понимаю “слишком много переменных, влияющих на результат, и возможных связей между вовлеченными людьми, для того чтобы иметь возможность надежно предсказывать хотя бы ближайшее будущее”. Мы часто страдаем от склонности упрощать, звучащей как “это не может быть настолько сложно”, “мы уже это делали”, “мы хорошо знаем что делать”. И я нередко встречал людей искренне верящих что их проект “недостаточно сложен” для того чтобы применять Скрам. Я искренне верю что эти люди просто не понимают что значит “сложен”. В этой статье я покажу пару моделей полезных для понимания сложности и для лучшего понимания чем Скрам (и другие итеративные подходы) лучше. 

Выкинь свои планы?

Большинство людей понимают сложность исключительно в контексте “насколько сложно то, что мы создаем”. Недавно я общался с руководителем, который считал что его проект простой, потому, что речь идет о переписывании огромной, но уже существующей системы. Но ведь это всего лишь один из факторов! На курсах для профессиональных скрам-мастеров мы всегда просим участников найти можно больше факторов, которые влияют на успех проекта (примечание переводчика: имеются в виду курсы Professional Scrum Master и Professional Scrum Master Advanced от scrum.org). Мы даем всего несколько минут, но этого хватает, чтобы участники полностью заполнили лист формата A1. Если бы мы давали целый день, я точно знаю - им бы не хватило стен в классе чтобы записать все факторы. 

Просто, чтобы вы представили, на вскидку можно перечислить:

• Стили и опыт общения в команде

• Правомочия команды и поддержка проекта внутри организации

• Профессиональный уровень вовлеченных специалистов

• Насколько у проекта ясная цель

• Количество вовлеченных в проект

• Техническая и организационная культура 

• Обмен знаниями

• Используемый процесс

• Насколько доступны представители заказчика

• Насколько заинтересованы и вовлечены пользователи

• Выбранный инструментарий

• Нестабильность рынка

• Умение планирования и управления временем

• Мотивация

• Время исполнения проекта

• Качество и размер унаследованного кода

• Отношения с поставщиками ключевых компонент

Некоторые из факторов приведенных выше - просто огромны, например организационная культура, технические навыки, или прозрачность цели. Как вообще можно предсказать не только влияние этих факторов на проект, но и их взаимодействие между собой? Реальность состоит в том, что с таким уровнем непредсказуемости создание планов просто неоправданно. Планы превращаются в неисчерпаемый источник ритуализированных потерь времени и ресурсов, трату ресурсов впустую на составление, прочтение, понимание и поддержание в актуальном состоянии самих планов. Это не означает что мы не должны тратить времени на то, чтобы понять как мы будем все это делать. Мы просто должны делать это способом, учитывающим сложность и непредсказуемость. Как говорил Эйзенхауэр: “планы - бесполезны, но планирование - бесценно”. 

Я собираюсь описать два хорошо известных способа преодоления сложности - матрицу Стейси (Stacey’s matrix) и модель Кеневин (Cynefin).

Примечание переводчика: Позволю себе немного дополнить. Западные источники тоже часто стараются оградить читателя от излишне сложных знаний, но мы-то не такие, да? “Сложность” в данном случае не модная выдумка и не околонаучное словоблудие. Это отрасль науки, входящее в общую теорию систем, называемая “теорией сложных систем”. Теория получила активное развитие с середины 70-х годов прошлого века, и известный ученый и популяризатор науки Хоукинг даже предсказал что 21-й век будет веком познания сложных систем. Итак, что такое сложность, и, самое главное, то самое непонятное слово часто встречающееся в контексте Аджайла - эмерджентность? Система считается сложной, если её поведение невозможно предсказать, зная поведение каждого отдельного элемента системы. Поведение, которое свойственно только системе как единому целому, но не свойственно ни одному её компоненту как раз и называется эмерджентным. 

Выше, где автор говорит об упражнении на их курсах, приведен хороший пример эмерджентности сложной системы - каждый участник в отдельности (даже если бы мы посадили каждого написать свой список на листочке и потом собрали листочки в кучу) - не был бы в состоянии составить насколько исчерпывающий список факторов. Такой список и за такое короткое время возможен как раз для группы участников, совместно работающих на один результат. Взаимодействие разных способов мышления и разного опыта (а это еще один жупел нашего времени - та самая дайверсити!), происходящее в реальном времени, как раз и создает условия для возникновения поведения и получения результата, свойственного только группе. Кстати, когда вам в следующий раз будут рассказывать псевдонаучную байку про групповое перетягивание каната - проведение такого эксперимента по совместному мышлению является самым простым способом показать что это “всё совсем не так”.  

Матрица Стейси

Один из способов понимания сложности - это матрица Ральфа Стейси. За годы её использования было выработано несколько “классических” способов представления, но все они говорят о сложности как о функции от согласованности понимания “что надо делать” и уверенности в знании о том “как надо делать”. Ниже показана матрица в виде, адаптированном для процессов разработки ПО. 

Матрица Стейси создана, чтобы помочь руководителям понять степень сложности, с которой они столкнулись, и выбрать адекватную модель принятия решений. Для разработки ПО матрицу организуют по координатам “Требования” (Что делать?) и “Технологии” (Как делать?). Первая определяет насколько хорошо нам известно какой именно продукт следует создать, вторая - насколько хорошо нам известно как именно следует создавать продукт. Матрица как она представлена на рисунке не совсем совпадает с оригинальной матрицей в работах Стейси, но использует те же самые концепции. Матрица определяет четыре типа ситуаций:

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

Усложненная: Проект усложнен, если нам не очень хорошо понятно что мы будем делать или как мы будем делать. Я часто привожу пример инструментария для Web. Реализация достаточно понятна, достаточно взглянуть на схожие решения, типа Magneto или WooCommerce, но вот в чем именно нуждается рынок и как именно представить рынку новый продукт уже не так очевидно. Другой пример - стыковка интерфейсов двух разных систем. Что делать вполне понятно - вот хорошо задокументированный интерфейс одной системы, вот хорошо задокументированный интерфейс другой системы. Но вопрос “как” уже не так однозначен, начиная прямо с вопроса “какие данные в одной системе соответствуют конкретным данным в другой системе”? Часто ответить на все эти вопросы заранее просто невозможно. Кто-то может сказать что анализ, проектирование и разработка вполне решает такие задачи, но по моему опыту - не очень. Именно итеративная разработка может помочь здесь. 

Примечание переводчика: По моему мнению в выводах автор зря уходит от теории сложности, предлагая доверять его всего лишь его опыту. Предсказательный подход (чаще известный как “водопад”) весь построен на одной посылке - систему можно полностью изучить разобрав её на части и изучив каждую часть. Именно на этом построен хорошо известный механизм упрощения сложных и больших задач - декомпозиция. Мы разбираем требования на части (OOA), мы разбираем дизайн на части (OOD/OOP), мы разделяем работу на маленькие кусочки (WBS) и рассчитываем что в итоге у нас получиться именно то что нам надо. Каждый кусочек-то правильный, так? Теперь вернемся в вопросу “а что такое сложная система и что такое эмерджентное поведение”. А ведь это система, поведение которой не объясняется поведением отдельных частей! То есть, весь предсказательный подход в принципе не может работать для сложной системы - методы которые там применяются просто не предназначены для понимания и создания сложных систем, они не учитывают поведения возникающего только у системы в целом.

Сложная: В сложной системе нам не очень хорошо известно ни что делать, ни как делать. Взаимодействие между неизвестными нам переменными настолько сложны, что их просто невозможно предсказать заранее, а значит любой план, построенный на предсказаниях будет бесполезен. Вместо того, чтобы управлять тем, чем мы управлять не способны - лучше использовать более подходящий процесс управления - эмпирический. В эмпирическом процессе принятие решение происходит на основе того, что уже случилось, а не на основе того, что мы ожидаем что случиться. Поэтому мы ведем работу небольшими шагами, постоянно проверяя приближаемся ли мы к конечному результату. Scrum является примером такого процесса. 

Примечание переводчика: В русском языке эмпирический подход еще называют научным подходом - способом познания неизвестного путем высказывания теоретически обоснованной гипотезы и проведении эксперимента по ее проверке, объективного и повторяемого. Скрам использует эту же самую терминологию когда мы говорим об управлении. Цель спринта, как и спринт бэклог являются не более чем гипотезами о том, что реализация выбранной функциональности создаст ожидаемую заказчиком ценность, а команда способна эту функциональность реализовать. Спринт является, по сути, экспериментом по проверке этих гипотез, ревью - валидацией результата эксперимента, а ретроспектива - адаптацией процесса на основе новых знаний, полученных в результате проведенного эксперимента. Предиктивный процесс совершенно некорректно сравнивает разработку ПО с массовым производством и пытается применить методы массового производства к работам, которые по сути являются НИОКР (научно-исследовательские и опытно-конструкторские работы). Ни на одном заводе и ни в одном КБ такой глупостью, как внедрением методов массового производства в конструкторскую работу никогда не занимались. А вот если посмотреть как работают в результативном КБ - то внезапно окажется что это очень похоже… на все тот же Аджайл. Такие дела. 

Хаотичная: В правом верхнем углу зарезервировано место для процессов находящихся в непрерывном изменении. В таких местах даже вчерашний опыт оказывается бесполезным для предсказания будущего и принятия решения. Представьте себе к примеру глобальный отказ энергосистемы. Лучшее что мы можем сделать - это, подобно медикам, заняться триажем - выбирать где сейчас мы можем приложить усилия с для достижения наибольшей возможной пользы.

Примечание переводчика: Термин триаж пришел из сортировки раненных военными врачами или в медицине катастроф. Цель триажа в первую очередь оказать помощь тем, кого можно спасти и кто без оказания немедленной помощи не выживет. В целом и общем - это поиск баланса между “вот этим уже не помочь” и “вот эти вполне подождут”, в ситуации когда время потраченное на принятие решения уменьшает шансы на успех лечения. 

Итеративный подход может быть эффективен и тут, но с двумя условиями. Во-первых итерация должна быть очень короткой, во-вторых объем работы в итерации должен быть жестко ограничен. 

В нашей модели добавлена ещё одна ось, которой нет в исходной матрице Стейси - количество вовлеченных людей. Это отражает увеличение сложности любого процесса при увеличении количества вовлеченных людей. Работа элементарная для одного может оказаться сложной для группы, просто представьте себе выбор “какое бы кино посмотреть” компанией из десяти человек. 

Ограничения матрицы Стейси

Интересно, что сам Стейси отказался в итоге от использования матрицы, объясняя это тем, что все работы - сложные. Даже самая простая работа внезапно может оказаться сложной, если “что-то пошло не так”. 

Вторая причина заключается в том, что бездумное использование матрицы может создать впечатление что мы можем уменьшить сложность системы просто “усилием мысли”, например потратив немного времени на то, чтобы договориться что мы будем делать или как мы будем делать. Иными словами “все что нам надо - просто еще больше планирования”. Но это совершенно противоречит тому, что пытался донести Стейси своей матрицей. 

И, наконец, третья причина в том, что матрица “как есть” учитывает только “согласованность” и “определенность” (примечание переводчика: координаты в оригинальной матрице Стейси), но на самом деле сложность зависит от большего числа факторов, таких как способность людей договариваться, умение применять имеющиеся навыки, состояние культуры в компании и даже просто неудачное стечение обстоятельств. 

Модель Кеневин (Cynefin framework)

Модель Кеневин была разработана в 1999 Дейвом Сноуденом (Dave Snowden) из АйБиЭм, чтобы помочь лидерам и управленцам лучше понять ситуацию, в которой они оказались и выбрать правильную стратегию действий. Позже модель была доработана Синтей Курц (Cynthia Kurtz). Модель активно используется Эджайл-сообществом и помогает объяснить почему Эджайл вообще и Скрам в частности хорошо подходят для разработки ПО. Модель выглядит сложнее матрицы Стейси, но дает более четкое объяснение. 

Говоря простыми словами, Кеневин определяет пять видов сложности, которые принципиально различаются между собой. Соответственно, модель утверждает что есть четыре способа познания неизвестного. Каждому виду сложности соответствует свой способ познания и свой подход к управлению. Хотя модель выглядит как квадрат 2x2, на самом деле в ней нет осей абсцисс и ординат. 

Виды сложности:

Простое. В простой ситуации очевидно что делать, так как проблема понятна, а путь решения хорошо известен и проверен. Диагностика проблемы и выбор решения не требует экспертных знаний. Такие задачи хорошо решаются выбором “лучших практик” (best practices). Управление строится на диагностике ситуации (осознай), понимании к какой уже известной категории относится проблема (упорядочь) и к выбору и применению известного и устоявшегося метода решения (реагируй). Примером такой ситуации может быть колл-центр, использующий готовые сценарии для звонков. Для управления в простой ситуации достаточно убедиться что люди понимают что надо сделать и как надо сделать. 

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

Сложное. В сложной ситуации и проблема и способы решения по большей части неизвестны. В такой ситуации даже найти правильного эксперта или задать правильный вопрос - уже сложно (мы имеем дело с “неизвестными нам неизвестным”). И понимание проблемы и поиск её решения требуют активного экспериментирования, до тех пор пока не начнет проявляться подходящий способ решения. И если общее направление еще может быть известно заранее, окончательное решение остается неясным до тех пор, пока оно не будет найдено. Подход к управлению строится на планировании и проведении эксперимента (попробуй), на анализе результатов эксперимента (осознай) и выборе нового эксперимента на основе полученных ранее знаний (реагируй). (примечание переводчика: коллеги, применяющие методы Деминга и их производные, такие как Kaizen или SixSigma без труда узнают цикл PDCA - plan, do, check, act). Наиболее эффективный стиль управления в такой ситуации - сотрудничество. 

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

Беспорядок. Область в центре модели зарезервирована для ситуаций, в которых сложность неизвестна. Сноуден добавил эту область, чтобы подчеркнуть важность того, что любые действия должны начинаться с понимания ситуации, в который мы находимся, и использования доступных данных и информации для оценки сложности ситуации. Если таких данных нет - то ситуация остается беспорядочной. Приоритет в таком случае остается за определением степени сложности ситуации и выборе правильной стратегии решения проблем. 

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

Знания, границы и где тут Скрам 

Ключевой элемент Кеневин - это знание. Наше понимание ситуации помогает сделать и проблему и способ решения более очевидной. Используя рекомендуемый для каждого варианта подход - мы в первую очередь лучше понимаем проблему, с которой столкнулись. И это помогает нам снизить степень сложности. 

Представьте что мы находимся в хаосе, скажем, обычный наш пример массового отказа систем.  У нас нет времени сидеть и думать, мы сортируем проблемы по важности и решаем то что можем решить здесь и сейчас. Принцип: важное - вперед, жестко ограниченное количество незаконченный работы (work in progress). Рано или поздно, все эти действия приведут систему в более упорядоченное состояние и дадут нам время на более продуманные решения. 

В сложной системе, если следовать Сноудену, Скрам позволяет сделать сложное просто усложненным. Скрам разделяет большую проблему (например продукт) на множество мелких проблем (PBI), и каждый из отдельных кусочков уже будет просто усложненным. 

Таким образом, изменяя наше поведение, мы способствуем лучшему пониманию ситуации. Это помогает двигаться по модели по часовой стрелке - от хаоса - к сложному, от сложного - к усложненному, и, наконец, - от усложненного к простому. Между простым и хаосом находится перевал (иногда “обрыв”) показывающий возможность падения из простоты обратно в хаос. Такое случается, например, когда устоявшиеся лучшие практики устаревают, но их упорно продолжают применять. Или, например, когда человек, обладающий критически важными для продукта знаниями, покидает компанию, не передав знания и опыт кому-то еще. При первой же возникшей проблеме оставшимся придется иметь дело с хаосом и собирать головоломку утерянных знаний заново. 

Самый важный урок тут заключается в том, что разработка ПО никогда не бывает простой. Она усложнена, сложна, и иногда просто хаотична. Когда нам не хватает знаний ни о том, что следует получить, ни о том как мы будем это делать - итеративный подход позволяет нам найти и проблему и решение. Сколько бы мысленных усилий мы не тратили на предсказания, огромное количество влияющих на ситуацию факторов легко сделают эти предсказания беспочвенными. А значит использование далеко идущих планов в сложном окружении легко “доведет вас до цугундера”. 

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

Так что там про Скрам? 

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

Примечание переводчика: Повторюсь, важность этой статьи для понимания Эджайл и Скрам сложно переоценить. Обратите внимание, что в ней совершенно не говориться о “методах и практиках” - ни о ревью, ни о парном программировании, ни о, прости Господи, еще каком тим-билдинге. Вместо этого в ней выводятся очень важные признаки того, что проектная команда действительно реализует Эджайл. 

• Если команда осознает недостаток своих знаний о проблеме и способах её решения.

• Если команда организует свою работу признавая и учитывая этот недостаток знаний

• Если команда стремиться к получению дополнительных знаний о проблемах и способах решения путем эксперимента

• Если команда осознанно и обоснованно использует практически полученный опыт для улучшения своих знаний и для изменения своего поведения сообразно ситуации.

Вот тогда и только тогда команда действительно делала Эджайл. А не тогда, когда команда разбрелась как “подружки по парам” делая типа XP, и не когда они собираются на формальный митинг для пляски с бубнами в течении 15 минут ежедневно, называя их точно также, как в скрам-гайде. Такие дела.