Чистый Agile. Основы гибкости - [58]

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

Наращивание внедрения Agile

Ниже приведен список отдельных методов для внедрения Agile. Этот список был изначально создан и периодически обновлялся посредством трех главных ступеней в Agile-коучинге — устранения дублей, сбора идей на стикерах и точечного голосования при участии группы из примерно десятка корпоративных коучей. Для справки здесь приведено обобщенное описание этих методов. Существует гораздо больше методов Agile, которые здесь не перечислены. Рассмотрим для начала этот список. Например, вместо того чтобы внедрять Scrum, Kanban, экстремальное программирование или один из наборов методов для масштабирования Agile, подумайте, какой метод из списка ниже наиболее уместен для текущих потребностей той или иной группы или команды, и внедрите его. Попробуйте его применять некоторое время, потом повторите действия.

• Практики Kanban: методы Kanban основаны на наглядности хода работ (с помощью карточек на стене), ограничении количества выполняемых работ и прохождении работы через разные стадии.

• Scrum и экстремальное программирование (XP): эти две методологии часто увязывают вместе, потому что они очень похожи, за исключением технических методов XP. В SAFe, например, их упоминают совместно как ScrumXP. Обе методологии включают в себя большое разнообразие методов, например короткие ежедневные собрания команды, «владелец продукта», «фасилитатор процесса» (он же «скрам-мастер»), ретроспективы, кросс-функциональность команд, пользовательские истории, небольшие релизы, рефакторинг, заблаговременное написание тестов и парное программирование.

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

• Деревья эскалации: если есть смысл всегда работать над чем-либо, что приносит наибольшую пользу, тогда есть смысл безотлагательно поднимать препятствия по строго намеченному пути эскалации. Они применимы к широко используемому методу Scrum of Scrums и не такому известному retrospective of retrospectives. Одним из паттернов для этого является фрактальный паттерн масштабирования для Scrum@Scale посредством Scrum, Scrum of Scrums и даже Executive Action Team.

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

• Kanban портфеля: традиционные способы управления портфелями способствуют распределению работников по нескольким командам, что ведет к неконтролируемой многозадачности. Многозадачность создает трение, увеличивает сложность и снижает производительность. Kanban портфеля накладывает ограничения на количество выполняемых работ на уровне инициативы и обеспечивает постоянное внимание на работе, приносящей наибольшую пользу. Одновременное управление меньшим количеством проектов также значительно упрощает (или даже решает) проблему согласования нескольких команд. Kanban портфеля лучше всего работает в паре с наименее возможным приростом (Minimum Viable Increment).

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

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

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

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

• Небольшие и ценные пользовательские истории: