WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 |
-- [ Страница 1 ] --

Краткое содержание О серии ХР 12 Предисловие 13 Введение 15 Часть 1. Проблема Глава 1. Риск: основная проблема 24 Глава 2. Эпизод из программистской практики 28 Глава 3. Экономика разработки

программного обеспечения 32 Глава 4. Четыре переменные 36 Глава 5. Стоимость внесения изменений 43 Глава 6. Обучение управлению автомобилем 49 Глава 7. Четыре ценности 52 Глава 8. Базовые принципы 60 Глава 9. Обратно к истокам 68 Часть 2. Решение Глава 10. Краткий обзор 78 Глава 11. Как это работает? 89 Глава 12. Стратегия менеджмента 97 Глава 13. Стратегия организации рабочего места 104 Глава 14. Разделение полномочий между технарями и бизнесменами 109 Глава 15. Стратегия планирования 114 Глава 16. Стратегия разработки 127 Глава 17. Стратегия проектирования 134 Глава 18. Стратегия тестирования 147 Часть 3. Реализация ХР Глава 19. Внедрение ХР 154 Глава 20. Адаптация ХР для существующего проекта 156 Глава 21. Жизненный цикл идеального ХР-проекта 162 Глава 22. Роли для людей Глава 23. Правило 20 на 80 Глава 24. Что делает ХР сложной? Глава 25. Когда не следует использовать ХР Глава 26. ХР в работе Глава 27. Заключение Аннотированная библиография Словарь терминов Алфавитный указатель Содержание О серии ХР Предисловие Введение Данная книга Что такое ХР? Достаточность План книги Благодарности От издательства Часть 1. Проблема Глава 1. Риск: основная проблема Наша цель Глава 2. Эпизод из программистской практики Глава 3. Экономика разработки программного обеспечения Варианты Пример Глава 4. Четыре переменные Взаимосвязь между переменными Фокус на объеме работ Глава 5. Стоимость внесения изменений Глава 6. Обучение управлению автомобилем Глава 7. Четыре ценности Коммуникация Простота Содержание Обратная связь Храбрость Ценности на практике Глава 8. Базовые принципы Глава 9. Обратно к истокам Кодирование Тестирование Слушание Проектирование Заключение Часть 2. Решение Глава 10. Краткий обзор Игра в планирование Небольшие версии Метафора Простой дизайн Тестирование Переработка Программирование парами Коллективное владение Постоянно продолжающаяся интеграция 40-часовая рабочая неделя Заказчик на месте разработки Стандарты кодирования Глава 11. Как это работает? Игра в планирование Небольшие версии Метафора Простой дизайн Тестирование Переработка кода Программирование в парах Коллективное владение Постоянно продолжающаяся интеграция 40-часовая рабочая неделя Заказчик на месте разработки Стандарты кодирования Заключение 8 Содержание Глава 12. Стратегия менеджмента Метрики Инструктирование Слежение Интервенция Глава 13. Стратегия организации рабочего места Глава 14. Разделение полномочий между технарями и бизнесменами Бизнес Разработчики Что делать? ПО Выбор технологии Что если это сложно? Глава 15. Стратегия планирования Игра в планирование Цель Стратегия Куски Игроки Ходы Итерационное планирование Планирование за неделю Глава 16. Стратегия разработки Постоянная интеграция Коллективное владение Программирование парами Глава 17. Стратегия проектирования Самая простая которая, возможно, сработает Как работает «проектирование при помощи переработки»? Что является самым простым? Как это может работать? Роль рисунков в дизайне Системная архитектура Глава 18. Стратегия тестирования Кто пишет тесты? Другие тесты Содержание Часть 3. Реализация ХР Глава 19. Внедрение ХР Глава 20. Адаптация ХР для существующего проекта Тестирование Проектирование Планирование Менеджмент Разработка Проблемы? Глава 21. Жизненный цикл идеального Исследование Планирование Итерации в первой версии Внедрение в эксплуатацию Обслуживание и поддержка Смерть Глава 22. Роли для людей Программист Заказчик Тестер Ревизор Инструктор Консультант Большой босс Глава 23. Правило 20 на 80 Глава 24. Что делает ХР сложной? Глава 25. Когда не следует использовать ХР Глава 26. ХР в работе Фиксированная цена Разработка чужими силами Разработка своими силами Время и материалы Премия за завершение Раннее закрытие проекта Программные инфраструктуры Продукты широкого использования 10 Содержание Глава 27. Заключение Ожидание Аннотированная библиография Философия Отношение Внезапные процессы Системы Люди Управление проектами Программирование Другое Словарь терминов Алфавитный указатель Посвящается моему отцу, а также благодарю Синди (Cindee Andres), мою жену и партнера, за то, что она требовала, чтобы я не обращал на нее внимания и писал.

Спасибо Бетани (Bethany), (Lincoln), Форресту (Forrest) и за то, что они не отвлекали меня и предоставили мне писать.

