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