Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Любой компании хочется добиться большей эффективности разработки ПО, ведь это напрямую влияет на прибыль. Большая часть литературы по Agile ориентирована на крупные компании с высокими темпами роста, но как быть, если ваша компания находится не на переднем фланге ИТ? Хорошая новость в том, что каждая организация может улучшить производительность, и эта книга поможет найти конкретные пути и решения, позволяющие извлечь максимальную выгоду от Agile-методов. «Я не евангелист Agile. Я сторонник того, что работает, и противник того, что много обещает, но не приносит результатов. В этой книге методология Agile представлена не как движение, которое требует повышенной сознательности, а как набор специальных управленческих и технических методов, эффект и взаимодействие которых доступны для понимания любому бизнесмену или айтишнику. Энтузиасты Agile могут раскритиковать эту книгу за то, что она не пропагандирует передовые методы Agile. Но в этом и смысл — акцент на практических методах, доказавших свою эффективность. История Agile полна идей, которые удалось успешно реализовать паре энтузиастов в некоторых организациях, но которыми невозможно пользоваться всем остальным», — говорит Стив Макконнелл. Новая книга Стива Макконнелла, автора легендарных книг Code Complete и Software Estimation, объединяет реальный опыт сотен компаний. Воспользуйтесь простым и понятным руководством по современным и самым эффективным методам Agile.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 314
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчики И. Сигайлюк, И. Сигайлюк, И. Сигайлюк
Стив Макконнелл
Еще более эффективный Agile. — СПб.: Питер, 2024.
ISBN 978-5-4461-1705-5
© ООО Издательство "Питер", 2024
Оглавление
Отзывы о книге «Еще более эффективный 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
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства 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 года
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.
1 Стандарт MIL-STD-2167A, предполагающий каскадную модель разработки программного обеспечения в проектах Министерства обороны США, в конце 1994 года заменили на стандарт MIL-STD-498, предполагающий никак не связанную с каскадной модель разработки.
Глава 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.
