Книга: Экстремальное программирование

Глава 8.Базовые принципы

Глава 8.

Базовые принципы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пол Чисолм (Paul Chisolm) пишет:

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

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

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

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

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

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

• немного;

• просто;

• ценно.

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

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

Оглавление книги