Искусство Agile-разработки. Теория и практика гибкой разработки ПО E-Book

Джеймс Шор

• Herausgeber: Питер
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Russisch

Seitenzahl: 988

Veröffentlichungsjahr: 2023

Beschreibung

Большинство компаний, разрабатывающих ПО, якобы используют Agile, но на самом деле не понимают, что это такое Agile. Хотите повысить гибкость своей команды? В книге вы найдете четкие, конкретные и подробные рекомендации о том, что, как и почему следует делать, а когда стоит пойти на компромиссы. Джеймс Шор предлагает реальные решения по освоению, планированию, разработке и управлению, основанные на более чем двадцатилетнем опыте Agile. Он объединяет актуальные идеи экстремального программирования, Scrum, Lean, DevOps и многих других в единое целое. Узнайте, как успешно внедрить гибкую разработку в вашей команде и организации, или разберитесь, почему Agile вам не подходит.

Leseprobe

Джеймс Шор , Шэйн Уорден

Искусство Agile-разработки. Теория и практика гибкой разработки ПО

2023

Переводчик Е. Дьяконова

Джеймс Шор , Шэйн Уорден

Искусство Agile-разработки. Теория и практика гибкой разработки ПО. — СПб.: Питер, 2023.

ISBN 978-5-4461-2386-5

© ООО Издательство "Питер", 2023

Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

Отзывы

Автор «Искусства Agile-разработки» смог совершить, казалось бы, невозможное, собрав все материалы по обширнейшей теме разработки современного программного обес­печения в понятную и увлекательную книгу. Новички, лишь начинающие изучать итеративные процессы, найдут в ней отличный обзор популярных практик. Людям, заблудившимся в дебрях мудреных процессов «масштабизации Agile», она предлагает хорошие идеи выхода из этого ада. Первое издание оказало огромное влияние на мою карьеру два десятилетия назад, и, уверен, второе издание аналогичным образом поможет миллионам разработчиков улучшить свои методы поставки ПО.

Гойко Аджич, автор книг Running Serverless, Impact Mapping и Specification by Example

В этой книге есть все: от кода до поставки готового продукта. Заработанные десятилетиями тяжелого труда знания превратились в легкочитаемый и доступный для восприятия материал — обязательный к прочтению для всех, кто работает с командой разработчиков программного обеспечения или в ней.

Ави Кесснер, инженер, Forter

Эта книга получит свое постоянное место на моей книжной полке.

Кришна Кумар, основатель и CEO, Exathink Research

Первое издание этой книги заворожило меня до такой степени, что до сих пор стоит на моей книжной полке в качестве справочника. Второе издание сохраняет шарм своего предшественника и содержит еще больше знаний, накопленных за последнее десятилетие.

Бенджамин Мускалла, старший инженер-программист, GitHub

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

Луиза Нуньес, менеджер программ, Thoughtworks

Это моя любимая книга об Agile. Она охватывает технические и управленческие темы. Я использую ее на своих занятиях и всегда рекомендую своим клиентам.

Николас Паес, инженер-программист и преподаватель, Университет Буэнос-Айреса

Джеймс подробнейшим образом описывает собственный опыт в Agile-разработке ПО. Простыми словами, связывая теорию с практикой.

Кен Пью, главный консультант, автор книги Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability

Тысячи книг об Agile. Какую из них прочитать? Я советую вам эту. Джеймс работает с Agile с первых дней его появления и знает свое дело. Книга разбирает весь бессмысленный мусор в нашей отрасли, окружающий это понятие, и предлагает тщательно выверенный, целостный подход. Этот подход не будет быстрым и легким, но он того стоит. Мне понравилась книга «Искусство Agile-разработки». Это книга с характером!

Бас Водде, соавтор LeSS

Джеймс Шор полностью обновил «Искусство Agile-разработки», дополнив книгу новыми инструментами, методами и уроками прошедшего десятилетия. Эта жемчужина среди книг поможет вам превратить ваш стиль работы в действительно эффективный Agile-подход.

Билл Уэйк, XP123, LLC

Моей семье

Предисловие

Когда мы писали Манифест Agile для разработки программного обеспечения, нашими сторонниками было незначительное меньшинство людей, пытавшихся изменить отрасль. Сейчас, 20 лет спустя, «agile» — это мейнстрим. Я пишу «agile» в кавычках намеренно: множество людей говорят, что они занимаются разработкой программного обеспечения по Agile, в самом деле искренне в это веря, однако их действия мало напоминают то ви́дение, которым мы поделились со всеми два десятилетия назад.

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

Джеймс Шор был одним из пионеров, вставших на тропу экстремального программирования (Extreme Programming, XP), центрального элемента движения Agile. Первое издание этой книги было отличным руководством для команд, показывавшим им, что нужно знать для правильного выполнения Agile-процессов. Позже Джеймс вместе с Дианой Ларсен продолжили работу над созданием модели Agile Fluency™, которая объединила в себе их опыт развития навыков в использовании подходов Agile. Модель показывает, что простое применение техник проектного управления, часто именуемых базовым подходом Scrum, дает некую ценность, фокусируя внимание на потребностях клиентов, но не учитывает технических навыков, необходимых для того, чтобы полностью раскрыть преимущества высокой производительности и надежности, которых добиваются многие команды.

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

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

Мартин Фаулер, Chief Scientist, Thoughtworks

Введение

Вопрос: Что нужно делать, чтобы выступить в Карнеги-холле?

Ответ: Практиковаться, практиковаться и еще раз практиковаться.

Я хочу помочь вам овладеть мастерством Agile-разработки.

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

Как можно научиться такому сложному искусству? Практикуясь!

Во-первых, эта книга — руководство. Она содержит подробное описание одного из способов практического применения Agile. Книга основана на экстремальном программировании, но также берет идеи и практики из Scrum, Kanban, DevOps, Lean Software Development, Lean Startup и др. В конечном счете это практическое пособие, которое позволит вам успешно внедрить Agile-разработку в вашу команду и организацию или поможет обнаружить, что Agile не подходит в вашей ситуации.

Во-вторых, эта книга призвана помочь вам овладеть мастерством Agile-разработки. Освоить Agile означает выйти за рамки книги рецептов. Разработка программного обеспечения — слишком чувствительный к контексту процесс, чтобы какой-то один подход подошел вам полностью, и слишком богатый нюансами, чтобы какая-то книга могла научить вас, как его освоить. Мастерство приходит изнутри — благодаря опыту и интуитивному пониманию природы волн, вызванных брошенным в воду камнем вашего выбора.

