Как избавиться от потерь в процессе разработки ПО?

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

Далее пойдет речь в контексте фреймворка LeSS (не LeSS Huge), где один 1 Владелец Продукта, 1 Бэклог Продукта и от 2 до 8 Команды Разработки (от 3 до 9 человек в каждой). Как гласит один из принципов LeSS - это всё тот же Скрам, который описан в руководстве по Скраму. Например, нет никаких новых ролей кроме: Владельца Продукта, Скрам-мастера и Команды (Команды Разработки).

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

Я часто слышу такие вопросы. И вот зачем.

На материальном производстве (фабрике, заводе, пиццерии) потери легко заметить даже неспециалисту - их можно увидеть или пощупать. Потери - это то, во что вложены силы, деньги и время, но что ещё не участвует в генерации денежного потока для компании. Например, склады с неготовой продукцией, дефекты в производстве, устаревшее оборудование, требующее ручного труда, приготовленные, но не проданные пиццы. Думаю, что вы уже догадались, что сейчас будет отсылка к Бережливому Производству (Lean Manufacturing) и компании Toyota. Да, за последние 40 лет многие предприятия от пиццерий до крупных производств научились применять эти подходы и снижать потери на производстве.

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

Все практики, про которые ниже пойдёт речь, как раз нацелены на устранение потерь в сфере разработки ПО: перегруз и переработки, частое переключение контекста, write-only документация, велосипеды с квадратными колёсами, искажение, устаревание требований и их задержки при передачах, отложенное распространение знаний, отложенная интеграция и тестирование и многие другие. Т.е. с помощью данных практик, в основе которых лежит Бережливое Мышление, вы сможете увеличить скорость поставки не за счёт давления на разработчиков и их героизма, а за счёт устранения препятствий на их пути и удаления не добавляющих ценности шагов в процессе. Думаю, что все понимают, что постоянное давление и героизм не приводят к устойчивым долгосрочным результатам. Приведу цитату:

Сharles Lecht, “The Management of Computer Programming Projects”, 1967

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

Основа Скрама - кросс-функциональные самоорганизованные команды, которые "накидываются" на задачу и работают над ней от начала до конца. Об эффективности таких команд писали ещё в 1986 в своей знаменитой статье The New New Product Development Game Хиротака Такеути (Hirotaka Takeuchi) и Икудзиро Нонака (Ikujiro Nonaka). А что если, эту идею “выкрутить” до предела и ограничить одной количество задач в Спринте для одной команды? Как и предлагают авторы шаблона One-piece continuous flow. В этот момент читатель должен вздрогнуть и возмутиться: “Как это всего одну? Люди же будут простаивать. Что они будут делать? Это же не эффективно!”

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

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

Кто-то может спросить: “А дефектами с прода и техническими улучшениями?”. Так же, я как писал выше у команд один источник работы - Бэклог Продукта. Команды затягивают элементы из него и только из него. Я часто слышал, что в многих компаниях есть несколько бэклогов - “бизнесовый”, “тех. улучшения”, “с дефектами”… Чем больше бэклогов, тем выше утилизация команды и переключение контекста, которое замедляет движение всего потока. Т.е. две задачи, сделанные друг за другом, займут меньше времени, чем если постоянно переключаться между ними.

Как и любая техника, оne-piece continuous flow имеет множество ограничений. Она не принесёт ничего кроме боли, если, например, члены команды делятся между продуктами и проектами и тут же "перебрасываются" на другой участок, в компании фокус на краткосрочные результаты (часто неявный) и другие препятствия, которые могут быть на пути создания по-настоящему кросс-функциональных команд, как то рекомендует LeSS.

“Как же работать всей командой над одной задачей? Все должны работать за одним компьютером? Это невозможно!” - многие скажут. Возможно, на Хабре, например, было несколько статей, который описывают такую практику. Не будем долго останавливаться на данном подходе, но позволю дать несколько рекомендаций:

• Во-первых, моббинг (как и любая другая командная практика) в культуре давления, утилизации и личных KPI не взлетит. Известная басня Ивана Андреевича это иллюстрирует;
• Во-вторых, не всегда и не все команды должны использовать на постоянной основе данную технику. Это такой же инструмент, а за инструменты отвечает самоорганизованная команда;
  
• В-третьих, в условиях работы из дома моббинг становится единственным способом качественно общаться с коллегами, при этом выполняя свою работу.

Тут кроме очевидных инструментов (Zoom, Skype, Meet, Miro, ...) могу порекомендовать плагин Code With Me для тех, кто пользуется средами разработки от компании JetBrains (думаю, в других современных IDE такая возможность тоже есть). Он позволяет совместно вести разработку в паре или бóльшей группе, даже если не у всех есть нужная версия IDE. В последнем случае запускается облегченная версия клиента, которая скачивается при первом подключении.

Когда команды начинают плотно работать вместе над одной задачей, делают это постоянно, то они непрерывно учатся друг у друга. И когда большая часть работы для них становится понятной и реализуемой, им становиться тесно в одной большой команде. Зачем работать в большой команде из 9+ человек? Если можно выполнять вдвое больше задач параллельно, следуя шаблонам Mitosis и Small Teams!

Если ту же работу (от начала до конца) могут выполнить 3-4 человека вместо 7-10, то получается масштабирование разработки путем естественного деления. Т.е. дав командам возможность в начале пути работать только над одним элементом вы в итоге получите больше команд, независимо выполняющих разработку над разными элементами Бэклога. Такой же подход описывает Крэг Ларман (Craig Larman) и Бас Водди (Bas Vodde), говоря о “команде Тигров”.

При масштабировании от одной до нескольких команд у опытных управленцев возникнет идея: “Нам нужен кто-то, кто будет отвечать за релизы, а ещё кто-то, кто будет отвечать за развитие тестирования, ...”. Как вы знаете, в Скрам/LeSS нет таких ролей, и подобные вопросы адресуются командам.

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

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

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

Подводя итоги, описанными техниками мы минимизировали следующие основные потери:

• Устаревание требований. Требования теперь не передаются в виде исчерпывающих документов, а обсуждаются и уточняются в момент их реализации;
• Узкие места в виде знаний. Знания между членами команд распространяются через совместную работу (pair/mob), поэтому как я писал, общий информационный фон выравнивается с временем.
  

• Излишняя специализация команды. Часто команды имеют специализацию (бэк", "фронт"," "авторизация", ..). Но универсальные фиче-команды могут взять любую задачу из Бэклога Продукта, а полученные знания в рамках её реализации распространить через непосредственное общение (и также через сообщества и другие техники координации) на другие команды.

  
  

Мы рассмотрели потери, которые часто встречаются в разработке ПО во многих компаниях. Но последние 20-25 лет индустрия не стояла на месте и теперь может предложить продуктовым группам различные техники, как “Экстремальное Программирование” (XP), “Чистый Код” (Clean Code), CI/CD и те, которые мы рассмотрели выше. Все они направлены на то, чтобы устранить или минимизировать порой неощутимые потери в нашей работе, и дать возможность делать счастливыми нас и наших клиентов за счёт устранения всего того, что ценности не приносит.