XP - практика применения.

[_RVK_]

XP - практика применения.

Хотелось бы узнать об опыте пременения методологии XP среди разработчиков.
1. Применяете ли вы XP в своих проектах? Если нет то почему?
2. Какие из практик вы применяете, какие нет, почему?
3. Как проходил процес внедрения XP в вашем коллективе. Какие из практик внедрялись в первую очередь, какова переодичность внедрения новых практик.
4. Есть ли положительные результаты?
5. Какое время прошло от понимания необходимости применения XP до его внедрения.
6. Какие сложности были?

Вообще, больше хотелось бы узнать именно об опыте внедрения. С чего начинать, какие подводные камни и тд.

 

[Сергей123]

1. Не применяю или не знаю, что применяю. Потому что не дорос или потому что мне это не надо.

 

[_RVK_]

а что такое хр?

Экстремальное программирование

 

[filter]

2. Какие из практик вы применяете, какие нет, почему?

Если какая-либо из практик не применяется - это не XP,
так как эта методология базируется на взаимодополняемости всех практик.

Поэтому дальнейшие комментарии будут только об частичном внедрении некоторых практик

3. Как проходил процес внедрения XP в вашем коллективе. Какие из практик внедрялись в первую очередь, какова переодичность внедрения новых практик.

Внедрение практик XP у нас была исключительно инициативой программистов, поэтому удалось внедрить только то, что напрямую связано:
Coding standarts, Collective Ownership, TDD (unit + integration), Refactoring,Simple Design, Pair programming, Continous Integration

4. Есть ли положительные результаты?
Есть. Только положительные. По моих наблюдениях - улучшилось качество кода, продукты стали более предсказуемыми, легко модифицируемые. Из багтрекалки исчезли "тупые" баги.
Пропал страх перед внедрением новой функциональности.
Улучшилось настроение у начальства



6. Какие сложности были?
Одна глобальная сложность - понимаение комманды (программистов, менеджеров и клиентов) что это им необходимо. Если хоть у одного из этих звеньев понимания нет - работать сложно.

Например, у нас в команде были программисты, которые категорически не принимали новые подходы.
1) В парах отказывались работать
2) Тесты не хотели писать. Если и писали, то толку от этих тестов никакого не было.

Силой решить эту проблему нельзя.

Если в команде много новичков (по профессиональным качествам), то тоже сложно.

Менеджеры и клиенты должны понимать свою роль в этом процессе, так как меняется схема взаимодействия.

Вобщем попробовать внедрить стоит.

Очень хорошо все описано в книгах
Kent Beck "Extreme Programming Explained"
Kent Beck, Martin Fowler "Extreme Programming. Planning"

 

[_RVK_]

Если какая-либо из практик не применяется - это не XP

Да, конечно. Совокупность практик дает больший выигрыш чем каждая практика поотдельности. Но внедрять XP сразу при отстутствии опыта (или наставника с опытом) использование этой методологии сложно. И именно из-за неполного понимания необходимости у всех членов команды. Или вот еще сложность. В команде проекта 3 программиста. Со временем будет больше, но с Pair programming пока возникают сложности. Тем более что парное программирование наиболее эфективно в больших командах.

Очень хорошо все описано в книгах

Читаю сейчас
Кент Ауэр, Рой Миллер - Экстремальное программирование: постановка процесса. С первых шагов и до победного конца
и
Роберт К. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс - Быстрая разработка программ. Принципы, примеры, практика

 

[whirlwind]

>Если какая-либо из практик не применяется - это не XP,
так как эта методология базируется на взаимодополняемости всех практик.

Хотите сказать, что если я не кодирую в паре, значит у мя не XP?

Что такое XP - умение использовать прогрессивные технологии кодинга. Тесты - это TDD. Паттерны - это шаблоны типовых ситуаций. Рефакторинг - это оптимизация, которая может быть выполнена как до, так и после внедрения проекта. Насколько легко проект будет поддаваться рефакторингу, зависит от интуиции и опыта ведущего, а не от следования каким то канонам определенным какими то дядьками не имеющих ни малейшего понятия о наших задачах. Не надо ставить технологию самоцелью. Технология разработки должна облегчать работу, а не усложнять. И если нет понимания определенной технологии и нет в ее применении осознанной необходимости, не следует говорить - все, с завтрашнего дня у нас XP и ниипёт - а потом требовать от подчиненных невозможного.

ПС. И вообще каким боком тут менеджеры притулились, абсолютно не понятно. PM только ставит задачу, а с применением каких технологий она будет реализована - решает ведущий программист.

 

[filter]

И именно из-за неполного понимания необходимости у всех членов команды.

