Командный подход в «схватке» со сложностью: где и чем может быть полезен Scrum

Представьте, что вы — участник команды, которой нужно модернизировать существующую систему школьных электронных дневников. Думаю, за час вы испишете десятка два страниц, описывая потенциальные проблемы, сложности, подводные камни и узкие места. И идеи ещё не закончатся. Это простой проект или сложный?

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

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

Может казаться, что, если мы хотим создать сложную, высокотехнологичную систему, например сервер, систему хранения данных или программное решение, нужно просто нанять больше инженеров. Но как показывает практика, это работает лишь до определённого момента. Затем эффект от увеличения команды сходит на нет, потому что результативность и продолжительность встреч напрямую зависят от количества участников. Чем их больше, тем сложнее договориться между собой.

Оптимальное количество можно посчитать. Существует формула, по которой рассчитывают количество коммуникаций: N = n (n − 1)/2, где n — количество людей в команде. Для пяти человек понадобится 10 каналов коммуникаций, а для девяти — уже 36. По моему опыту, соблюдать баланс между эффективными коммуникациями и КПД команды получается, когда в ней не больше семи участников.

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

При создании сложных комплексных систем почти невозможно правильно понять задачу до того, как начнётся работа над ней. Написать техническое задание и оставить разработчиков с их собственным пониманием того, что нужно сделать, — это всё равно что оценить вероятность встречи динозавра на улице в 50%: «Либо встречу, либо нет».

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

Профессор Эдвард Деминг впервые приехал в послевоенную Японию в 1946 году. Дома, в Штатах, его идеи не нашли понимания, а вот в маленькой, бедной ресурсами и людьми Стране восходящего солнца методы статистического контроля качества были восприняты на ура. Доработанный профессором метод Шухарта, получивший впоследствии второе название — цикл Деминга, был массово внедрён в японских компаниях.

Хиротака Такеучи и Икуджиро Нонака в 1986 году выпустили статью The New New Product Development Game. Они исследовали успешный опыт быстрого создания принципиально новых продуктов на примерах компаний Honda, Xerox, Canon, Epson, NEC, Brother и других. Оказалось, что самые успешные компании использовали итеративно-инкрементальный подход, где стадии работы над проектами накладывались друг на друга.

А самое главное, эти компании сделали ставку на амбициозные цели и кросс-функциональные команды, которые сами решали, как запланировать и выстроить работу и каким способом достигнуть цели. Это приносило впечатляющие результаты. Команде проекта FX-3500 из компании Fuji Xerox удалось за два года разработать копировальный аппарат, который работал не хуже, чем премиальная модель, и стоил в два раза дешевле.

Работы Хиротаки Такеучи легли в основу течения, которое впоследствии назвали бережливым производством. Его цель — сократить количество действий, которые не добавляют ценности продукту. Для этого нужно постоянно рационализировать бизнес-процессы и вовлечь в эту задачу каждого сотрудника.

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

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

Scrum — это фреймворк. Не метод, не процесс, не набор практик. Всё это подразумевало бы законченный набор принципов и инструментов. Scrum же просто показывает, как именно эмпирический процесс может быть применён к разработке ПО, если использовать:

• прозрачность — понимание всеми в первую очередь главной цели;
• инспекцию — регулярную и частую проверку текущего состояния в его динамике на пути к цели;
• адаптацию — сбор и анализ информации, полученной в рамках инспекции, и принятие решений на её основе.

Это реализация эмпирического получения опыта.

Вот характеристики команд, работающих по Scrum:

