Лично я за.
Предлагаю вместе обсудить опыт применения XP (eXtreme Programming) на практике.
Уже более года, как я изучаю XP и пробую применять его принципы на практике.
Со своей стороны приведу комментарии к нескольким принципам.
Подключение заказчика (On-site Customer). Программа — это инструмент для решения определенных задач. Но кто, как не заказчик может лучше знать их специфику. А посему, подключим заказчика к процессу разработки. Пусть он будет под рукой когда программисту понадобится консультация, ведь потерянное время это его деньги. Пусть он будет в курсе событий и перестанет задавать вопросы типа: когда мы будем это иметь? Пусть он примет участие в принятии решений и разделив ответственность перестанет обвинять во всем программиста.
Небольшие релизы (Small Releases). Когда мы будем это иметь? Любой программист знает как сложно ответить на этот вопрос более менее точно. Оценить время на разработку релиза в целом очень сложно. Но вот если взять и разбить большой релиз на несколько маленьких, а задачи на каждый релиз детализировать до весьма небольших и легко прогнозируемых задач, то вполне можно не оплошаться с датой выхода релиза. В XP релиз состоит из 70-80 Итераций (Iteration), каждая из которых занимает 1-3 недели. Итерация реализует какую-то одну Историю Пользователя (User Story), которая является ни чем иным, как описанием некоей функции системы с точки зрения пользователя.
Не усложняйте проект (Simple Design). Зачем тратить время впустую, зачем делать то, что может никогда не понадобиться. Гораздо лучше оставить возможность расширения. Как это выглядит на практике? На мой взгляд в ОО программировании, существует лишь один безболезненный способ предусмотреть расширяемость — это реализовать наращиваемые сущности в виде иерархии классов. Например, если мы предполагаем, что в будущем некий набор операций может расшириться, то мы должны реализовать операции в виде иерархии классов, если же нет, то тогда можно использовать и стандартные типы или классы. В случае расширения все что нам надо, это добавить соответствующий подкласс.
Системная метафора (Metaphor). Системная метафора — это концепция системы, это используемая терминология, это платформа для общения между людьми, принимающими участие в разработке. Если уровень взаимодействия между людьми высок (а использование XP это предполагает), то системная метафора вам необходима как воздух.
Программируем вдвоем (Pair Programming). В основе этого принципа лежит сила общения. Хотя самому мне лишь изредка приходится работать в таком режиме (пока я не в силах это изменить ), доложу вам те приемущества, которые смог заметить:
— программист работает по 6 часов в день, и когда почти все это время он просиживает в одиночестве за компьтером — это утомляет, по-моему вдвоем гораздо веселей;
— взаимообучаемость;
— взаимозаменяемость;
— нет места халявщикам;
— и, как не странно, все это в итоге реально увеличивает производительность.
Начинай с тестов (Test-first Design). Тестирование — это не просто тестирование! Тест — это проект того кода, который мы собираемся написать. Как код будет использоваться? Именно на этот вопрос дает ответ тест. Кроме того, тест еще и прекрасная документация, не пресловутая спецификация, а живая, на примерах.
Рефакторинг (Refactoring). Совершенству нет предела, но хорошие идеи приходят не всегда и не сразу. Поэтому мы просто пишем код который выполняет то, что нам нужно. Если мы видим, что код можно улучшить, мы улучшаем его. Это и есть рефакторинг. Мы не сидим и не ждем вдохновения от бога, а просто делаем то, что на текущий момент является наилучшим вариантом. Завтра нас осенит и мы сделаем рефакторинг. Но надо иметь в виду, что без тестов рефакторинг может превратиться в геморрой.
Здравствуйте IT, Вы писали:
IT>Здравствуйте ChainSmoker, Вы писали:
CS>>Лично я за.
IT>Лично я не вижу ни одного против IT>А если сюда добавить правильную организацию внутри команды (тыпа MSF), то получится полная идилия
Если бы еще были конторы в которых все это практикуется...
Здравствуйте ChainSmoker, Вы писали:
CS>Лично я за. CS>Предлагаю вместе обсудить опыт применения XP (eXtreme Programming) на практике. CS>Уже более года, как я изучаю XP и пробую применять его принципы на практике. CS>Со своей стороны приведу комментарии к нескольким принципам.
CS>Подключение заказчика (On-site Customer). Программа — это инструмент для решения определенных задач. Но кто, как не заказчик может лучше знать их специфику. А посему, подключим заказчика к процессу разработки. Пусть он будет под рукой когда программисту понадобится консультация, ведь потерянное время это его деньги. Пусть он будет в курсе событий и перестанет задавать вопросы типа: когда мы будем это иметь? Пусть он примет участие в принятии решений и разделив ответственность перестанет обвинять во всем программиста.
CS>Небольшие релизы (Small Releases). Когда мы будем это иметь? Любой программист знает как сложно ответить на этот вопрос более менее точно. Оценить время на разработку релиза в целом очень сложно. Но вот если взять и разбить большой релиз на несколько маленьких, а задачи на каждый релиз детализировать до весьма небольших и легко прогнозируемых задач, то вполне можно не оплошаться с датой выхода релиза. В XP релиз состоит из 70-80 Итераций (Iteration), каждая из которых занимает 1-3 недели. Итерация реализует какую-то одну Историю Пользователя (User Story), которая является ни чем иным, как описанием некоей функции системы с точки зрения пользователя.
CS>Не усложняйте проект (Simple Design). Зачем тратить время впустую, зачем делать то, что может никогда не понадобиться. Гораздо лучше оставить возможность расширения. Как это выглядит на практике? На мой взгляд в ОО программировании, существует лишь один безболезненный способ предусмотреть расширяемость — это реализовать наращиваемые сущности в виде иерархии классов. Например, если мы предполагаем, что в будущем некий набор операций может расшириться, то мы должны реализовать операции в виде иерархии классов, если же нет, то тогда можно использовать и стандартные типы или классы. В случае расширения все что нам надо, это добавить соответствующий подкласс.
CS>Системная метафора (Metaphor). Системная метафора — это концепция системы, это используемая терминология, это платформа для общения между людьми, принимающими участие в разработке. Если уровень взаимодействия между людьми высок (а использование XP это предполагает), то системная метафора вам необходима как воздух.
CS>Программируем вдвоем (Pair Programming). В основе этого принципа лежит сила общения. Хотя самому мне лишь изредка приходится работать в таком режиме (пока я не в силах это изменить ), доложу вам те приемущества, которые смог заметить: CS>- программист работает по 6 часов в день, и когда почти все это время он просиживает в одиночестве за компьтером — это утомляет, по-моему вдвоем гораздо веселей; CS>- взаимообучаемость; CS>- взаимозаменяемость; CS>- нет места халявщикам; CS>- и, как не странно, все это в итоге реально увеличивает производительность.
CS>Начинай с тестов (Test-first Design). Тестирование — это не просто тестирование! Тест — это проект того кода, который мы собираемся написать. Как код будет использоваться? Именно на этот вопрос дает ответ тест. Кроме того, тест еще и прекрасная документация, не пресловутая спецификация, а живая, на примерах.
CS>Рефакторинг (Refactoring). Совершенству нет предела, но хорошие идеи приходят не всегда и не сразу. Поэтому мы просто пишем код который выполняет то, что нам нужно. Если мы видим, что код можно улучшить, мы улучшаем его. Это и есть рефакторинг. Мы не сидим и не ждем вдохновения от бога, а просто делаем то, что на текущий момент является наилучшим вариантом. Завтра нас осенит и мы сделаем рефакторинг. Но надо иметь в виду, что без тестов рефакторинг может превратиться в геморрой.
Я конечно прошу прощения за свою необразованность, но что такое eXtreme Programming и где можно про него почитать?
Лично я ничего против разумного использования такого подхода не имею.
Но очередной раз убеждаюсь, что для продвижения товара, технологии, идеологии и пр...
название — это самое главное.
В случае с "eXtreme Programming" — это очень хорошо видно.
На мой взгляд все эти рекомендации очень полезны, но по сути — ничего нового.
Зато слово "eXtreme" очень притягательно.
Оно и понятно. Всем нам хочется чего-то "экстремального"
В чистом виде XP плохо применяется при написании
1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
2. библиотек (нет заказчика)
3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте ChainSmoker, Вы писали:
DG>В целом я за, но есть несколько моментов.
DG>В чистом виде XP плохо применяется при написании DG>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP) DG>2. библиотек (нет заказчика) DG>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
Поддерживаю эти мысли.
Добавлю ещё, что в XP практически невозможно получить что-то фундаментальное и относительно-устойчивое (фреймворк, библиотеку компонентов) -- заказчиков нет.
DG>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
В этом я тоже согласен с вами.
XP -- техника, порождённая "низами", "верхи", как всегда, не хотят. Вот бы совместить приятное с полезным -- здорово бы было! :user:
Здравствуйте psc71, Вы писали:
P>Я конечно прошу прощения за свою необразованность, но что такое eXtreme Programming и где можно про него почитать?
Если коротко. XP — это методология программирования, состоящая из набора практик (слово практика выбрано не случайно, оно отражает практическую направленность принципов XP). Практики XP охватывают как процессы проектирования и кодирования программ, так и организацию процесса разработки в целом.
Насчет почитать. Русских ресурсов я не встречал, а из англоязычных могу отметить два следующих. http://www.extremeprogramming.org/ — здесь можно ознакомиться с приниципами XP. http://www.objectmentor.com/ — ну а здесь масса статей ведущих специалистов на тему XP и вообще о программировании.
Здравствуйте bkat, Вы писали:
B>Лично я ничего против разумного использования такого подхода не имею. B>Но очередной раз убеждаюсь, что для продвижения товара, технологии, идеологии и пр... B>название — это самое главное. B>В случае с "eXtreme Programming" — это очень хорошо видно. B>На мой взгляд все эти рекомендации очень полезны, но по сути — ничего нового. B>Зато слово "eXtreme" очень притягательно. B>Оно и понятно. Всем нам хочется чего-то "экстремального" ;)
Отчасти вы правы, в наше время, чтобы на что-то обратили внимание, надо это "продвигать".
Но боюсь, что хотя элементы "продвижения" наблюдаются и с XP, название это скорее отражает суть, чем является рекламным трюком.
XP означает программирование в экстремальных условиях, условиях где постоянно меняются как требования к программе, так и среда ее существования. Жесточайшая конкуренция требует с одной стороны, постоянно увеличивать функциональность, производительность и т.п. С другой стороны, идти в ногу с новейшими информационными технологиями, которые сегодня плодятся как кошки.
Кроме того, XP носит скорее эволюционный характер, чем революционный. Т.е. хотя есть кое-что полностью новое, многое адаптировано из уже существующего. Но главное — это акцентирование внимания на экстремальности сегодняшних условий.
Здравствуйте DarkGray, Вы писали:
DG>В целом я за, но есть несколько моментов.
DG>В чистом виде XP плохо применяется при написании DG>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
Согласен, что изменение интерфейсов наиболее затруднено. Но чем это припятcтвует применению XP?
DG>2. библиотек (нет заказчика)
Ну кто-то же будет их использовать. А значит будет если не заказчик-покупатель, то хотя бы заказчик-пользователь.
DG>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
Ну тут уж ничего не сделаешь — с pair programming придется расстаться. Но ведь остальное вполне применимо.
DG>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
Честно сказать, не вижу никакой связи между XP и техникой "программирования снизу" (или "сверху").
У XP свой акцент, это акцент не на "низ" или "верх", а на требования заказчика (не надо делать ничего кроме того, что надо заказчику). А в контексте требований заказчика, вы уже сами можете решать, как вам программировать, "снизу" и/или "сверху".
Из ваших постов у меня сложилось впечатление, что никто из вас особо не использовал XP на практике, а кто-то может и вообще плохо понимает что-это такое. И хотя я, в принципе, не вижу ничего против просветительской и агитаторской работы, но цель моя была иной — поделиться опытом.
Здравствуйте ChainSmoker, Вы писали:
CS>Здравствуйте bkat, Вы писали:
CS>XP означает программирование в экстремальных условиях, условиях где постоянно меняются как требования к программе, так и среда ее существования. Жесточайшая конкуренция требует с одной стороны, постоянно увеличивать функциональность, производительность и т.п. С другой стороны, идти в ногу с новейшими информационными технологиями, которые сегодня плодятся как кошки.
Изменение требований на проекте не имеет ничего общего с экстремальностью.
Это обычная практика и с этим просто нужно уметь жить.
Те команды, которые с этим не справляются, как правило имеют очень большие проблемы.
На мой взгляд, управление требованиями — это ключевой момент во всей разработке.
Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
Здравствуйте ChainSmoker, Вы писали:
CS>Здравствуйте DarkGray, Вы писали:
DG>>В целом я за, но есть несколько моментов.
DG>>В чистом виде XP плохо применяется при написании DG>>1. больших программ, которые нужно разбивать на модули (при введение модульности, появляется жесткий интерфейс между модулями, который припятствует применению XP)
CS>Согласен, что изменение интерфейсов наиболее затруднено. Но чем это припятcтвует применению XP?
Тем что XP говорит, давайте сначала сделаем это по простому, а как я зделаю, это просто, если у меня уже жестко прошит интерфейс.
DG>>2. библиотек (нет заказчика)
CS>Ну кто-то же будет их использовать. А значит будет если не заказчик-покупатель, то хотя бы заказчик-пользователь.
Но на этапе разработки, такого заказчика нет.
Вот возьмем класс CString, какой у него должен быть набор методов, как он должен быть устроен, насколько просто его надо реализовать и т.д. Даже наличие пары пользователей никак нам не поможет в реализации этого класса.
DG>>3. Разобщенность программистов (может быть вызвана чисто физическими причинами)
CS>Ну тут уж ничего не сделаешь — с pair programming придется расстаться.
Не только, тот же Кент Бек — делает очень большой акцент на то, что команда должна очень много общаться, и при говорит, что при отсутствии общения многие приемы из XP, начинают развалится... А какое может быть общение по e-mail-у.
CS>Но ведь остальное вполне применимо.
Я не говорю, что все не применимо, я говорю, что XP надо применять с оглядкой,
тот же тестинг, рефакторинг, "небольшие релизы" — я приветствую и использую,
"делать проще" — по мере возможностей (так библиочные вещи лучше делать функционально "замкнутыми", чем простыми — потом, их на много проще использовать, не надо помнить про частности реализации),
"подключить заказчика" — это хорошо, но на практике обычно сложно получается реализовать,
"системная метафора" — я скорее придерживаюсь подхода, что программа должна быть просто последовательна, а метафора — это уже вторично (так я видел жутко неудобные программы, использующие метафоры, так и удобные программы, которые не используют какие-либо метафоры, хотя, "программа под windows" — это уже метафора, а "консольная программа под unix" — это уже другая метафора.
"программирование в парах" — трудно реализуема на практике, т.к. добиться того, чтобы обоим людям было интересно(и продуктивно) работать в паре — очень сложно, т.к. равных людей не бывает, и в паре, обычно, более "активный"(умный, волевой) задавливает второго, которому остается только кивать гивой и иногда вставлять фразу: "а ты здесь забыл поставить точку с запятой"
DG>>В реальной жизни на проектах, которые не сами в себе, XP(как технику, "программирование снизу" надо совмещать какой-нибудь из техник "программирование сверху".
DG>>Техника "программирование сверху" дает скелет проекта, который не дает развалиться всему проекту и задает направление, в котором должен развиваться проект.
DG>>Этот скелет конечно не должен быть очень жестким и должен через определенные промежутки времени рефакторится
CS>Честно сказать, не вижу никакой связи между XP и техникой "программирования снизу" (или "сверху"). CS>У XP свой акцент, это акцент не на "низ" или "верх", а на требования заказчика (не надо делать ничего кроме того, что надо заказчику). А в контексте требований заказчика, вы уже сами можете решать, как вам программировать, "снизу" и/или "сверху".
Программирование сверху, предполагает, что у нас есть жесткий (более и менее) каркас, который мы заполняем, а XP (в чистом виде) — говорит, что не надо ни какого каркаса, ни надо ничего проектировать, а давайте сделаем первую версию, как можно проще (как у нас получится), потом еще что-нибудь добавим, а дальше, куда кривая вылезет, поэтому XP(опять же в чистом виде) очень плохо уживается с этапом проектирования.
Здравствуйте bkat, Вы писали:
B>Изменение требований на проекте не имеет ничего общего с экстремальностью. B>Это обычная практика и с этим просто нужно уметь жить. B>Те команды, которые с этим не справляются, как правило имеют очень большие проблемы. B>На мой взгляд, управление требованиями — это ключевой момент во всей разработке. B>Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
Но XP заявляет, что если следовать тем правилам, которые заложены в XP, то с проблемой изменения требований, команда столкнется в намного меньшей степени или не столкнется (именно, как с проблемой) вообще.
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте bkat, Вы писали:
B>>Изменение требований на проекте не имеет ничего общего с экстремальностью. B>>Это обычная практика и с этим просто нужно уметь жить. B>>Те команды, которые с этим не справляются, как правило имеют очень большие проблемы. B>>На мой взгляд, управление требованиями — это ключевой момент во всей разработке. B>>Если с этим есть проблемы, то проект тоже будет проблемным и никакой XP не поможет.
DG>Но XP заявляет, что если следовать тем правилам, которые заложены в XP, то с проблемой изменения требований, команда столкнется в намного меньшей степени или не столкнется (именно, как с проблемой) вообще.
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте bkat, Вы писали:
B>>А можно озвучить ключевые идеи этих правил?
DG>Дык, все те же самые.
DG>Подключение заказчика DG>Небольшие релизы DG>Не усложняйте проект DG>Системная метафора DG>Тестинг DG>Рефакторинг
Это не совсем правила. Это общие рекомендации.
Возмем, например, "Подключение заказчика".
Как вы его будете подключать? Как конкретно он будет участвовать на проекте?
Чтобы ответить на эти вопросы, нужны уже конкретные правила(процедуры),
которым следует команда разработчиков.
Самое сложное как раз выработать эти правила,
чтобы они действительно вели к реальному участию заказчика.
Можно очень активно общаться с заказчиком, и все же забыть о "мелочи",
которую он очень просил реализовать.
К чему я веду?
К тому, что XP и другие подобные методологии худо-бедно описывают цели,
но как к ним идти — это очень большой вопрос.
Вопрос к знатокам XP.
Имеются ли рекомендации по тому, как оценивать команду разработчиков,
на соответствие XP. Грубо говоря, хотелось бы почитать о методиках,
которые бы выдавали нечто типа:
— Команда Х выполняет требования XP на 100%;
— Команда Х выполняет требования XP на 50%;
Здравствуйте bkat, Вы писали:
B>Вопрос к знатокам XP. B>Имеются ли рекомендации по тому, как оценивать команду разработчиков, B>на соответствие XP. Грубо говоря, хотелось бы почитать о методиках, B>которые бы выдавали нечто типа: B>- Команда Х выполняет требования XP на 100%; B>- Команда Х выполняет требования XP на 50%;
Вот такого как раз нет, потому что я опять же напоминаю, что XP(в чистом виде) тоже не панацея, и ее надо комбинировать с другими типами разработки, а вот эта комбинация и есть субъективное дело команды.
), доложу вам те приемущества, которые смог заметить:
Если нам не помогут, то мы тоже никого не пощадим.
