Переводчик И. Сигайлюк

Художники В. Мостипан, Е. Неволайнен

Корректоры М. Молчанова (Котова), М. Одинокова

Верстка Е. Неволайнен

 

Стив Макконнелл

Еще более эффективный Agile. — СПб.: Питер, 2021.

 

ISBN 978-5-4461-1705-5

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

 

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

 

Отзывы о книге «Еще более эффективный Agile»

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

Шахида Низар, ведущий специалист по инжинирингу, Google

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

Джон Рейндерс, вице-президент по стратегии научно-исследовательских работ, управлению программами и наукам о данных, Alexion Pharmaceuticals

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

Гленн Гудрич, вице-президент по разработке продуктов, Skookum

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

Ксандер Бота, технический директор, Demonware

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

Чарльз Дэвис, главный технический директор, TomTom

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

Сунил Крипалани, директор по цифровым технологиям, OptumRx

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

Стефан Ландвогт, ведущий инженер-программист, Microsoft

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

Ильхан Дилбер, директор по тестированию и контролю качества, CareFirst

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

Брайан Дональдсон, президент Quadrus

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

Лиза Форсайт, старший директор, Smashing Ideas

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

Дэвид Уайт, консультант, Calaveras Group

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

Эрик Апчерч, ведущий разработчик-архитектор, Synaptech

Книга объединяет все особенности создания современных, преимущественно программных, систем: технических, управленческих, организационных, культурных и человеческих — в понятное, последовательное и осуществимое целое, основанное на реальном опыте.

Джованни Аспрони, главный консультант, Zublke Engineering Ltd

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

Хиранья Самарасекера, вице-президент по инжинирингу, Sysco LABS

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

Барбара Тэлли, директор, аналитик бизнес-систем, Epsilon

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

Грэм Хэйторнтвейт, вице-президент по технологиям, Impero Software

Книга учит нас смотреть на Agile как на набор инструментов, которые можно использовать выборочно по ситуации, а не как «пан или пропал».

Тимо Киссел, старший вице-президент по инжинирингу, Circle Media

Замечательная книга, которая наконец отвечает на вопрос «Зачем применять Agile?».

Дон Шафер, главный специалист по безопасности, охране труда и окружающей среды, Athens Group

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

Кевин Тейлор, старший, архитектор систем облачных вычислений, Amazon

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

Майк Блэксток, технический директор, Sense Tecnic Systems

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

Сумант Кумар, директор по развитию (инжиниринг), Innovative Business Solutions Organization, SAP

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

Деннис Рубсам, старший директор, Seagate

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

Пол ван Хаген, архитектор платформ и менеджер по совершенствованию программного обеспечения, Shell Global Solutions International B.V.

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

Том Спитцер, вице-президент по инжинирингу, EC Wise

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

Кеннет Лю, старший директор по управлению программами, Symantec

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

Брэд Мур, вице-президент по инжинирингу, Quartet Health

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

Дьюи Хоу, вице-президент по разработке продуктов, TechSmith Corporation

«Еще более эффективный Agile» — это отличное зеркало для внедрения Agile, в котором можно увидеть как положительные, так и отрицательные стороны.

Мэтт Шоутен, старший директор по развитию продуктов, Herzog Technologies

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

Стив Перрен, старший менеджер по развитию, Zillow

В книге рассматривают многие проблемы, с которыми мы долгие годы боролись, — жаль, не было этой книги, когда мы только начинали свой путь. Разделы «Рекомендации» просто великолепны.

Барри Сэйлор, вице-президент по разработке программного обеспечения, Micro Encoder Inc.

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

Том Керр, менеджер по разработке встраиваемого программного обеспечения, ZOLL Medical

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

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

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

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

Часть I. Введение в еще более эффективный Agile

В части I описаны фундаментальные концепции методологии гибкой разработки программного обеспечения под названием Agile. В частях II–IV мы углубляемся в конкретные предложения.

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

Если вы хотите начать с общего обзора, то перейдите к части V и прочитайте разделы «Наслаждайтесь плодами своих трудов» и «Краткое изложение ключевых принципов».

Глава 1. Введение

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

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

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

Бˆольшая часть литературы по Agile ориентирована на амбициозные компании с высокими темпами роста на новых рынках, например на Netflix, Amazon, Etsy, Spotify и т.п. Но как быть, если ваша компания занимается не таким передовым софтом? Что насчет компаний, которые производят ПО для научных приборов, оргтехники, медицинского оборудования, бытовой электроники, тяжелого машиностроения или аппаратуры для реализации технологических процессов? Мы обнаружили, что современные Agile-методы, если применять их с упором на то, что лучше подходит для определенного бизнеса, предоставляют преимущества и для таких программных продуктов.

Почему важен эффективный Agile