1. Это всегда кросс-функциональные команды, внутри которых есть все нужные компетенции, чтобы реализовать сложную комплексную задачу. Нет необходимости обращаться в другие центры экспертизы (например, за дизайном сайта или приложения) — люди с нужными компетенциями есть внутри команды.
2. У команды одно информационное пространство. Это может быть как офис, так и общие чаты, облачные пространства, одни и те же списки рассылки и иные инструменты для коммуникации.
3. Команда терпимо относится к ошибкам. Это принцип fail fast — чем раньше ты обнаружишь, что совершил ошибку, тем скорее она будет исправлена, а команда получит новую информацию о проекте. Но важно понимать, что итеративный подход подразумевает, что стоимость ошибки не должна быть слишком велика. По Scrum нельзя построить самолёт или сделать хирургическую операцию.
4. Никакой избыточной документации.
5. Предсказания, а не обязательства — как говорилось выше, на первый план выступают практический опыт и знания, накопленные ранее при работе с проблемой. У команды должна быть возможность проводить эксперименты и исследовать. Если задачу можно просчитать на старте, а для её выполнения нужно точно выполнить план — не будет смысла работать по Scrum. Только зря потратите деньги и время на команду, scrum-мастера и проведение встреч.
6. T-shape-развитие компетенций — в командах нет жёсткого функционального разделения ролей, коллеги перенимают опыт друг у друга и используют новые знания, ускоряя работу над проектом.

Вот как на схеме выглядит процесс спринта.

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

Scrum — гибкий фреймворк, и часто считают, что гибкость подходит для описания самого процесса. Но это не так. Эмпирика здесь относится к конечной цели. Команда фиксирует объём работ на период в две недели или месяц — спринт, который циклически повторяется, — и в течение этого времени работает по достаточно жёстким правилам. Составляет бэклог задач на этот отрезок, укладывается в запланированное на встречи время, соблюдает правила код-ревью, берёт именно те задачи, которые надо брать, а не те, что вдохновляют.

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

В сложных системах наиболее ценным источником информации являются не предсказания и экспертные мнения, а практический опыт и знания, накопленные при работе с проблемой ранее. Это основа эмпирического итеративного процесса. Вот примеры.

• Разработчик ПО сменил работу, и его попросили оценить, сколько времени займёт настройка новой системы сборки. На прошлом месте он постоянно использовал Bazel, который применяется и на нынешнем проекте. Разработчик легко сориентируется сам и даст знать команде о реальных сроках.
• И наоборот: специалист может прекрасно разбираться в последнем стандарте C++, но если он не в курсе, как организован логгер и что именно триггерит исключения в новом проекте, то точность оценки времени его работы будет те самые 50% из анекдота — может, угадал, а может, нет.

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

Закончилось это всё красивым итальянским словом «фиаско»: когда проект был закончен, для него просто не нашлось заинтересованных пользователей. Те, кто выражал интерес в самом начале, нашли альтернативу, а система координат заказчика, увы, не совпадала с системой координат основной массы потенциальных покупателей. А теперь подсчитайте зарплату шести сеньоров в течение двух лет. Её можно было потратить с большей пользой, если бы заказчик работал вместе с командой над достижением общих целей — то есть вёл себя как владелец продукта.

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

• Кому нужны результаты моей работы?
• Кто будет пользоваться этими результатами?
• Как я проверю, что всё сделал правильно?

Эти и множество других вопросов, подходящих именно под ваш проект, должны задавать себе все — от начинающего разработчика до матёрого владельца продукта. Даже эти простые и очевидные вопросы существенно упростят жизнь и помогут сделать шаг навстречу эффективной работе.

Мой опыт показывает, что фреймворк Scrum — это не философский камень, не панацея и не серебряная пуля. Это инструмент, который, как и другие, нужно применять по назначению. И надо учиться это делать. Кен Швабер прав, Scrum похож на шахматы: доступен в изучении на первый взгляд, но непростой, если ставится цель стать мастером. И если про парусный спорт говорят, что это игра в шахматы в гамаке под дождём, то, пожалуй, Scrum — это фонарик, который подсвечивает вам путь по горному перевалу, где вокруг туман, а шаг в сторону — обрыв. Но за горным перевалом вас ждут отличные результаты эффективной работы вашей команды. Поэтому: keep calm and Scrum ON!