Стив Макконнелл - Еще более эффективный 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 стараются как можно меньше работать с
требованиями заранее (большее внимание уделяется самой сути проекта,
чем деталям). Предполагается откладывание подавляющего большинства
подробных требований до тех пор, пока в ходе проекта не понадобится их
реализация. Последовательная модель разработки разбирает большую
часть подробных требований заранее.
Требования — это та --">