В свое время я пытался разрабатывать программное обеспечение так, как будто у меня нет никаких эмоций, при этом я держался на некотором расстоянии от своих соратников. Это не было эффективным. Когда я говорю другим о том, что чувствую, и слушаю остальных, когда они говорят, что они чувствуют, весь процесс протекает более гладко. Методики ХР настолько далеки от того, о чем мы говорили и о чем мы слышали и с чем мы добивались успеха в прошлом, что вся методика ХР выглядит странно для тех, кто с ней раньше не сталкивался. Наибольшую сложность представляет противоречивость ХР. Когда я встречаюсь с очередным новым менеджером, я часто опасаюсь, что он воспримет то, о чем я говорю, как нечто радикальное, или безумное, или непрактичное. Однако я не знаю другого, лучшего способа разработки программного обеспечения, поэтому со временем я уже научился преодолевать в себе этот страх. Однако когда вы приступаете к объяснению сути ХР незнакомому с этой дисциплиной человеку, вы должны быть готовы к тому, что он отнесется к ХР достаточно жестко.
Небольшие проблемы могут привести к значительным эффектам. Проверки и балансирование ХР достаточно надежны, однако процесс может в некоторой степени варьироваться. При этом необходимо учитывать, что даже на первый взгляд незначительные вещи могут привести к значительным отклонениям. Когда мы работали над системой управления выплатами в команде Chrysler C3, у команды возникли проблемы с реализацией работы к сроку. Мы никак не могли добиться того, чтобы наши предварительные оценки совпадали с реальностью. В каждой очередной итерации мы каждый раз не успевали реализовывать одну или две истории. Для того чтобы определить корень проблемы, мне потребовалось три или четыре месяца. Я услышал, как кто-то говорит о синдроме первого вторника. Я переспросил, что это означает, и один из членов команды объяснил мне: Синдром первого вторника – это ощущение, которое возникает на следующий день после совещания, посвященного планированию очередной итерации, когда ты приходишь на работу, смотришь на свои истории и не представляешь себе, как можно реализовать все это за то время, которое было оценено как достаточное.
Дело оказалось в следующем. Изначально я описал процесс следующим образом.
1. Распределение заданий между участниками.
2. Оценка заданий участниками в индивидуальном порядке.
3. Перераспределение в случае, если кто-то оказывается перегруженным.
Однако команда захотела избежать третьего шага, в результате было предложено изменить процесс следующим образом.
1. Коллективная оценка заданий.
2. Распределение заданий между участниками.
Проблема заключалась в том, что связанная с задачей оценка не принадлежала человеку, принимающему на себя ответственность за выполнение этой задачи. Иными словами, получалось, что один человек (или команда в целом) решает, за какое время можно справиться с задачей, а другой человек вынужден работать над решением этой задачи, пытаясь успеть в заданный ему срок. В результате на следующий день исполнитель приходит на работу, смотрит на задачу и с ужасом думает: Разве можно справиться с этим за три дня? Я даже не владею всеми необходимыми для этого знаниями. Согласитесь, что это не самое продуктивное состояние для программиста. Таким образом, на каждую итерацию борьбы с синдромом первого вторника у каждого члена команды уходил день или два. Нет ничего удивительного в том, что они не могли достичь всех поставленных перед ними целей.
Я рассказал эту историю для того, чтобы проиллюстрировать, что небольшие проблемы во время проекта могут стать причиной значительных эффектов. Я не имел в виду, что вы обязаны делать все именно так, как описано в данной книге. Вы можете попробовать сформировать свой собственный процесс разработки. Но именно это и делает ХР сложной – если вы принимаете на себя ответственность за формирование собственного процесса разработки, значит, вы принимаете на себя ответственность за наблюдение за возникновением и решением разного рода проблем.
Управление проектами, основанное на незначительных отклонениях то в одну сторону, то в другую сторону, идет в разрез с традиционными методиками управления, основанными на предварительном планировании с последующим следованием жестко заданному плану. Именно такая дисциплина применяется в большинстве организаций. Финальная сложность, благодаря которой ХР-проект вполне может умереть, состоит в том, что управление проектом в соответствии с метафорой управления автомобилем совершенно неприемлема в рамках культуры производства, принятой во многих компаниях. Раннее предупреждение о проблемах рассматривается как признак слабости или как жалобы на жизнь. Если ваша компания потребует от вас действовать вопреки принципам, которые вы избрали для себя определяющими, вам потребуется храбрость.
Глава 25.
Когда не следует использовать ХР
Точные пределы использования ХР еще не до конца исследованы. Однако есть известный набор факторов, который делает применение ХР невозможным, – слишком большие команды, недоверчивые заказчики, технология, которая не позволяет легко и просто вносить изменения.
В рамках ХР используются методики, которые сами по себе являются неплохими вне зависимости от того, что вы думаете об общей картине. Вы должны применять их. Точка. Тестирование – хороший пример. Игра в планирование тоже, скорее всего, будет работать, несмотря на то что вы будете большее время тратить на формирование оценок и предварительное проектирование. Однако, как предписывает правило 20 на 80, существует значительная разница между применением всех методик и применением только некоторых из них.
Дисциплину ХР не следует применять абсолютно для любых проектов. При некоторых комбинациях времени, места, команды разработчиков и заказчиков проект ХР может лопнуть, как воздушный шарик. Очень важно не использовать ХР для таких проектов. ХР необходимо использовать там, где эта дисциплина обеспечивает реальные преимущества, и ее не нужно использовать там, где она может дать сбой. Именно этому и посвящена данная книга – прочитав ее, вы сможете решить, когда можно использовать ХР, а когда этого лучше не делать.
Я не буду говорить вам нечто вроде: Не следует использовать ХР для разработки программ управления стратегическими ракетами. Я никогда не разрабатывал программное обеспечение подобного рода, поэтому я не могу сказать вам, на что это похоже. Исходя из этого я не могу сказать вам, будет ли работать ХР в данной ситуации. Однако при этом я так же не могу с уверенностью сказать вам, что в данном случае ХР абсолютно точно не будет работать. Если вы занимаетесь разработкой программ для стратегических ракет, вы должны самостоятельно решить, подходит ли для вас ХР или нет.
Все же я достаточно часто сталкивался с неудачами ХР для того, чтобы рассказать вам о некоторых факторах, благодаря которым ХР совершенно точно не будет работать. Воспринимайте все, о чем я буду рассказывать, как перечень рабочих сред, о которых я точно знаю, что в них ХР работает не самым лучшим образом.
Самым большим барьером, стоящим перед ХР, является культура. Но не национальная культура, которая безусловно тоже немаловажна, а бизнес-культура.
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