Компании хотят большей эффективности разработки ПО для своего же блага. Они также хотят большей эффективности, потому что от ПО зависят многие другие аспекты бизнеса. В докладе State of DevOps говорится, что «компании с высокопроизводительной организацией ИТ имели в два раза больше шансов превзойти свои показатели прибыльности, доли рынка и производительности» [Puppet Labs, 2014]. У высокопроизводительных компаний было в два раза больше шансов достичь или превзойти свои цели по удовлетворенности клиентов, качеству и количеству работ, эффективности и другим задачам.

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

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

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

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

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

 

Для кого эта книга

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

Если же вы многое узнали о методах Agile 10–15 лет назад, но с тех пор не обновляли свои знания и ваш Agile-подход устарел, то и в этом случае эта книга для вас.

И самое главное — если ваша компания уже пыталась внедрить аспекты Agile, но вы недовольны результатом, читайте дальше!

Чем она отличается от прочих книг по Agile

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

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

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

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

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

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

Структура

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

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

А что думаете вы?

Я бы не написал эту книгу без огромного количества отзывов. Исходную рукопись тщательно проверяла моя команда из Construx Software. Я попросил сторонних добровольцев прорецензировать черновик и более 300 руководителей в отрасли разработки ПО оставили свыше 10 тысяч комментариев. Их неоценимая помощь принесла моей книге огромную пользу.

Как вы отреагировали на эту книгу? Совпадает ли материал с вашим опытом? Помогла ли книга в решении каких-нибудь проблем? Буду рад видеть ваши сообщения. Контакты для связи со мной указаны ниже.

Белвью, штат Вашингтон (США) 4 июля 2019 года

stevemcc@construx.com

Linkedin.com/in/stevemcc

SteveMcConnellConstrux

@Stevemconstrux

MoreEffectiveAgile.com

Глава 2. В чем отличие Agile?

Большинство книг по Agile, в которых есть глава вроде «В чем заключается отличие Agile?», сразу же погружают нас в описание Манифеста Agile 2001 года и связанных с ним методов, которым уже 20 лет.

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

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

Разработка по каскадной модели в ее чистом виде велась главным образом в ранних проектах Министерства обороны США, и ко времени написания Манифеста Agile эта очень сырая реализация уже была вытеснена более сложными моделями1.

В наибольшем противопоставлении с Agile сейчас находится модель последовательной разработки. Во избежание путаницы сравнение представлено в табл. 2.1.

Короткие и долгие циклы релиза

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

Таблица 2.1. Различия между моделью последовательной разработки и Agile

Последовательная модель	Agile
Долгие циклы релиза	Короткие циклы релиза
Большая часть сквозной разработки ведется большими партиями в течение долгих циклов релиза	Большая часть сквозной разработки ведется малыми партиями за короткие циклы релиза
Подробное заблаговременное планирование	Обобщенное заблаговременное планирование вместе со своевременным по­дробным планированием
Подробные заблаговременные требования	Обобщенные заблаговременные требования вместе со своевременными подробными требованиями
Заблаговременное проектирование	Стихийное проектирование
Тестирование в конце, часто как отдельная задача	Непрерывное, автоматизированное тестирование, интегрированное в разработку
Нечастое упорядоченное сотрудничество	Частое упорядоченное сотрудничество
В целом, подход идеалистичен, ориентирован на контроль и заранее намеченный план	В целом, подход эмпиричен, ориентирован на оперативность и совершенствование

Сквозная разработка ведется маленькими и большими партиями

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

Своевременное и заблаговременное планирование

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

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

Своевременные и заблаговременные требования

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

Требования — это та область, в которой современные Agile-методы вышли за рамки идей, сопутствующих методологии Agile в начале 2000-х. Я рассмотрю эти изменения в главе 13 «Создание требований еще более эффективного Agile» и в главе 14 «Определение приоритетов требований еще более эффективного Agile».

Стихийное и заблаговременное проектирование

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

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

Непрерывное, автоматизированное тестирование, интегрированное в разработку, и отдельный тест в конце

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

Частое упорядоченное и нечастое упорядоченное сотрудничество

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

Эмпиричность, оперативность, ориентация на совершенствование и идеалистичность, намеченный план, ориентация на контроль

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

Что общего между методологией Agile и моделью последовательной разработки

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

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

Источник преимуществ Agile

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

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

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

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

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

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

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

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

Акцент на модели эмпиричного и оперативного совершенствования позволяет командам быстрее учиться на своем опыте и со временем улучшать продукт.

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

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

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

Граница Agile

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

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

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

 

Рис. 2.1. Пример границы Agile. Здесь применение Agile-методов ограничено только техническим подразделением

Непонимание границы Agile может привести к неоправданным ожиданиям и прочим проблемам. Рассмотрим такие ситуации:

