Эта книга об экстремальном программировании. Экстремальное программирование, часто обозначаемое аббревиатурой «XP» — это упрощенная методика организации производства для небольших и средних по размеру команд разработчиков, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований. Данная книга предназначена для того, чтобы помочь вам определить, оправдано применение XP в вашей ситуации или нет.
Содержание
О серии XP
Предисловие
Введение
Данная книга
Что такое XP?
Достаточность
План книги
Благодарности
От издательства
Часть 1. Проблема
Глава 1. Риск: основная проблема
Наша цель
Глава 2. Эпизод из программистской практики
Глава 3. Экономика разработки программного обеспечения
Варианты
Пример
Глава 4. Четыре переменные
Взаимосвязь между переменными
Фокус на объеме работ
Глава 5. Стоимость внесения изменений
Глава 6. Обучение управлению автомобилем
Глава 7. Четыре ценности
Коммуникация
Простота
Обратная связь
Храбрость
Ценности на практике
Глава 8. Базовые принципы
Глава 9. Обратно к истокам
Кодирование
Тестирование
Слушание
Проектирование
Заключение
Часть 2. Решение
Глава 10. Краткий обзор
Игра в планирование
Небольшие версии
Метафора
Простой дизайн
Тестирование
Переработка
Программирование парами
Коллективное владение
Постоянно продолжающаяся интеграция
40-часовая рабочая неделя
Заказчик на месте разработки
Стандарты кодирования
Глава 11. Как это работает?
Игра в планирование
Небольшие версии
Метафора
Простой дизайн
Тестирование
Переработка кода
Программирование в парах
Коллективное владение
Постоянно продолжающаяся интеграция
40-часовая рабочая неделя
Заказчик на месте разработки
Стандарты кодирования
Заключение
Глава 12. Стратегия менеджмента
Метрики
Инструктирование
Слежение
Интервенция
Глава 13. Стратегия организации рабочего места
Глава 14. Разделение полномочий между технарями и бизнесменами
Бизнес
Разработчики
Что делать?
Выбор технологии
Что если это сложно?
Глава 15. Стратегия планирования
Игра в планирование
Цель
Стратегия
Куски
Игроки
Ходы
Итерационное планирование
Планирование за неделю
Глава 16. Стратегия разработки
Постоянная интеграция
Коллективное владение
Программирование парами
Глава 17. Стратегия проектирования
Самая простая вещь, которая, возможно, сработает
Как работает «проектирование при помощи переработки»?
Что является самым простым?
Как это может работать?
Роль рисунков в дизайне
Системная архитектура
Глава 18. Стратегия тестирования
Кто пишет тесты?
Другие тесты
Часть 3. Реализация XP
Глава 19. Внедрение XP
Глава 20. Адаптация XP для существующего проекта
Тестирование
Проектирование
Планирование
Менеджмент
Разработка
Проблемы?
Глава 21. Жизненный цикл идеального XP-проекта
Исследование
Планирование
Итерации в первой версии
Внедрение в эксплуатацию
Обслуживание и поддержка
Смерть
Глава 22. Роли для людей
Программист
Заказчик
Тестер
Ревизор
Инструктор
Консультант
Большой босс
Глава 23. Правило 20 на 80
Глава 24. Что делает XP сложной?
Глава 25. Когда не следует использовать XP
Глава 26. XP в работе
Фиксированная цена
Разработка чужими силами
Разработка своими силами
Время и материалы
Премия за завершение
Раннее закрытие проекта
Программные инфраструктуры
Продукты широкого использования
Глава 27. Заключение
Ожидание
Аннотированная библиография
Философия
Отношение
Внезапные процессы
Системы
Люди
Управление проектами
Программирование
Другое
Словарь терминов
Алфавитный указатель
ОТРЫВОК
Глава 8
Базовые принципы
Исходя из четырех ценностей мы сформулируем десяток (или около того) принципов, в соответствии с которыми будет формироваться наш стиль. В дальнейшем мы будем проверять рассматриваемые методики на соответствие этим принципам.
Рассказ об управлении автомобилем учит нас делать множество небольших изменений и при этом не отрывать глаз от дороги. Четыре ценности — коммуникация, простота, обратная связь и храбрость — предоставляют нам критерий для проверки качества решения. Все же четыре ценности слишком туманны для того, чтобы в значительной степени помочь нам в оценке, какие именно методики мы должны использовать. Мы должны извлечь из описанных ценностей конкретные принципы, которые мы сможем использовать, оценивая ту или иную методику.
Эти принципы помогут нам выбирать между несколькими альтернативами. Предпочтение будет отдаваться альтернативе, которая соответствует принципам в большей степени. Каждый из принципов является воплощением ценностей, о которых я рассказал в предыдущей главе. Ценность может быть туманной: например, то, что для одного человека является простым, для другого человека является сложным. Принцип — это нечто более конкретное. Либо вы используете быструю обратную связь, либо нет. Вот перечень фундаментальных принципов:
быстрая обратная связь;
приемлемая простота;
постепенное изменение;
приемлемое изменение;
качественная работа.
Быстрая обратная связь — психология обучения учит нас тому, что время между воздействием и ответной реакцией имеет огромное значение при обучении. Эксперименты с животными показывают, что даже незначительная разница в задержках ответной реакции влечет за собой существенные отличия в обучении. Задержка в несколько секунд между стимулом и ответом приводит к тому, что мышь не может понять, что красная кнопка означает еду. Таким образом, одним из принципов должна стать наиболее высокая быстрота, с которой сведения о состоянии системы передаются тем,
кто в них заинтересован. В рамках нашей дисциплины необходимо обеспечить быстрое получение этих сведений, быструю интерпретацию и быстрое внесение в систему модификаций, сформированных на основе анализа этих сведений. Все это необходимо выполнять с максимально возможной скоростью. Бизнес должен быстро определять, каким образом система будет полезной для него, и он должен возвращать разработчикам эти сведения в течение дней или недель, но не в течение месяцев или лет. Программисты должны изучать, каким образом лучше всего проектировать, реализовы
вать и тестировать систему, необходимые для этого сведения должны поступать к ним в течение секунд или минут, но не дней, недель и месяцев.
Приемлемая простота — необходимо решать каждую проблему так, как если бы ее можно было решить самым смехотворно простым способом. Времени, которое вы экономите на решении 98% проблем, для которых это утверждение является истинным, вполне хватает, чтобы справиться с решением оставшихся 2% проблем. Во многих смыслах этот принцип является наименее привычным и наиболее трудным для программистов. В рамках установившихся традиций мы приучены к тщательному планированию своих действий, мы привыкли проектировать код с расчетом на его дальнейшее повторное исп
ользование. Однако в рамках XP огромные усилия (тестирование, переработка кода, коммуникация) прикладываются для того, чтобы сегодня программист думал о решении только сегодняшних проблем и был уверен в том, что завтра в случае необходимости имеющийся код можно будет с легкостью усовершенствовать так, как этого требует складывающаяся ситуация. Экономика разработки программ, представленная в виде набора нескольких вариантов, приветствует данный подход.
Постепенное изменение — объемные изменения, в рамках которых за один раз меняется абсолютно все, не срабатывают. Даже в Швейцарии, центре дотошного планирования, где я живу в настоящее время, люди избегают делать масштабные изменения. Любая проблема решается при помощи серии небольших изменений, в результате которых достигается желаемый эффект.
Как будет показано, постепенное изменение применяется в XP во многих областях и многими способами. Дизайн изменяется понемногу за один раз. План меняется понемногу за один раз. Команда меняется незначительно за один раз. Даже сама дисциплина XP должна внедрятся постепенно — маленькими шажками.
Приемлемое изменение — лучшей стратегией является та, которая решает наиболее актуальную для вас проблему и при этом сохраняет для вас максимальную свободу дальнейших действий.
Качественная работа — никто не любит плохо работать. Каждому нравится делать свою работу на «отлично». Из четырех ранее рассмотренных переменных (объем работ, затраты, время и качество) качество на самом деле не является свободно изменяемой переменной. Единственно возможными для нее значениями являются «превосходно» и «невероятно превосходно» — выбор между этими двумя значениями зависит от того, поставлены ли на карту человеческие жизни. В противном случае ваша работа вам не нравится, вы работаете плохо и ваш проект необратимо утекает в сточную канаву
.
Далее приводится перечень менее важных принципов. Эти принципы все же могут помочь нам в определенных ситуациях:
обучение обучению;
небольшие изначальные инвестиции;
игра для того, чтобы победить;
надежное экспериментирование;
открытая честная коммуникация;
работа в соответствии с человеческими инстинктами, а не вопреки им;
принимаемая ответственность;
локальная адаптация;
путешествие налегке;
откровенные оценки.
Обучение обучению — вместо того чтобы сформировать набор доктрин наподобие «вы должны тестировать так-то и так-то», мы должны сконцентрироваться на стратегиях обучения, благодаря которым мы смогли бы научиться заранее определять, какой объем тестирования нам потребуется. Точно так же мы не должны жестко определять объем проектирования, переработки и любых других действий. Мы должны научиться определять необходимый объем по ходу дела. Некоторые идеи мы можем принять со всей уверенностью. В отношении других идей мы будем менее уверенными. В отношении
таких идей читатели должны самостоятельно определить, нуждаются ли они в них или нет.
Небольшие изначальные инвестиции — если на слишком ранней стадии вы вложите в проект слишком много денег, вы приведете этот проект к краху. Стесненный бюджет принуждает программистов и заказчиков избегать слишком завышенных требований и использовать более осторожные подходы. Обладая скромным бюджетом, вы стараетесь извлекать максимальную прибыль из того, чем вы обладаете, и с максимальной пользой использовать имеющиеся ресурсы. Однако чрезмерный недостаток ресурсов — это тоже плохо. Если у вас не хватает ресурсов на решение даже всего одной инте
ресной для вас проблемы, разрабатываемая вами система перестанет быть для вас интересной. Если над вами нависает некто, кто диктует вам объем работ, сроки окончания, уровень качества и затраты, вы вряд ли сможете управлять проектом так, чтобы привести его к желаемому успешному финалу. А вообще, как показывает практика, в большинстве случаев каждый может обойтись меньшим запасом ресурсов, чем тот запас, с которым он чувствует себя комфортно.
Игра для того, чтобы победить, — для меня всегда доставляет удовольствие смотреть, как играет баскетбольная команда UCLA Джона Вудена (John Wooden). Как правило, эти ребята выходят из поединка победителями. Однако даже тогда, когда игра близка к завершению, ребята из UCLA уверены, что они играют для того, чтобы победить. Конечно же, до этого они уже были победителями много-много раз. Они несколько расслаблены. Однако при этом они делают все для того, чтобы выиграть. И они выигрывают вновь.
Я вспоминаю игру баскетбольной команды из Орегона, которая была ярким контрастом. Орегон сражался с Аризоной, команда которой обладала национальной номинацией. Четыре игрока из Аризоны играли в национальной сборной NBA. Однако на половине матча неожиданно для всех Орегон оказался впереди на целых 12 очков. Игроки из Аризоны не могли ничего с этим поделать. Защита Орегона постоянно отражала их атаки. Однако после перерыва Орегон снизил темп игры и стал играть, экономя силы. Они закрывали глаза на медленно сокращающуюся разницу в счете, так как поставили
перед собой задачу — просто удержать победу. И, конечно же, эта стратегия не сработала. Аризона немедленно воспользовалась своим преимуществом в опыте и выиграла игру.
Отличие состоит в том, что в одном случае команда играет для того, чтобы выиграть, а в другом случае — для того, чтобы не проиграть. Большинство игроков в мире разработки программного обеспечения, с которыми мне приходилось иметь дело, играют для того, чтобы не проиграть. Изводится масса бумаги. Проводится огромное количество совещаний.
Каждый пытается разрабатывать в строгом соответствии с общепринятыми правилами (по книжке) не потому, что в этом есть смысл, а потому, что в конце работы они получат возможность сказать, что это не их вина в том, что все кончилось так плачевно.
Если разработка программного продукта осуществляется для того, чтобы победить, каждый член команды делает все, чтобы помочь команде выиграть и не делает чего-либо такого, что может помешать этому.
Надежное экспериментирование — каждый раз, когда вы принимаете решение и не тестируете его, существует вероятность, что принятое вами решение неправильно. Чем больше таких решений вы принимаете, тем выше становится эта вероятность. Именно так увеличивается риск. Чтобы снизить риск, результатом сеанса проектирования должен стать не завершенный дизайн, а серия экспериментов, отвечающих на вопросы, которые возникли у вас в процессе проектирования. Результатом обсуждения требований также должна стать серия экспериментов. Каждое абстрактное решение до
лжно быть протестировано.
Открытая честная коммуникация — это настолько очевидный принцип, что я чуть не забыл его упомянуть. Для всех очевидно, что общение должно быть открытым и искренним, однако зачастую приходится сталкиваться с обратным. И это огорчает. Программисты должны быть способны объяснить последствия решений, принимаемых другими людьми. Например: «В этом куске кода ты нарушил принцип инкапсуляции, и в результате у меня возникли проблемы». Программисты должны быть способны говорить друг другу о проблемах в коде. Они должны быть способны свободно и без стеснения
рассказать о своих страхах и в ответ получить поддержку. Они должны быть способны с легкой душой сообщать заказчикам и менеджерам плохие новости. Они должны делать это как можно раньше, и их не надо за это наказывать.
Если я вижу, как кто-то, прежде чем ответить на мой вопрос, оглядывается вокруг, чтобы посмотреть, кто его слышит, я воспринимаю это как серьезную проблему всего проекта. Если обсуждаются личные вопросы, я, конечно же, понимаю необходимость некоторой конфиденциальности, однако вопрос о том, какую из двух объектных моделей использовать, не должен быть тайной за семью печатями.
Работа в соответствии с человеческими инстинктами, а не вопреки им — люди любят выигрывать. Люди любят учиться. Люди любят взаимодействовать с другими людьми. Люди любят быть частью команды. Люди любят управлять. Люди любят, когда им доверяют. Люди любят хорошую работу. Люди любят, когда разрабатываемая ими программа отлично работает.
Пол Чисолм (Paul Chisolm) пишет.
Я был на совещании, на котором один так называемый менеджер контроля качества предложил добавить шесть дополнительных полей в состав HTML-формы, и без того заполненой данными, которые к тому же редко когда использовались. Этот самый менеджер объяснил, что добавление новых полей необходимо не потому, что данная информация окажется полезной в дальнейшем, а потому, что дополнительные поля позволят СЭКОНОМИТЬ ВРЕМЯ. Моя реакция была следующей: я ударил лбом о твердую поверхность стола, за которым проводилось совещание, прямо как мультипликационный герой
Warner Brothers, который только что услышал что-то невероятное. После этого я попросил их перестать мне лгать. На сегодняшний день я не знаю, был ли это наименее профессиональный или, наоборот, наиболее профессиональный поступок в моей жизни. Однако мой глазной врач сказал мне, чтобы я больше не стучал головой о стол, так как при этом сетчатка в моем глазу может отсоединиться от глазного дна. (Источник: электронная почта.)
Это достаточно сложно — разработать процесс, в рамках которого краткосрочные личные интересы служат долгосрочным интересам всей команды. Вы можете сколько угодно рассуждать на тему, насколько та или иная методика способствует достижению долгосрочной всеобщей цели, однако как только вы оказываетесь под давлением, вы обнаруживаете, что если методика не способствует решению конкретной проблемы, стоящей перед вами в настоящий момент, вы отбрасываете ее в сторону. Если дисциплина XP не будет удовлетворять краткосрочным личным интересам людей, она обреч
ена на провал.
Некоторым в XP нравится именно то, что эта дисциплина создает у программистов ощущение, будто они занимаются именно тем, чем они занимались бы, если бы их никто не заставлял специально заниматься той или иной проблемой. При этом XP обеспечивает общее развитие проекта в заданном направлении. Мне запомнилась одна образная цитата: «XP соответствует поведению программистов в условиях дикой природы».
Принимаемая ответственность — ничто не может так повредить работе отдельного человека или всей команды, как жесткое указание, чем именно они должны заниматься. Это особенно справедливо, если то, что предлагается сделать, сделать невозможно. Люди работают эффективнее, только если они чувствуют, что занимались бы этой работой, даже если бы никто их к этому не принуждал. Если человеку приказали выполнять некоторую не устраивающую его работу, в ходе своей деятельности он сможет найти множество способов объяснить свое нежелание и несогласие с этим. Все эт
о пагубно повлияет как на его собственную деятельность, так и на деятельность всей команды.
Альтернативой этого является ответственность, которая не вешается на человека в приказном порядке, а принимается им добровольно. Это не означает, что вы всегда занимаетесь только тем, чем вам нравится заниматься. Вы являетесь частью команды, и если команда придет к выводу, что некоторая задача требует решения, должен найтись человек, который возьмется за это вне зависимости от того, насколько отталкивающей для него будет эта задача.
Локальная адаптация — вы должны адаптировать то, о чем вы читаете в данной книге, к своим локальным условиям. Это является применением принципа принимаемой ответственности к используемому вами процессу разработки. Адаптация XP не означает, что я должен сказать вам, как вы должны разрабатывать программный продукт. Это означает, что вы должны самостоятельно определить, как вы должны разрабатывать программный продукт. Я могу рассказать вам лишь о том, какие методики я проверил на собственном опыте и при этом убедился, что они неплохо срабатывают. Я мог
у сообщить вам о возможных последствиях в случае, если вы отклонитесь от использования предлагаемых мною методик. В конце концов, это ваш собственный процесс разработки. Сегодня вы должны определить, как он будет происходить. Вы должны убедиться в том, что принятые решения будут исполняться и завтра. Вы должны модифицировать этот процесс и адаптировать его. Вы не должны думать так: «Теперь я знаю, как следует разрабатывать программы». Вместо этого вы должны сказать себе: «Я должен обдумать все это, а затем уже приступать к программированию». Да, вы долж
ны, но это того стоит.
Путешествие налегке — вы не можете нести с собой гору багажа и при этом двигаться быстро. Вы должны использовать в отношении своего багажа следующие наречия:
немного;
просто;
ценно.
Члены команды XP должны стать интеллектуальными кочевниками, в любую минуту готовыми быстро упаковать свои пожитки и следовать за пастухом. Пастухом в данном случае является дизайн, который развивается в ином направлении, чем это предполагалось ранее, или заказчик, который хочет развивать проект в ином направлении, чем это предполагалось ранее, или член команды, который решил уйти из проекта, или технология, которая подчас эволюционирует с головокружительной быстротой, или изменяющийся климат, в котором функционирует бизнес.
Как все кочевники, члены команды XP должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.
Откровенные оценки — наше желание контролировать процесс разработки программного обеспечения ведет нас к необходимости оценки. Эта оценка должна быть достаточно точной. Это хорошо, однако похоже на то, что мы вынуждены оценивать на уровне детализации, который не поддерживается имеющимися у нас инструментами. Если у вас нет надежного способа измерения на таком уровне детализации, то лучше сказать: «Это займет две недели, чуть больше или чуть меньше», чем сказать: «14,176 суток». Мы также нуждаемся в единицах измерения, которые соответствуют избранной нами
методике работы. Например, количество строк кода становится бессмысленной системой измерения в случае, если код начинает стремительно раздуваться за счет того, что мы обнаружили более эффективные способы программирования.
Экстремальное программирование. / К. Бек - СПб: Питер, 2002. - 224 с.
|