Я не могу спрогнозировать, какую волну поднимет ваш выбор в вашей организации. Я и не пытаюсь. Вы должны сами определить нюансы и достичь понимания. Это единственный способ овладеть искусством. Следуйте практикам. Смотрите, что происходит. Думайте, почему они сработали… или не сработали. Потом повторяйте. Что было таким же? Что получилось по-другому? Почему? Потом делайте это снова. И снова.

Поначалу вам может быть трудно понять, как использовать каждую из практик. Они могут выглядеть простыми на бумаге, но сложными в реальном применении. Продолжайте практиковаться, пока не станет легче.

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

Однажды правила перестанут вас интересовать. В конце концов, Agile не о том, чтобы следовать правилам. Тогда вы подумаете: «Речь о простоте и обратной связи, общении и доверии. О поставке ценности и смелости делать правильные вещи в нужное время». Вы станете мгновенно оценивать множество возможностей и интуитивно выбирать лучшее направление действий.

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

Для прагматиков

А что, если вы не хотите овладевать так называемым «искусством»? Что, если вы хотите просто разрабатывать хорошее ПО?

Не волнуйтесь. Эта книга и для вас тоже. На основе моего многолетнего опыта Agile-разработки я создал единый, четко определенный, комплексный подход.

Это позволяет мне использовать простой язык. Я даю много практических советов. Я честно пишу, когда мой подход не будет работать и какие альтернативы можно рассмотреть в таком случае. Глава 2 поможет вам начать.

Есть и обратная сторона обсуждения только одного подхода: ни один подход не применим ко всем случаям. Мой совет может быть непригоден для вашей команды или организации. Прочтите главы 4 и 5, чтобы понять, на каких общих условиях возможен успех, и изучите подраздел «Предварительные требования» каждой практики.

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

Я применяю эти идеи в реальной работе уже более 20 лет. В правильной среде они действительно работают. Agile оказывается более увлекательным и успешным, чем любой другой подход к разработке программного обеспечения, который я пробовал. Присоединяйтесь.

Что нового во втором издании

Первое издание было полностью переработано. Во втором издании сохранен приземленный, практический подход, свойственный первому изданию, как и большинство приводившихся в нем практик. Но почти все они были переписаны с учетом 14 лет прогресса Agile, не говоря уже о моем собственном 14-летнем опыте.

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

Среди наиболее заметных дополнений:

• подробное руководство по внедрению Agile и адаптации этого внедрения к потребностям вашей компании, основанное на модели Agile FluencyТМ1, которую я создал вместе с Дианой Ларсен;

• новая глава о масштабировании Agile, основанная на моем опыте помощи большим и маленьким компаниям;

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

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

Для кого предназначена книга

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

Книга представляет собой краткий справочник, но ее также можно читать и подряд, от корки до корки. Каждая практика в частях II–IV предназначена для самостоятельного чтения. Блоки «См. также» и ссылки на источники помогут вам сопоставить информацию. Вдобавок печатное издание можно открыть в любом месте и быстро просмотреть интересующую информацию. Можете пролистать книгу и остановиться, чтобы прочитать какую-то врезку более внимательно, если она привлечет ваше внимание.

Если вы менеджер или руководитель высшего звена, который хочет понять, как Agile может или должен работать в вашей компании, то прочитайте часть I. Если вы руководитель командного уровня, то прочтите еще и раздел «Менеджмент» главы 10 и, возможно, другие практики, рассматриваемые в той же главе.

Если вы член команды или менеджер, заинтересованный в том, чтобы внедрить Agile в свою компанию или улучшить уже работающую в ней практику Agile, то прочитайте всю книгу целиком. Часть I поможет вам понять, как представить идеи Agile коллегам. Остальной материал книги поможет разобраться, как воплотить Agile в жизнь.

Если вы часть Agile-команды и просто хотите получить знания, которые позволят выполнять вашу работу, то можете сосредоточиться на практиках, изложенных в частях II и III. Начните с главы 1, чтобы получить общую картину, затем перейдите к тем практикам, которые использует ваша команда.

Если вы не являетесь частью Agile-команды, но работаете с одной из них, то посоветуйтесь с ними, что почитать. Продакт-менеджеры, владельцы продукта, дизайнеры могут начать с главы 8 и раздела «Цель» главы 7. Сотрудникам отделов безопасности и отделов эксплуатации рекомендую разделы «Сборка для эксплуа­тации» главы 15, «Обнаружение слепых зон» и «Анализ инцидентов» главы 16. Тестировщики, ознакомьтесь с главой 16.

Если вам просто любопытно узнать об Agile, то начните с главы 1. После этого ознакомьтесь с частями II–IV. Начните с наиболее интересных для вас практик. Можете читать их в любом порядке.

О приглашенных авторах

Эта книга создана в соавторстве с несколькими выдающимися людьми. Гитте Клитгаард написала раздел «Безопасность» главы 7, профессионально осветив тему психологической безопасности. Диана Ларсен написала разделы «Динамики команды» и «Устранение препятствий» главы 11, поделившись своим многолетним опытом организационного и командного развития. Шейн Уорден, мой соавтор первого издания, не смог написать новый материал для второго, но остался надежным и ценным советчиком, и наша работа над первым изданием легла в основу этой книги.

Гитте Клитгаард

Гитте Клитгаард — Agile-коуч, инструктор и наставник, специализирующаяся на помощи организациям в формировании психологической безопасности и ответственности. Гитте сразу переходит к сути дела и помогает людям стать самими собой и таким образом достичь успеха.

Ее вклад в сообщество включает организацию встреч для тренеров и выступления на конференциях, где она поднимает темы психического здоровья и психологической безопасности и делает их доступными для общего понимания. Гитте создает безопасную и уважительную атмосферу на работе и за ее пределами. Она умеет слушать и вовлекать в обсуждение более тихие голоса и малые сообщества.

В свободное время Гитте собирает LEGO, коллекционирует фигурки Йоды и поддерживает связь с друзьями со всего земного шара, многих из которых она считает своей второй семьей.

Гитте является владельцем Native Wired и руководила преобразованиями в таких компаниях, как LEGO, Spotify и Mentimeter.

Диана Ларсен

Более 20 лет Диана Ларсен вносила свой вклад в формирование основ и расширение идей Agile, а также в практику создания и развития квалифицированных команд. Диана — соавтор книг Agile Retrospectives2, Liftoff, 2nd ed., Five Rules for Accelerated Learning и электронной книги The Agile Fluency Model: A Brief Guide to Success with Agile; кроме того, сейчас пишет две новые книги. Будучи главным коучем, консультантом, координатором, спикером и наставником, она продолжает вносить свой вклад и соответствует своему званию в проекте Agile Fluency — «Главное связующее звено» (Chief Connector). Живет в Портленде, на верхнем левом побережье США.