О серии ХР Экстремальное программирование (Extreme часто обозна чаемое аббревиатурой ХР, — это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продук тов, которая фокусирует усилия обеих сторон (программистов и бизнес менов) на общих, вполне достижимых целях. Команды, использующие ХР, производят качественное программное обеспечение с весьма большой ско ростью. Методики, которые входят в состав дисциплины ХР, описанной в данной книге, выбраны из-за того, что они основаны на человеческом творчестве и принятии того, что человек является существом неустойчи вым и подверженным ошибкам.

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

Я сказал «начало ответа на так как продолжения на самом деле не существует. Люди, создававшие и внедрявшие ХР, тоже думали над решением этого вопроса. Попробовав использовать ХР, они перешаг нули порог и побывали в неизведанном. Вернувшись, они рассказали свою историю. Изложенные ими мысли — это указатели, расставленные вдоль дороги: «Здесь живут драконы», «Через 15 км открывается хороший вид», «Этот участок опасен во время дождя».

Прошу прощения, но мне пора идти программировать.

Кент Бек, серии Предисловие Экстремальное программирование (eXtreme Programming, XP) определя ет кодирование как ключевую и основополагающую деятельность при ра боте над программным проектом. Возможно, что это неправильно!

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

Не следует делать вывод, что все, что вам потребуется для успешной реализации программного проекта, — это безоглядное ожесточенное про граммирование. Разрабатывать программное обеспечение очень непросто, а разрабатывать качественное программное обеспечение и при этом за вершать работу в срок — еще сложнее. Чтобы описанный мною подход сработал, необходимо последовательное применение важных дополнитель ных правил и методик. Именно с этого Кент Бек (Kent Beck) начинает свою побуждающую к размышлениям книгу об ХР.

Кент был среди тех руководителей компании Tektronix, которые осо знали огромный потенциал, заложенный в методике программирования в связанных парах при разработке сложных инженерных приложений 14 Предисловие в среде Smalltalk. Вместе с Cunningham) Кент стал вдохновителем развития методики программирования по об разцам (ее еще называют программированием с использованием паттер нов — patterns которая в значительной степени повлияла на мою собственную карьеру. В рамках ХР описывается подход к разра ботке программного обеспечения, который сочетает в себе методики, ис пользуемые многочисленными успешно работающими разработчиками, которые изучили множество литературы, посвященной организации тру да программистов, и опробовали на практике множество методов и про цедур разработки программного продукта. Как и программирование по образцам, ХР формирует набор наиболее эффективных методик, таких как тестирование программных модулей, программирование парами и пе реработка кода. В рамках ХР эти методики скомбинированы таким обра зом, чтобы дополнять и часто контролировать друг друга. Основная цель данной книги — рассказать о взаимодействии и совместном использова нии различных методик. У всех методик программирования одна цель — создание программного продукта с заданной функциональностью к задан ному сроку. Предлагаемый OTI весьма успешный процесс Just In Time Software не является ХР в чистом виде, однако между этими двумя под ходами очень много общего.

Я сотрудничал с Кентом и использовал описанные в рамках ХР эпи зоды при работе над небольшим, но небезызвестным проектом под на званием Его взгляды и подходы к разработке программ всегда за ставляли меня задумываться над тем, как лично я привык работать над программным проектом. Без сомнения, ХР ставит под вопрос многие тра диционные подходы, используемые в индустрии программирования. Про читав данную книгу, вы сможете самостоятельно решить, надо ли вам при менять ХР в своей работе или нет.

Эрих Гамма (Erich Gamma) См. книгу Э. Гамма, Р. Хельма, Р. Джонсона и Дж. Влиссидеса «Приемы объектно-ориенти рованного проектирования. Паттерны проектирования», выпущенную издательствами «Пи тер» и в 2001 году. — Примеч. ред.

JUnit — программная инфраструктура, предназначенная для автоматического тестирования модулей в среде Java. — Примеч. пер.

Введение Эта книга об экстремальном программировании (eXtreme Programming, XP).

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

Для многих ХР выглядит набором вполне приемлемых и оправданных с точки зрения здравого смысла методов организации труда. Тогда почему программирование в соответствии с методиками ХР называется экстремаль ным? Дело в том, что ХР доводит использование многих общепринятых и широко используемых принципов программирования до экстремальных уровней.

• Если пересмотр кода — это хорошо, значит, мы будем пересматри вать код постоянно (программирование парами);

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

• если проектирование — это хорошо, значит, проектирование надо сделать составной частью повседневной работы каждого из участ ников проекта (переработка кода);

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

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

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

16 Введение • если небольшие итерации — это хорошо, необходимо сделать итера ции очень, очень маленькими — секунды, минуты, может быть но не недели и месяцы, и ни в коем случае не годы (игра в плани рование).

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

ХР формирует два набора обещаний:

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

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

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

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

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

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

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

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

Что такое ХР?

Что такое ХР? ХР — это упрощенный, эффективный, гибкий, предсказуе мый, научно обоснованный и весьма приятный способ разработки про граммного обеспечения, предусматривающий низкий уровень риска. От других методик ХР отличается по следующим признакам.

• Благодаря использованию чрезвычайно коротких циклов разработ ки ХР предлагает быструю, реальную и постоянно функционирую щую обратную связь.

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

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

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

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

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

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

• ХР основывается на методиках, которые удовлетворяют как крат косрочным инстинктам отдельных программистов, так и долгосроч ным интересам всего проекта в целом.

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

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

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

Введение Нововведениями в ХР являются следующие особенности:

• все эти давно известные приемы собраны под одной крышей;

• интенсивность, с которой эти приемы внедряются в повседневную работу, доведена до крайности;

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

Достаточность В своих работах The Forest People «Лесные народы» и The Mountain People «Горные народы» антрополог Колин Тернбулл (Colin описывает два совершенно отличающихся друг от друга общества. В горах необхо димых для жизни ресурсов не хватает, и люди всегда находятся на грани голода. Культура, которая возникла в подобных условиях, выглядит ужа сающе. Матери бросают своих детей ради того, чтобы выжить самим. Про питание может стать причиной смертоубийства. Жестокость, зверство и предательство являются обыденными и повседневными.

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

ХР — это попытка ответить на вопрос: «Как лично вы программирова ли бы, если бы у вас было достаточно времени?» Вообще-то у вас нет лиш него времени, так как в конце концов программирование — это бизнес.

В любом бизнесе побеждает тот, кто делает работу быстрее. Однако если бы у вас было время, вы наверняка уделяли бы внимание разработке тес тов;

вы наверняка заново переделали бы архитектуру системы в случае, если пришли бы к выводу, что это необходимо;

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

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

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

Книга разделена на три части.

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

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

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

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

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

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

Вард Каннингхэм (Ward Cunningham) — это мой основной источник, из которого я черпал излагаемый в книге материал. Так или иначе я по тратил последние пятнадцать лет, просто пытаясь объяснить другим лю дям то, чем Вард уже давно занимается практически. Спасибо также Рону Джеффрису (Ron Jeffries) за то, что он тоже это попробовал, а затем су щественно улучшил. Спасибо Мартину Фолеру (Martin Fowler) за то, что он объясняет все это простым мягким языком и без нервных срывов. Спа сибо Эриху Гамма (Erich Gamma) за длительные беседы, совмещенные с созерцанием лебедей в Лимме, а также за то, что он не позволил мне покинуть его с плохими мыслями в голове. И конечно же, ничего этого не произошло бы в моей жизни, если бы у меня не было такого примера для подражания, как мой отец, Дуг Бек (Doug Beck), который оттачивал свое мастерство программирования в течение многих лет.

Спасибо команде СЗ в компании Chrysler за то, что они сопровождали меня в моих изысканиях. А также особое спасибо нашим менеджерам Сью Ангер (Sue Unger) и Рону Сэведжу (Ron Savage) за то, что у них хватило храбрости дать нам попробовать.

Спасибо компании Daedalos Consulting за помощь в написании данной книги.

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

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

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

Спасибо (перечисление в случайном порядке, в котором я получал от них комментарии) Хатчинсону (Greg Hutchinson), Массимо Арнольди (Massimo Arnoldi), Дэйву Клилу (Dave Сэмесу Шустеру 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), Де Гузман De Guzman), Тому Кабиту (Tom Kubit), Бругманну Bruegmann), 22 Введение Хаско Хейнеке (Hasko Heinecke), Петеру Мерелу (Peter Робу Ми (Rob Мее), Пете Макбрину (Pete Томасу Эрнсту (Thomas Ernst), Гуидо Хечлеру Haechler), Дитеру Холцу (Dieter Мартину Кнехту (Martin Knecht), Дирку Крампе (Dierk Патрику ру (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 вы найдете подробную информацию о наших книгах.

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

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

Риск: основная проблема Существующие дисциплины разработки программного обеспечения не срабатывают и не дают желаемого экономического эффекта. Эта проблема обладает огромным экономиче ским и гуманитарным значением. Мы нуждаемся в новом способе разработки программ ного обеспечения.

Основная проблема разработки программного обеспечения — это риск.

Вот несколько примеров риска.

• Смещение графиков — наступает день сдачи работы, и вы вынужде ны сообщить заказчику, что разрабатываемая система не будет гото ва еще в течение шести месяцев.

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

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

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

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

Риск: основная проблема • Изменение характера бизнеса — программная система устанавлива ется в реальной производственной рабочей среде, однако в течение шести последних месяцев проблема, для решения которой предназ началась эта система, потеряла актуальность, а вместо нее бизнес столкнулся с новой, еще более серьезной проблемой.

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

• Текучка кадров — в течение двух лет работы все хорошие програм мисты, работавшие над проектом, один за другим возненавидели разрабатываемую программную систему и ушли на другую работу.

На страницах данной книги вы прочитаете об экстремальном програм мировании Programming, XP) — дисциплине разработки про граммного обеспечения, которая ориентирована на снижение степени риска на всех уровнях процесса разработки. ХР способствует существенному увеличению производительности и улучшению качества разрабатываемых программ, кроме того, это весьма занятная практика, доставляющая всем ее участникам массу удовольствия.

Каким образом ХР снижает перечисленные ранее риски?

• Смещение графика — ХР предлагает использовать очень короткие сроки выпуска каждой очередной версии. Предполагается, что каж дая очередная готовая к использованию версия системы разрабаты вается в течение максимум нескольких месяцев. Таким образом, объем работ в рамках каждой версии ограничен, а значит, если и происхо дит смещение, оно менее значительное. В рамках каждой версии пре дусматривается выпуск нескольких итераций запрашиваемых заказ чиком возможностей, на разработку каждой из этих итераций уходит от одной до четырех недель. Так обеспечивается гибкая и чуткая об ратная связь с заказчиком, благодаря чему он получает представле ние о текущем ходе работ. В рамках каждой итерации планирование в соответствии с ХР осуществляется в терминах нескольких задач, которые необходимо решить для получения очередной итерации. На решение каждой из задач отводится от одного до трех дней. В резуль тате команда может обнаруживать и устранять проблемы даже в про цессе итерации. Наконец, ХР подразумевает, что возможности с наи высшим приоритетом будут реализованы в первую очередь. Таким образом, любые возможности, которые не удалось реализовать в рам 26 Глава 1 • Риск: основная проблема ках данной очередной версии программного продукта, обладают мень шим приоритетом.

• Закрытие проекта — в рамках ХР заказчик должен определить наи меньший допустимый набор возможностей, которыми должна об ладать минимальная работоспособная версия программы, имеющая смысл с точки зрения решения бизнес-задач. Таким образом, про граммистам потребуется приложить минимальное количество уси лий для того, чтобы заказчик понял, нужен ли ему этот проект или нет.

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

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

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

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

• Изменение характера бизнеса — в рамках ХР цикл работы над оче редной версией программы существенно укорачивается. Таким об разом, ко времени выхода очередной работоспособной версии про граммного продукта бизнес не успевает претерпеть существенных изменений. В процессе работы над очередной версией заказчик мо жет попросить отказаться от разработки некоторой функциональ ности и вместо нее добавить в программный продукт другие, совер шенно новые возможности. Команда разработчиков даже не обратит внимания на то, работает ли она над реализацией новых программ ных механизмов, или осуществляется разработка возможностей, оп ределенных еще несколько лет назад.

• Недостаток возможностей — в рамках ХР осуществляется реализа ция только наиболее высокоприоритетных задач.

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

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

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

Наша цель Если мы признаем, что риск является основной проблемой, которую тре буется решить, то в каком месте следует искать решение этой проблемы?

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

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

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

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

Я смотрю на мой набор карточек с задачами. На самой верхней из них написано: «Экспорт значения квартальных издержек на момент обраще ния к системе». Я вспоминаю, что на сегодняшнем утреннем совещании ты сообщил присутствующим, что завершил блок вычисления значения квартальных издержек. Я обращаюсь к тебе (моему гипотетическому со ратнику) с вопросом, не найдется ли у тебя времени помочь мне с разра боткой блока экспорта. Ты отвечаешь: Это одно из основных правил ХР: если к тебе обращаются с просьбой о помощи, ты обязан от ветить «да». Таким образом мы становимся партнерами по программиро ванию в паре.

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

Эпизод из программистской практики Ты спрашиваешь у меня: «Как выглядят тестовые случаи для этой за дачи?» Я отвечаю: «После выполнения экспортирующего кода значения в экс портированной записи должны соответствовать бинарным значениям».

Ты спрашиваешь: «Какие поля требуется заполнить?» «Я не знаю, надо спросить у Эдди».

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

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

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

После этого мы разрабатываем наш тестовый случай. Благодаря тому, что перед этим мы разработали суперкласс, создание нового тестового слу чал не представляет труда. Мы выполняем эту работу в течение несколь ких минут. Где-то в середине работы я говорю: «Я уже представляю себе, как мы можем это реализовать. Мы можем...» Однако ты прерываешь меня: «Давай сначала завершим работу над те стовым случаем». Пока мы пишем тестовый случай, в голову приходят идеи для трех вариаций. Ты записываешь их на очередной карточке.

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

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

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

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

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

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

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

• Два программиста работают над решением задачи вместе в одной паре.

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

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

Сразу же за разработкой следует интеграция, которая включает в себя также интеграционное тестирование.

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

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

• финансовые потоки, втекающие в проект и вытекающие из проекта;

• коэффициенты прибыли (процентная ставка);

• вероятность того, что проект выживет.

Максимизировать экономическую выгоду можно следующим образом:

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

Спасибо Джону Фаваро (John Favaro) за анализ ХР с точки зрения ценовых вариаций.

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

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

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

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

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

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

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

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

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

• Вариант роста инвестиций — если вы видите, что рынок начинает расти, вы можете оперативно увеличить инвестиции для того, 34 Глава 3 • Экономика разработки программного обеспечения чтобы с выгодой воспользоваться этим. Стратегия управления про ектом будет более выгодной в случае, если вы будете обладать воз можностью все больше и больше расширять производство за счет увеличения объема инвестиций. Чем быстрее и чем дольше проект может расти, тем лучше.

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

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

• объем инвестиций, необходимых для реализации того или иного ва рианта;

• цена, в рамках которой вы сможете достигнуть цели, если вы будете действовать в рамках того или иного варианта;

• текущая ценность поставленной вами цели;

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

• неопределенность, с которой вы можете оценить ценность постав ленной вами цели.

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

• частый возврат точных сведений о текущем состоянии разработки;

• множество возможностей в значительной степени изменить набор изначально заданных требований и направление развития проекта;

• меньший объем изначальных инвестиций;

• возможность при желании увеличить темпы разработки.

Чем большей будет неопределенность, тем полезнее окажется создан ная нами стратегия. Это утверждение является справедливым вне зави симости от того, является ли причиной неопределенности технический риск, изменяющиеся условия, в которых функционирует бизнес, или бы стро эволюционирующие требования заказчика. (Это является теорети ческим ответом на вопрос: «Надо ли мне использовать Использо вать ХР следует в условиях, когда требования заказчика неопределенны или быстро меняются.) Пример Пример Представьте, что вы занимаетесь программированием фактически в оди ночку. Вы видите, что добавление в программу некоторой возможности обойдется вам в $10. Вы ожидаете, что вы сможете заработать на этой возможности приблизительно $15. Таким образом, чистая текущая цен ность (Net Present Value, NPV) добавления в программу данной возмож ности составит $5.

Представьте, что вы не можете сказать точно, какова будет на самом деле ценность рассматриваемой вами возможности, — вы можете лишь предположить, что заказчик будет готов заплатить за нее В действи тельности этот параметр может отличаться от предполагаемого вами зна чения на 100% в обе стороны. Теперь предположим, что если вы собере тесь добавлять данную возможность спустя год от текущего момента, то это все равно будет стоить вам те же $10 (см. главу 5).

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

С учетом этой процентной ставки искомая ценность составит около $7,87.

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

Говоря проще, варианты помогают нам избавиться от нежелательного риска.

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

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

• затраты (cost);

• время (time);

• качество (quality);

• объем работ (scope).

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

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

Помимо качества, время, как правило, также выходит из-под контроля.

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

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

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

Взаимосвязь между переменными Затраты (cost) — чем больше денег, тем легче работать, однако слишком большое количество денег в самые кратчайшие сроки создаст больше про блем, чем требуется решить. С другой стороны, если вы выделяете на про ект слишком мало денег, вы не сможете решить поставленные перед вами заказчиком проблемы.

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

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

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

Объем работ (scope) — сократив объем работ, вы можете повысить ка чество (при условии, конечно, что поставленная заказчиком задача реше на). Сокращение объема работ позволяет также сократить время проекта и связанные с проектом затраты.

Между рассмотренными четырьмя переменными не существует про стой зависимости. Например, вы не сможете увеличить скорость работы программы, просто затратив на ее разработку больше денег. Как говорит народная мудрость, «девять женщин не могут родить ребенка за один месяц». (И в противоположность тому, что я слышал от некоторых 38 Глава 4 • Четыре переменные менеджеров, даже восемнадцать женщин не смогут родить ребенка за один месяц.) В определенном смысле затраты являются наиболее ограничивающей переменной. Вы не можете напрямую менять деньги на качество, объем работ или скорость, с которой выпускаются промежуточные версии про дукта. На самом деле в начале проекта вообще не существует возможно сти потратить сразу много денег. В начале работ инвестирование необхо димо выполнять понемногу и затем, с течением времени, увеличивать объемы вложений. В процессе того, как проект будет развиваться, вы смо жете эффективно тратить все большее и большее количество денег.

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

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

Он настаивал: «Вы не понимаете. Мы обязаны задействовать в проек те 40 программистов».

Я ответил: «Вы не сможете сделать этого».

Однако он не унимался: «Но мы обязаны».

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

Все эти программисты поувольнялись. Они наняли еще 40 программистов.

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

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

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

С другой стороны, затраты тесно связаны с другими переменными.

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

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

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

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

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

Существует весьма странная зависимость между внутренним и внеш ним качеством. Внешнее качество — это качество, измерением которого занимается заказчик. Внутреннее качество оценивается программистами.

Если вы намерены временно пожертвовать внутренним качеством для того, чтобы сократить время разработки, и при этом надеетесь на то, что внеш нее качество не пострадает слишком сильно, имейте в виду, что вы стре митесь к достижению краткосрочной цели. Возможно, закрыв глаза на 40 Глава 4 • Четыре переменные качество внутренней отделки, вам удастся сэкономить пару недель или даже месяц, однако с течением времени количество внутренних проблем может увеличиться настолько, что разрабатываемую вами систему будет чрезвычайно сложно сопровождать и развивать;

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

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

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

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

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

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

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

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

Что, если посмотреть на нечеткость требований не как на проблему, а как на удобную возможность? В этом случае мы можем обнаружить, что показатель объема работ является наиболее удобной в управлении пере менной из тех четырех переменных, о которых я говорил ранее. Так как этот показатель наименее четко очерчен, мы можем формировать его в соответствии с нашими собственными предпочтениями и предпочтени ями заказчика — немного в эту сторону, немного в ту сторону. Если время поджимает и надо выпускать очередную версию продукта, у нас всегда будет что-то, что мы можем отложить до следующей версии. Однако если мы будем стараться не втискивать в рамки версии слишком много работы, то сохраним возможность выпустить продукт требуемого каче ства в указанные сроки.

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

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

Разрабатываемая нами дисциплина должна подразумевать низкую сто имость внесения изменений в проект, так как предполагается, что направ 42 Глава 4 • Четыре переменные ление развития проекта будет меняться достаточно часто. Не стоит тра тить деньги на разработку программного продукта, который в дальнейшем не будет использоваться. Не стоит тратить деньги на асфальтирование до роги, по которой вы все равно не будете ездить, так как вам придется свер нуть на ближайшем повороте. Чтобы в подобной ситуации добиться жела емых результатов, вы должны использовать методику, в рамках которой стоимость внесения в проект изменений будет приемлемой в течение все го времени жизни системы.

Если вы будете отказываться от реализации важной функциональности в конце каждого очередного периода работы над очередной версией про дукта, заказчик в скором времени разочаруется в вашей работе. Чтобы из бежать этого, ХР использует две стратегии.

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

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

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

Одно из общепринятых фундаментальных правил, определяющих традици онную стратегию разработки программного обеспечения, утверждает, что по мере работы над проектом стоимость внесения изменений в разрабатывае мый программный продукт увеличивается экспоненциально. Я помню, как, будучи студентом колледжа, сидел в огромной аудитории, пол которой был покрыт блестящим линолеумом, и смотрел, как профессор рисует на доске кривую, изображенную на Рис. 1. С течением времени стоимость внесения изменений в программный продукт возрастает экспоненциально г 44 Глава 5 • Стоимость внесения изменений «Затраты, связанные с исправлением проблемы, обнаруженной внутри программного продукта, растут экспоненциально с течением времени, — говорил профессор. — Проблема, для решения которой в процессе анали за требований потребовался бы доллар, может стоить вам нескольких ты сяч долларов, если вы обнаружите ее в момент, когда система уже будет в производстве».

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

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

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

Рис. 2. Можем ли мы использовать только один компонент для каждой пары дебет/кредит?

17.02 — я обращаюсь к Массимо и прошу его, чтобы он подошел ко мне и сел рядом для того, чтобы помочь мне разобраться в ситуации. Мы пишем запрос. Выясняется, что из всех 300 000 трансакций в системе ни Стоимость внесения изменений одна не использует более одной учетной записи для снятия денег и более одной учетной записи для переноса денег. Каждой из трансакций соот ветствует только одна дебетная учетная запись и только одна кредитная учетная запись.

17.05 — если мы хотим исправить систему, как мы можем этого до стичь? Мы можем изменить интерфейс компонента Transaction, а также изменить реализацию. Мы переписываем четыре требуемых метода и при ступаем к тестированию.

17.15 — все тесты (более чем 1000 модульных и функциональных те стов) по-прежнему выполняются на 100% отлично. Мы не можем приду мать ситуацию, в которой внесенные нами изменения могут стать причи ной неработоспособности системы. Мы приступаем к работе над кодом миграции базы данных.

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

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

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

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

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

Что, если все эти инвестиции не пропали даром? Что, если вся эта суета с новыми языками программирования и новыми базами данных не была напрасной? Что, если теперь стоимость внесения изменений не рас тет экспоненциально, как раньше, а увеличивается более медленно, со вре менем приближаясь к асимптоте? Что, если завтра профессор, преподаю 46 Глава 5 • Стоимость внесения изменений щий студентам основы разработки программного обеспечения, нарисует на доске линию, изображенную на рис. 3?

Рис. 3. Стоимость изменений со временем может увеличиваться существенно медленнее, чем экспонента Именно это является одним из основных предположений ХР. Это тех ническое предположение ХР. Если стоимость внесения в систему изме нений со временем растет достаточно медленно, стратегия разработки программы должна быть совершенно другой, отличной от той, которая используется в случае, если стоимость внесения в систему изменений со временем растет экспоненциально. В подобной ситуации вы можете от кладывать решение важных задач на более поздние сроки. Вы получаете возможность принимать важные решения настолько поздно, насколько это возможно. Это делается для того, чтобы осуществлять связанные с этим затраты как можно позже. Кроме того, если вы откладываете решение важ ных вопросов на более поздний срок, тем самым вы повышаете вероят ность того, что выбранное вами решение окажется правильным. Другими словами, сегодня вы должны реализовать только то, без чего сегодня не обойтись, при этом вы можете рассчитывать на то, что проблемы, реше ние которых вы отложили до завтра, развеются сами собой, то есть пере станут быть актуальными. Вы можете добавлять в дизайн новые элемен ты только в случае, если эти новые элементы упрощают код или делают написание следующего фрагмента кода более простым.

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

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

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

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

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

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

Чтобы упростить модификацию вашего кода даже спустя несколько лет после начала работы над проектом, вы должны учитывать следующие факторы:

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

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

48 Глава 5 • Стоимость внесения изменений • постоянная практика в деле модификации дизайна системы — ког да приходит время менять систему, вы не почувствуете страха перед этим.

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

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

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

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

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

Я отлично помню тот день, когда впервые начал учиться водить маши ну. Я и моя мать сели в машину и выехали на автостраду Interstate 5 вбли зи Чико в штате Калифорния. Это прямой как стрела пустынный участок шоссе, выходящий из-под колес машины и, подобно натянутой струне, устремляющийся вдаль — к линии горизонта. Моя мать позволи ла мне пересесть в водительское кресло, а сама села на место переднего пассажира. И мы поехали. В начале я с осторожностью изучил, как имен но движение рулевого колеса влияет на направление движения автомо биля, затем, освоившись, я позволил себе несколько расслабиться. «Уп равлять машиной надо так, — учила меня моя мама, — направь машину 50 Глава б • Обучение управлению автомобилем строго по середине дороги и езжай по этой дороге прямо в направлении горизонта».

Мы ехали достаточно долго, и где-то посередине нашего путешествия что-то отвлекло мое внимание. Машина стала смещаться в сторону края дороги. Моя мать несколько обеспокоилась...

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

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

Абсолютно все в мире программного обеспечения меняется. Требова ния заказчиков меняются. Дизайн меняется. Бизнес видоизменяется. Тех нологии меняются. Команда разработчиков меняется. Члены команды раз работчиков меняются. Сама по себе проблема остается неизменной, так как изменение рано или поздно должно произойти. На самом деле про блема состоит в том, что когда происходит изменение, люди не в состоя нии с ним справиться.

Шофером программного проекта является заказчик. Если программа не делает того, чего заказчик от нее хочет, — это ваша неудача. Конечно же, заказчик не может сказать точно, чего именно он хочет от программы.

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

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

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

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

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

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

Четыре ценности для ХР — это:

• коммуникация (communication);

• простота (simplicity);

• обратная связь (feedback);

• храбрость (courage).

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

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

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

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

Это не означает, что излишние разговоры мешают работе. Люди час то попадают в ситуацию, когда они сомневаются, делают ошибки, отвле каются. В рамках ХР существует специальное ответственное лицо — ин структор (coach), в чьи обязанности входит следить за тем, чтобы люди общались тогда, когда это надо. Если инструктор замечает, что люди пе рестают общаться, он стимулирует коммуникацию.

Простота Вторая ценность ХР — это простота. Инструктор ХР спрашивает коман ду: «Какова самая простая вещь, которая скорее всего сработает?» (эта фраза является часто употребляемым выражением, в определенном смысле девизом, так что в мире ХР даже существует специальная аббревиатура — Do The Simplest Thing That Could Possibly DTSTTCPW).

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

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

Грег Хатчинсон Hatchinson) пишет:

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

На третий день условия задачи, для решения которой требовалось данное диалоговое окно, изменились и надобность в подобном диалоговом окне полностью отпала. Таким образом, два человеко-дня ушло на то, чтобы решить проблему, которая сразу же после этого перестала быть актуальной. Все же если вы сможете найти применение для данно го кода, сообщите мне об этом. (Источник: электронная почта.) ХР делает свою ставку. что лучше сделать простую вещь сегодня и заплатить чуточку больше завтра для того, чтобы модифициро вать ее (если в этом возникнет необходимость), чем разработать более слож ный код сегодня, а потом что этот код больше не нужен.

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

Обратная связь Третья ценность в ХР — это обратная связь. Инструктор ХР часто произ носит: «Не у меня, спроси у системы» и «Ты еще не написал Обратная связь для этого тестовый случай?» Обратная связь, обеспечивающая точные и конкретные данные о текущем состоянии системы, — это воистину бес ценная вещь. Оптимизм — это профессиональная болезнь всего програм мирования. Обратная связь — это лекарство от этой болезни.

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

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

О том, что к эксплуатации системы следует приступать как можно рань ше, следует рассказать подробнее. Одной из стратегий в процессе плани рования является правило, в соответствии с которым наиболее полезные для заказчика истории реализуются программистами и начинают эксплу атироваться как можно раньше. Благодаря этому программисты получа ют обратную связь, которая обеспечивает их сведениями о качестве при нятых ими решений. Процесс разработки начинает напоминать управление автомобилем — программисты прилагают усилия для того, чтобы проект развивался в направлении, удобном для заказчика, при этом колеса долж ны всегда оставаться на асфальте. Некоторые программисты занимаются разработкой системы длительное время до того, как она начнет эксплуа 56 Глава 7 • Четыре ценности тироваться в реальных рабочих условиях. Откуда же они могут узнать о что выполняемая ими работа действительно качественна и необхо дима?

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

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

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

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

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

Я расскажу вам о том, как храбрость срабатывает в реальной жизни.

В середине восьмой итерации включающего в себя 10 итераций рабочего графика (25 из 30 недель) первой версии первого крупного ХР-проекта команда обнаружила фундаментальную ошибку в архитектуре системы.

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

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

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

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

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

Однако это не обязательно. Возможно, следующим утром будет легче на чать с нуля.

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

Стратегия проектирования в ХР напоминает алгоритм взбирания на холм (hill climbing). Вы делаете простой дизайн, затем вы делаете его бо лее сложным, далее вы его упрощаете, потом опять усложняете. Пробле ма подобных алгоритмов состоит в том, что вы ищете локальный опти f 58 Глава 7 • Четыре ценности мум, — при этом никакое незначительное изменение не может улучшить ситуацию, однако улучшения можно достичь, используя значительное из менение.

Достигнув локального оптимума вы, возможно, упускаете более эффек тивный вариант дизайна. Что поможет вам избежать этого? Храбрость.

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

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

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

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

Ценности на практике Я обратился к команде СЗ (именно эти люди работали над тем самым крупным ХР-проектом, о котором я говорил чуть раньше) с просьбой рас сказать мне о моменте в процессе работы над проектом, который показал ся им наиболее достойным восхищения. Я надеялся истории о переделке кода, о спасении благодаря тестам или по крайней мере о том удовлетворении, которое испытывал заказчик, используя разработанную систему на практике. Вместо этого я услышал следующее.

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

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

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

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

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

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

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

• быстрая обратная связь;

• приемлемая простота;

• постепенное изменение;

• приемлемое изменение;

• качественная работа.

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

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

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

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

Постепенное изменение — объемные изменения, в рамках которых за один раз меняется абсолютно все, не срабатывают. Даже в Швейцарии, центре дотошного планирования, где я живу в настоящее время, люди из бегают делать масштабные изменения. Любая проблема решается при помощи серии небольших изменений, в результате которых достигается желаемый эффект.

62 8 • Базовые принципы Как будет показано, постепенное изменение применяется в ХР во мно гих областях и многими способами. Дизайн изменяется понемногу за один раз. План меняется понемногу за один раз. Команда меняется незначи тельно за один раз. Даже сама дисциплина ХР должна внедрятся посте пенно — маленькими шажками.

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

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

Далее приводится перечень менее важных принципов. Эти принципы все же могут помочь нам в определенных ситуациях:

• обучение обучению;

• небольшие изначальные инвестиции;

• игра для того, чтобы победить;

• надежное экспериментирование;

• открытая честная коммуникация;

• работа в соответствии с человеческими инстинктами, а не вопреки им;

• принимаемая ответственность;

• локальная адаптация;

• путешествие налегке;

• откровенные оценки.

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

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

Игра для того, чтобы победить, — для меня всегда доставляет удоволь ствие смотреть, как играет баскетбольная команда UCLA Джона Вудена (John Wooden). Как правило, эти ребята выходят из поединка победите лями. Однако даже тогда, когда игра близка к завершению, ребята из UCLA уверены, что они играют для того, чтобы победить. Конечно же, до этого они уже были победителями много-много раз. Они несколько рас слаблены. Однако при этом они делают все для того, чтобы выиграть.

И они выигрывают вновь.

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

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

Изводится масса бумаги. Проводится огромное количество совещаний.

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

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

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

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

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

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

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

Базовые принципы Пол Чисолм (Paul Chisolm) пишет.

Я был на на котором один так называемый менеджер контроля качества предложил добавить шесть дополнительных полей в состав HTML-формы, и без того заполненой которые к тому же редко когда использовались. Этот самый ме неджер что добавление новых полей необходимо не потому, что данная информация окажется полезной в дальнейшем, а потому, что дополнительные поля позволят СЭКОНОМИТЬ ВРЕМЯ. Моя реакция была следующей: я ударил лбом о твер дую поверхность за которым проводилось совещание, прямо как мультиплика ционный герой Warner Brothers, который только что услышал что-то невероятное. После этого я попросил их перестать мне лгать. На сегодняшний день я не знаю, был ли это наименее профессиональный или, наоборот, наиболее профессиональный поступок в моей жизни. Однако мой глазной врач сказал мне, чтобы я больше не стучал голо вой о стол, так как при этом сетчатка в моем глазу может отсоединиться от глазного дна. (Источник: электронная почта.) Это достаточно сложно — разработать процесс, в рамках которого крат косрочные личные интересы служат долгосрочным интересам всей коман ды. Вы можете сколько угодно рассуждать на тему, насколько та или иная методика способствует достижению долгосрочной всеобщей цели, однако как только вы оказываетесь под давлением, вы обнаруживаете, что если методика не способствует решению конкретной проблемы, стоящей перед вами в настоящий момент, вы отбрасываете ее в сторону. Если дисципли на ХР не будет удовлетворять краткосрочным личным интересам людей, она обречена на провал.

Некоторым в ХР нравится именно то, что эта дисциплина создает у программистов ощущение, будто они занимаются именно тем, чем они занимались бы, если бы их никто не заставлял специально заниматься той или иной проблемой. При этом ХР обеспечивает общее развитие про екта в заданном направлении. Мне запомнилась одна образная цитата: «ХР соответствует поведению программистов в условиях дикой природы».

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

Альтернативой этого является ответственность, которая не вешается на человека в приказном порядке, а принимается им добровольно. Это не 66 Глава 8 • Базовые принципы означает, что вы всегда занимаетесь только тем, чем вам нравится зани маться. Вы являетесь частью команды, и если команда придет к выводу, что некоторая задача требует решения, должен найтись человек, который возьмется за это вне зависимости от того, насколько отталкивающей для него будет эта задача.

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

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

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

• немного;

• просто;

• ценно.

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

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

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

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

Рассказ об управлении автомобилем. Четыре ценности — коммуникация, простота, обратная связь и храбрость. Двойной набор принципов. Теперь мы готовы приступить к формированию дисциплины разработки про граммного обеспечения. Вначале надо определить круг решаемых нами проблем. К какой области будут относиться наши предписания? Решени ем проблем какого сорта мы будем заниматься? Проблемы какого сорта будут игнорироваться нами?

Я вспоминаю, как я впервые научился программировать на BASIC.

У меня была пара книг, в которых описывались основы программирова ния. Я достаточно быстро прочитал их и, когда я закончил, решил при ступить к решению которая была несколько сложнее, чем при митивные примеры, рассматривавшиеся в этих книгах. Я решил написать игру Trek (Звездный путь), похожую на ту, в которую я играл в Law rence Hall of Science в университете Berkeley, только моя версия должна была бы стать круче.

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

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

Я чувствовал, что надо сделать что-то еще помимо программирования, но я не знал, что именно.

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

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

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

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

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

Коммуникация подобного рода очень просто преобразуется в обучение.

Я вижу вашу идею, и у меня появляется моя собственная, однако мне 70 Глава 9 • Обратно к истокам сложно объяснить ее на словах, поэтому я, так же как и вы, обращаюсь к кодированию. Так как наши идеи связаны между собой, мы используем связанный код. Вы видите мою идею, и у вас появляется еще одна.

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

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

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

Тестирование Английские философы-позитивисты Лок (Locke), Беркли (Berkeley) и Хьюм (Hume) утверждают, что все, чего нельзя измерить, на самом деле не существует. Если речь заходит о коде, я с ними полностью согласен.

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

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

Pages:     || 2 | 3 | 4 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.