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