Шейн Уорден

Шейн Уорден — руководитель инженерно-технической службы и писатель, в частности, соавтор первого издания этой книги, а также книги Masterminds of Programming3. В свободное от работы время он помогает находить животным хорошие дома.

Условные обозначения

В книге используются следующие условные обозначения.

Аудитория

В этих блоках указывается целевая аудитория каждой практики Agile.

См. также

В этих блоках приводятся связанные практики.

Курсив

Курсивом выделены новые термины и важные понятия.

Шрифт одной ширины

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

Жирный шрифт одной ширины

Показывает добавленный код в работающих примерах кода.

Перечеркнутый шрифт одной ширины

Показывает удаленный код в работающих примерах кода.

Шрифт без засечек

Используется для обозначения URL, адресов электронной почты, названий кнопок, каталогов.

Использование примеров кода

Дополнительные материалы доступны для скачивания по ссылке https://www.james­shore.com/v2/books/aoad2.

Пожалуйста, напишите по адресу электронной почты [email protected], если у вас технический вопрос или проблема с использованием материалов.

Эта книга призвана помочь в решении ваших задач. В общем случае все примеры кода из книги вы можете использовать в своих программах и в документации. Вам не нужно обращаться в издательство за разрешением, если вы не собираетесь воспроизводить существенные части кода, или если вы разрабатываете программу и используете в ней несколько фрагментов кода из книги, или если будете цитировать эту книгу либо примеры из нее, отвечая на вопросы. Вам потребуется разрешение от издательства O’Reilly, если вы хотите продавать или распространять примеры из книги либо хотите включить существенные объемы программного кода из книги в документацию вашего продукта.

Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов, издательства и ISBN.

Получить разрешение на использование значительных объемов программного кода примеров из этой книги можно по адресу [email protected].

Благодарности

Эта книга вдохновлена бессчетным количеством источников. На протяжении всей книги я поблагодарил скольких мог, но наверняка забыл кого-то. (Пожалуйста, примите мои извинения.) Я хочу выразить особую признательность Кенту Беку, Рону Джеффрису и Уорду Каннингему за то, что они создали экстремальное программирование, с которого я начал мое Agile-путешествие. Алистер Коберн и его круглый стол по программному обеспечению, как и бурные споры и обсуждения Вики-страниц C2 Уорда Каннингема, помогли определить направление в начале этого пути. Благодарю также Диану Ларсен, с которой я работаю много лет — ее точка зрения так хорошо уравновешивает мою. И конечно, Мартина Фаулера, чей вдумчивый стиль письма много лет вдохновляет меня.

Поддержка этого издания со стороны O’Reilly была просто исключительной. Я выражаю огромную благодарность Гэри О’Брайену, моему редактору, обеспечивавшему постоянную обратную связь и поддержку. Благодарю также Мелиссу Даффилд, которая помогла сделать так, чтобы книга пользовалась успехом; Райана Шоу, убедившего меня в том, что пришло время для второго издания; Дебору Бейкер, подготовившую издание ранних выпусков книги; Сюзанну Хьюстон, которая позаботилась о том, чтобы люди узнали о книге; Ника Адамса и команду Tools издательства O’Reilly, которые выстроили производственный процесс и успешно разобрались с моими запутанными и придирчивыми требованиями к оформлению; Кристофера Фоучера, который руководил превращением «сырой рукописи» в «законченную книгу»; Тонью Трибулу и Стефани Инглиш, исправивших мои грамматические чудачества; Кейт Дулли, превратившую мои наброски от руки в понятные рисунки.

Что касается обратной связи, особую признательность выражаю моим рецензентам. Рецензирование было открытым, и мы получили более 700 электронных писем от десятков людей. Практически каждое было содержательным и полезным и в результате улучшило книгу. Кроме того, благодарю тех людей, которые ответили на мои прямые запросы на рецензию. Спасибо всем: Адриану Саттону, Энтони Уильямсу, Ави Кесснер, Басу Водде, Бенджамину Мускалла, Биллу Уэйку, Брэду Эпплтону, Си Кейту Рэйю, Си Джею Джеймсону, Кристиану Дювану, Дэйвиду Пулу, Диане Ларсен, Диего Фонтдевиле, Эмили Бач, Эрику Петерсону, «Эвану M.», Францу Амадору, Джорджу Динвидди, Гойко Аджичу, Джейсону Йипу, Джеффу Григгу, Джеффу Паттону, Джеффри Палермо, Йохану Алуддену, Кену Пью, Кришне Кумару, Лиз Кеог, Луизе Нуньес, Марсело Лопесу, Маркусу Гертнеру, Мартину Фаулеру, Михалу Свободе, Николасу Паесу, Полу Стивенсону, Петеру Гравесу, Реувену Ягелю, Рикардо Майерхоферу, Рону Джеффрису, Рону Квартелу, Саре Хоран Ван Треесе, Стиву Бементу, Томасу Джей Оуэнсу, Тодду Литтлу и Уорду Каннингему.

Особая благодарность тем рецензентам, которые пошли еще дальше, прочитав и прокомментировав почти каждую из частей книги: Басу Водде, Биллу Уэйку, Кену Пью, Мартину Фаулеру и Томасу Джей Оуэнсу.

Процесс открытого рецензирования пошел на пользу и первому изданию, и все его преимущества, в свою очередь, отразились и на этой книге. Спасибо Адриану Ховарду, Адриану Саттону, Энн Баркомб, Энди Лестеру, Энтони Уильямсу, Басу Водде, Биллу Капуто, Бобу Коррику, Брэду Эпплтону, Крису Уилеру, Кларку Чингу, Дади Ингольфссону, Диане Ларсен, Эрику Петерсену, Джорджу Динвидди, Илье Прейсу, Джейсону Йипу, Джеффу Олферту, Джеффри Палермо, Джонатану Кларке, Кейт Рэй, Кевину Рутерфорду, Ким Грэсман, Лизе Криспин, Марку Уайтэ, Николасу Эвансу, Филиппе Антрасу, Рэнди Коулмэн, Роберту Шмитту, Рону Джеффрису, Шейну Доуну, Тиму Хоутону и Тони Бирну за их множественные комментарии и Брайану Марику, Кену Пью и Марку Стрейбеку за их замечания по готовому черновику.

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

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

