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