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

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

Изображение создано
с помощью нейросети
Изображение создано с помощью нейросети
757
0
7 августа 2023

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

Из статьи вы узнаете
  • как рассчитать количество каналов коммуникаций в команде
  • что такое эмпирическое управление процессами и для каких проектов оно подходит
  • как устроен процесс работы по Scrum

Мир большой сложности

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

Кристиан Вервейс, scrum-мастер и автор множества материалов о фреймворке, понимает сложность как «слишком много переменных, влияющих на результат, и возможных связей между вовлечёнными людьми, для того чтобы иметь возможность надёжно предсказывать хотя бы ближайшее будущее».

Почитайте перевод его статьи «О сложности, или зачем вам Скрам?» на «Хабре».

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

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

Расходы на коммуникации

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

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

Баланс между эффективными коммуникациями и КПД команды

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

Медленная обратная связь

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

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

Как люди учились работать со сложными комплексными системами

Хорошая новость в том, что мы не первые сталкиваемся с вызовами сложных систем. Нам есть на чьи труды опереться и что почитать. Множество способов и методов управления пришли к нам из производства. Три автора, работы которых я обычно вспоминаю, когда рассказываю про Agile и Scrum, — это Эдвард Деминг, Хиротака Такеучи и Джефф Сазерленд.

Эдвард Деминг

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

Это формализованный алгоритм действий руководителя для принятия решений. Он позволяет организовать получение структурированной обратной связи и корректировать рабочий процесс в зависимости от неё.

Хиротака Такеучи

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

Иллюстрация из статьи
Источник: «The New New Product Development Game», Harvard Business Review

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

Хиротака Такеучи и Икуджиро Нонака проводили аналогию с игрой в регби. Цель команды — донести мяч на половину поля противника. В каждый конкретный момент мяч находится в руках только одного игрока, а остальные отслеживают, что происходит на поле, помогают игроку с мячом продвигаться вперёд, а если нужно, перехватывают инициативу, чтобы достигнуть цели.

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

Джефф Сазерленд

Третий автор, о котором нужно рассказать — Джефф Сазерленд, участник Agile Aliance и один из авторов фреймворка Scrum. Его книгу «Scrum. Революционный метод управления проектами» называют азбукой scrum-мастера. Она формирует начальные представления о том, что такое фреймворк, как и откуда он появился, где применим и почему его используют в спецслужбах и строительстве, часто даже не предполагая этого.

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

Основы Scrum

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

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

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

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

«Скрам основывается на эмпирическом управлении процессами, а не на детерминированном. Эмпиризм означает, что процесс адаптируется к данным, получаемым в ходе работы. Очевидно, процесс с эмпирическим управлением всегда дороже, чем обычный процесс с детерминированным управлением. Поэтому детерминированный подход применяется всегда, когда механизмы процесса достаточно хорошо понятны. Если же механизмы плохо известны, детерминированный подход не приводит к продукту с необходимым соотношением цена/качество с первого раза и продукт приходится переделывать». Источник: scrumtrek.ru

Принципы формирования команд

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

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

ЭЛЕМЕНТЫ SCRUM: РОЛИ, СОБЫТИЯ, АРТЕФАКТЫ

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

Схема спринта в Scrum
Обычно от гибких подходов бизнес ожидает сокращения времени создания и выхода продукта на рынок. Согласно исследованию «Agile в России 2021» компании ScrumTrek, достижение этой цели отмечают больше половины участников опроса: в 2021 году этот показатель в России составил 58% (в среднем по миру — 64%).

Заметки практика

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

Работаем короткими отрезками

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

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

Опираемся на практический опыт

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

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

Своевременно получаем обратную связь

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

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

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

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

Задаём правильные вопросы

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

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

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

В заключение

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

Наверх
Будь первым, кто оставит комментарий