Роберт Мартин - Чистый Agile. Основы гибкости

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

Добиваться большого, сосредоточившись на меньшем

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

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

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

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

• Непрерывная интеграция:в экстремальном программировании делается еще больший упор на согласованность, этот метод призывает проводить слияние всего продукта после каждой отметки об изменении.

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

Будущее Agile-коучинга

В последние несколько лет профессиональный коучинг и фасилитация все прочнее занимают свое место среди дисциплин Agile. На курсах скрам-мастера с расширенной сертификацией (ACSM), проводимых Scrum Alliance, есть несколько учебных задач, связанных с коучингом и фасилитацией, а программы «сертифицированный командный коуч» (CTC) и «сертифицированный корпоративный коуч» (CEC) требуют усвоения еще большего количества навыков фасилитации и коучинга. Руководство по Scrum дает определение скрам-мастера как того, кто проводит коучинг.

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

Кажется, в последние пару месяцев наблюдается рост интереса к профессиональному коучингу. Люди все чаще пропускают обучение по программе ICP-ACC и сразу идут на обучение по ICF. Появилась первая коучинговая школа Agile, аккредитованная ICF, и скоро появится, по крайней мере, еще одна. Agile-коучинг ждет большое будущее!

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