• Agile в разработке ПО и нормативы, не соответствующие Agile.

• Agile в продажах и разработка ПО не по Agile.

• Agile в разработке ПО и корпоративные клиенты, не работающие по Agile.

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

Рекомендации

Изучайте

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

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

• Поговорите с нетехническими руководителями о том, что для них Agile. Как они воспринимают границу или контакт между их работой и работой команд разработчиков?

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

Приспосабливайтесь

• Запишите предварительный план проведения границы Agile в своей компании.

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

Дополнительные ресурсы

[Эндрю Стеллман и Дженнифер Грин, 2013]. Learning Agile: Understanding Scrum, XP, Lean, and Kanban. Эта книга — хорошее введение в концепцию Agile с точки зрения профессионалов Agile.

[Бертран Мейер, 2014]. Agile! The Good, the Hype and the Ugly. Эта книга начинается с развлекательной критики излишеств в движении Agile и определяет наиболее полезные принципы и методы, связанные с движением Agile.

Глава 3. Отвечая на вызовы сложности и неопределенности

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

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

Cynefin

Набор методов Cynefin был создан Дэвидом Сноуденом, работавшим в IBM, в конце 1990-х [Курц, 2003].

С тех пор развитие этого метода продолжается Сноуденом и другими специалистами [Сноуден, 2007]. Сноуден описывает Cynefin как «осмысленный набор методов». Он помогает понять, какая тактика будет полезна в зависимости от сложности и неопределенности ситуации.

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

Cynefin — это валлийское слово, которое означает «среда обитания», или «окрестности». Контексты не считаются категориями, скорее их рассматривают как кластеры значений, которые являются источником свойства, отраженного в названии, — «срˆеды обитания».

 

Рис. 3.1. Набор методов Cynefin — это полезный и осмысленный инструмент, который можно применять в отрасли разработки ПО

Контексты «Сложные» и «Запутанные» наиболее актуальны в области разработки ПО. Все пять контекстов описаны в следующих разделах с целью прояснения.

Контекст «Очевидные»

При контексте «Очевидные» (Obvious) проблемы хорошо поддаются пониманию, а решения приходят на ум сами собой. Буквально все сходятся на одном и том же правильном решении. Связь между причиной и следствием проста и прямолинейна. Это сфера применения паттерна: программируемое процедурное механическое поведение.

Подход к проблемам контекста «Очевидные» в наборе методов объясняется следующим образом:

осознайте

классифицируйте

реагируйте

Приведем несколько примеров проблем из контекста «Очевидные»:

• Прием заказа в ресторане.

• Обработка платежа по кредиту.

• Наполнение бака автомобиля топливом.

На более глубоком уровне команды разработчиков сталкиваются с большим количеством «очевидных» проблем, например: «Этот оператор if должен проверять на наличие 0, а не 1».

На уровне проекта сложно найти примеры «очевидных проблем» вроде описанных в Cynefin. Когда вы в последний раз в области разработки ПО видели проблему какого угодно размера, у которой было бы только одно верное решение, с которым были бы все согласны? Существует хорошее исследование в области разработки ПО, которое показывает, что когда разным проектировщикам встречается одна и та же проблема, они создают решения, объем кода которых превышает объем кода, необходимый для выполнения задач проектирования, в десять раз [Макконнел, 2004]. По моему опыту, эта разница существует даже в выполнении такой, казалось бы, простой задачи, как «создать краткий отчет». «Одно правильное решение» на практике оказывается сколь угодно разным. Так что, думаю, что за рамками программ уровня «hello world» в разработке ПО не бывает «очевидных» проблем. Пока мы рассматриваем разработку ПО в крупных масштабах, полагаю, что можно спокойно игнорировать контекст «Очевидные».

Контекст «Сложные»

При контексте «Сложные» (Complicated) проблема известна вам в общих чертах, вы знаете, какие вопросы нужно задать и как получить на них ответы.

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

Подход к проблемам контекста «Сложные» в наборе методов объясняется следующим образом:

осознайте

анализируйте

реагируйте

Этот подход противопоставлен подходу контекста «Очевидные» в том, что средний этап требует анализа, а не простой классификации проблемы и выбора одного правильного ответа.

Приведем несколько примеров проблем из контекста «Сложные»:

• Определение причины стука двигателя.

• Приготовление изысканного блюда.

• Написание запроса к базе данных для получения конкретного результата.

• Устранение в производственной системе ошибки, которая приводит к неполному обновлению.

• Определение приоритетности требований пользователей для версии 4.1 зрелой системы.

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

Большое количество разработок и проектов в области создания ПО попадают в контекст «Сложные». Исторически контекст относился к сфере влияния модели последовательной разработки.

Если проект главным образом находится в контексте «Сложные», может сработать линейный, последовательный подход, строго полагающийся на заблаговременное планирование и анализ. При таком подходе сложности возникают тогда, когда проблему трудно ясно определить.

