2 _ChaiNik:
Кто-нибудь пользовал eXtreme Programming в чистом виде? Было бы интересно узнать мнение как оно на российской почве приживается и в сикульных проектах...

Вообще не важно к каким проектам применять экстремальное программирование или XP, это касается не только софтовых проектов, также это могут быть любые технические/инженерные проекты в к-рых что-либо поэтапно создается командой людей. Что же касается XP для создания софта, то сам автор идеи XP - Кент Бек по его словам разочаровался в своем детище

Обсуждение достоинств и недостатков XP, в том числе о групповом программировании, рефакторинге можно посмотреть в том числе здесь: www.xprogramming.ru и здесь: www.xprogramming.com

Одно время XP обсуждалась многими (аналитиками, программистами и рук.проектов) на конференции Yahoo CASE-Tools
- основное мнение: у XP как у подхода есть достоинства, но и очень много недостатков, в т.ч. постоянно "переделывание" кода и отсутствие гарантированного качества кода, "безответственность" участников XP проекта, удовлетворение любых потребностей заказчика. Несмотря на то, что XP продолжает развиваться она не является серьезным конкурентом таким признанным и провереным методологиям/подходам по созданию софта как RUP, ICONIX, PJM, SSADM, ADM, MSF даже в если их брать и в урезанном варианте для небольших комманд

2 1024:
Белые книжки от микрософтпресс для экзамена 70-100, рекомендую. Описано примерно то же самое, тока утверждается что это микрософт придумала.

MS по-мойму не имеет никакого отношения к XP. Не путаешь с MSF?

2 1024:
Скока я про то и то не читал, вроде одно и тож тока разными словами.

На самом деле они разные хотя и об одном - эффективно создавать ПО, но IMHO и тот и тот - "уродцы" недоделанные, поскольку создавались не гигантами мысли вроде Йордана-Демарки или Тройки друзей, а программистами, к-рые решили слегка у себя порядок навести, а заодно и велосипед изобрести снова . Поэтому XP - примитивна до безобразия и немощна для чуть-чуть уже серьезных проектов, а MSF вообще не методология строго говоря, а процесс производства ПО в виде набора инструкций (типа "нарисуй схему взаимодействия компонентов, напиши код, оттестируй все это сначала по отдельности, а потом вместе") и иструментов (VS)

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

А кто говорит, что она недельная? Просто все относительно.
Далее: то, что я сказал не противоречит наличию обязанностей/ролей участников, да - там расписан процесс и участники. Другой вопрос что MSF не детальная, она не затрагивает всех аспектов "от и до" по сравнению, например, с тем же RUP, у к-рого есть поддержка всего жизненного цикла от бизнес-анализа (он самый настоящий и с 2 ролями, а не так как у MSF - "investigate and analyze all business needs" и все, а что за этим скрывается?) до поддержки ПО (адаптивной,инкриментой). Вдобавок тот же RUP, например, официально признан SEI как удовлетворяющий CMM level2,3, а MSF нет насколько мне известно, т.е у MSF нет планирования и контроля качества, их надо как-то дополнительно притягивать за уши

2 _ChaiNik:
На самом деле меня интересуют вполне конкретные вещи. Я начинаю проект в котором команда будет состоять из одного человека - меня :). И уже на этапе составления ТЗ (на который по идее надо потратить значительное время), начинаю склняться к системе заявок XP. В первом приближении методы XP кажутся приемлемыми для такого рода проектов.

На самом деле любая корректная и самодостаточная методология или процесс в принципе хорошо подходят как для больших, так и для маленьких проектов, тот же RUP, те же SSADM или MSF.
Например, есть известная статья "A Software Development Process for a Team of One" (рус: "Проект одного человека на неделю") Статья эта может не очень дельная, а скорее эдакая типичная поучительная американская сказочка для разработчиков, но центральная мысль там правильная : даже маленькому проекту из одного человека нужен процесс/методология, а также CASE-средства для осуществления этого процесса. Намек есессно делается на RUP, к-рый как утверждается самой Rational годится и для одного человека.
Это правда: где-то 3 года назад, когда я уже был достаточно знаком с основными продуктами Rational, с одним человеком мы - т.е всего вдоем решили реально выполнить проект "ОТ и ДО" по слегка урезанному RUP'98 (без БА и планирования) все ТОЛЬКО средствами Rational чтобы проверить это утверждение. Потрахались мы прилично, но не разачаровались, поскольку поняли, что одно дело знать отдельные фазы процесса (например, системный анализ или проектирование БД) и средства для них (Rose, Data Modeler и DelphiLink), а совсем другое знать полностью процесс, а главное следовать ему . Таким образом есть один недостаток, но существенный по сравнению с XP-подходом недостаток: требуются большие (для кого-то значительно большие) начальные затраты на изучение RUP (т.е прочтение и осознание, что и как надо делать) и средств Rational. Однако, даже XP требует изучения и следования ему. К чему это все? К тому, что лучше все сначала взвесить и понять стоит ли изучать и ради чего. Так что может лучше и не начинать пользовать XP, когда можно, например, использовать тот же редуцированный (reduced) или урезанный RUP, т.е просто выкинуть из него нек-рые стадии/фазы (как это обычно делается в России), например, тот же бизнес-анализ, или что-то еще к-рые просто вам не нужны, упростить планирование,
тестирование и т.д. Оставить, например, выявление требований/ВИ, сбор требований/ВИ, генерацию ТЗ по шаблону, получение моделей ВИ, анализа и проектирования приложения/БД, генерацию кода/DDL
Какие преимущества у такого подхода:

=> Использоваение процесса, к-рый признан SEI удовлетворяющим CMM и является признанным
де-факто стандартом производства ПО на основе ООАП-подхода (во всем цивилизованном мире,
включая и Россию). Хотя на самом деле ваш урезанный RUP не будет может даже удовлетворять
и CMM-2, но само использование и получение опыта использования RUP может серьезно пригодиться
и просто будет вызывать уважение, нежели использование XP

=> Использование средств Rational, к-рые автоматизируют и интергрируют (почти) все стадии
этого процесса RUP. Возможно также использование других средств, например, от тех же
Sybase, CA, Microsoft, TogetherSoft и тд. также с этим RUP.
С XP также можно использовать любые средства, но не понятно на основе чего их интергрировать,
т.е я не слышал о программном фреймворке для XP типа как есть для RUP - Rational Suite.

=> Наличие полноценной документации из одного источника - Rational как для процесса,
так и для средств ПО, а также море информации от сообщества пользующего RUP и продукты
Rational (статьи, форумы, обзоры, рассылки и тд и тп)

(Статьи по теме (на англ): Using the Rational Unified Process (RUP) Successfully for Small Development Projects ,
RUP and XP, Part I: Finding Common Ground , RUP and XP, Part II: Valuing Differences )

2 _JINX:
Я вот слабо знаком с RUP у меня сложилось мнение что это что то вроде набора инструментов с помощью которых можно вести любой процесс. (в том числе ХР) Я не прав?

Если строго, то это не так , хотя и от части верно. RUP = "Rational Unified Process" или "Унифицированнымй процесс Rational", а развернуто: "Унифицированный процесс производства/создания ПО" - это итеративный, инкрементный процесс создания ПО на основе ООАП (OOAD) , если дословно цитировать его последнее определение, т.е это процесс - т.е набор связанных деятельностей для создания ПО (хотя и это уже не совсем так, поскольку стадиями RUPа пытаются заменить даже бизнес-анализ). Следовательно ничего не мешает осуществлять RUP другими средствами, не от Rational, а например, от Microsoft или CA. Далее: Rational (Тройка друзьев) создала не только процесс, но и конечно софт под процесс - Rational Suite, к-рый автоматизирует и интегрирует все стадии RUP. Теперь: а почему бы не попытаться реализовать другой процесс , например, XP или тот же SSADM c помощью Rational Suite ("RUP")? Отчего ж нельзя, можно! Вот так и родилось заблуждение, распространяемое неграмотными ИТ-авторами особенно российскими, к-рые ставят знак равенства между "процессом" и "средствами для процесса". Конечно, не обошлось и без самой Rational, усердно толкавшей в массы лозунг: "Говорим RUP, подразумеваем Rational Suite!" и наоборот ;)

(Краткая статейка: What is the Rational Unified Process? )

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

Без рекламы не обойтись - любой идее или технологии нужен промоушен. Однако, следует уметь отделять зерна от плевел. Тогда все встанет ясно. Далее: какое-то странное и однобокое понимание, что XP или другая методология/процесс создания ПО - это командная работа и только. Командная работа - это вообще из области менеджмента или психологии, а то что в XP как в подходе упор делается именно на личностные взаимоотношения участников проекта, то это является его недостатком поскольку результат сильно зависит от т.н человеческого фактора

В 20 веке много чего сложного создавалось командами - те же самолеты в шарашках, ядерные бомбы и.т.п. Если почитать мемуары участников этих проектов, то там мы обнаружим все то же самое, что теперь "перекрестили" во всякие англоязычные аббревиатуры.

Наврядли можно обнаружить методологию в чьих-то мемуарах, намеки и идеи "как лучше" может быть, а вот методологию врядли, если только это не мемуары Росса или Йордана

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

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

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

Именно изобретения и есть, но отнюдь не новые. Вот, к примеру, структурным системным анализом занимался еще Тейлор, широко в промышленности он начал использоваться в 60-70-х гг. в США,Японии и Европе, стандартом (SADT/IDEF) стал в начале 90-х, в России о нем ученые мужи и экономисты знали давно, но он почти нигде не использовался и не используется широко до сих для того же реинжиниринга с целью оптимизации бизнесса, а японцы благодаря ему и Демингу с его управлением качеством получили в 70-х экономический бум и сейчас занимают лидирующие промышленные позиции в мире и дело здесь не только в японской психологии и трудолюбии. Так что одно дело изобрести технологию и совсем другое - чтобы она начала использоваться широко в отрасли, в той же ИТ-индустрии

2 Циничный Кот:
А у меня вопрос - кто-нибудь заморачивался созданием полноценного процесса автоматического тестирования и что из этого вышло???... Если не жалко - поделитесь, плиз...

Сей сабж очень интересен, но он очень большой. Может лучше в отдельный топик? Обсудим все от теории до практики как говорится ;)