| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > УП: Методологии > Плюсы и минусы agile методологий: XP |
| Автор: Royan 3.4.2009, 11:22 |
| Agile методологии получили большую популярность в IT сфере. Создана масса agile сообществ (www.agilerussia.ru, agiledev.ru, www.agilebelarus.org, www.agileukraine.org), разработаны разные http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods Этим топиком я бы хотел начать дискуссию среди тех участников формуа, которые работают или работали в команде, где применялось экстримальное программирование. Вопрос очень простой, в чем вы видите плюсы этой методолгии и в чем минусы. Я бы хотел обратить внимание, чтобы каждый высказывающийся говорил только о том варианте XP который применялся в его/её команде, со всеми косяками и наоборот приятными неожиданностями. |
| Автор: surlac 23.2.2011, 21:21 | ||
Плюсы и минусы вытекают из величины проекта и команды. А так, вопрос слишком общий. Тут нужно рассматривать конкретные методы XP, например pair programming, continuous integration. |
| Автор: bilbobagginz 25.2.2011, 07:20 |
| Royan, это всего лишь методология. поэтому не нужно ее возносить (как некоторые, до уровня религии) она всего лишь помогает молодым командам избегать разных орг. обломов, и быть сосредоточенными на реально своих задачах. т.е. если команда хорошо умеет ДУМАТЪ и РЕШАТЬ поставленные задачи, аджайл дает больше преимуществ 1. клиенту/заказчику: возможность воздействовать на контракты и результаты, корректировать и т.д., чтобы избежать известной диаграммы "что хотел клиент, что понял меркетолог, что понял архитект, что понял тимлид, что сделал программист" 2. самой фирме на планерном уровне: несмотря на укороченные "тактические" предсказания (как времени так и человекочасов) - их точность довольно высокая. а стратегические предсказания имеют заранее известные границы, точнеет с опытом... используемые практики ТРЕБУЮТ вышокого уровня от работников. напр. то же самое парное программирование: да, "2 головы лучше, чем одна". но если обе головы ОЧЕНЬ маленькие, не всегда.. или постоянная интеграция: для нее надо еще и код написать ;-) |
| Автор: surlac 25.2.2011, 18:21 | ||||||||
Смысл парного прогр-я - обмен знаниями и как следствие более качественный код. Согласен, что эта методика не так эффективна для "ОЧЕНЬ маленьких голов", но все же к этому стремиться стоит. Покрайней мере, этот подход является основным в спортивном программировании, там где нужна максимальная эффективность.
Этот метод просто не работает для малых проектов (с низким уровнем сложности). Больше потеряете от внедрения, чем получите в итоге.
Не обязательно, пишите код после написания тестов:
в итоге получите Test Infected System  |
| Автор: bilbobagginz 7.4.2011, 00:11 | ||
можно все довести до абсурда если очень хочется.со временем уровень unit test-ов поднимается, т.к. начинаешь делать меньше низкоуровневой работы. в итоге тебе надо принципиально меньше кода написать. поэтому, даже если прировнять рабочий код по времени/величине к тестовому, 2*мало кода, получается меньше чем без теста и много низкоуровневого кода. кроме того, при написании кода создается связка между планом и кодом. это тоже важно. для думания на нужном уровне, с правильной терминологией.... (если оправдывает себя, конечно.) |