1 Agile Fluency — зарегистрированный товарный знак Agile Fluency Project LLC.

2Дерби Э., Ларсен Д. Agile ретроспектива. Как превратить хорошую команду в великую.

3Бьянкуцци Ф., Уорден Ш. Пионеры программирования: диалоги с создателями наиболее популярных языков программирования.

I. Улучшая гибкость

Глава 1. Что есть Agile

Agile везде. И, как ни парадоксально, нигде.

Двадцать лет назад локомотив Agile с ревом ворвался в сознание разработчиков программного обеспечения. За это время количество компаний, называющих себя Agile, возросло на порядки. А сколько команд действительно применяет Agile-подход в своей работе? Не так много. Agile, легко повторяемое название, пользуется огромным успехом. А как насчет идей, стоящих за названием? Вообще-то большинство из них игнорируется.

Исправим это.

Происхождение Agile

В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и называлось: «Кризис программного обеспечения». Проекты разработки выходили за рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто цитируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть их была полностью отменена [Standish1994].

Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом.

Чтобы взять под контроль разработку ПО, большие организации придумали ­высокодетализированный процесс, точно определявший, как ПО должно создаваться. Все жестко контролировалось, чтобы исключить возможность ошибки. (Во всяком случае, в теории.)

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

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

Подход, основанный на фазах, получил название водопадной (waterfall develop­ment) или каскадной разработки (phase-gate development)4. Если вам это кажется похожим на нелепое пугало — считайте, что вам повезло. Не все команды применяли в 1990-х перегруженный документацией каскадный процесс, но он широко признавался как логичный и разумный метод работы. Конечно, нужно было определить требования, разработать проект, затем выполнить реализацию и следом — тестирование.Конечно, нужно было документировать каждую фазу. Это была дисциплина. Это была инженерия. Как еще можно было добиться успеха?

Рожденный из кризиса

Крупные компании расписывали свои процессы в мельчайших деталях. Роли, ответственности, шаблоны документов, языки моделирования, советы по контролю за изменениями… каждый аспект разработки строго регламентировался и контролировался. Если проект заканчивался провалом (а согласно CHAOS Report, менее одной шестой доли проектов были успешны), причиной считалась недостаточная детализация процесса: нужно больше документов, больше согласований. Это порождало огромное количество документации. Мартин Фаулер описывал это в своей статье The Almighty Thud [Fowler1997].

Этот стиль работы был далеко не лучшим. Он был бюрократическим и бесчеловечным. Казалось, знания и навыки не так важны, как соблюдение процессов. Программисты чувствовали себя легко заменимыми винтиками бездушной машины. И даже она работала не очень хорошо.

И тогда несколько человек создали более простые, изящные и менее директивные методы разработки программного обеспечения. Они назывались легковесными в отличие от тяжеловесных, использовавшихся большими компаниями. Эти методы носили такие названия, как адаптивная разработка программного обеспечения (Adaptive Software Development), Crystal, разработка на основе функциональности (Feature-Driven Development, FDD), метод разработки динамических систем (Dynamic Systems Development Method, DSDM), экстремальное программирование (ХР) и Scrum.

К концу 1990-х эти методы стали привлекать серьезное внимание. Экстремальное программирование, в частности, вызвало вспышку массового интереса среди программистов. В 2001 году 17 сторонников легковесной методологии встретились на горнолыжном курорте в штате Юта, чтобы обсудить объединение усилий.

Манифест Agile

«Лично я не ожидал, что эта конкретная группа [людей] сможет договориться о чем-либо по существу», — позже говорил Алистер Кокберн.

И действительно, за два дня они смогли договориться только о двух вещах: названии Agile и заявлении о четырех ценностях новой методологии (рис. 1.1). В течение следующих нескольких месяцев, переписываясь по электронной почте, эти люди сформулировали 12 сопутствующих принципов (рис. 1.2) [Beck2001].

Рис. 1.1. Ценности Agile

Рис. 1.2. Принципы Agile

Это стало Манифестом Agile, который изменил мир. «Таким образом, — продолжил Алистер, — они в конце концов все же смогли договориться о чем-то по существу»5.

Однако единого метода Agile не было. Его никогда не было и никогда не будет. Agile подразумевает три составляющие: название, ценности и принципы. И все. Это не что-то, что можно делать. Это философия. Это способ мышления, посвященный разработке программного обеспечения. Невозможно «использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть. Если ваши команды воплощают философию Agile, то вы — Agile. Если не воплощают — то нет.

Суть Agile

Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании в тщательно продуманные, беспристрастно точные объяснения. Его определение «Суть разработки программного обеспечения по Agile» — одно из лучших:

Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы6.

Мартин Фаулер

Адаптивность вместо предиктивности

Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в области программного обеспечения успешна? В отчете успешность определена очень специфическим образом:

• успешный — проект выполнен вовремя и в рамках бюджета, все характеристики и функциональности соответствуют изначально запланированным;

• сомнительный — проект завершен, результаты переданы в эксплуатацию, но количество характеристик и функциональностей меньше, чем было заявлено изначально. Запланированные бюджет и сроки проекта превышены;

• неуспешный — проект отменен в какой-либо момент в течение цикла разработки.

Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они все говорят о соответствии запланированному. Если вы сделали то, что собирались сделать, то вы успешны. А если нет, то неуспешны! Все просто.

На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]:

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

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

Взгляните еще раз на Манифест (см. рис. 1.1 и 1.2). Найдите пару минут, чтобы вдумчиво изучить ценности и принципы Agile. Сколько из них относятся к поставкам ценного программного обеспечения и адаптации к полученной обратной связи?

Ориентированность на людей, а не на процессы

В случае тяжеловесных процессов люди пытались избежать ошибок, тщательно определяя каждый аспект разработки ПО. При добавлении в процессы регламента индивидуальные навыки становились менее важными. В теории вы могли применять один и тот же процесс снова и снова с разными людьми и получать одни и те же результаты. (Если вдуматься, то они и получали. Просто не те результаты, которые хотели.)

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

У Agile-команд тоже есть процессы (у любой команды они есть, пусть и неявные), но они находятся на службе у человека, а не наоборот. И Agile-команды сами отвечают за свои процессы. Желая улучшить методы работы, люди меняют процессы.

Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы имеют отношение к концепции «люди на первом месте»?

Почему Agile победил

