Кент Бек - Экстремальное программирование
Вард Каннингхэм (Ward Cunningham) рассказывал мне о книге, посвященной освоению техники горнолыжного спуска. Эта книга называлась The Athletic Skier (Лыжник-спортсмен). Половина книги была посвящена настройке и подгонке горнолыжных ботинок таким образом, чтобы вы уверенно стояли на лыжах, чувствовали склон и поддерживали равновесие во время спуска. После этого в книге говорилось: Однако после того, как вы выполните 80% всех этих упражнений, вы улучшите вашу ситуацию лишь на 20%. Далее объяснялось, что существует огромная разница между состоянием равновесия и состоянием потери равновесия. Если вы немножко не в равновесии, это может означать, что вы полностью потеряли равновесие. На это влияет огромное количество факторов, например качество настройки ваших горнолыжных ботинок. Если хотя бы один из них настроен неправильно, значит, вы потеряете баланс. По мере того как вы учитываете в своей подготовке все большее количество факторов, ситуация будет очень медленно улучшаться. Однако когда вы внесете в свою подготовку несколько самых последних изменений, вы получите существенные, кардинальные улучшения вашей техники спуска.
Я думаю (и это просто моя гипотеза), что подобное положение вещей имеет место и в отношении ХР. Методики и принципы ХР работают вместе друг с другом, и в результате получается сила, которая действует сильнее, чем сумма составляющих ее частей. Вы не просто выполняете тестирование, вы тестируете систему, которая должна быть простой, и при этом система становится простой благодаря тому, что вы программируете в паре и ваш партнер следит за тем, чтобы вы должным образом перерабатывали код, напоминает вам о том, что вы должны писать больше тестов, и одобрительно хлопает вас по плечу, когда вы избавляетесь от излишней сложности кода, и...
Тут возникает дилемма. Не является ли ХР вещью из разряда все или ничего? Должны ли вы обязательно следовать каждой из входящих в ХР методик или вы рискуете не заметить вообще никаких улучшений? Вовсе нет. Вы можете получить заметное увеличение продуктивности, даже если вы будете использовать только часть методик ХР. Однако я подозреваю, что вы сможете получить гораздо больше, если вы будете по максимуму использовать все методики в комплексе.
Глава 24.
Что делает ХР сложной?
Несмотря на то что отдельные методики без труда могут исполняться обычными программистами в индивидуальном порядке, соединение всех кусков воедино и поддержание их в этом состоянии – далеко не простая задача. Сложной ХР становится в основном из-за эмоций, в особенности из-за страха.
Когда люди слушают то, что я им рассказываю об ХР, они говорят: То, о чем ты рассказываешь, кажется таким простым! Да, это действительно очень просто. Не надо обладать ученой степенью в области компьютерных наук для того, чтобы участвовать в ХР-проекте (в действительности ученая степень частенько является одним из серьезных мешающих факторов).
ХР очень проста в своих деталях, однако ее сложно реализовать на практике.
Повторю это снова. ХР легко понять, но сложно реализовать. Именно так. Методики, составляющие ХР, может изучить каждый, кто занимается программированием. Это несложная часть работы. Сложная часть – это собрать и поддерживать в состоянии баланса. Отдельные составные части ХР поддерживают друг друга, однако существует множество проблем, опасений, страхов, событий и ошибок, которые могут вывести процесс из состояния баланса. Причина, по которой вам приходится жертвовать наиболее технически опытным членом команды, чтобы он исполнял роль инструктора, состоит в том, что задача поддержки процесса в состоянии баланса – это очень непростая задача.
Я не хочу пугать вас. Я не хочу пугать вас больше, чем это необходимо. ХР может с успехом применяться большинством команд, занимающихся разработкой программного обеспечения. (Исключения рассматриваются в следующей главе.) Я хочу рассказать вам о некоторых моментах, показавшихся мне сложными, когда я применял ХР в отношении моего собственного кода, равно как и когда я инструктировал команды, решившие внедрить у себя ХР. Я не хочу нагонять на вас излишний страх, но когда переход к ХР будет для вас сложным (а я вам обещаю, что такие моменты будут), вы должны знать, что вы не одиноки. Сложности у вас возникают потому, что то, чем вы занимаетесь, – это сложно.
Сложно делать вещи простыми. Это звучит неправдоподобно, но иногда проще сделать что-нибудь более сложное, чем сделать что-нибудь простое. Это особенно верно, если в прошлом вы долго и успешно делали сложные вещи. Умение видеть мир в самых простых терминах – это очень сложное умение. Проблема состоит в том, что вы должны изменить свою систему ценностей. Вместо того чтобы восхищаться тем, как кто-то (например, вы) добивается функционирования чего-либо сложного, вы должны научиться относиться к сложности с презрением и не успокаиваться до тех пор, пока вы не добьетесь тех же самых результатов от более простой системы.
Сложно признавать то, что вы чего-то не знаете. ХР – это дисциплина, которая основана на предположении, что вы можете работать не быстрее, чем вы можете получать важную информацию, то есть обучаться, поэтому освоение ХР может быть для вас персональным испытанием. А если вы обучаетесь, это означает, что до этого вы чего-то не знали. Сможете ли вы без каких-либо опасений и стеснений прийти к заказчику и попросить его объяснить вам то, что для него является простейшей, элементарнейшей концепцией? Сможете ли вы без опасений и стеснений обратиться к вашему партнеру по паре и сказать ему, что существуют некоторые тривиальные, базовые сведения об информационных технологиях, которые вы, откровенно говоря, недостаточно хорошо изучили в школе. Или, может быть, просто забыли.
Сложно взаимодействовать с соратниками. Вся наша система образования ориентирована на индивидуальное продвижение вперед. Если вы работаете над проектом не один, учитель называет это жульничеством, подсказкой и нечестностью и наказывает вас. В большинстве компаний система вознаграждений основана на индивидуальных оценках и повышениях (часто такую систему называют игрой с нулевой суммой), а это тоже стимулирует индивидуальное мышление. В рамках ХР вы должны оттачивать свое мастерство благодаря помощи ваших сотоварищей. Дисциплина ХР основана на тесном взаимодействии всех членов команды. Сложно разрушать эмоциональные стены. Гладкое течение проекта ХР основано на гладком выражении эмоций. Если кто-либо чувствует себя расстроенным или озлобленным и никому не говорит об этом, через некоторое время это сказывается на производительности команды. Мы привыкли отделять нашу эмоциональную жизнь от нашей деловой жизни, однако команда не может функционировать эффективно, если не будет происходить живого общения, если не будут подчеркиваться страхи, если не будет разряжаться гнев, если счастье не будет делиться между всеми членами команды.
В свое время я пытался разрабатывать программное обеспечение так, как будто у меня нет никаких эмоций, при этом я держался на некотором расстоянии от своих соратников. Это не было эффективным. Когда я говорю другим о том, что чувствую, и слушаю остальных, когда они говорят, что они чувствуют, весь процесс протекает более гладко. Методики ХР настолько далеки от того, о чем мы говорили и о чем мы слышали и с чем мы добивались успеха в прошлом, что вся методика ХР выглядит странно для тех, кто с ней раньше не сталкивался. Наибольшую сложность представляет противоречивость ХР. Когда я встречаюсь с очередным новым менеджером, я часто опасаюсь, что он воспримет то, о чем я говорю, как нечто радикальное, или безумное, или непрактичное. Однако я не знаю другого, лучшего способа разработки программного обеспечения, поэтому со временем я уже научился преодолевать в себе этот страх. Однако когда вы приступаете к объяснению сути ХР незнакомому с этой дисциплиной человеку, вы должны быть готовы к тому, что он отнесется к ХР достаточно жестко.
Небольшие проблемы могут привести к значительным эффектам. Проверки и балансирование ХР достаточно надежны, однако процесс может в некоторой степени варьироваться. При этом необходимо учитывать, что даже на первый взгляд незначительные вещи могут привести к значительным отклонениям. Когда мы работали над системой управления выплатами в команде Chrysler C3, у команды возникли проблемы с реализацией работы к сроку. Мы никак не могли добиться того, чтобы наши предварительные оценки совпадали с реальностью. В каждой очередной итерации мы каждый раз не успевали реализовывать одну или две истории. Для того чтобы определить корень проблемы, мне потребовалось три или четыре месяца. Я услышал, как кто-то говорит о синдроме первого вторника. Я переспросил, что это означает, и один из членов команды объяснил мне: Синдром первого вторника – это ощущение, которое возникает на следующий день после совещания, посвященного планированию очередной итерации, когда ты приходишь на работу, смотришь на свои истории и не представляешь себе, как можно реализовать все это за то время, которое было оценено как достаточное.