Понимание всеми принимаемых правил игры - главный фактор.

В команде проекта 3 программиста. Со временем будет больше, но с Pair programming пока возникают сложности.

Если сложность только в нечетном количестве - попробуйте устроить сессии. Скажем по 2 часа в день поработайте в паре.
Если профессиональный уровнь разный - то лучше, чтобы менее опытный кодировал, а более опытный наблюдал и руководил действиями. Но все действия должны согласовываться вместе, например как лучше реализовать какую-то часть функциональности в данный момент.
Кодер - реализовывает.
Наблюдатель смотрит за правильностью реализации и указывает на ошибки.

Тем более что парное программирование наиболее эфективно в больших командах.

В больших - это сколько человек?

 

[_RVK_]

В больших - это сколько человек?

у Кента Ауэра написанно чем больше тем эфективнее.

-~{}~ 10.02.06 13:50:

И вообще каким боком тут менеджеры притулились, абсолютно не понятно. PM только ставит задачу, а с применением каких технологий она будет реализована - решает ведущий программист.

Не согласен. Если менеджер выполняет роль заказчика, он должен играть по общим правилам, по крайней мере на этапе планирования.

-~{}~ 10.02.06 13:52:

Кстати ели в команде разработчиков 1 человек, использовать XP ему не суждено?

 

[whirlwind]

>Не согласен. Если менеджер выполняет роль заказчика, он должен играть по общим правилам, по крайней мере на этапе планирования.

Хз, хз. Мне еще не встречался ПМ, который вообще что то в программинге понимал. С ПМ обсуждается бизнес логика, как правило, но только в виде формул.

 

[_RVK_]

Мне еще не встречался ПМ, который вообще что то в программинге понимал

А это и не нужно. Одна из определяющих практик: Заказчик - член команды. Обычно роль заказчика играет Progect manager.

 

[filter]

Автор оригинала: whirlwind
Хотите сказать, что если я не
кодирую в паре, значит у мя не XP?

Именно такой тезис был в книге Кента Бека.

Что такое XP - умение использовать прогрессивные технологии кодинга.

XP это не набор слов, а все таки методология разработки ПО. А следовательно - это не только кодинг. У каждой методологии есть свои правила. XP имеет свои, достаточно гибкие. По сути дела - это объединение _конкретных_ практик.

Если Вы используете какие-либо практики XP и они у вас работают - супер, но вопрос тут подняли с точки зрения XP как методологии.

Насколько легко проект будет поддаваться рефакторингу, зависит от интуиции и опыта ведущего,

Опыта не только ведущего, всей команды. Каждый член команды имеет одинаковый доступ к коду.

Не надо ставить технологию самоцелью. Технология разработки должна облегчать работу, а не усложнять. И если нет понимания определенной технологии и нет в ее применении осознанной необходимости, не следует говорить - все, с завтрашнего дня у нас XP и ниипёт - а потом требовать от подчиненных невозможного.

Я именно это и говорил - понимание - главный фактор.

ПС. И вообще каким боком тут менеджеры притулились, абсолютно не понятно. PM только ставит задачу,

Таким образом, что как минимум PM должен понимать как происходит процесс разработки и следить за выполнением плана. + взаимодействовать с клиентом если требуется какая либо его коррекция.

а с применением каких технологий она будет реализована - решает ведущий программист.

Технологии мы тут не обсуждали.

 

[whirlwind]

>Обычно роль заказчика играет Progect manager.

ну дык и я о нем
ПМ = ProjectManager

Только каким боком _не_программисты_ относятся к XP (т.е. вообще к какой либо технологии кодинга) все равно не пойму. Видимо не дорос исчо

-~{}~ 10.02.06 14:11:

>Каждый член команды имеет одинаковый доступ к коду.
Но опыт у всех разный, не стоит об этом забывать.

>Технологии мы тут не обсуждали.
Ну если TDD нельзя назвать технологией разработки, то можете кинуть в меня камень.

 

[_RVK_]

whirlwind
советую почитать теорию я только начал вникать в XP, но мне еще до этого было понятно, что чем теснее связанны все действующие лица проекта, тем лучше.
PM контролирует процесс разрабротки, принимает решение о завершении задач, или изменении плана разработки. И он должен быть в курсе всего. Если программист говорит "Я не успею завершить задачу к заявленному сроку", PM должен четко понимать почему, а не верить на слово.

TDD это методология а не технология. Но в рамках XP это всего лишь состовная часть более общей методологии разработки. Камнями бросаться не буду

 

[filter]

>Каждый член команды имеет одинаковый доступ к коду.
Но опыт у всех разный, не стоит об этом забывать.