В течение первых десяти лет после появления Манифеста Agile столкнулся с небывалой критикой. Его называли «недисциплинированным». Говорили, что он никогда не будет работать. Следующие десять лет критики молчали. Agile был уже везде, по крайней мере это название. Тяжеловесные водопадные методы практически умерли. Молодые программисты вообще не верили в то, что кто-то когда-то мог работать таким образом.

Не то чтобы основанные на фазах процессы неполноценны по сути. У них, безус­ловно, есть свои недостатки, но если ограничивать их объем, при этом действуя в хорошо изученной предметной области, то методы водопадного стиля тоже могут работать. Проблема была в самом тяжеловесном процессе, который применяли крупные компании. Словно по иронии судьбы, процессы, предназначенные для того, чтобы избегать проблем, на самом деле сами вызывали большинство проблем, с которыми сталкивались компании.

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

В случае тяжеловесных процессов придавалось настолько большое значение контролю над процессами и согласованию документации, что порождались значительные задержки и расходы. На то, чтобы получить работающее ПО, уходили годы, и заказчику не показывали ничего конкретного почти до самого конца проекта. Вместо того чтобы приветствовать изменения, в этих процессах делалось все, чтобы их избежать. Была даже отдельная составная часть процессов «Совет по контролю за изменениями» (Change Control Board), чьей основной задачей было сказать «нет» запросам на изменения. (Точнее, «да, но за это понадобится доплатить».)

Все это наслаивалось друг на друга в проектах, где люди годами вели разработку, прежде чем могли что-то показать клиенту. И когда они это делали, было уже слишком поздно и дорого что-то менять. В конечном итоге они выдавали программное обеспечение, которое не делало то, чего хотел заказчик.

Типичный провал тяжеловесного процесса

Третьего февраля 2005 года Роберт С. Мюллер III, директор Федерального бюро расследований, предстал перед подкомитетом Сената США, чтобы объяснить, как ФБР умудрилось потратить впустую 104,5 миллиона долларов7.

Это явно было не комфортно для компании. В июне 2001-го ФБР запустило проект VCF с целью заменить программное обеспечение для управления делами. Через четыре года он был отменен. Общие затраты составили 170 миллионов долларов; 104,5 миллиона из них были полностью невозвратными.

Сроки и последовательность событий проекта могут рассказать нам хорошо знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноябре 2002-го, были определены «четкие требования». Программное обеспечение было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило некоторое количество недостатков в VCF, которые делали его непригодным для использования». Подрядчик, разрабатывавший программу, согласился исправить недостатки, но только за дополнительную плату в размере 56 миллионов долларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять недочеты, фактически перечеркнув годы работы.

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

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

Почему Agile работает

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

«Если коротко, то экстремальное программирование обещает снизить риски проекта, улучшить отклик на потребности бизнеса и повысить продуктивность в течение всего срока жизни системы, сделать приятным создание ПО в команде — и все это одновременно. Это правда. Прекратите смеяться» [Beck2000a].

Extreme Programming Explained, первое издание

Одни действительно смеялись. А другие попробовали и обнаружили, что (вопреки всеобщему мнению о том, как должна вестись разработка ПО) экстремальное программирование реально выполняло все, что обещало. Так, несмотря на смех, оно пользовалось спросом, а вместе с ним Agile.

Экстремальное программирование было живым примером Agile, заложившим основу идей и терминологии, которые используются до сих пор. Однако сила сообщества Agile в том, что оно всегда было широкой коалицией. Agile не ограничивается каким-то одним методом. Он постоянно расширяется, включая в себя новых людей и свежие идеи. «Бережливая разработка программного обеспечения» (Lean software development), Scrum, Kanban, «Бережливый стартап» (Lean Startup), DevOps и многие-многие другие подходы внесли свой вклад в то, что сейчас известно под общим названием Agile.

Если взять все эти идеи и сгруппировать по категориям, то получится пять центральных концепций.

• Полагайтесь на людей. Создавайте процессы, которые понятны и могут работать с учетом человеческой природы. Отдайте право принимать решения в руки тех, кто наиболее квалифицирован в этой области. Выстраивайте здоровые рабочие взаимоотношения, основанные на сотрудничестве.

• Поставляйте полезный продукт. Запрашивайте обратную связь, экспериментируйте и подстраивайте свои планы. Считайте частично выполненную работу затратами, а не прибылью. Концентрируйтесь на создании ценных результатов. Поставляйте продукт часто.

• Исключите напрасную трату времени и усилий. Выполняйте работу маленькими обратимыми шагами. Примите возможность неудачи и стройте ваши планы с учетом вероятности их быстрого провала. Максимизируйте невыполненную работу. Стремитесь к производительности, а не эффективности.

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

• Совершенствуйте ваши процессы. Экспериментируйте с новыми идеями. Настраивайте и адаптируйте то, что работает. Никогда не считайте, что отлаженный, популярный способ будет самым лучшим и для вас.

Agile определяется Манифестом, но сам Манифест — лишь начальная точка. Agile работает потому, что люди заставляют его работать. Они берут идеи Agile, адаптируют их к своим ситуациям и не перестают совершенствоваться.

Почему Agile терпит неудачу

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

Дело в том, что нет такого Agile, который можно было бы где-то взять. Это просто набор идей. Существуют специфические подходы Agile, такие как экстремальное программирование и Scrum, которые могут вам объяснить, как бытьAgile, но вам все же придется принять лежащую в его основе философию.

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

Карго-культы

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

Однажды войска покинули остров, и большие металлические птицы перестали прилетать. Успевшие привыкнуть к комфорту островитяне сплели из бамбука собственную взлетно-посадочную полосу. Они построили высокую платформу, посадили на нее своего вождя и надели ему на голову кокосы, которым придали форму наушников. Но как бы ни старались островитяне, большие металлические птицы так больше никогда и не вернулись.

Трагедия карго-культа — в его приверженности к поверхностным, внешним проявлениям какой-либо идеи в сочетании с полным непониманием того, как эта идея работает на самом деле. В той истории островитяне воссоздали все элементы по отдельности: взлетно-посадочную полосу, башню, наушники, — но не знали обо всей инфраструктуре, благодаря которой прибывали самолеты.

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

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

Так и получается карго-культ. Много действий, ноль результата. Относящаяся к Agile составляющая отсутствует.

«В моей предыдущей компании огромное количество человеко-часов тратилось на совещания».

«Из-за этого [Agile] целая команда (30+ человек) лишилась работы, поскольку они не произвели почти ничего в результате почти года работы».

«Все это [Agile] означает, что разработчиков просто обманули, когда проект изменился... за день до поставки».

Реальные комментарии об Agile из сети

Слово Agile — повсюду. Идеи Agile — нет. Это вечный самообман для многих: единственный Agile, который они знают, — это карго-культ Agile.

Настало время это исправить. В этой книге я расскажу вам, как применять идеи Agile по-настоящему. Будьте начеку, чтобы не поддаться поборникам карго-культа Agile, которых вы встретите в книге. Они покажут вам, как делать не надо.

Готовы? Поехали.

4 Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса, написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для описания того, что люди уже давно делали [Bossavit2013, chapt. 7].

5 Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожидал… что эта конкретная группа приверженцев различных гибких методик сможет договориться о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Манифеста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой. Таким образом, мы все же смогли договориться о чем-то по существу».

6 Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно найти в статье [Fowler2000].

7 Источники: Mueller’s February 3, 2005, testimony to Congress (https://oreil.ly/GlQSa) и Inspector General Glenn Fine’s May 2, 2005, testimony to Congress (https://oig.justice.gov/node/672).

8 Впервые я прочел эту историю в трудах Ричарда Фейнмана, где в числе прочего была представлена его речь на церемонии вручения дипломов в Калтехе в 1974 году [Feynman1974]. История основана на реальных ритуалах, практиковавшихся в Меланезии после Второй мировой войны.

Глава 2. Как быть Agile

Как перейти от нагромождения Agile-идей к реальным, действующим Agile-командам?

Нужна практика. Очень много практики.

Практика Agile

У каждой команды есть свой подход к работе — процессы, или методы, которым она следует, зачастую формально не задокументированы. Эти методы отра­жают лежащую в их основе философию разработки программного обеспечения, хотя она не всегда бывает четко сформулирована и не обязательно последовательна.

Чтобы быть Agile, вам нужно изменить свои методы так, чтобы они стали отражать философию Agile. Это одновременно и проще, и сложнее, чем кажется. Это просто, поскольку в большинстве случаев вы можете начать с одного из готовых Agile-методов, например, представленного в этой книге. И это сложно, так как вам понадобится перестроить свой стиль работы, а это подразумевает изменение многих привычек.

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

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

Таким образом, несмотря на соблазн сразу настроить метод Agile под себя, лучше все же начать со стандартного, «книжного» подхода. Идея удалить наименее знакомые практики выглядит заманчиво, но именно они и будут вам нужны больше всего, если вы действительно собираетесь перейти на Agile. Именно с этими практиками связаны главные изменения в философии.

Как достичь мастерства

Овладение искусством разработки по Agile требует реального опыта использования конкретного, четко определенного метода Agile. Начните со стандартного, «книжного» подхода. Примените его на практике — полностью — и потратьте несколько месяцев, совершенствуя практику и досконально разбираясь, почему она работает. Потом настройте под себя. Выберите один из нюансов, разберитесь с последовавшими переменами и повторите.

Данная книга посвящена этой цели. В ней представлен тщательно подготовленный набор практик Agile, проверенных в реальном мире. Чтобы совершенствоваться в искусстве Agile или просто достичь бо́льшего успеха с помощью практик Agile, выполняйте следующие шаги.

1. Выберите для освоения подгруппу идей Agile. Глава 3 поможет вам определиться.

2. Применяйте как можно больше соответствующих практик. Они описаны в частях II–IV. Практики Agile усиливают друг друга, поэтому работают наилучшим образом, если использовать их все вместе.

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

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

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

На рис. 2.1 показан этот процесс. Сначала следуйте правилам, потом нарушайте их и в конце концов будьте выше правил9.

Рис. 2.1. Как достичь мастерства

С чего начать?

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

Присоединение к действующей команде Agile

Если вы планируете присоединиться к действующей Agile-команде или просто хотите дополнить свои знания о том, как Agile работает на практике, то можете перейти к частям II–IV. Каждая часть начинается с истории в стиле «один день из жизни», описывающей, как может выглядеть Agile. Команды, работающие по Agile, отличаются друг от друга, поэтому и ваша не будет абсолютно такой же. Но эти истории дадут вам представление, чего можно ожидать.

Прочитав истории, переходите к интересующим вас практикам. Каждая написана как отдельный справочный материал.

Введение Agile

Если вы помогаете своей организации сформировать Agile-команды или только хотите убедить ее сделать это, то оставшиеся главы части I помогут вам начать. Чтобы структурировать процесс, используйте чек-лист, представленный ниже.

Сначала убедитесь, что Agile подходит вашей компании:

• выберите подход Agile, который ваша организация сможет поддерживать (см. главу 3);

• определите, что ей нужно сделать, чтобы успешно внедрить Agile (см. главу 4);

• получите согласие на эксперимент с Agile (см. главу 5);

• если у вас несколько команд, то решите, как вы будете их масштабировать (см. главу 6).

За несколько недель до начала:

• определитесь, кто будет коучем (или коучами) команды, и выберите по меньшей мере одного человека, который будет продакт-менеджером (см. раздел «Вся коман­да» главы 7);

• организуйте встречу продакт-менеджера с исполнительным спонсором команды и ключевыми стейкхолдерами, чтобы разработать замысел проекта (см. раздел «Цель» главы 7);

• обеспечьте команде физическое или виртуальное помещение (см. раздел «Командная комната» главы 7);

• запланируйте и проведите сессию подготовки устава команды (см. врезку «Планирование сессии подготовки устава» в главе 7);

• попросите команду ознакомиться с новым методом. Раздайте людям копии этой книги, чтобы они могли ее изучить самостоятельно, предложите применить некоторые практики в их текущей работе и рассмотрите возможность проведения тренинга по тем практикам, которые вызывают трудности (практики представлены в частях II–IV).

Когда команда будет готова начать, сделайте глубокий вдох и:

• поручите членам команды спланировать первую рабочую неделю (см. подраздел «Ваша первая неделя» главы 9).

Совершенствование действующих Agile-команд

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

Если вы заинтересованы в небольшой регулировке уже работающих процессов вашей команды, то перейдите к частям II–IV и прочитайте об интересующих вас практиках. Если вы хотите более масштабных улучшений, то процесс будет таким же, как и при внедрении Agile в команду, за исключением того, что вам понадобится сосредочиться на конкретных элементах, требующих изменений.

В качестве руководства используйте чек-листы из предыдущего подраздела «Внедрение Agile» данной главы.

Если Agile не срабатывает в вашей организации, то ознакомьтесь с врезкой «Руководство по устранению неполадок» в главе 4.

Применение отдельных практик Agile

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

• Ежедневное планирование. Если вы боретесь с частыми прерываниями (inter­ruptions), то попробуйте использовать однодневные итерации (см. раздел «Планирование задач» главы 9). Возьмите за основу игру в планирование (см. раздел «Игра в планирование» главы 8) и измеряемый потенциал (capacity) по работе вашей команды на спринте (см. раздел «Потенциал» главы 9) и проводите совместные сессии планирования в начале каждого дня, откладывая все прерывания на сессию планирования следующего дня. Обеспечьте условия, чтобы люди сами оценивали свои задачи.

• Итерации. Если частые прерывания для вас не проблема, но вы все же хотели бы улучшить свое планирование, то попробуйте использовать недельные итерации (см. раздел «Планирование задач» главы 9). В этом случае вы также можете практиковать ежедневные рабочие стендап-митинги (см. раздел «Стендап-митинги» главы 9) и регулярные демо для стейкхолдеров (см. раздел «Демо для стейкхолдеров» главы 10). Со временем рассмотрите возможность использования индексных карточек для планирования и больших диаграмм, показывающих предстоящую работу, как описано в разделе «Визуальное планирование» главы 8.

• Ретроспективы. Частое проведение ретроспектив (см. раздел «Ретроспективы» главы 11) — отличный способ адаптировать и улучшить рабочие процессы команды. Могут быть полезны и другие практики, перечисленные в главе 11.

• Быстрая обратная связь. Быстрая автоматизированная сборка значительно улучшит вашу жизнь, а также откроет возможности для других усовершенствований (см. раздел «Нулевое трение» главы 13).

• Непрерывная интеграция. Непрерывная интеграция (практика, а не инструмент) не только уменьшает проблемы интеграции, но и способствует повышению качества сборок и тестов. Более подробную информацию см. в разделе «Непрерывная интеграция» главы 13.

• Разработка через тестирование. Хотя эту практику не так легко принять, как другие, она весьма эффективна. Разработка через тестирование (см. соответствующий раздел главы 13) позволяет снизить частоту появления программных ошибок (багов), повысить скорость разработки, улучшить вашу способность к переработке кода (рефакторингу) и сократить технический долг. На ее освоение может уйти некоторое время, так что запаситесь терпением.

Другие практики, описанные в частях II–IV, также могут оказаться полезными. Agile-практики объединены множеством зависимостей друг от друга, поэтому обязательно обратите внимание на блоки «См. также» и подраздел «Предварительные требования» каждой практики.

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

9 Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари (Shu-Ha-Ri).

Глава 3. Выберите свою гибкость

Нет смысла использовать Agile ради него самого. Задайте себе два вопроса.

1. Поможет ли нам Agile стать более успешными?

2. Чего нам будет стоить достижение этого успеха?

Ответив на эти вопросы, вы поймете, нужен ли вам Agile.

Что ценно для организаций?

Успех определяется не только доходами. Вот только несколько составляющих успеха:

• улучшение финансовых результатов — прибыль, рост выручки, биржевая стои­мость акций, снижение затрат;

• достижение целей организации — стратегические цели, оригинальные исследования, благотворительные цели;

• укрепление позиций на рынке — продвижение бренда, конкурентные различия, лояльность существующих клиентов, привлечение новых;

• обретение популярности — стратегическая информация, аналитика, отзывы клиентов;

• снижение риска — безопасность, требования законодательства, аудит;

• увеличение потенциала — наем и удержание персонала, моральный климат и развитие навыков, автоматизация.

Модель Agile Fluency

В 2014 году я сотрудничал с Дианой Ларсен, чтобы проанализировать, почему компании видят разные результаты от их Agile-команд. Мы оба работали с командами с самого начала. С годами мы заметили, что команды начинали склоняться к кардинально разным типам результатов и эти результаты имели тенденцию группироваться в разных «зонах».

Мы обобщили эти наблюдения в модели Agile Fluency™. Ее упрощенный вариант показан на рис. 3.1 [Shore2018b].

Рис. 3.1. Упрощенная модель Agile Fluency™

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

ПРИМЕЧАНИЕ

Несмотря на то что на рис. 3.1 представлен прямой путь от одного уровня к другому, в реальности все более беспорядочно. Команды могут достигать уверенного владения навыками на любом уровне, в любом порядке, хотя продвижение, показанное на рис. 3.1, типично.

Навыки, необходимые для свободного применения, перечислены в предисловиях к частям II–IV. Но уверенное владение навыками не достигается само по себе. Ваша организация тоже должна инвестировать в эти навыки своих команд. Это гораздо больше, чем поддерживать идеи Agile на словах. Организация должна произвести реальные, значительные изменения, которые занимают время, стоят денег и требуют вложения политического капитала.

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

Инвестирование в Agile должно стать осознанным выбором. Тщательно изучите каждый из уровней. Каждый требует затрат, и каждый имеет свои преимущества. Выберите те уровни, которые имеют наилучшее соотношение затрат и выгоды для вашей ситуации.

Вероятнее всего, вам не удастся убедить вашу компанию инвестировать в каждый уровень. Это нормально. В отличие от моделей зрелости (maturity models), таких как интегрированная модель зрелости возможностей компании при разработке ПО (Capability Maturity Model Integration, CMMI), модель Agile Fluency™ не показывает продвижения от слабых навыков к сильным. Вместо этого она демонстрирует множество вариантов соотношения инвестиций/выгоды. Хотя диаграмма показывает наиболее распространенный вариант продвижения, каждый уровень можно выбрать независимо. Каждый имеет ценность сам по себе.

Уровень владения навыками и степени зрелости

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

Каждый уровень имеет несколько степеней зрелости.

1. Обучение — команда изучает нужные навыки.

2. Профессионализм — команда может продемонстрировать нужные навыки, когда она концентрируется на них.

3. Свободное владение — команда демонстрирует нужные навыки автоматически, не прикладывая осознанных усилий, при условии, что в команде есть коуч.

4. Самостоятельное свободное владение — команда демонстрирует нужные навыки автоматически, не нуждаясь в присутствии в команде коуча.

Уровень фокусировки (Focusing)

Уровень фокусировки — это самые основы Agile: сфокусированность на бизнес-результатах; командная работа; принятие на себя ответственности. Команды, которые свободно владеют навыками на этом уровне, фокусируют процесс разработки на основной цели команды, сначала выпускают наиболее ценные функциональности и меняют направление в ответ на меняющиеся потребности бизнеса. Они постоянно фокусируются на наиболее значимых приоритетах своей организации.

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

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

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

Если же вам удастся получить поддержку, то владение навыками на уровне фокусировки может быть достигнуто каждой командой примерно за 2–6 месяцев целенаправленных усилий. При должной поддержке они превзойдут свой предыдущий уровень производительности даже в течение 1–4 месяцев10. В части II приведены практики, которые могут им понадобиться.

Уровень поставки (Delivering)

Agile-команды могут менять свои планы в любое время. Для большинства команд это несколько снижает качество их кода. Они постепенно теряют свою способность вносить изменения, эффективные с точки зрения затрат. В итоге команды могут сказать, что нужно выбросить ПО и переписать его заново, а это дорогое и невыгодное решение.

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

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

Если ваша компания сделает эти инвестиции, то на достижение владения навыками на уровне поставки у ваших команд уйдет от 3 до 24 месяцев, и повышение производительности вы сможете увидеть в течение 2–6 месяцев. Точное количество времени, которое понадобится каждой команде, зависит от текущего качества ее кода и от того, сколько у нее будет коучей. Часть III содержит нужные практики.

Уровень оптимизации (Optimizing)

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

Команды уровня оптимизации достигают этой степени гибкости. Они понимают, чего хочет рынок, каковы требования бизнеса и как можно соединить одно с другим. Или, как в обстановке стартапа, они понимают, чему им надо научиться и как к этому приступить. Они постоянно оптимизируют свои планы создания продукта, чтобы те достигли максимально возможного уровня.

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

Такие структурные изменения требуют одобрения на высоком уровне, которое может быть трудно получить. Команды обычно тратят по меньшей мере год на укрепление доверия с помощью уверенного владения навыками на уровне поставки,прежде чем получают разрешение на такие инвестиции. Как только это происходит, свободное владение навыками в оптимизации занимает следующие 3–9 месяцев, хотя увидеть некоторые улучшения можно уже в течение 1–3 месяцев. Но даже в этом случае оптимизация остается бесконечным процессом экспериментирования, обучения и открытий. В части IV мы поговорим о том, как начать.

Уровень укрепления (Strengthening)

Есть еще один последний уровень в модели Agile Fluency™. Он во многом теоретичен: это возможное будущее Agile. Кроме того, он подходит только для организаций, находящихся на переднем крае теории и практики управления. Это обстоя­тельство выводит данный уровень за рамки темы этой книги. Вкратце, уровень укрепления предполагает переработку коллективных идей команд и направление их в организационные улучшения. Если вы хотите узнать об этом больше, то прочтите главу 19.

Уровни свободного владения навыками Agile, резюме

Фокусировка

• Основные преимущества: фокус на бизнес-приоритеты, наглядность работы команды, способность менять направление.

• Инвестиции: структура команд, управление, рабочая среда.

• Примерные сроки: падение производительности на 1–4 месяца, достижение владения наыками в течение 2–6 месяцев.

Поставка

• Основные преимущества: мало дефектов и высокая производительность, техническая долговечность.

• Инвестиции: навыки разработки, слияние тестирования и эксплуатации.

• Примерные сроки: падение производительности на 2–6 месяцев, достижение владения навыками в течение 3–24 месяцев.

Оптимизация

• Основные преимущества: повышение уровня ценности релизов и улучшенные продуктовые решения.

• Инвестиции: встроенное управление продуктом, команда несет ответственность за бюджет и планы.

• Примерные сроки: падение производительности на 1–3 месяца, достижение владения навыками в течение 3–9 месяцев.

Выберите свои уровни

К каким уровням свободного владения навыками должна стремиться ваша команда? Это зависит от того, на каких из них вас может поддержать ваша организация. В идеале все вместе: фокусировка, поставка и оптимизация — наилучший вариант. Комбинация трех уровней обеспечивает наилучшие результаты и чистейшую реализацию идей Agile.

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

Другими словами, выбирайте те уровни, которые нужны вашей компании и за которые она хочет платить.

Какие же уровни вам все-таки выбрать?

• Каждая команда нуждается в свободном владении навыками на уровне фокусировки. Это базовое свойство. Если ваша компания не может инвестировать по меньшей мере в навыки в фокусировке, то, вероятно, Agile вам не подходит, хотя, возможно, у вас получится постепенно продвигаться в этом направлении, если вы начнете со свободного владения навыками на уровне поставки.

• Свободное владение навыками на уровне поставки снижает затраты и повышает скорость разработки. Без нее ваш код в конечном итоге скатится к техническому долгу. Это делает уровень поставки очевидной целью для большинства команд. Тем не менее многие организации не готовы к большим инвестициям в обучение и качество кода, требующимся для уровня поставки. Тогда имеет смысл начать со свободного владения навыками на уровне фокусировки, продемонстрировать успех и использовать его как положительный пример для обоснования дальнейших инвестиций.

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

Больше информации о каждом уровне и его преимуществах вы можете найти в предисловиях к частям II–IV. Подробная информация о необходимых инвестициях представлена во врезке «Список необходимых инвестиций» в главе 4. Если вы не можете определиться, какой из уровней выбрать, то начните с фокусировки и поставки.

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

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

10 Временные рамки, приведенные в этой главе, приблизительны и основаны на моем опыте. Ваш опыт может быть другим.

Глава 4. Инвестируйте в гибкость

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

Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели эти инвестиции действительно настолько важны?

Да, действительно настолько.

Инвестировать в Agile важно, поскольку вы инвестируете в изменение границ, которые вас сдерживают. По большей части команды сдерживают не процессы, которым они следуют, а ограничения, в которых они находятся. Попробуйте делать эти инвестиции и не следовать практикам, и ваши команды, вероятно, все же покажут улучшение результатов. А если, наоборот, следовать практикам и игнорировать инвестиции? Тогда командам придется тяжело.

Как сказал Мартин Фаулер11, «я вижу поразительную параллель между ДХХ (Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель экстремального программирования). Любой из них, получив в подарок ограниченный мир, посмотрит на его ограничения, которые мы принимаем как должное, сочтет их несущественными и создаст новый мир без них… они просто подложат под них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они могут создавать такие вещи, как экстремальное программирование и Rails, которые встряхивают всю индустрию».

Делайте инвестиции — в них секрет успеха Agile.

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

Список необходимых инвестиций

Все команды Agile

• Получите поддержку руководства, команд и ключевых стейкхолдеров, как описано в главе 5.

• Создайте долговечные кросс-функциональные команды и все время назначайте людей только в эти команды (см. раздел «Выберите или создайте Agile-команды» текущей главы).