Масштабированный скрам. Как организовать гибкую разработку в крупной компании - страница 15

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

Большинство случаев локальной оптимизации могут рассматриваться как варианты нарушения принципа «Следи за эстафетной палочкой, а не за бегунами».

При масштабном внедрении скрама или принципов гибкой разработки большинство возникающих вопросов типа «Да, но?..» касаются именно локальной оптимизации, например: «Да, но… как насчет управленческой отчетности?» или, более обобщенно, «Да, но… как насчет <этого конкретного случая>?». В результате правила и практики меняются таким образом, чтобы удовлетворить требования отчетности или служить любой другой второстепенной цели, вместо того чтобы обеспечивать глобальную оптимизацию – улучшать общую способность системы быстро создавать ценность. Иногда можно встретить локальную оптимизацию ради редких или чрезвычайных случаев. Например, группа, отвечающая за централизованный выбор программного инструмента для всей компании, фокусируется на самых сложных и редких случаях его использования и на основе этого сценария выбирает инструмент, который подходит именно для таких случаев. В результате достигается субоптимизация для 5 % случаев – за счет простоты использования и скорости в 95 % случаев.

Еще одна причина локальной оптимизации – консервативное мышление и незнание новых подходов к работе. Особенно часто это встречается в крупных продуктовых группах. Например, однажды мы помогали большой сетевой продуктовой группе в Европе внедрить скрам и практику непрерывной интеграции (НИ) вместе с системой НИ, которая постоянно интегрировала, собирала и автоматически тестировала продукт. Спустя некоторое время внешний менеджер проверил, как идут дела, и потребовал изменить практику интеграции, потому что у группы не было формального плана, в соответствии с которым менеджер по интеграции должен был вручную интегрировать все ПО, и, разумеется, не было и самого менеджера по интеграции. Внешний менеджер хотел «оптимизировать» работу менеджера по интеграции, который был больше ни к чему. Он не понимал, что вся эта устаревшая модель работы стала не нужна благодаря НИ. Эта история повторяется во всех крупных устоявшихся компаниях-разработчиках, где локальной оптимизации подвергаются существующие традиционные способы работы, такие как ручное тестирование, или отдельные группы по разработке архитектуры, компонентные команды и т. д. Консультанту, который занимается внедрением масштабированного скрама на уровне компании, приходится разгребать горы таких локальных оптимизаций.

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