Вот тут этот минус восполняется парным программированием. Менее опытный кодирует - более опытный наблюдает.

>Технологии мы тут не обсуждали.
Ну если TDD нельзя назвать технологией разработки, то можете кинуть в меня камень.

Ок. Не правильно интепретировал ваше "технология". Но это не принципиально.

 

[whirlwind]

>TDD это методология а не технология

Технология — определённая последовательность действий для достижения желаемого результата; способ изготовления чего-либо. ...
http://ru.wikipedia.org/wiki/Технология

Методология - это учение о методах и средствах деятельности
http://ru.wikipedia.org/wiki/Методология

TDD = test -> code -> refactoring = определённая последовательность действий для достижения желаемого результата = технология.

По опреденлению, получить что-либо можно только используя технологию а методология - это не есть правило.

 

[filter]

Думаю продолжать дальше не имеет смысла. Пошла вода.

 

[romy4]

>1. Применяете ли вы XP в своих проектах? Если нет то почему?
частично. пока только вводится

>2. Какие из практик вы применяете, какие нет, почему?
shared resources (не знаю как точно по-русски) - владение кодом (модуля) более чем 1м человеком; пробовал 4 руки; экстримом множно назвать и работу по кол-ву времени от 2-3 часов в сутки и до 12 и более.

>3. Как проходил процес внедрения XP в вашем коллективе. Какие из практик внедрялись в первую очередь, какова переодичность внедрения новых практик.
методом проб и ошибок. да нет периодичности. все как-то в потоке

>4. Есть ли положительные результаты?
угу

>5. Какое время прошло от понимания необходимости применения XP до его внедрения.
не знаю. это с опытом пришло.

 

[syfisher]

>1. Применяете ли вы XP в своих проектах? Если нет то почему?

Что уже ввели:
* Коллективное владение кодом. До определенных пределов. Естественно крупные рефакторинги просто так новичками не проводятся. Стандарты кодирования - само собой.
* Парное программирование. Опять же таки - не для всего. В основном работа в паре ведется или для модификации фреймворка, или для обучения, или в новой, неизученной области.
* TDD (test-first, simple design, рефакторинг). Реальный качественный скачок в использовании тестов произошел около года назад. То есть после 1.5 лет применения. Возможно просто возросла квалификация.
* Приемочное тестирование для некоторых проектов.
* Практически нет дизайн-сессий. Убедились в их бесполезности уже давно. Конечно мы иногда обсуждаем подолгу какие-либо проблемы, но больших и подробных UML диаграмм больше не рисуем.

В настоящее время вводится Continous Integration. Пока только для фреймворка. Через некоторое время начнем и для проектов.

Наша беда в том, что мы заняты слишком мелкими проектами. Это обычные сайты, которые можно сделать и оттестировать максимум за 1 месяц. Очень тяжело себя убедить создавать приемочные тесты, например. Плюс к этому такое понятие, как заказчик на месте разработки - тоже не актуально. Единственным крупным начинанием является фреймворк, где мы и заказчики, и исполнители, и менеджеры.

То, чем мы занимаемся чистым экстремальным программированием назвать весьма сложно. Лучше сказать - что это часть Agile Development-а.

>3. Как проходил процес внедрения XP в вашем коллективе. Какие из практик внедрялись в первую очередь, какова переодичность внедрения новых практик.

Началось все в 2003 году. До этого читались вышеуказанные книги (и некоторые другие). Сначала внедрялось модульное тестирование, рефакторинг, владение кодом и т.д. Проблем было очень много. В статье в phpinside.ru некоторые из них я описал.

Где-то через 1.5 года мы доросли до понимания сути гибких методик. Теперь все это воспринимается намного спокойнее.

>4. Есть ли положительные результаты?

Повышение квалификации. Гибкий код. Более предсказуемая разработка.

>5. Какое время прошло от понимания необходимости применения XP до его внедрения.

Для меня важнее период от начала внедрения до пожинания плодов. Не менее 1 года.

Например, я лишь совсем недавно реально понял, что такое безопасные рефакторинги. Писать чистый код - это легко. Но как правильно выделять классы, ломать иерархии, да так, чтобы не ломать функционала всех системы в целом - вот это настоящее умение. Например, недавно закончил рефакторинг системы команд для одного из проектов. Это затронуло более десятка классов. Запускал дебаггер лишь пару раз.

 

[filter]

_RVK_

Наткнулся сегодня на интересную статью
http://www.gamesfromwithin.com/articles/0602/000104.html

 

[_RVK_]

По этому мини опросу можно сделать вывод что XP применяется далеко не всеми и большей частью не в полном объеме. Интересно почему?