Agile Thinking: 6 принципов здравого смысла
Термин Agile Thinking и шесть принципов, на которых оно держится, я впервые услышал в 2016 году от Хино Маркса (Gino Marckx) из EPAM, на его трёхдневном воркшопе для бизнеса и ИТ. Записал их тогда же, а в 2026 году причесал текст, поправил цифры и назвал, откуда они. Этим объяснением я до сих пор пользуюсь на тренингах.
Что такое Agile Thinking? Это не методология и не набор практик. Это то, как вы думаете и как работаете на конкретный практический результат. Я бы сказал, почти процесс, который заставляет применять здравый смысл.
Интереснее другой вопрос. Где это применять? Самое очевидное применение — разработка продукта или ведение проекта. Но совсем другая история, когда гибким мышлением перестраивают саму компанию и её процессы или коучат сотрудников.
Держится Agile Thinking на шести простых принципах.
Знайте свою цель
Фокусируйтесь на реальной, чёткой и даже в чём-то минимально необходимой цели. Требования часто собирают по принципу «сделать всё». А нужно ли это всё, чтобы дойти до цели?
Цифры здесь неприятные. По данным Standish Group, которые Джим Джонсон показал на конференции XP в 2002 году, в типичной системе 45 % функций не используются никогда и ещё 19 % используются редко. То есть почти две трети сделанного пользователю нужно редко или не нужно вовсе. Умение найти и выкинуть из объёма ненужные требования и есть фокус на цели.
Понимайте контекст
Инструментов, которые помогают вести работу по Agile, много. Но из коробки они не работают. Их нужно наполнить вашим контекстом: чем живёт организация, как у вас принято работать вместе, как люди общаются. Что-то заработает сразу, что-то придётся адаптировать. Но главное, не бояться экспериментировать и искать то, что приживётся именно у вас.
Получайте обратную связь как можно чаще
Команде разработки важно понимать, что она движется в правильном направлении и делает ровно то, что нужно заказчику. По ходу работы всплывает множество нюансов, которые невозможно передать на бумаге и на редких встречах.
Представим, что вы заказчик. Вы написали требования и ждёте приёмочного тестирования (UAT), которое случится через несколько месяцев. На приёмке выясняется, что результатом пользоваться невозможно. Вы заводите дефекты и ждёте ещё несколько недель. Потом снова дефекты и снова ожидание. И может оказаться, что работу, которая шла четыре месяца, придётся выкинуть или смириться и пользоваться тем, что есть.
А теперь другой сценарий. Команда показывает вам результат раз в две недели, и каждый такой показ даёт ей обратную связь от вас. Если что-то сделано не так, ничего страшного, потому что в худшем случае вы потеряете две недели. Частая обратная связь даёт именно тот результат, который нужен вам, и экономит кучу времени и денег.
Двигайтесь короткими итерациями
Двухнедельные итерации дают результат быстрее. Доработки раньше уходят в продуктив, и раньше начинается отдача. Для этого требования придётся собирать иначе, чем в классическом подходе. Нужно научиться мыслить MVP (minimum viable product — минимальный жизнеспособный продукт).
От этого растёт и качество. Настоящие пользователи (например, сотрудники фронт-офиса) получают доработку рано и успевают дать обратную связь, пока работа ещё идёт. Поправить можно сразу, а не в следующем проекте. Работать им становится удобнее, а значит, и клиентов они обслуживают лучше.
Сокращайте потери
Ищите то, что мешает дойти до цели. Классификация потерь пришла из промышленного Lean. У Тайити Оно в производственной системе Toyota их семь. Мэри и Том Поппендик перенесли её в разработку. В их книге «Implementing Lean Software Development» 2006 года семь потерь выглядят так:
- недоделанная работа;
- лишние функции (те самые 45 %);
- повторное изучение того, что уже знали;
- передача работы из рук в руки;
- переключение между задачами;
- ожидание;
- дефекты.
Находить их помогают практики постоянного улучшения. Не бойтесь менять процессы, роли и форматы документов. Их придумали люди, чтобы было удобнее работать, и не они должны диктовать вам, как работать. Не бойтесь менять себя и то, что вокруг.
Работайте в команде
Объединяйтесь в самоорганизующиеся команды вокруг общей цели. Больше разговаривайте. Электронная почта — один из самых неэффективных каналов общения, а самый продуктивный — живой разговор у доски. Возьмите за правило: если переписка требует трёх и больше обменов сообщениями, назначайте встречу и обсуждайте вопрос лицом к лицу.