Реклама

Около десяти лет тому назад возникло ощущение, что в программной инженерии упускается нечто важное: о концепции экстремального программирования (Extreme Programming, XP) речь идет еще с 2000 года, но Scrum по большей части оставался в стороне. И когда пришло время разобраться, обнаружились две поразительные неувязки в мире методов Agile.

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

Второе расхождение — неожиданная мешанина лучших и худших идей, а также немалого числа идей неоднозначных.

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

Восторги в сторону

Применительно к Agile моей естественной реакцией было применить часто помогающее правило: если вам что-то интересно, преподайте об этом курс, а если вы чем-то озадачены, напишите об этом книгу. Так и родилась книга «Agile! The Good, the Hype and the Ugly» («Скорая разработка: полезное, хайп и вредное») [2], а также онлайн-курс «Agile Software Development» (доступен на www.edx.org). Основная цель книги — создать самоучитель по Agile-методам, который должен был стать ответом на многочисленные запросы о появлении исчерпывающего, но без излишеств сжатого описания концепций скорой разработки. Вторая цель — дать анализ и критическую оценку массовых восхвалений в адрес Agile. Последние просто поражают. Взять хотя бы книгу одного из авторов концепции Scrum, которая обещает «вдвое больше работы за половину времени» [3]. Ничего себе! Вряд ли кто-то отказался бы от возможности четырехкратного повышения производительности. В другой книге [4], также от создателей Scrum, сообщаетcя: «Индустрия программного обеспечения 40 лет вами пренебрегала — не преднамеренно, но из-за своей сути. Мы хотим восстановить партнерские отношения». Ни больше ни меньше. Интересно, а при составлении подобного заявления, случайно, не использовалась сама программная система?

В целом публикациям об Agile присущ какой-то подростковый максималистский дух («Только мы знаем истину!»). Однако идеи не рождаются в вакууме — развитие Agile стоит рассматривать как эволюцию, а не революцию. Если судить только по «агиткам» скорой разработки, это неочевидно, но сообщество программной инженерии не дожидалось появления «Манифеста Agile» для признания необходимости перемен. Например, еще в 1995 году в книге «Object Successs: A Manager's Guide to Object Orientation, Its Impact on the Corporation and Its Use for Reengineering the Software Process» для бизнес-руководителей рекомендовалось проектировать ПО с расчетом на изменение и подчеркивалась важность приоритета кода над диаграммами и документацией. Польза Agile состояла не в разработке новых идей, а в том, чтобы наконец-то убедить отрасль принять уже существующие, давно известные, а также другие — например, о ценности тестов и необходимости итеративного процесса — разработки.

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

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF