Пора признать, что у нас в России была и есть проблема с качеством перевода с английского. Чаще всего он проявляется в переводах названий фильмов, но, как бы абсурдно это ни звучало, также встречается и при переводе профессиональных терминов, в том числе тех, которые призваны быть инженерными. Agile — один из примеров такой проблемы.

Более двадцати пяти лет назад кто-то первый неверно трактовал термин agile, возможно потому, что был руководителем разработки, а не переводчиком и, как следствие, перевёл слово как гибкость (flexible). Из-за всеобщего невежества в этой тематике тогда его никто не поправил, а термин был подхвачен и распространен.

Невежество не устранилось, а двадцать пять лет накапливалось кумулятивно, и теперь мы имеем гибкое производство, гибкие методологии, гибкие фреймворки, гибкие практики, а также мастера по scrum или владельца продукта не как роль в производстве, а как должность в вакансиях.

Agile: способность быстро, легко или ловко двигаться
переносный смысл: способность быстро соображать и понимать

Варианты перевода: проворный, расторопный, ловкий

Agility: ловкость, проворство, подвижность, быстрота, прыть, живость.

Хм. Пока ничего общего с гибкостью. Проверим по словарям русского языка.

Гибкость. Буквальный смысл: способность легко гнуться. Переносное значение: способность легко, быстро приспосабливаться к обстоятельствам.

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

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

Те самые, которые являются прямым переводом этого слова: ловкий, проворный, прыткий, расторопный.

Причина, по которой изначально методология создания ценности, в частности программного обеспечения, была названа agile, как раз в том, что производство должно было стать более ловким и проворным, а значит — менее неповоротливым и монолитным.

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

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

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

Скорость ⏫, простои ⏬

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

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

Если отклонение от плана приносит пользу, но не соответствует целям, мы должны подумать: польза не сто́ит того, или цель пора поменять? Такое решение уже почти наверняка будет вынесено за пределы команды.

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

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

Любой член команды может и должен сообщить, если считает, что не видит ценности для потребителя в том, что он делает.

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

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

До сих пор многие организации мыслят через призму поросшего мхом agile-манифеста, тогда как важнее руководствоваться принципами неписаного манифеста сотрудников или манифеста талантов.

Скорость ⏫, трата времени на ненужные задачи ⏬

Команды ограничивают количество задач, над которыми работают одновременно. В Agile-сообществе это называется ограничением незавершенного производства (WIP) и является вторым по распространенности недопониманием принципов Agile (первое место занимает миф о том, что Agile исключает документацию).

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

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

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

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

Скорость ⏫, простои ⏬, устойчивость производства ⏫

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

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

Команды анализируют свою работу, извлекают уроки и немедленно применяют сделанные выводы, оценивают результат и делают новые выводы. Никто не запрещает полуавтономной команде экспериментировать, и у нее есть на это время.

Члены команды непредвзято тестируют инструменты и практики, где это возможно, или используют проверенные методы там, где риски высоки.

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

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

Представьте, что вы зашли в цех и видите, как сотрудник кладет деталь в ведро с водой и ставит его на огонь: “Ну, написано же — варить!”

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

Такое недопонимание приобрело абсурдные масштабы, но исправить ситуацию можно легко. Я там был, я знаю.