Экстремальное программирование и быстрая разработка ПО

[Crash]

Частично методику тоже используем, так как там есть довольно дельные и полезные мысли.

[Grim]

Позвольте побыть злым языком, и испортить приятную беседу...

Для начала, терминология: рефРакторинг пришется с буквой р, а компромисный треугольник не стоит называть треугольником баланса.

Далее, ИМО вся теория ХР является утопией. Если сравнить ее, скажем, с тем же Msf получится, что ХР игнорирует огромное количество производственных моментов, на которые заостряет внимание Msf.
Например, ХР призывает иметь представителей заказчика прямо в цеху разработки. По моему это какой-то бред, и превращение работы неизвестно во что. В противовес, Msf предлагает иметь менеджера по взаимодействию с заказчиком. Задача этого человека (или отдела) есть представление интересов комманды у заказчика, и интересов заказчика в комманде - этакий двуликий человечек. Главное, чтобы он был объективен. Кроме того, должен быть отдел (или один сотрудник) по взаимодействию с конечными пользователями. Который реально и является законообразующим звеном, которое может сказать заказчику о неправильности его требований к проекту, на конкретном примере - отзывах пользователей о функциональности текущей версии.
Вывод:
ХР можно использовать в небольших колличествах, применяя некоторые моменты описанные в этой теории, но не переусердствовать. Хотя я лично всех бы от этого отговаривал.

[Crash]

Дык об этом то и речь, что использовать надо _то_, что _эффективно_ сработает на проекте в данном случае, а не тупо как баран следовать процессу, фанатично придерживаясь методологии и закрывая глаза на "узкие" места.
Частично используем и Msf, например, вся инфа должна быть доступна любому участнику проекта, да и много других частей, которые эффективно сказываеются на процессе.

[orika]

С Grim согласен. Не надо доводить до крайностей=) Но вот реальный пример из жизни, когда мы работали с заказчиком и его представители (конечные пользователи) 2-е недели прямо таки жили в нашем офисе я не забуду. Ибо сделана работа была раза в два быстрее и качественнее. А что касается одного посредника, так это хорошо если, как заметил Grim он адекватен...

[Dva]

А еще лучше когда разработчик сам является и заказчиком и паблишером :)
Многие наши проекты именно так и производятся, в этом случаи PM или гейм-дизайнер выступает в роли заказчика, главное что бы стандарты качества у этого человека были на уровне.
Любой посредник это замедление процесса, даже если он будет просто делать forward писем.

[Crash]

Сообщение от Dva

А еще лучше когда разработчик сам является и заказчиком и паблишером :)
Многие наши проекты именно так и производятся, в этом случаи PM или гейм-дизайнер выступает в роли заказчика, главное что бы стандарты качества у этого человека были на уровне.
Любой посредник это замедление процесса, даже если он будет просто делать forward писем.

IMHO, не совсем корректно. Иначе бы не вводили playtest'ы, на которых проверяется корректность выполнения требований конечных пользователей (заказчика). В MSF даже объект такой в команде есть, который собирает эти требования и совместно с разработчиками улучшает продукт. Все это, IMHO, :). Но еще раз подчеркну, игру делаем для пользователей, а в данном случае, PM и геймдизайнер не могут являться абсолютным носителем верного видения результата проекта, они могут иметь свой очень субъективный взгляд, что внесет в проект серьезные риски. Еще раз, все это IMHO ;).
С наступающим!

[Dva]

Playtest-ы конечно присутствуют, вопрос в другом, MSF это хорошо,
но мобилные реалии таковы что над проектом работают 3-5 человек и поэтому одному человеку приходится играть разные роли, художник-гейм-дизайнер, pm-внутр заказчик-внештатный тестер и т.д. =)

[Crash]

Ахха, помогают _очень_, сразу видим, что модифицировать придется или внести в "learning curve" :). Дешево и полезно.