Контекст «Запутанные»

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

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

Рекомендуемый подход к проблемам контекста «Запутанные» в Cynefin объясняется следующим образом:

исследуйте

осознайте

реагируйте

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

Приведем несколько примеров проблем из контекста «Запутанные»:

• Покупка подарка кому-то, кому трудно угодить, — вы вручаете подарок и знаете, что вам придется его обменять!

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

• Выявление пользовательских требований для совершенно новой системы.

• Создание ПО, работающего на базовом оборудовании, которое все еще дорабатывается.

• Обновление ПО, в то время как конкуренты обновляют свое.

Большое количество разработок и проектов в области создания ПО попадают в контекст «Сложные», а это владения Agile и итеративной разработки. Если проект в основном находится в контексте «Сложные», рабочий подход заключается в том, чтобы сначала экспериментировать и разведывать, прежде чем проблема станет полностью определенной в принципе.

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

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

Контекст «Хаотические»

Контекст «Хаотические» (Chaotic) немного отстоит от паттерна, который можно ожидать на основании сведений о трех предыдущих контекстах. При контексте «Хаотические» связь между причиной и следствием бурная и подвижная. Невозможно обнаружить связь между причиной и следствием даже после повторных экспериментов, даже задним числом.

Вы не знаете, какие вопросы нужно задавать, а разведка и эксперименты не дают единообразных ответов.

Контекст также включает в себя дефицит времени, которого нет в остальных контекстах.

Cynefin характеризует контекст «Хаотические» как контекст решительного лидерства, ориентированного на действие. Рекомендованный подход — навести порядок в хаосе и сделать это как можно скорее:

действуйте

осознайте

реагируйте

Приведем несколько примеров проблем из контекста «Хаотические»:

• Обеспечение помощи во время стихийных бедствий, в то время как бедствие еще происходит.

• Прекращение кидания едой в школьной столовой.

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

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

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

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

Контекст «Беспорядочные»

В середине диаграммы Cynefin расположился контекст «Беспорядочные» (Dis­order), в котором нет ясного представления о том, к какому контексту относится ваша проблема. Подход, рекомендованный Cynefin к решению проблем контекста «Беспорядочные», таков: разобрать проблему по составляющим, а затем определить, к какому контексту какая составляющая относится.

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

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

Cynefin и вызовы в области разработки

Cynefin — это интересный, полезный и осмысленный набор методов, а все пять контекстов можно распространить за пределы проблем в области разработки ПО. Но, как показано на рис. 3.2, контексты «Хаотические» и «Очевидные» нельзя распространить на уровень целого проекта по причинам, которым я привел выше. Это означает, что для практических целей проекты разработки ПО должны ориентироваться в основном на контексты «Сложные», «Запутанные» и «Беспорядочные» (при этом «Беспорядочные» нужно привести в порядок и определить, относятся ли проблемы к «сложным», «запутанным» или сразу к обоим типам).

 

Рис. 3.2. Связь между контекстами Cynefin и вызовами в отрасли разработки ПО

Принимая во внимание то, что у вас есть на выбор только два контекста Cynefin, возникает вопрос: «А что делать, если я прогадал и определил не тот контекст?»

Как показано на рис. 3.3, чем больше неопределенности в проекте, тем лучше срабатывает подход контекста «Запутанные» (Agile), чем контекста «Сложные» (последовательная разработка).

 

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

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

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

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

Успех в «запутанных» проектах: петля Бойда

Полезная модель для решения проблем «запутанных» проектов — это петля Бойда, она же петля НОРД (OODA). Как показано на рис. 3.4, «НОРД» означает «наблюдение, ориентация, решение, действие», иногда петлю еще называют «циклом НОРД».

 

Рис. 3.4. Основу петли Бойда составляют четыре этапа, первый из которых — наблюдение

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

Наблюдение

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

Ориентация

На этапе «Ориентация» вы соотносите наблюдения с ситуацией. Бойд заявил, что мы соотносим их с нашим «генетическим наследием, культурной традицией, усвоенным опытом и возникающими обстоятельствами» [Адольф, 2006]. Проще говоря, вы решаете, какая информация имеет значение для вас, а затем выбираете, как реагировать.

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

Решение

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

В бейсболе питчер, делающий бросок с переменой скорости (медленная подача), когда отбивающий ожидает быстрой подачи, эффективно пробивает петлю Бойда соперника, действуя при этом медленнее. Другой способ подумать об этом — подчинить игру вашего соперника своим правилам (то, что сделала Apple на рынке с помощью iPhone).

Действие

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

За рамками основ петли Бойда

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

 

