Курский Форум

Экстремальное программирование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек (Kent Beck), Уорд Каннингем (Ward Cunningham), Мартин Фаулер и другие.

Основные практики XP

Двенадцать основных практик экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership)
Стандарт кодирования (Coding standard or Coding conventions)
(Programmer welfare)
40-часовая рабочая неделя (Sustainable pace, Forty hour week)

что думаете?
полная информация

А что тутъ думать… Она въ эл. виде есть? Дай почитать?….
Наскока я понялъ это книшка по управлению программерскими командами…

скинь плз на обменник

я не могу всю википедию скинуть

вот статья:

Парное программирование
Парное программирование означает, что весь код создаётся парами людей, программирующими одну задачу сидя за одним рабочим местом. Один программист контролирует машину и в основном думает над кодированием детально. Другой программист сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени люди меняются ролями.

Пары не фиксированы: рекомендуется «перемешивать» их насколько это возможно, так чтобы каждый знал что делает каждый другой, и все были близко знакомы со всей системой. Таким образом, парное программирование усиливает взаимодействие внутри команды.

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

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

Заказчик всегда рядом
«Заказчик» в XP — это не тот кто оплачивает счета, а тот кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

в ней не все аспекты раскрыты, есть ссылки на книги.

хорошо пишут… такое б в инстах преподавать

а кто там способен на преподавание такого?
и вообще кто там у вас щас преподаёт? есть люди которые в теле чего-то, что они почерпнули из полупублицистических кних на тему "программирования"?

А пачаму не можешь?

Anri писал(а):Заказчик всегда рядом

1 Итересно, это для узко специлизированой задачи или просто что бы знать за что платить?
2 А в книге рассмтроено удаленное програмирование (по сети)?

Нас короче пытались этому учить в колледже.
Но одно дело когда программисты делают проект,другое когда студенты из бывшего ПТУ *SARCASTIC*

!

на http://www.natahaus.ru есть в электронном виде, pdf.

Опять же небольшая ложка дёгтя:
Про экстремальное программирование пишут много. Большие компании им не пользуются, эта технология не для них. Малые компании пытаются вырасти до больших и стараются использовать методы, которые те используют. То есть не экстремальное программирование.
"Заказчик всегда рядом" - практически невыполнимое условие. Заказчик - тоже человек и у него есть _его_ работа.
http://exprogramming.ru/XPRules/UserStories.html

Поскольку наш продукт скорее коробочный чем заказной, то Заказчик для нас - это член команды который знает что надо сделать (роль сходная с Program Manager в Microsoft, или с Постановщиком Задач в советской схеме работы). Другими словами, если невозможно иметь реального Заказчика в своей команде - заведите человека, который будет играть такую роль.

В этом случае Заказчик будет субъективен, для более точной ясности проекта ему необходимо практически _постоянно_ контактировать с заказчиком. Опять же - практически не достижимое условие.
Парное программирование и Коллективное владение кодом.
Очень интересная штука, но не будем забывать, что мы находимся в России. А здесь каждый человек - Левша, но вот собери 20 Левшей, посади в комнату и попробуй заставить их что-то делать сообща. Думаете у них что-то получится? Нет.
Сразу же начнётся: а почему этот получает больше, ведь я целый день струячил, не поднимая головы, а он лишь сидел рядом молча.
Смысл в том, что в таких условиях разработки очень сложно правильно оценить работу каждого из сотрудников, не ущемив их собственную (как мне кажется врождённую) гордыню.

anonimous писал(а):В этом случае Заказчик будет субъективен, для более точной ясности проекта ему необходимо практически _постоянно_ контактировать с заказчиком. Опять же - практически не достижимое условие.

Не будет он субъективен. Я последние 5 лет по такой схеме работаю. Иногда этого "засланца" задушить хочится, но без него ни фига не выйдет нормальной работы, паскольку именно разработчик - самый предвзятый человек на свете. Он даже пытаясь тестировать просто подсознательно не делает 90% ошибок, которые видит и без тестов "засланец"

Залил указанную книжку в местные доки, кому интересно велкам

Модные идеи, не более того. Парное программирование - вообще бред. Как будто программист сидит и непрерывно пишет код, как если бы он просто текст набирал. Он может за день 2 строчки напишет, но таких, что целого дня стоят. А другой, значит, сидит и фтыкает в экран, на котором ничего не происходит. Не знаю, для кого это. В моей практике это никогда не применялось и надеюсь, не будет.
А заказчик рядом - это ж когда он есть! А если продукт коробочный, заказчиков нет. Да если и есть, как правило, его надо отлавливать, потому что у него свои дела.

snb писал(а):Модные идеи, не более того…

хде вы люди, работающие в комманде? *HOHO*