Надежное экспериментирование – каждый раз, когда вы принимаете решение и не тестируете его, существует вероятность, что принятое вами решение неправильно. Чем больше таких решений вы принимаете, тем выше становится эта вероятность. Именно так увеличивается риск. Чтобы снизить риск, результатом сеанса проектирования должен стать не завершенный дизайн, а серия экспериментов, отвечающих на вопросы, которые возникли у вас в процессе проектирования. Результатом обсуждения требований также должна стать серия экспериментов. Каждое абстрактное решение должно быть протестировано.
Открытая честная коммуникация – это настолько очевидный принцип, что я чуть не забыл его упомянуть. Для всех очевидно, что общение должно быть открытым и искренним, однако зачастую приходится сталкиваться с обратным. И это огорчает. Программисты должны быть способны объяснить последствия решений, принимаемых другими людьми. Например: В этом куске кода ты нарушил принцип инкапсуляции, и в результате у меня возникли проблемы. Программисты должны быть способны говорить друг другу о проблемах в коде. Они должны быть способны свободно и без стеснения рассказать о своих страхах и в ответ получить поддержку. Они должны быть способны с легкой душой сообщать заказчикам и менеджерам плохие новости. Они должны делать это как можно раньше, и их не надо за это наказывать.
Если я вижу, как кто-то, прежде чем ответить на мой вопрос, оглядывается вокруг, чтобы посмотреть, кто его слышит, я воспринимаю это как серьезную проблему всего проекта. Если обсуждаются личные вопросы, я, конечно же, понимаю необходимость некоторой конфиденциальности, однако вопрос о том, какую из двух объектных моделей использовать, не должен быть тайной за семью печатями.
Работа в соответствии с человеческими инстинктами, а не вопреки им – люди любят выигрывать. Люди любят учиться. Люди любят взаимодействовать с другими людьми. Люди любят быть частью команды. Люди любят управлять. Люди любят, когда им доверяют. Люди любят хорошую работу. Люди любят, когда разрабатываемая ими программа отлично работает.
Пол Чисолм (Paul Chisolm) пишет:

Я был на совещании, на котором один так называемый менеджер контроля качества предложил добавить шесть дополнительных полей в состав HTML-формы, и без того заполненой данными, которые к тому же редко когда использовались. Этот самый менеджер объяснил, что добавление новых полей необходимо не потому, что данная информация окажется полезной в дальнейшем, а потому, что дополнительные поля позволят СЭКОНОМИТЬ ВРЕМЯ. Моя реакция была следующей: я ударил лбом о твердую поверхность стола, за которым проводилось совещание, прямо как мультипликационный герой Warner Brothers, который только что услышал что-то невероятное. После этого я попросил их перестать мне лгать. На сегодняшний день я не знаю, был ли это наименее профессиональный или, наоборот, наиболее профессиональный поступок в моей жизни. Однако мой глазной врач сказал мне, чтобы я больше не стучал головой о стол, так как при этом сетчатка в моем глазу может отсоединиться от глазного дна.
Пол Чисолм (Paul Chisolm). Источник: электронная почта.
Это достаточно сложно – разработать процесс, в рамках которого краткосрочные личные интересы служат долгосрочным интересам всей команды. Вы можете сколько угодно рассуждать на тему, насколько та или иная методика способствует достижению долгосрочной всеобщей цели, однако как только вы оказываетесь под давлением, вы обнаруживаете, что если методика не способствует решению конкретной проблемы, стоящей перед вами в настоящий момент, вы отбрасываете ее в сторону. Если дисциплина ХР не будет удовлетворять краткосрочным личным интересам людей, она обречена на провал.
Некоторым в ХР нравится именно то, что эта дисциплина создает у программистов ощущение, будто они занимаются именно тем, чем они занимались бы, если бы их никто не заставлял специально заниматься той или иной проблемой. При этом ХР обеспечивает общее развитие проекта в заданном направлении. Мне запомнилась одна образная цитата: ХР соответствует поведению программистов в условиях дикой природы.
Принимаемая ответственность – ничто не может так повредить работе отдельного человека или всей команды, как жесткое указание, чем именно они должны заниматься. Это особенно справедливо, если то, что предлагается сделать, сделать невозможно. Люди работают эффективнее, только если они чувствуют, что занимались бы этой работой, даже если бы никто их к этому не принуждал. Если человеку приказали выполнять некоторую не устраивающую его работу, в ходе своей деятельности он сможет найти множество способов объяснить свое нежелание и несогласие с этим. Все это пагубно повлияет как на его собственную деятельность, так и на деятельность всей команды.
Альтернативой этого является ответственность, которая не вешается на человека в приказном порядке, а принимается им добровольно. Это не означает, что вы всегда занимаетесь только тем, чем вам нравится заниматься. Вы являетесь частью команды, и если команда придет к выводу, что некоторая задача требует решения, должен найтись человек, который возьмется за это вне зависимости от того, насколько отталкивающей для него будет эта задача.
Локальная адаптация – вы должны адаптировать то, о чем вы читаете в данной книге, к своим локальным условиям. Это является применением принципа принимаемой ответственности к используемому вами процессу разработки. Адаптация ХР не означает, что я должен сказать вам, как вы должны разрабатывать программный продукт. Это означает, что вы должны самостоятельно определить, как вы должны разрабатывать программный продукт. Я могу рассказать вам лишь о том, какие методики я проверил на собственном опыте и при этом убедился, что они неплохо срабатывают. Я могу сообщить вам о возможных последствиях в случае, если вы отклонитесь от использования предлагаемых мною методик. В конце концов, это ваш собственный процесс разработки. Сегодня вы должны определить, как он будет происходить. Вы должны убедиться в том, что принятые решения будут исполняться и завтра. Вы должны модифицировать этот процесс и адаптировать его. Вы не должны думать так: Теперь я знаю, как следует разрабатывать программы. Вместо этого вы должны сказать себе: Я должен обдумать все это, а затем уже приступать к программированию. Да, вы должны, но это того стоит.
Путешествие налегке – вы не можете нести с собой гору багажа и при этом двигаться быстро. Вы должны использовать в отношении своего багажа следующие наречия:
• немного;
• просто;
• ценно.
Члены команды ХР должны стать интеллектуальными кочевниками, в любую минуту готовыми быстро упаковать свои пожитки и следовать за пастухом. Пастухом в данном случае является дизайн, который развивается в ином направлении, чем это предполагалось ранее, или заказчик, который хочет развивать проект в ином направлении, чем это предполагалось ранее, или член команды, который решил уйти из проекта, или технология, которая подчас эволюционирует с головокружительной быстротой, или изменяющийся климат, в котором функционирует бизнес. Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56