Рис. 3.5. Полная петля Бойда. С каждого этапа можно перейти сразу к этапу «Действие» или назад к «Наблюдению», как отмечено пунктирными линиями

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

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

Петля Бойда и последовательная разработка

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

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

Таблица 3.1. Различия между подходами модели последовательной разработки и петли Бойда (Agile)

Последовательная разработка	Петля Бойда (Agile)
Изначальное внимание на планировании	Изначальное внимание на наблюдении
Упор на долгие сроки	Упор на короткие сроки
Предсказуемый	Оперативный
Идеалистичный	Эмпирический
Рассматривает неопределенность как риск	Рассматривает неопределенность как возможность
Ориентирован на контроль	Ориентирован на улучшение
Хорошо справляется со «сложными» проблемами	Хорошо справляется с «запутанными» проблемами, а также со «сложными»

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

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

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

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

Ключевой принцип: изучайте и приспосабливайтесь

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

Раздел «Рекомендации» в конце каждой главы подчеркивает значение этого принципа.

Рекомендации

Изучайте

• Пересмотрите ваши текущие проекты. Какие их составляющие можно отнести к «запутанным», а какие — к «сложным»?

• Пересмотрите недавно законченный проект. Как команды относились к проекту: как к «сложному» или как к «запутанному»? Оказывалось ли так, что какие-то вызовы, связанные с проектом, могли возникнуть из того, что «запутанный» проект могли классифицировать по ошибке как «сложный» (или наоборот)?

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

• С точки зрения петли Бойда понаблюдайте за тем, кто ваш соперник (определенный конкурент, доля рынка, требуемый уровень получения прибыли, бюрократия и так далее).

• Понаблюдайте за 3–5 областями неопределенности, которые вы могли бы подчинить своим интересам, чтобы получить преимущество над соперником.

Приспосабливайтесь

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

• Ориентируйтесь с помощью областей неопределенности теми способами, которые обеспечивают преимущества перед соперником.

• Принимайте решение, как воспользоваться преимуществами ваших наблюдений, а затем действовать.

Дополнительные ресурсы

[Дэвид Дж. Сноуден и Мэри Э. Бун, 2007]. A Leadet’s Framework for Decision Making. Harvard Business Review. Ноябрь 2007 г. Это хорошо написанное введение в Cynefin, которое охватывает гораздо больше информации, чем дал я.

[Барри В. Боэм, 1988]. A Spiral Model of Software Development and Enhancement. IEEE Computer, май 1988 г. С точки зрения Cynefin эта работа предлагает подход к проектам, при котором каждый из них изначально рассматривается как «запутанный». Нужно проводить разведку, до тех пор пока полный объем вызовов, связанных с проектом, не будет достаточно понят, для того чтобы отнести проект к «сложным». На этом этапе проект выполняется с использованием подхода последовательной разработки.

[Стив Адольф, 2006]. What Lessons Can the Agile Community Learn from a Maverick Fighter Pilot? Заседание конференции Agile 2006. Здесь представлено краткое объяснение петли Бойда в особом контексте Agile.

[Джон Р. Бойд, 2007]. Patterns of Conflict. Январь 2007 г. Эта работа — воссоздание инструктажа полковника Джона Бойда.

[Роберт Корам, 2002]. Boyd: The Fighter Pilot Who Changed the Art of War. Здесь представлена подробная биография полковника Джона Бойда.

[Чет Ричардс, 2004]. Certain to Win: The Strategy of John Boyd, Applied to Business. Книга представляет собой понятное описание происхождения петли Бойда и ее применения для принятия управленческих решений.

ЧАСТЬ II. Еще более эффективные команды

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

Если вам больше интересны конкретные рабочие методы, чем динамика в команде, переходите к части III «Еще более эффективная работа». Если вам больше интересны проблемы менеджеров высшего звена, переходите к части IV «Еще более эффективная организация».

ГЛАВА 4. Начало эффективного Agile: Скрам

Основной проблемой в отрасли разработки ПО за 35 лет моей карьеры и, вероятно, дольше было избегание модели «написания кода, проверки и исправления ошибок» — то есть написание кода без продумывания или планирования с последующей отладкой, до тех пор пока он не станет работать. Такой неэффективный режим приводит к тому, что больше половины затраченных усилий у команд уходит на исправление недочетов, созданных ранее ими же [Макконнел, 2004].

В 1980–1990-х разработчики сказали бы, что занимаются структурным программированием, но многие действительно работали по модели «написания кода и исправления ошибок», тем самым упуская преимущества структурного программирования. В 1990–2000-х разработчики сказали бы, что занимаются объектно-ориентированным программированием, но многие из них все еще занимались тем, что писали код и исправляли ошибки, страдая от последствий. В 2000–2010-х разработчики и команды продолжают говорить, что занимаются разработкой по Agile, и хотя прошли уже десятилетия нарабатывания опыта и последствия известны, многие все еще продолжают заниматься написанием кода и исправлением ошибок. Чем больше что-то меняется, тем больше остается таким же!

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

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

