http://rsdn.ru/poll/2383.aspx

Автор: strcpy
Дата: 16.06.09
Вопрос: Используется ли у вас на работе extreme programming со всеми его атрибутами: полным покрытием тестами, полным совместным владением кодом, регулярным парным программированием и пр.

Спасибо.

Здравствуйте, strcpy, Вы писали:

S>http://rsdn.ru/poll/2383.aspx

Автор: strcpy
Дата: 16.06.09
Вопрос: Используется ли у вас на работе extreme programming со всеми его атрибутами: полным покрытием тестами, полным совместным владением кодом, регулярным парным программированием и пр.

S>Спасибо.

Так про XP вроде уже решили, что оно того не стоит. Другое дело более иные agile методы. Скажем, скрам ещё шевелится.

N_>Так про XP вроде уже решили, что оно того не стоит.
А кто это решил?

N_>Другое дело более иные agile методы. Скажем, скрам ещё шевелится.
Судя по голосованию, срам конкретно пролетает — 2.9%

Здравствуйте, strcpy, Вы писали:

S>http://rsdn.ru/poll/2383.aspx

Автор: strcpy
Дата: 16.06.09
Вопрос: Используется ли у вас на работе extreme programming со всеми его атрибутами: полным покрытием тестами, полным совместным владением кодом, регулярным парным программированием и пр.

За всю свою практику, ни разу не видел команды, полностью вндерившей все 12 практик XP. Обычно внедряются 3-4 практики, после чего радостно рапортуется о "разработке по XP" или, того хуже, о "полной бесполезности XP на практике". Проблема в том, что XP, как методология, начинает положительно влиять на проект только в комплекте из всех 12 практик. Слово eXtreme в названии стоит совсем не зря. Практики eXtreme Programming это экстремальное развитие проверенных временем best practices программирования. XP устроена так, что каждая практика поддерживает другие, нейтрализуя их побочные эффекты. Например, коллективное владение кодом без парного программирования быстро вырождается в бардак. Игра в планирование не работает без заказчика onsite. Заказчик не согласится сидеть с командой, если у него не будет быстрой обратной связи. И т.п. В результате, XP можно полноценно внедрить только в очень ограниченном количестве проектов.

N_>>Другое дело более иные agile методы. Скажем, скрам ещё шевелится.
_>Судя по голосованию, срам конкретно пролетает — 2.9%
Ещё меньше, нужно обнулить тех, кто не голосовал или отшутился.

Здравствуйте, astral_marine, Вы писали:

N_>>Так про XP вроде уже решили, что оно того не стоит.
_>А кто это решил?

N_>>Другое дело более иные agile методы. Скажем, скрам ещё шевелится.
_>Судя по голосованию, срам конкретно пролетает — 2.9%

Вы правда полагаете, что это голосование реально что-то значит?

M>За всю свою практику, ни разу не видел команды, полностью вндерившей все 12 практик XP. Обычно внедряются 3-4 практики...

как с этим обстоят дела у нас в конторе:

• Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.

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

• Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Он пишет пользовательские истории, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

заказчик работает с нами в одном кабинете.

• Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры — крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования.

придерживаемся привил именования на интуитивном уровне

• Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Программисты в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое наипростейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время программиста.

сначала DTSTTCPW, затем refactoring

• Стандарты кодирования (coding conventions). Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Определение наиболее важных объектов стандартизации в XP субъективно.

Resharper

• Рефакторинг (refactoring). Рефакторинг — это оптимизация существующего кода в сторону упрощения, что предусматривает постоянную работу по упрощению кода. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг надо отложить.

с этим сложнее, порой совмещаем создание нового кода с рефакторингом старого.

• Парное программирование (pair programming) — одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.

около 40-50% времени

• 40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) — это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение — одно из основных правил.

сверхурочно не работает, скорее даже наоборот

• Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.

есть.

• Частая смена версий (small releases). Минимальная итерация — один день, максимальная — месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.

от 2 недель до 1 месяца.

• Непрерывная интеграция (continuous integration). Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это жесткое и однозначное — если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.

• Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP — одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test — тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности). Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты; любой программист имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.

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

N_>Вы правда полагаете, что это голосование реально что-то значит?
Значит.

Здравствуйте, Miroff, Вы писали:

M>Здравствуйте, strcpy, Вы писали:

S>>http://rsdn.ru/poll/2383.aspx

Автор: strcpy
Дата: 16.06.09
Вопрос: Используется ли у вас на работе extreme programming со всеми его атрибутами: полным покрытием тестами, полным совместным владением кодом, регулярным парным программированием и пр.

M>За всю свою практику, ни разу не видел команды, полностью вндерившей все 12 практик XP. Обычно внедряются 3-4 практики, после чего радостно рапортуется о "разработке по XP" или, того хуже, о "полной бесполезности XP на практике". Проблема в том, что XP, как методология, начинает положительно влиять на проект только в комплекте из всех 12 практик. Слово eXtreme в названии стоит совсем не зря. Практики eXtreme Programming это экстремальное развитие проверенных временем best practices программирования. XP устроена так, что каждая практика поддерживает другие, нейтрализуя их побочные эффекты. Например, коллективное владение кодом без парного программирования быстро вырождается в бардак. Игра в планирование не работает без заказчика onsite. Заказчик не согласится сидеть с командой, если у него не будет быстрой обратной связи. И т.п. В результате, XP можно полноценно внедрить только в очень ограниченном количестве проектов.

Интересно, есть ли известные проекты, написаные с посощью этой методологии?

Здравствуйте, Muxa, Вы писали:

M>манагеры после совещания с нами определяют для нас список задач для реализации на ближайшее время, мы оцениваем трудоемкость каждой задачи, после чего манагеры сортируют задачи по приоритетности и выставляют сроки под разработку каждой (список задач распланирован на полгода-год вперед).

Не понимаю, при чем здесь манагеры. В XP приоритет определяет заказчик и только заказчик. Он же решает в какую итерацию попадет фича. Сроки на фичу оценивают те, кто ее будет делать.

M>придерживаемся привил именования на интуитивном уровне
Метафора это немного не о том. Это скорее набор сущностей, которыми оперирует система. Метафора проходит через весь проект, от наименований классов до интерфейса. Например, в бухгалтерии есть счета, документы, проводки, планы счетов и т.п. В интернет магазине есть каталог и корзина. Это общеупотребительные метафоры. В других случаях внятную метафору придумать трудно.

M>с этим сложнее, порой совмещаем создание нового кода с рефакторингом старого.
Рефакторинг вообще не имеет смысла как отдельная активность. Только в качестве подготовки к внесению изменений. Потребовалось что-то поменять, сперва порефакторили, а затем поменяли но уже легче.

M>сверхурочно не работает, скорее даже наоборот
Пойнт не столько в сверхурочной работе, сколько в работе по расписанию в одно и то же время. Если графики не совкадают, парное программирование будет срываться.

M>от 2 недель до 1 месяца.
ИМХО, идеальный случай это взяли билд из системы continuous integration и его уже можно показывать/ставить.

M>а вот с тестами последнее время напряг.
M>нас осталось мало, а кол-во задач не уменьшилось, поэтому и огребаем иногда
О чем я и говорю. Отсутствие тестов отрицательно сказывается на рефакторинге. Сложно рефакторить, если не знаешь, оно работает или нет. Проблемы с рефакторингом скажутся на простоте дизайна. А там по нарастающей.

Здравствуйте, Nikolay_, Вы писали:

N_>Вы правда полагаете, что это голосование реально что-то значит?

его тоже проплатили? )