Их работа стала для меня огромным подспорьем. Не могу подыскать слова благодарности за то, что у них хватило терпения прочитать до конца всю эту прозу, для многих из них изложенную на иностранном языке.
Спасибо (перечисление в случайном порядке, в котором я получал от них комментарии) Грегу Хатчинсону (Greg Hutchinson), Массимо Арнольди (Massimo Arnoldi), Дэйву Клилу (Dave Cleal), Сэмесу Шустеру (Sames Schuster), Дону Уелсу (Don Wells), Джошу Киревски (Joshua Kerievsky), Торстену Диттмару (Thorsten Dittmar), Морицу Бекеру (Moritz Becker), Дэниэлу Габлеру (Daniel Gubler), Кристофу Хенирики (Christoph Henrici), Томасу Зангу (Thomas Zang), Дирку Коэнигу (Dierk Koenig), Мирославу Новаку (Miroslav Novak), Роднёю Райану (Rodney Rayan), Френку Вестфалу (Frank Westphal), Полу Трунцу (Paul Trunz), Стиву Хайесу (Steve Hayes), Кевину Бредтке (Kevin Bradtke), Джанни Де Гузман (Jeanine De Guzman), Тому Кабиту (Tom Kubit), Фалку Бругманну (Falk Bruegmann), Хаско Хейнеке (Hasko Heinecke), Петеру Мерелу (Peter Merel), Робу Ми (Rob Мее), Пете Макбрину (Pete McBreen), Томасу Эрнсту (Thomas Ernst), Гуидо Хечлеру (Guido Haechler), Дитеру Холцу (Dieter Holz), Мартину Кнехту (Martin Knecht), Дирку Крампе (Dierk Krampe), Патрику Лиссеру (Patrick Lisser), Элизабет Майер (Elisabeth Maier), Томасу Мансини (Thomas Mancini), Алексио Морено (Alexio Moreno), Рольфу Пфеннингеру (Rolf Pfenninger) и Мэтиасу Ресселу (Matthias Ressel).
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство Питер, компьютерная редакция).
Мы будем рады узнать ваше мнение!
Все исходные тексты, приведенные в книге, вы можете найти по адресу http://www.piter.com/download.
На web-сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.
Часть 1.
Проблема
В данной части книги подготавливается сцена, на которой должно в последующем появиться экстремальное программирование. Здесь описываются различные аспекты проблемы, которую предстоит решить, сформировав новую дисциплину разработки программного обеспечения.
В данной части обсуждаются базовые предположения, которые мы должны учитывать, подбирая методики разработки программного обеспечения, – метафора управления автомобилем, четыре значения, принципы, сформированные на основе этих значений, а также деятельность, которую требуется структурировать в рамках новой дисциплины разработки программного обеспечения.
Глава 1.
Риск: основная проблема
Существующие дисциплины разработки программного обеспечения не срабатывают и не дают желаемого экономического эффекта. Эта проблема обладает огромным экономическим и гуманитарным значением. Мы нуждаемся в новом способе разработки программного обеспечения.
Основная проблема разработки программного обеспечения – это риск .
Вот несколько примеров риска.
• Смещение графиков – наступает день сдачи работы, и вы вынуждены сообщить заказчику, что разрабатываемая система не будет готова еще в течение шести месяцев.
• Закрытие проекта – после нескольких смещений графика и переносов даты сдачи проект закрывается, даже не будучи доведен до стадии опробования в рабочих условиях.
• Система теряет полезность – разработанное программное обеспечение успешно устанавливается в реальной производственной рабочей среде, однако после пары лет использования стоимость внесения в нее изменений и/или количество дефектов увеличиваются настолько, что становится дешевле заменить систему новой разработкой.
• Количество дефектов и недочетов – программная система устанавливается в реальной производственной рабочей среде, однако количество дефектов и недочетов столь велико, что система не используется.
• Несоответствие решаемой проблеме – программная система устанавливается в реальной производственной рабочей среде, однако выясняется, что на самом деле она не решает проблему бизнеса, для решения которой она изначально предназначалась.
• Изменение характера бизнеса – программная система устанавливается в реальной производственной рабочей среде, однако в течение шести последних месяцев проблема, для решения которой предназначалась эта система, потеряла актуальность, а вместо нее бизнес столкнулся с новой, еще более серьезной проблемой.
• Недостаток возможностей – программная система обладает множеством потенциально интересных возможностей, каждую из которых было очень приятно программировать, однако выясняется, что ни одна из этих возможностей не приносит заказчику достаточно много пользы.
• Текучка кадров – в течение двух лет работы все хорошие программисты, работавшие над проектом, один за другим возненавидели разрабатываемую программную систему и ушли на другую работу.
На страницах данной книги вы прочитаете об экстремальном программировании (eXtreme Programming , XP) – дисциплине разработки программного обеспечения, которая ориентирована на снижение степени риска на всех уровнях процесса разработки. ХР способствует существенному увеличению производительности и улучшению качества разрабатываемых программ, кроме того, это весьма занятная практика, доставляющая всем ее участникам массу удовольствия.
Каким образом ХР снижает перечисленные ранее риски?
• Смещение графика – ХР предлагает использовать очень короткие сроки выпуска каждой очередной версии. Предполагается, что каждая очередная готовая к использованию версия системы разрабатывается в течение максимум нескольких месяцев. Таким образом, объем работ в рамках каждой версии ограничен, а значит, если и происходит смещение, оно менее значительное. В рамках каждой версии предусматривается выпуск нескольких итераций запрашиваемых заказчиком возможностей, на разработку каждой из этих итераций уходит от одной до четырех недель. Так обеспечивается гибкая и чуткая обратная связь с заказчиком, благодаря чему он получает представление о текущем ходе работ. В рамках каждой итерации планирование в соответствии с ХР осуществляется в терминах нескольких задач, которые необходимо решить для получения очередной итерации. На решение каждой из задач отводится от одного до трех дней. В результате команда может обнаруживать и устранять проблемы даже в процессе итерации. Наконец, ХР подразумевает, что возможности с наивысшим приоритетом будут реализованы в первую очередь. Таким образом, любые возможности, которые не удалось реализовать в рамках данной очередной версии программного продукта, обладают меньшим приоритетом.
• Закрытие проекта – в рамках ХР заказчик должен определить наименьший допустимый набор возможностей, которыми должна обладать минимальная работоспособная версия программы, имеющая смысл с точки зрения решения бизнес-задач. Таким образом, программистам потребуется приложить минимальное количество усилий для того, чтобы заказчик понял, нужен ли ему этот проект или нет.
• Система теряет полезность – в рамках ХР создается и поддерживается огромное количество тестов, которые запускаются и перезапускаются после внесения в систему любого изменения (несколько раз на дню), благодаря этому удается тщательно следить за качеством разрабатываемой программы. ХР постоянно поддерживает систему в превосходном состоянии. Дефектам просто не дают накапливаться.
• Количество дефектов и недочетов – в рамках ХР разрабатываемая система тестируется как программистами, создающими тесты для каждой отдельной разрабатываемой функции, так и заказчиками, которые создают тесты для каждой отдельной реализованной возможности системы.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56