Ключевой принцип: начните со Скрама

Если вы все еще не внедрили Agile или если его реализация не так эффективна, как хотелось бы, я рекомендую отталкиваться от самого начала. В Agile это Скрам. Скрам наиболее директивный из распространенных Agile-методов. В его обширную экосистему входят множество книг, предложений по подготовке и инструментов. И есть доказательства, что он работает. Комплексный анализ исследований, проведенный Дэвидом Ф. Рико, показал, что в среднем рентабельность инвестиций во внедрение Скрама составляла 580% [Рико, 2009]. В докладе 2017–2018 годов State of Scrum сообщается, что в 84% случаев внедрения Agile применялись методы Скрам [Scrum Alliance, 2017].

Что такое Скрам?

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

Основы Скрама

Если вы уже знакомы с основами, то можете пропустить этот раздел и перейти к разделу «Распространенные ошибки при внедрении Скрама», а если и эта тема вам уже знакома, то к разделу «Факторы успешного внедрения Скрам». Считается, что наиболее канонично Скрам описан в работе «Руководство по Скраму» [Швабер, 2017]. В основном опыт применения Скрама в моей компании совпадает с описанием, приведенным в этом руководстве. Следующее описание соответствует руководству версии ноября 2017 года, если не оговорено иное.

В целом, Скрам известен тем, что уделяет внимание проведению мероприятий (встречи, митинги, церемонии), распределению ролей и наличию артефактов, связывая все это набором правил.

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

Команды, работающие по Скраму, организуют работу в «спринты», которые представляют собой итерации длиной от 1 до 4 недель. Лучше всего подходят спринты длительностью в 1–3 недели. Практика показала, что риски увеличиваются с длительностью спринтов, а возможности улучшения ограничиваются. Чаще всего команды работают по двухнедельным спринтам.

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

Термин «спринт» означает итерацию, которая условно представляет собой каденцию продолжительностью 1–3 недели.

Термин «развертывание» означает доставку продукта до потребителя, которая может происходить в сети за часы, а может занимать год и больше при встраивании ПО в оборудование. Разработку можно организовать по каденциям в 1–3 недели вне зависимости от того, сколько времени занимает доставка — часы, месяцы или годы.

Значение термина «релиз» разнится в зависимости от контекста, но чаще всего означает больший объем работы, чем выполняемый за спринт, то есть означает больший промежуток времени или больший набор связанного функционала.

На рис. 4.1 представлен порядок работ в проекте, выполняемом по Скраму.

 

Рис. 4.1. Краткая схема работы по Скраму

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

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

Над планированием спринта работает вся команда. Это эффективно, потому что команда кросс-функциональна и имеет все компетенции для принятия решений.

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

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

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

Во время спринта команда собирается на дейли-скрам (также известен как ежедневный стендап), он проводится каждый день, за исключением первого и последнего дня спринта. На 15-минутной встрече, сосредоточенной на отслеживании продвижения относительно цели спринта, обычно отвечают всего на три вопроса:

• Что было сделано вчера?

• Что будет сделано сегодня?

• Какие сложности в достижении результатов имеются?

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

Актуальное «Руководство по Скраму» гласит, что эти три вопроса на сегодня устарели, однако я считаю, что они придают встрече структуру, которая важна для плодотворного ее проведения.

Команда, применяющая Скрам, так и живет: стендап, работа, стендап, работа, «сполоснуть и повторить» — каждый спринт одно и то же.

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

 

Рис. 4.2. Пример диаграммы сгорания задач, на которой показано соотношение запланированного и оставшегося объема работ в часах. Диаграмма сгорания задач, как правило, измеряет часы, а не истории

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

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

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

 

Рис. 4.3. Пример диаграммы сгорания задач до условного релиза

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

В главе 20 «Еще более эффективная предсказуемость» содержится подробная информация о том, как поддерживать предсказуемость проектов, выполняемых по Agile.

 

Рис. 4.4. Пример более сложной диаграммы выполнения задач до релиза

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

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

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

Роли в Скраме

В Скраме для обеспечения рабочего процесса есть три роли.

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

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

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

Скрам-команда обычно состоит из 3–9 участников команды разработчиков, скрам-мастера и владельца продукта (рис. 4.5).

 

Рис. 4.5. Организация команды, работающей по Скраму. Иногда скрам-мастер является членом команды разработчиков, но не всегда

Обратите внимание: роли в Скраме — это именно роли, а не должности. Как сказал мне один топ-менеджер: «Наши должности не обусловлены ролями в Скраме. Нам не нужно, чтобы методы управления кадрами у нас зависели от технических методик».

