• Принципы SOLID: хотя эти принципы важны на любом уровне организации, они особенно полезны для упрощения согласования работы нескольких команд посредством значительного сокращения зависимостей.
• Небольшие и ценные пользовательские истории: небольшие, самостоятельно выпускаемые истории ограничивают количество зависимостей, а это упрощает согласование нескольких команд.
• Небольшие и частые релизы: независимо от того, будут ли эти релизы предоставлены клиенту, практика наличия продукта, готового к релизу, у всех команд помогает выявлять проблемы координации и архитектуры. Появляется возможность отыскать и устранить корень проблемы. Некоторые команды, работающие по Scrum, забывают об этом, но в самом Scrum говорится: «На каждом этапе продукт должен быть в рабочем состоянии, независимо от того, решит ли владелец продукта выпустить релиз». Это означает, что нужно согласовать работу команды с работой других команд, от которых зависит состояние продукта.
• Непрерывная интеграция: в экстремальном программировании делается еще больший упор на согласованность, этот метод призывает проводить слияние всего продукта после каждой отметки об изменении.
• Простота проектирования: этот метод также известен как «независимость проектирования», считается одним из труднейших для изучения методов, поскольку он один из самых нелогичных. Команды тяжело справляются с этим методом, даже когда им не нужно согласовывать свои действия с другими командами. При согласовании работы нескольких команд монолитные, централизованные, заранее спланированные архитектуры создают огромные зависимости между командами, которые, как правило, заставляют их работать в тесной связи между собой, что нарушает большую часть обещаний Agile. Простота проектирования, особенно в сочетании с такими методами, как микросервисная архитектура, позволяет применять Agile в крупных масштабах.
Будущее Agile-коучинга
В последние несколько лет профессиональный коучинг и фасилитация все прочнее занимают свое место среди дисциплин Agile. На курсах скрам-мастера с расширенной сертификацией (ACSM), проводимых Scrum Alliance, есть несколько учебных задач, связанных с коучингом и фасилитацией, а программы «сертифицированный командный коуч» (CTC) и «сертифицированный корпоративный коуч» (CEC) требуют усвоения еще большего количества навыков фасилитации и коучинга. Руководство по Scrum дает определение скрам-мастера как того, кто проводит коучинг.
Поскольку все больше людей проходят курсы профессионального коучинга и встречают профессиональных коучей, которые работают в сообществе Agile, коучинг в Agile привлекает к себе все больше внимания.
Кажется, в последние пару месяцев наблюдается рост интереса к профессиональному коучингу. Люди все чаще пропускают обучение по программе ICP-ACC и сразу идут на обучение по ICF. Появилась первая коучинговая школа Agile, аккредитованная ICF, и скоро появится, по крайней мере, еще одна. Agile-коучинг ждет большое будущее!
Заключение (снова Боб)
Во многих отношениях эта глава была больше о том, чего не нужно делать, чем о том, что стоит. Возможно, потому что я видел много примеров того, как не нужно переходить на Agile. В конце концов, я сейчас думаю так же, как и 20 лет назад: «Что может быть проще? Всего лишь соблюдать простые правила и применять методы. Вот и все».
Глава 7. Мастерство высшего уровня
Автор Сандро Манкузо, 27 апреля 2019 года
Волнение. Его чувствуют многие разработчики, когда впервые слышат об Agile. Для большинства из нас, разработчиков, которые приходят с фабрик программного обеспечения с менталитетом каскадной модели, Agile оставался надеждой на избавление от гнета. Надеждой на то, что мы будем работать сообща, к нашему мнению будут прислушиваться и уважать его. У нас будут модели и методы лучше, чем были. Мы будем работать малыми итерациями и безотлагательно давать обратную связь. Мы будем регулярно выпускать релизы нашего приложения. Мы будем поддерживать общение и обратную связь с пользователями. Мы будем постоянно анализировать и приспосабливать наши способы работы. Мы будем вовлечены с самого начала разработки. Мы будем ежедневно на связи с клиентами. Мы на самом деле будем одной командой. Мы будем регулярно обсуждать деловые и технические вопросы и договариваться о том, как двигаться вперед, к нам будут относиться как к профессионалам. Бизнес и технологии будут работать сообща на производство замечательных программных продуктов, приносящих пользу нашим компаниям и клиентам. В самом начале нам казалось, что Agile слишком хорош, чтобы быть правдой. Мы думали, что наши компании никогда не примут мировоззрение Agile, не говоря уже о самих методах.
Но большинство из них смогли это сделать и были приятно удивлены. Вдруг все изменилось. У нас появились списки невыполненных задач и пользовательские истории вместо документов с требованиями. У нас появились настоящие доски и диаграммы сгорания задач вместо диаграмм Ганта. У нас появились стикеры, которые мы передвигали каждое утро в соответствии с ходом работ. В стикерах чувствовалась какая-то мощная энергетика — что-то, что вызывало сильную психологическую зависимость. Они как будто представляли нашу приверженность Agile. Чем больше таких заметок было на стене, тем более вовлеченными в Agile мы себя ощущали. Мы стали командой, работающей по Scrum, а не бригадой строителей. У нас больше не было менеджеров проекта. Нам сказали, что нам не нужны менеджеры, теперь наши менеджеры будут «владельцами продукта», а у нас будет самоорганизация. Нам сказали, что владельцы продукта и разработчики будут тесно сотрудничать, словно одна команда. И отныне, поскольку наша команда работает по Scrum, мы наделены правом принятия решений. Не только технических, но и тех, что связаны с самим проектом. Или мы так думали.
Agile бурей захватил отрасль программного обеспечения. Но, как и в игре в испорченный телефон, изначальный посыл Agile исказили и упростили, преподнося его компаниям как методологию, которая ускорит выпуск программного обеспечения. Для компаний и руководителей, применяющих каскадную модель или RUP, это звучало райской песнью.
Менеджеры и заинтересованные лица пришли в восторг. В конце концов, кто бы не хотел испробовать Agile? Кто бы не хотел быстрее выпускать программное обеспечение? Даже среди скептиков Agile вызывал интерес. Если ваши конкуренты хвастаются тем, что используют Agile, а вы нет, что вам мешает? Что о вас подумают ваши потенциальные клиенты? Компании не могут позволить себе отказаться от Agile. За годы, последовавшие за саммитом Agile, компании по всему миру встали на путь перехода к Agile. Началась эра внедрения Agile.
Похмелье от Agile
Переход из одной культуры в другую был непрост. Компаниям требовалась помощь извне, чтобы осуществить его в своих организациях. Появился новый вид специалистов — Agile-коучи. Было создано много различных программ сертификации. Некоторые сертификаты можно получить, просто пройдя двухдневные курсы.
Продать методы Agile менеджерам среднего звена было легко — всем им хотелось, чтобы ПО выпускалось быстрее. «Инжиниринг — это несложно. Если наладить процесс разработки, с ним тоже будет все в порядке, — говорили менеджерам. — Дело всегда в людях». И они покупали. Руководители работают с людьми и покуда занимают свою должность, они счастливы, когда их подчиненные работают быстрее.
Множество компаний на самом деле получили пользу от перехода на Agile, и сегодня их положение дел гораздо лучше, чем до этого.
Многие из этих компаний могут развертывать ПО несколько раз в день, бизнес и технологии у них работают действительно как одна команда. Но так, конечно, далеко не у всех. Менеджеры в попытке ускорить разработчиков используют полную прозрачность процесса для контроля каждого шага. Agile-коучи, у которых нет опыта ведения бизнеса и опыта технических работ, обучают менеджеров и говорят разработчикам, что им делать. Дорожные карты и вехи определяются менеджерами и навязываются командам разработчиков — разработчики могут оценивать работу, но их заставляют вписывать свои оценки в навязанные вехи. Довольно часто можно встретить проекты, в которых используются соответствующие итерации и пользовательские истории, уже распределенные руководством на следующие полгода-год. Если разработчик не в состоянии угнаться за всеми единицами сложности историй за спринт, ему придется работать в следующем спринте больше, чтобы наверстать упущенное. Ежедневные стендап-митинги становятся встречами, где разработчики должны делать доклад о ходе работ владельцам продукта и Agile-коучам, подробно рассказывая о том, над чем они работают и когда эти работы закончат. Если владелец продукта думает, что разработчики тратят слишком много времени на автоматизированные тесты, рефакторинг, парное программирование или что-то подобное, он просто команде запрещает это делать.
В их модели Agile нет никакой стратегическо-технической работы. В ней нет требований к архитектуре или проектированию. Порядок таков, что нужно просто сосредоточиться на какой-либо невыполненной работе из списка, которую нужно выполнить незамедлительно и которой присвоили наивысший приоритет. И так одно задание с наивысшим приоритетом следует за другим. Такой подход приводит к длинной последовательности итеративных тактических работ и накоплению технического долга. Хрупкое программное обеспечение, знаменитые монолиты (или распределенные монолиты, если говорить о командах, которые пробуют использовать микросервисную архитектуру) становятся в порядке вещей. Ошибки и неполадки оказываются излюбленной темой для обсуждения на ежедневном стендап-митинге и ретроспективах. Релизы выходят не так часто, как ожидали клиенты. Тестирование вручную занимает целые дни, а то и недели. И надежда на то, что применение Agile убережет от всех напастей, бесследно уходи