Agile методологии получили большую популярность в IT сфере. Создана масса agile сообществ (www.agilerussia.ru, agiledev.ru, www.agilebelarus.org, www.agileukraine.org), разработаны разные методологии и техники Этим топиком я бы хотел начать дискуссию среди тех участников формуа, которые работают или работали в команде, где применялось экстримальное программирование. Вопрос очень простой, в чем вы видите плюсы этой методолгии и в чем минусы. Я бы хотел обратить внимание, чтобы каждый высказывающийся говорил только о том варианте XP который применялся в его/её команде, со всеми косяками и наоборот приятными неожиданностями.

Плюсы и минусы вытекают из величины проекта и команды. 
А так, вопрос слишком общий. Тут нужно рассматривать конкретные методы XP, например pair programming, continuous integration.

Royan, это всего лишь методология. поэтому не нужно ее возносить (как некоторые, до уровня религии)
она всего лишь помогает молодым командам избегать разных орг. обломов, и быть сосредоточенными на реально своих задачах.
т.е. если команда хорошо умеет ДУМАТЪ и РЕШАТЬ поставленные задачи, аджайл дает больше преимуществ 
1. клиенту/заказчику: возможность воздействовать на контракты и результаты, корректировать и т.д., чтобы избежать известной диаграммы "что хотел клиент, что понял меркетолог, что понял архитект, что понял тимлид, что сделал программист"
2. самой фирме на планерном уровне: несмотря на укороченные "тактические" предсказания (как времени так и человекочасов) - их точность довольно высокая. а стратегические предсказания имеют заранее известные границы, точнеет с опытом...

используемые практики ТРЕБУЮТ вышокого уровня от работников. напр. то же самое парное программирование: да, "2 головы лучше, чем одна".
но если обе головы ОЧЕНЬ маленькие, не всегда..
или постоянная интеграция: для нее надо еще и код написать ;-)




Это сообщение отредактировал(а) bilbobagginz - 25.2.2011, 07:23

Смысл парного прогр-я - обмен знаниями и как следствие более качественный код. Согласен, что эта методика не так эффективна для "ОЧЕНЬ маленьких голов", но все же к этому стремиться стоит. Покрайней мере, этот подход является основным в спортивном программировании, там где нужна максимальная эффективность.


Этот метод просто не работает для малых проектов (с низким уровнем сложности). Больше потеряете от внедрения, чем получите в итоге.


Не обязательно, пишите код после написания тестов:

в итоге получите Test Infected System   

можно все довести до абсурда  если очень хочется.
со временем уровень unit test-ов поднимается, т.к. начинаешь делать меньше низкоуровневой работы.
в итоге тебе надо принципиально меньше кода написать.
поэтому, даже если прировнять рабочий код по времени/величине к тестовому, 2*мало кода, получается меньше чем без теста и много низкоуровневого кода.
кроме того, при написании кода создается связка между планом и кодом.
это тоже важно. для думания на нужном уровне, с правильной терминологией....
(если оправдывает себя, конечно.)