Распространенные ошибки при внедрении Скрама

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

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

Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать.

Антуан де Сент-Экзюпери

Если ваша организация внедрила Скрам и вы не видите значительных преимуществ, первый вопрос, который стоит задать: «А вы действительно внедрили Скрам или только некоторые его части?»

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

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

Неэффективный владелец продукта

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

Проблемы, касающиеся владельца продукта, бывают нескольких видов:

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

• Работы владельца продукта недостаточно — команде остро не хватает требований. Владелец продукта может поддерживать 1–2 команды, редко больше.

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

• Владелец продукта не понимает, как обозначать требования к ПО, — это еще одна дорога к низкокачественным требованиям, которые получает команда.

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

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

• Владелец продукта не имеет права принимать решения по продукту.

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

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

• Владелец продукта не соблюдает правила, предписанные Скрам, — настаивает на изменении требований в середине спринта или ведет проект с прочими нарушениями методов Скрам.

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

Недостаточное уточнение бэклога продукта

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

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

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

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

Слишком большие истории

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

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

• Команде нужно стремиться завершить 6–12 историй за каждый спринт (при условии, что команды рекомендованного размера).

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

Дейли-скрам проводится не каждый день

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

Чаще всего мы слышим, что дейли-скрам проводится реже потому, что «митинги занимают слишком много времени». В этом и соль проблемы! Встречи должны укладываться в 15 минут. Если сосредоточиться на трех ключевых вопросах, то в этот отрезок времени уложиться можно. Решение проблемы чрезмерно долгих ежедневных митингов — не уменьшить частоту их проведения, а ограничить время встречи и сосредоточиться на трех вопросах. Более подробно о ежедневных митингах можно узнать далее в этой главе.

Слишком долгие спринты

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

Акцент на горизонтальных, а не вертикальных срезах

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

Разделение команды разработчиков и тестировщиков

Частый пережиток модели последовательной разработки — разделение команды разработчиков и тестировщиков. Такое деление отнимает у скрам-команд кросс-функциональные навыки и знания, которые нужны для эффективной работы.

Нечеткие критерии готовности

Одно из важнейших средств поддержки высокого качества — это строгие критерии готовности (Definition of Done, DoD). Они гарантируют, что когда член команды или команда сообщает о том, что элемент бэклога готов, команда или организация может быть по-настоящему уверена в том, что больше ничего делать с этим элементом не требуется.

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

Уровень качества в спринтах не достигает уровня релиза

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

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

Не проводятся ретроспективы

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

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

Результаты ретроспектив не учитываются в последующем спринте

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

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

Скрам и что-то еще

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

Неэффективный скрам-мастер

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

• Отсутствует скрам-мастер — ожидается, что команда будет работать по Скраму без назначения определенного лица на роль мастера.

• Работы скрам-мастера недостаточно, он отвечает за поддержку слишком большого количества команд.

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

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

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

Что общего в ошибках внедрения Скрама?

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

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

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

Факторы успешного внедрения Скрама

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

• Эффективный владелец продукта.

• Уточнение бэклога.

• Соблюдение небольшого размера историй.

• Ежедневное проведение митингов.

• Ограничение длительности спринтов до 1–3 недель.

• Организация работы по вертикальным срезам.

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

• Формулирование четких критериев готовности.

• Качество, приемлемое для релиза, в каждом спринте.

• Проведение ретроспектив в каждом спринте.

• Своевременное применение знаний и навыков, полученных из ретроспектив.

• Эффективный скрам-мастер.

Подробнее об этом — в следующих главах.

Успешный спринт

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

• Спринт обеспечивает пригодный и ценный инкремент продукта (совокупную функциональность), который полностью отвечает критериям готовности.

• Ценность инкремента спринта возрастает по сравнению с предыдущим спринтом.

• Скрам-команда улучшает процесс в сравнении с предыдущим спринтом.

• Команда узнает что-то новое о себе, бизнесе, своем продукте или своих клиентах.

• Команда мотивирована не хуже или лучше, чем в конце предыдущего спринта.

Распределение времени в типичном спринте

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

Таблица 4.1. Пример распределения сил разработчиков во время спринта

Параметры планирования спринта
Продолжительность спринта (рабочих дней)	10
Идеальное количество часов в сутки (время, потраченное на проект)	× 6
Общее идеальное количество часов на спринт для разработчика	= 60
Количество действий, по Скраму на спринт для разработчика	часов
Разработка, включая тестирование	48
Дейли-скрам (стендапы)	2
Уточнение бэклога продукта (5%)	3
Планирование спринта	4
Обзор спринта	2
Ретроспектива спринта	1
Итого	60

