Применяете ли вы Extreme Programming?

[_RVK_]

Применяете ли вы Extreme Programming?

Хочется получить некоторую статистику по этому вопросу, а так же понимание почему Extreme Programming не столь популярно(ИМХО) среди Web разработчиков.

 

[MiRacLe]

не применяю.
Я не готов программить в паре.
Заказчик(-и) не готов(-ы) получать проект по чайной ложке в час - хочется всё и сразу (с минимумом усилий со своей стороны)

 

[baev]

почему Extreme Programming не столь популярно

— по-моему, потому же, почему писательские дуэты можно «по пальцам пересчитать»

(ответил «Нет»)

 

[_RVK_]

Интересно, почему XP в первую очередь связывают с парным программированием и чем парное программирование всех так пугает?

 

[whirlwind]

Видимо вопрос применения XP можно рассматривать только в контексте конкретной задачи. XP легко проецируется на разработку фреймворка, но разработки на основе фреймворка как правило не настолько сложны и не нуждаются в таких подходах. ИМХО.

 

[_RVK_]

whirlwind
Согласен что 3-х дневные задачи выполнять парой глупо. В теории идет речь о 2-х недельных циклах. То есть минимальные сроки при которых XP эфективно 2 недели. Даже тестирование здесь ощутимого выигрыша не даст.

 

[ForJest]

Работа в паре гиперэффективна, по моему опыту. И по части производительности и по части обучения.
Точно также как рыцарь+оруженосец эффективнее чем просто рыцарь .
Вне зависимости от сроков проекта, 3 дня или 3 месяца. Два человека, работающие в паре создают больше чем два человека работающие по одному.

 

[_RVK_]

ForJest
Интересная позиция. Хочешь сказать что сайт, расчитанный на 3 дня 2 программиста в паре сделают за 1.5?

 

[zerkms]

отметил переключатель номер 2
считаю что безусловно удобный и продуктивный подход

 

[ForJest]

_RVK_
То что я хотел сказать я уже сказал, не больше и не меньше .

Я могу _предположить_, что скорее всего сайт, который ДВА человека делают за ТРИ дня работая каждый за своим компьютером, но работая над ним (этим сайтом) вместе, сделают этот сайт за ДВА дня, если будут работать в ПАРЕ.

-~{}~ 13.02.06 16:37:

Т.е. по-простому говоря, я _предполагаю_
2 человека 2 компьютера - 3 дня
2 человека, работа в паре за одним компьютером - 2 дня.

 

[Kelkos]

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

 

[Krisha]

Полностью поддерживаю ForJest.

Сам выбрал второй вариант, так как не всё и не всегда применимо для любой ситуации и придерживаться всех "правил" XP на 100% это было бы по-моему просто глупо.

Лично для меня основное правило XP - гибкость и еще раз гибкость во всех смыслах этого слова.

>> почему Extreme Programming не столь популярно(ИМХО) среди Web разработчиков.

По двум причинам:
1. Много понтов
2. Мало опыта

 

[syfisher]

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

 

[Alexandre]

Нет, но некоторые методики ХР хочу внедрить.
(это уже специфика фирмы )

 

[Krisha]

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

 

[syfisher]

Krisha Да так можно работать, если финансовые вопросы программистов не касаются. Но если нет - тогда любое изменение приводит к снижению прибыли от проекта.

 

[Krisha]

syfisher
Уточните, плиз, мысль. При чем тут финансовые вопросы и программисты ? И какие изменения приводят к снижению прибыли, не совсем понятно...

 

[syfisher]

Krisha
Есть проект, есть TЗ (допустим не слишком четкое), есть сроки и время. Для заказчика процесс создания проекта не выглядит как XP.

Допустим, мы решили работать по XP внутри. В качестве внутреннего заказчика - project manager. Итерации - для того, чтобы показывать прогресс реальному заказчику. Все нормально, но...

Далее заказчик меняет часть требований, PR их принимает и дает программистам команду. Затраты на проект возрасли, так? Сроки - тоже. Сумма - скорее всего нет! Кто отвечает за эту ситуацию? Конечно, если PR умеет грамотно защищать финансовые интересы команды - это очень хорошо. Если заказчик действительно заинтересован в проекте - он обязательно согласится на повышение стоимости проекта.

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

В чистом XP набор функционала принимается от заказчика на одну итерацию, для которой и рассчитывается сумма. Никаких изменений заказчик в функционал в рамках одной итерации не вносит. Закончили итерацию, заказчик посмотрел - оплатил. Далее опять собираемся вместе - набираем функционал на следующую итерацию, определяет стоимость - приступаем и т.д.

 

[amorfis]

Насчет парного программирования хочу замолвить слово.
Была задача написать модуль для одной системы. Писали в двоем за одним компьютером, прям как в одном из принципов ХР. Написали достаточно быстро и с первого раза, так как я замечал ошибки напарника, а он мои, что позволило хорошо съэкономить на отладке.
При этом параллельно с нами работал еще один человек. Ему понадобилось времени больше чем в 2 раза по сравнению с нами.
Так что ХР в некоторых случаях рулит.

 

[Krisha]

Автор оригинала: syfisher
Далее заказчик меняет часть требований, PR их принимает и дает программистам команду. Затраты на проект возрасли, так? Сроки - тоже. Сумма - скорее всего нет! Кто отвечает за эту ситуацию? Далее заказчик меняет часть требований, PR их принимает и дает программистам команду. на проект возрасли, так? Сроки - тоже. Сумма - скорее всего нет!

В случае изменений требований заказчиком В ЛЮБОМ случае происходит пересмотр сроков и стоимости - это ВООБЩЕ не имеет отношения к тому, в каком стиле ведется разработка. Если же изначально такое не было оговорено с заказчиком, то PM, простите, мудак полный и гнать его в шею.

Более того, в классической форме планирования если меняются требования, то каскадно проходим следующие этапы:
изменение требований->анализ требований в связи с изменениями->составление списка необходимых работ по внесению изменений в уже разработанный функционал->составление списка необходимых дополнительных работ->внесение изменений в календарные планы проекта->оценка или переоценка трудозатрат->принятие решения о продолжении или приостановке проекта (перечислено не всё, но основное). Это и есть итерация для заказчика. Внутри же команды такие итерации можно дробить на гораздо меньшие.

К тому же, нормальный ПМ никогда не будет объемный проект вести единым безостановочным процессом. Обычно все проектные работы разбиваются на части и ни один нормальный заказчик не платит всю сумму сразу, а соглашается на поэтапный вариант.

-~{}~ 14.02.06 17:46:

Но это мы уже ударились в вопросы планирования, а начали с вопросов ведения процсса разработки