ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 351
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Глава 6. Внедрение Agile
234
Внедрение Agile с помощью Agile и коуча
Манифест Agile сам по себе замечательный шаблон для коучин- га и согласования работы нескольких команд: «Дайте им среду и поддержку, в которой они нуждаются, и доверьте им выполнение работы» . В подтверждение вышесказанного у сообщества Agile есть несметное число паттернов для масштабирования, которые совместимы с ценностями и принципами Манифеста Agile . Гово- ря это, я имею в виду не наборы методов, а отдельные методы, из которых эти наборы состоят .
Все эти наборы суть готовые рецепты, состоящие из отдельных методов Agile . Вместо того чтобы действовать по одному из этих рецептов, можно подготовить свой собственный рецепт с Agile и коучем, который безупречно подходит именно вам . Если по ва- шему рецепту получается SAFe, Nexus, LeSS или Scrum@Scale, то замечательно!
Мы приводим краткий обзор того, как самые успешные Agile- коучи, работающие с крупными предприятиями, сочетают свое ре- месло и Agile, и это лучшим образом сказывается на организации .
На уровне отдельных людей смысл коучинга в том, чтобы помогать им решать проблемы самостоятельно . А коучинг на уровне команд и организаций помогает самостоятельно достигать своих целей целым командам .
Прежде всего, коуч рассматривает всех, кого затронет переход на Agile, в качестве клиентов . Затем, проводя ретроспективы, мероприятия в опенспейсах и прочее, он выясняет, чт
ó клиенты считают вызовами и возможностями . Становится понятно, сколь- ко работы нужно провести, чтобы внедрить Agile . Затем с помо- щью групповых средств принятия решений, например точечного голосования, коуч определяет, с чего нужно начинать в первую
Коучинг — альтернативный взгляд
235
очередь . Потом он помогает организации провести несколько наиболее важных изменений . Затем проводит ретроспективу и повторяет действия .
Конечно, для многих участников такое внедрение Agile будет про- исходить впервые . Одного коучинга недостаточно, важно также проводить обучение и тренинги, чтобы сотрудники могли прини- мать решения, будучи достаточно осведомленными .
Наращивание внедрения Agile
Ниже приведен список отдельных методов для внедрения Agile .
Этот список был изначально создан и периодически обновлялся посредством трех главных ступеней в Agile-коучинге — устране- ния дублей, сбора идей на стикерах и точечного голосования при участии группы из примерно десятка корпоративных коучей . Для справки здесь приведено обобщенное описание этих методов . Су- ществует гораздо больше методов Agile, которые здесь не перечис- лены . Рассмотрим для начала этот список . Например, вместо того чтобы внедрять Scrum, Kanban, экстремальное программирование или один из наборов методов для масштабирования Agile, поду- майте, какой метод из списка ниже наиболее уместен для текущих потребностей той или иной группы или команды, и внедрите его .
Попробуйте его применять некоторое время, потом повторите действия .
z
Практики Kanban: методы Kanban основаны на наглядности хода работ (с помощью карточек на стене), ограничении коли- чества выполняемых работ и прохождении работы через разные стадии .
z
Scrum и экстремальное программирование (XP): эти две мето- дологии часто увязывают вместе, потому что они очень похожи,
Глава 6. Внедрение Agile
236
за исключением технических методов XP . В SAFe, например, их упоминают совместно как ScrumXP . Обе методологии включа- ют в себя большое разнообразие методов, например короткие ежедневные собрания команды, «владелец продукта», «фаси- литатор процесса» (он же «скрам-мастер»), ретроспективы, кросс-функциональность команд, пользовательские истории, небольшие релизы, рефакторинг, заблаговременное написание тестов и парное программирование .
z
Распределение командных событий; когда командные события, такие как стендап-митинги и ретроспективы, распределены по времени между несколькими командами, тогда возможно под- нимать ежедневные и системные препятствия по дереву эска- лации . Такое распределение по времени задает время начала и конца итераций, а также их продолжительность . Команды, не работающие по итерациям, которые могут выпускать релизы по требованию, могут соотносить свой рабочий график с любой другой каденцией .
z
Деревья эскалации: если есть смысл всегда работать над чем- либо, что приносит наибольшую пользу, тогда есть смысл без- отлагательно поднимать препятствия по строго намечен ному пути эскалации . Они применимы к широко используемому методу Scrum of Scrums и не такому известному retrospec- tive of retrospectives . Одним из паттернов для этого является фрактальный паттерн масштабирования для Scrum@Scale посредством Scrum, Scrum of Scrums и даже Executive Action
Team .
z
Регулярное межкомандное взаимодействие: этот метод пред- полагает регулярное взаимодействие между мастерами Scrum, владельцами продукта и членами команды, которые работают сообща на результат . Один из способов это обеспечить — прово- дить регулярные события на открытом пространстве .
Коучинг — альтернативный взгляд
237
z
Kanban портфеля: традиционные способы управления порт- фелями способствуют распределению работников по несколь- ким командам, что ведет к неконтролируемой многозадачно- сти . Многозадачность создает трение, увеличивает сложность и снижает производительность . Kanban портфеля накладыва- ет ограничения на количество выполняемых работ на уровне инициативы и обеспечивает постоянное внимание на работе, приносящей наибольшую пользу . Одновременное управление меньшим количеством проектов также значительно упрощает
(или даже решает) проблему согласования нескольких команд .
Kanban портфеля лучше всего работает в паре с наименее воз- можным приростом (Minimum Viable Increment) .
z
Наименее возможный прирост: существует много вариантов развития этой идеи, но все они сводятся к обдумыванию того, какой путь короче и позволит скорее получить наибольшую пользу . Растущее число организаций принимают другую край- ность — внедряют непрерывную доставку, регулярно и часто выпускают небольшие обновления, иногда по несколько раз на дню .
Добиваться большого,
сосредоточившись на меньшем
Большинство случаев внедрения Agile в нескольких командах одновременно сталкивается с проблемой того, что их члены боль- ше думают о преодолении сложности, а не о решении задач для достижения простоты . По своему опыту могу сказать, что один из краеугольных камней применения Agile в крупных масштабах — это высокий уровень применения Agile на уровне команд и очень низкий уровень сложности во всех структурах . Когда у вас целая флотилия быстроходных лодок, то практически незачем связы-
Глава 6. Внедрение Agile
238
вать их вместе . Ниже приведены некоторые методы, как правило, ассоциирующиеся с Agile на уровне команды, которые выполняют функцию двойного назначения в качестве инструмента согласова- ния работы нескольких команд .
z
Принципы SOLID: хотя эти принципы важны на любом уровне организации, они особенно полезны для упрощения согласо- вания работы нескольких команд посредством значительного сокращения зависимостей .
z
Небольшие и ценные пользовательские истории: небольшие, самостоятельно выпускаемые истории ограничивают количе- ство зависимостей, а это упрощает согласование нескольких команд .
z
Небольшие и частые релизы: независимо от того, будут ли эти релизы предоставлены клиенту, практика наличия продукта, готового к релизу, у всех команд помогает выявлять пробле- мы координации и архитектуры . Появляется возможность отыскать и устранить корень проблемы . Некоторые команды, работающие по Scrum, забывают об этом, но в самом Scrum говорится: «На каждом этапе продукт должен быть в рабочем состоянии, независимо от того, решит ли владелец продукта выпустить релиз» . Это означает, что нужно согласовать работу команды с работой других команд, от которых зависит состо- яние продукта .
z
Непрерывная интеграция: в экстремальном программировании делается еще больший упор на согласованность, этот метод при- зывает проводить слияние всего продукта после каждой отметки об изменении .
z
Простота проектирования: этот метод также известен как
«независимость проектирования», считается одним из труд-
Коучинг — альтернативный взгляд
239
нейших для изучения методов, поскольку он один из самых нелогичных . Команды тяжело справляются с этим методом, даже когда им не нужно согласовывать свои действия с други- ми командами . При согласовании работы нескольких команд монолитные, централизованные, заранее спланированные ар- хитектуры создают огромные зависимости между командами, которые, как правило, заставляют их работать в тесной связи между собой, что нарушает большую часть обещаний Agile .
Простота проектирования, особенно в сочетании с такими методами, как микросервисная архитектура, позволяет при- менять Agile в крупных масштабах .
Будущее Agile-коучинга
В последние несколько лет профессиональный коучинг и фасили- тация все прочнее занимают свое место среди дисциплин Agile . На курсах скрам-мастера с расширенной сертификацией (ACSM), про- водимых Scrum Alliance, есть несколько учебных задач, связанных с коучингом и фасилитацией, а программы «сертифицированный командный коуч» (CTC) и «сертифицированный корпоративный коуч» (CEC) требуют усвоения еще большего количества навыков фасилитации и коучинга . Руководство по Scrum дает определение скрам-мастера как того, кто проводит коучинг .
Поскольку все больше людей проходят курсы профессионального коучинга и встречают профессиональных коучей, которые рабо- тают в сообществе Agile, коучинг в Agile привлекает к себе все больше внимания .
Кажется, в последние пару месяцев наблюдается рост интереса к профессиональному коучингу . Люди все чаще пропускают об- учение по программе ICP-ACC и сразу идут на обучение по ICF .
Глава 6. Внедрение Agile
Появилась первая коучинговая школа Agile, аккредитованная ICF, и скоро появится, по крайней мере, еще одна . Agile-коучинг ждет большое будущее!
ЗАКЛЮЧЕНИЕ (СНОВА БОБ)
Во многих отношениях эта глава была больше о том, чего не нужно делать, чем о том, что стоит . Возможно, потому что я видел много примеров того, как не нужно переходить на Agile . В конце концов, я сейчас думаю так же, как и 20 лет назад: «Что может быть про- ще? Всего лишь соблюдать простые правила и применять методы .
Вот и все» .
7
МАСТЕРСТВО ВЫСШЕГО
УРОВНЯ
Автор Сандро Манкузо, 27 апреля 2019 года
Глава 7. Мастерство высшего уровня
242
Волнение . Его чувствуют многие разработчики, когда впервые слышат об Agile . Для большинства из нас, разработчиков, которые приходят с фабрик программного обеспечения с менталитетом каскадной модели, Agile оставался надеждой на избавление от гнета . Надеждой на то, что мы будем работать сообща, к нашему мнению будут прислушиваться и уважать его . У нас будут модели и методы лучше, чем были . Мы будем работать малыми итерация- ми и безотлагательно давать обратную связь . Мы будем регулярно выпускать релизы нашего приложения . Мы будем поддерживать общение и обратную связь с пользователями . Мы будем постоянно анализировать и приспосабливать наши способы работы . Мы бу- дем вовлечены с самого начала разработки . Мы будем ежедневно на связи с клиентами . Мы на самом деле будем одной командой .
Мы будем регулярно обсуждать деловые и технические вопросы и договариваться о том, как двигаться вперед, к нам будут отно- ситься как к профессионалам . Бизнес и технологии будут работать сообща на производство замечательных программных продуктов, приносящих пользу нашим компаниям и клиентам . В самом начале нам казалось, что Agile слишком хорош, чтобы быть правдой . Мы думали, что наши компании никогда не примут мировоззрение
Agile, не говоря уже о самих методах .
Но большинство из них смогли это сделать и были приятно удив- лены . Вдруг все изменилось . У нас появились списки невыпол- ненных задач и пользовательские истории вместо документов с требованиями . У нас появились настоящие доски и диаграммы сгорания задач вместо диаграмм Ганта . У нас появились стикеры, которые мы передвигали каждое утро в соответствии с ходом работ .
В стикерах чувствовалась какая-то мощная энергетика — что-то, что вызывало сильную психологическую зависимость . Они как будто представляли нашу приверженность Agile . Чем больше таких заметок было на стене, тем более вовлеченными в Agile мы себя
Похмелье от Аgile
243
ощущали . Мы стали командой, работающей по Scrum, а не брига- дой строителей . У нас больше не было менеджеров проекта . Нам сказали, что нам не нужны менеджеры, теперь наши менеджеры будут «владельцами продукта», а у нас будет самоорганизация .
Нам сказали, что владельцы продукта и разработчики будут тесно сотрудничать, словно одна команда . И отныне, поскольку наша ко- манда работает по Scrum, мы наделены правом принятия решений .
Не только технических, но и тех, что связаны с самим проектом .
Или мы так думали .
Agile бурей захватил отрасль программного обеспечения . Но, как и в игре в испорченный телефон, изначальный посыл Agile иска- зили и упростили, преподнося его компаниям как методологию, которая ускорит выпуск программного обеспечения . Для компаний и руководителей, применяющих каскадную модель или RUP, это звучало райской песнью .
Менеджеры и заинтересованные лица пришли в восторг . В конце концов, кто бы не хотел испробовать Agile? Кто бы не хотел бы- стрее выпускать программное обеспечение? Даже среди скептиков
Agile вызывал интерес . Если ваши конкуренты хвастаются тем, что используют Agile, а вы нет, что вам мешает? Что о вас подумают ваши потенциальные клиенты? Компании не могут позволить себе отказаться от Agile . За годы, последовавшие за саммитом Agile, компании по всему миру встали на путь перехода к Agile . Началась эра внедрения Agile .
ПОХМЕЛЬЕ ОТ АGILE
Переход из одной культуры в другую был непрост . Компаниям требовалась помощь извне, чтобы осуществить его в своих ор- ганизациях . Появился новый вид специалистов — Agile-коучи .
Глава 7. Мастерство высшего уровня
244
Было создано много различных программ сертификации . Неко- торые сертификаты можно получить, просто пройдя двухдневные курсы .
Продать методы Agile менеджерам среднего звена было легко — всем им хотелось, чтобы ПО выпускалось быстрее . «Инжини- ринг — это несложно . Если наладить процесс разработки, с ним тоже будет все в порядке, — говорили менеджерам . — Дело всегда в людях» . И они покупали . Руководители работают с людьми и покуда занимают свою должность, они счастливы, когда их под- чиненные работают быстрее .
Множество компаний на самом деле получили пользу от перехода на Agile, и сегодня их положение дел гораздо лучше, чем до этого .
Многие из этих компаний могут развертывать ПО несколько раз в день, бизнес и технологии у них работают действительно как одна команда . Но так, конечно, далеко не у всех . Менеджеры в по- пытке ускорить разработчиков используют полную прозрачность процесса для контроля каждого шага . Agile-коучи, у которых нет опыта ведения бизнеса и опыта технических работ, обучают
менеджеров и говорят разработчикам, что им делать . Дорожные карты и вехи определяются менеджерами и навязываются ко- мандам разработчиков — разработчики могут оценивать работу, но их заставляют вписывать свои оценки в навязанные вехи . До- вольно часто можно встретить проекты, в которых используются соответствующие итерации и пользовательские истории, уже распределенные руководством на следующие полгода-год . Если разработчик не в состоянии угнаться за всеми единицами слож- ности историй за спринт, ему придется работать в следующем спринте больше, чтобы наверстать упущенное . Ежедневные стен- дап-митинги становятся встречами, где разработчики должны делать доклад о ходе работ владельцам продукта и Agile-коучам,
234
Внедрение Agile с помощью Agile и коуча
Манифест Agile сам по себе замечательный шаблон для коучин- га и согласования работы нескольких команд: «Дайте им среду и поддержку, в которой они нуждаются, и доверьте им выполнение работы» . В подтверждение вышесказанного у сообщества Agile есть несметное число паттернов для масштабирования, которые совместимы с ценностями и принципами Манифеста Agile . Гово- ря это, я имею в виду не наборы методов, а отдельные методы, из которых эти наборы состоят .
Все эти наборы суть готовые рецепты, состоящие из отдельных методов Agile . Вместо того чтобы действовать по одному из этих рецептов, можно подготовить свой собственный рецепт с Agile и коучем, который безупречно подходит именно вам . Если по ва- шему рецепту получается SAFe, Nexus, LeSS или Scrum@Scale, то замечательно!
Мы приводим краткий обзор того, как самые успешные Agile- коучи, работающие с крупными предприятиями, сочетают свое ре- месло и Agile, и это лучшим образом сказывается на организации .
На уровне отдельных людей смысл коучинга в том, чтобы помогать им решать проблемы самостоятельно . А коучинг на уровне команд и организаций помогает самостоятельно достигать своих целей целым командам .
Прежде всего, коуч рассматривает всех, кого затронет переход на Agile, в качестве клиентов . Затем, проводя ретроспективы, мероприятия в опенспейсах и прочее, он выясняет, чт
ó клиенты считают вызовами и возможностями . Становится понятно, сколь- ко работы нужно провести, чтобы внедрить Agile . Затем с помо- щью групповых средств принятия решений, например точечного голосования, коуч определяет, с чего нужно начинать в первую
Коучинг — альтернативный взгляд
235
очередь . Потом он помогает организации провести несколько наиболее важных изменений . Затем проводит ретроспективу и повторяет действия .
Конечно, для многих участников такое внедрение Agile будет про- исходить впервые . Одного коучинга недостаточно, важно также проводить обучение и тренинги, чтобы сотрудники могли прини- мать решения, будучи достаточно осведомленными .
Наращивание внедрения Agile
Ниже приведен список отдельных методов для внедрения Agile .
Этот список был изначально создан и периодически обновлялся посредством трех главных ступеней в Agile-коучинге — устране- ния дублей, сбора идей на стикерах и точечного голосования при участии группы из примерно десятка корпоративных коучей . Для справки здесь приведено обобщенное описание этих методов . Су- ществует гораздо больше методов Agile, которые здесь не перечис- лены . Рассмотрим для начала этот список . Например, вместо того чтобы внедрять Scrum, Kanban, экстремальное программирование или один из наборов методов для масштабирования Agile, поду- майте, какой метод из списка ниже наиболее уместен для текущих потребностей той или иной группы или команды, и внедрите его .
Попробуйте его применять некоторое время, потом повторите действия .
z
Практики Kanban: методы Kanban основаны на наглядности хода работ (с помощью карточек на стене), ограничении коли- чества выполняемых работ и прохождении работы через разные стадии .
z
Scrum и экстремальное программирование (XP): эти две мето- дологии часто увязывают вместе, потому что они очень похожи,
Глава 6. Внедрение Agile
236
за исключением технических методов XP . В SAFe, например, их упоминают совместно как ScrumXP . Обе методологии включа- ют в себя большое разнообразие методов, например короткие ежедневные собрания команды, «владелец продукта», «фаси- литатор процесса» (он же «скрам-мастер»), ретроспективы, кросс-функциональность команд, пользовательские истории, небольшие релизы, рефакторинг, заблаговременное написание тестов и парное программирование .
z
Распределение командных событий; когда командные события, такие как стендап-митинги и ретроспективы, распределены по времени между несколькими командами, тогда возможно под- нимать ежедневные и системные препятствия по дереву эска- лации . Такое распределение по времени задает время начала и конца итераций, а также их продолжительность . Команды, не работающие по итерациям, которые могут выпускать релизы по требованию, могут соотносить свой рабочий график с любой другой каденцией .
z
Деревья эскалации: если есть смысл всегда работать над чем- либо, что приносит наибольшую пользу, тогда есть смысл без- отлагательно поднимать препятствия по строго намечен ному пути эскалации . Они применимы к широко используемому методу Scrum of Scrums и не такому известному retrospec- tive of retrospectives . Одним из паттернов для этого является фрактальный паттерн масштабирования для Scrum@Scale посредством Scrum, Scrum of Scrums и даже Executive Action
Team .
z
Регулярное межкомандное взаимодействие: этот метод пред- полагает регулярное взаимодействие между мастерами Scrum, владельцами продукта и членами команды, которые работают сообща на результат . Один из способов это обеспечить — прово- дить регулярные события на открытом пространстве .
Коучинг — альтернативный взгляд
237
z
Kanban портфеля: традиционные способы управления порт- фелями способствуют распределению работников по несколь- ким командам, что ведет к неконтролируемой многозадачно- сти . Многозадачность создает трение, увеличивает сложность и снижает производительность . Kanban портфеля накладыва- ет ограничения на количество выполняемых работ на уровне инициативы и обеспечивает постоянное внимание на работе, приносящей наибольшую пользу . Одновременное управление меньшим количеством проектов также значительно упрощает
(или даже решает) проблему согласования нескольких команд .
Kanban портфеля лучше всего работает в паре с наименее воз- можным приростом (Minimum Viable Increment) .
z
Наименее возможный прирост: существует много вариантов развития этой идеи, но все они сводятся к обдумыванию того, какой путь короче и позволит скорее получить наибольшую пользу . Растущее число организаций принимают другую край- ность — внедряют непрерывную доставку, регулярно и часто выпускают небольшие обновления, иногда по несколько раз на дню .
Добиваться большого,
сосредоточившись на меньшем
Большинство случаев внедрения Agile в нескольких командах одновременно сталкивается с проблемой того, что их члены боль- ше думают о преодолении сложности, а не о решении задач для достижения простоты . По своему опыту могу сказать, что один из краеугольных камней применения Agile в крупных масштабах — это высокий уровень применения Agile на уровне команд и очень низкий уровень сложности во всех структурах . Когда у вас целая флотилия быстроходных лодок, то практически незачем связы-
Глава 6. Внедрение Agile
238
вать их вместе . Ниже приведены некоторые методы, как правило, ассоциирующиеся с Agile на уровне команды, которые выполняют функцию двойного назначения в качестве инструмента согласова- ния работы нескольких команд .
z
Принципы SOLID: хотя эти принципы важны на любом уровне организации, они особенно полезны для упрощения согласо- вания работы нескольких команд посредством значительного сокращения зависимостей .
z
Небольшие и ценные пользовательские истории: небольшие, самостоятельно выпускаемые истории ограничивают количе- ство зависимостей, а это упрощает согласование нескольких команд .
z
Небольшие и частые релизы: независимо от того, будут ли эти релизы предоставлены клиенту, практика наличия продукта, готового к релизу, у всех команд помогает выявлять пробле- мы координации и архитектуры . Появляется возможность отыскать и устранить корень проблемы . Некоторые команды, работающие по Scrum, забывают об этом, но в самом Scrum говорится: «На каждом этапе продукт должен быть в рабочем состоянии, независимо от того, решит ли владелец продукта выпустить релиз» . Это означает, что нужно согласовать работу команды с работой других команд, от которых зависит состо- яние продукта .
z
Непрерывная интеграция: в экстремальном программировании делается еще больший упор на согласованность, этот метод при- зывает проводить слияние всего продукта после каждой отметки об изменении .
z
Простота проектирования: этот метод также известен как
«независимость проектирования», считается одним из труд-
Коучинг — альтернативный взгляд
239
нейших для изучения методов, поскольку он один из самых нелогичных . Команды тяжело справляются с этим методом, даже когда им не нужно согласовывать свои действия с други- ми командами . При согласовании работы нескольких команд монолитные, централизованные, заранее спланированные ар- хитектуры создают огромные зависимости между командами, которые, как правило, заставляют их работать в тесной связи между собой, что нарушает большую часть обещаний Agile .
Простота проектирования, особенно в сочетании с такими методами, как микросервисная архитектура, позволяет при- менять Agile в крупных масштабах .
Будущее Agile-коучинга
В последние несколько лет профессиональный коучинг и фасили- тация все прочнее занимают свое место среди дисциплин Agile . На курсах скрам-мастера с расширенной сертификацией (ACSM), про- водимых Scrum Alliance, есть несколько учебных задач, связанных с коучингом и фасилитацией, а программы «сертифицированный командный коуч» (CTC) и «сертифицированный корпоративный коуч» (CEC) требуют усвоения еще большего количества навыков фасилитации и коучинга . Руководство по Scrum дает определение скрам-мастера как того, кто проводит коучинг .
Поскольку все больше людей проходят курсы профессионального коучинга и встречают профессиональных коучей, которые рабо- тают в сообществе Agile, коучинг в Agile привлекает к себе все больше внимания .
Кажется, в последние пару месяцев наблюдается рост интереса к профессиональному коучингу . Люди все чаще пропускают об- учение по программе ICP-ACC и сразу идут на обучение по ICF .
Глава 6. Внедрение Agile
Появилась первая коучинговая школа Agile, аккредитованная ICF, и скоро появится, по крайней мере, еще одна . Agile-коучинг ждет большое будущее!
ЗАКЛЮЧЕНИЕ (СНОВА БОБ)
Во многих отношениях эта глава была больше о том, чего не нужно делать, чем о том, что стоит . Возможно, потому что я видел много примеров того, как не нужно переходить на Agile . В конце концов, я сейчас думаю так же, как и 20 лет назад: «Что может быть про- ще? Всего лишь соблюдать простые правила и применять методы .
Вот и все» .
7
МАСТЕРСТВО ВЫСШЕГО
УРОВНЯ
Автор Сандро Манкузо, 27 апреля 2019 года
Глава 7. Мастерство высшего уровня
242
Волнение . Его чувствуют многие разработчики, когда впервые слышат об Agile . Для большинства из нас, разработчиков, которые приходят с фабрик программного обеспечения с менталитетом каскадной модели, Agile оставался надеждой на избавление от гнета . Надеждой на то, что мы будем работать сообща, к нашему мнению будут прислушиваться и уважать его . У нас будут модели и методы лучше, чем были . Мы будем работать малыми итерация- ми и безотлагательно давать обратную связь . Мы будем регулярно выпускать релизы нашего приложения . Мы будем поддерживать общение и обратную связь с пользователями . Мы будем постоянно анализировать и приспосабливать наши способы работы . Мы бу- дем вовлечены с самого начала разработки . Мы будем ежедневно на связи с клиентами . Мы на самом деле будем одной командой .
Мы будем регулярно обсуждать деловые и технические вопросы и договариваться о том, как двигаться вперед, к нам будут отно- ситься как к профессионалам . Бизнес и технологии будут работать сообща на производство замечательных программных продуктов, приносящих пользу нашим компаниям и клиентам . В самом начале нам казалось, что Agile слишком хорош, чтобы быть правдой . Мы думали, что наши компании никогда не примут мировоззрение
Agile, не говоря уже о самих методах .
Но большинство из них смогли это сделать и были приятно удив- лены . Вдруг все изменилось . У нас появились списки невыпол- ненных задач и пользовательские истории вместо документов с требованиями . У нас появились настоящие доски и диаграммы сгорания задач вместо диаграмм Ганта . У нас появились стикеры, которые мы передвигали каждое утро в соответствии с ходом работ .
В стикерах чувствовалась какая-то мощная энергетика — что-то, что вызывало сильную психологическую зависимость . Они как будто представляли нашу приверженность Agile . Чем больше таких заметок было на стене, тем более вовлеченными в Agile мы себя
Похмелье от Аgile
243
ощущали . Мы стали командой, работающей по Scrum, а не брига- дой строителей . У нас больше не было менеджеров проекта . Нам сказали, что нам не нужны менеджеры, теперь наши менеджеры будут «владельцами продукта», а у нас будет самоорганизация .
Нам сказали, что владельцы продукта и разработчики будут тесно сотрудничать, словно одна команда . И отныне, поскольку наша ко- манда работает по Scrum, мы наделены правом принятия решений .
Не только технических, но и тех, что связаны с самим проектом .
Или мы так думали .
Agile бурей захватил отрасль программного обеспечения . Но, как и в игре в испорченный телефон, изначальный посыл Agile иска- зили и упростили, преподнося его компаниям как методологию, которая ускорит выпуск программного обеспечения . Для компаний и руководителей, применяющих каскадную модель или RUP, это звучало райской песнью .
Менеджеры и заинтересованные лица пришли в восторг . В конце концов, кто бы не хотел испробовать Agile? Кто бы не хотел бы- стрее выпускать программное обеспечение? Даже среди скептиков
Agile вызывал интерес . Если ваши конкуренты хвастаются тем, что используют Agile, а вы нет, что вам мешает? Что о вас подумают ваши потенциальные клиенты? Компании не могут позволить себе отказаться от Agile . За годы, последовавшие за саммитом Agile, компании по всему миру встали на путь перехода к Agile . Началась эра внедрения Agile .
ПОХМЕЛЬЕ ОТ АGILE
Переход из одной культуры в другую был непрост . Компаниям требовалась помощь извне, чтобы осуществить его в своих ор- ганизациях . Появился новый вид специалистов — Agile-коучи .
Глава 7. Мастерство высшего уровня
244
Было создано много различных программ сертификации . Неко- торые сертификаты можно получить, просто пройдя двухдневные курсы .
Продать методы Agile менеджерам среднего звена было легко — всем им хотелось, чтобы ПО выпускалось быстрее . «Инжини- ринг — это несложно . Если наладить процесс разработки, с ним тоже будет все в порядке, — говорили менеджерам . — Дело всегда в людях» . И они покупали . Руководители работают с людьми и покуда занимают свою должность, они счастливы, когда их под- чиненные работают быстрее .
Множество компаний на самом деле получили пользу от перехода на Agile, и сегодня их положение дел гораздо лучше, чем до этого .
Многие из этих компаний могут развертывать ПО несколько раз в день, бизнес и технологии у них работают действительно как одна команда . Но так, конечно, далеко не у всех . Менеджеры в по- пытке ускорить разработчиков используют полную прозрачность процесса для контроля каждого шага . Agile-коучи, у которых нет опыта ведения бизнеса и опыта технических работ, обучают
менеджеров и говорят разработчикам, что им делать . Дорожные карты и вехи определяются менеджерами и навязываются ко- мандам разработчиков — разработчики могут оценивать работу, но их заставляют вписывать свои оценки в навязанные вехи . До- вольно часто можно встретить проекты, в которых используются соответствующие итерации и пользовательские истории, уже распределенные руководством на следующие полгода-год . Если разработчик не в состоянии угнаться за всеми единицами слож- ности историй за спринт, ему придется работать в следующем спринте больше, чтобы наверстать упущенное . Ежедневные стен- дап-митинги становятся встречами, где разработчики должны делать доклад о ходе работ владельцам продукта и Agile-коучам,