Понятие «идеальное количество часов» означает количество часов, затраченных на проект (которые остаются после времени, затраченного на корпоративные накладные расходы). Идеальное количество в 5–6 часов характерно для большой солидной фирмы. В небольших компаниях идеальное количество в среднем 6–7 часов, а в стартапах — и более того.

При идеальном количестве 60 часов в спринте около 20% времени уходит на планирование и улучшение процесса. Соответственно 80% остается на саму разработку.

Проблемы при переходе на Скрам

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

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

Система показателей Скрама

Чтобы оценить точность следования правилам Скрама при его внедрении, будет полезным создать систему показателей для проекта, по которой будут оцениваться наиболее важные факторы успешного внедрения. На рис. 4.6 изображен пример звездообразной диаграммы системы показателей проекта, который мы уже видели в главе 1.

Пояснения к диаграмме:

0 Не применяется

2 Применяется редко и неэффективно

4 Применяется эпизодически с переменной эффективностью

7 Применяется постоянно и эффективно

10 Оптимизация

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

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

 

Рис. 4.6. Инструмент диагностики, показывающий производительность команды при работе по Скраму в соответствии с ключевыми факторами его успешного внедрения

Изучайте и приспосабливайтесь в Скраме: дейли-скрам

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

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

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

• Что было сделано вчера? (изначальный вопрос)

• Какие задачи были выполнены вчера?

• Что из того, что вы вчера выполнили, соответствует критериям готовности?

• Что вы сделали вчера, для того чтобы приблизиться к цели спринта?

• Что вы сделали вчера, для того чтобы выполнить план на спринт?

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

Прочие соображения

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

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

Экстремальное программирование (XP)

В начале существования Agile большое внимание уделялось экстремальному программированию (XP) (Бек, 2000; 2005), которое представляет собой набор определенных технических методов, процессов и дисциплин, олицетворявших изначальные принципы Agile. Первоначальное внимание на XP, если верить рекламе, было колоссальным, однако долгосрочное применение XP как целостного подхода к разработке ни у кого не получилось. Когда XP версии 1 требовало применения набора из 12 практических методов, даже в тех проектах, которые считались образцовыми, использовали примерно половину из этих методов [Греннинг, 2001; Шу, 2001; Пул, 2001].

Упор на полноценном использовании XP снизился с начала 2000-х годов. Сегодня XP вносит свой вклад как источник технических методов, которые считаются неотъемлемой частью современного Agile. К этим методам относится непрерывная интеграция, рефакторинг, разработка через тестирование и непрерывное тестирование.

Kanban

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

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

Kanban может оказаться более подходящим, чем Скрам, для небольших команд (1–4 человека) или для проведения работ, которые больше ориентированы на производство, чем на проектную деятельность.

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

Некоторым командам удавалось успешно начинать внедрение Agile с Kanban. Но Скрам более структурирован, перспективнее, больше ориентирован на работу в команде, поэтому, как правило, он лучше подходит для того, чтобы с него начинать внедрение Agile.

Немного подробнее о Kanban мы поговорим в главе 19 «Еще более эффективное совершенствование процесса».

Рекомендации

Изучайте

• Опросите ваши команды о том, как они применяют Скрам. Предложите им оценить степень применения Скрама согласно системе показателей. Насколько эффективно применяется Скрам?

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

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

Приспосабливайтесь

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

• Если ваши скрам-мастера неэффективны, подумайте об их переподготовке или замене.

Дополнительные ресурсы

[Кен Швабер и Джефф Сазерленд, 2017]. Руководство по Скраму. Исчерпывающее руководство по Скраму: Правила игры. По мнению многих специалистов, это краткое руководство является исчерпывающим описанием практических методов Скрама.

[Кеннет Рубин, 2012]. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Это издание является всеобъемлющим руководством по Скраму, которое рассматривает распространенные проблемы, связанные с внедрением Скрама.

[Митч Лейси, 2016]. The Scrum Field Guide: Agile Advice for Your First Year and Beyond, 2nd Ed. В этом руководстве по Скраму по косточкам разбираются проблемы, возникающие на практике при внедрении и применении Скрама.

[Майк Кон, 2010]. Succeeding with Agile: Software Development Using Scrum. Еще одна неплохая альтернатива работе Рубина 2012 г. и работе Лейси 2016 г.

[Джефф Сазерленд, 2014]. Скрам. Революционный метод управления проектами (М.: Манн, Иванов и Фербер, 2016). Эта книга ориентирована на бизнес и представляет читателю историю Скрама.

[Дженни Стюарт и др.]. Six Things Every Software Executive Should Know about Scrum. Серия Construx White Paper. Июль 2018 г. Здесь представлен краткий обзор Скрама, ориентированный на руководителей высшего звена.

[Дженни Стюарт и др.]. Staffing Scrum Roles. Серия Construx White Paper. Август 2017 г. В статье представлены распространенные проблемы при заполнении ролей в Скраме.