XP и реальность

[singalen]

Размышляю об XP.
Читал матчасть - увы, не Бека, а Ауэра-Миллера. Много воды и улюлюкания, мало собственно технических методик.
Почитал мнение dz. Здраво, хотя и либо НЕМНОГО предвзято, либо, что более вероятно, это отзыв из другого мира, от более сложных информсистем, гораздо более требовательных к качеству и вообще стоящих в разы ближе к системному барьеру.
XP кодо-центрична и предназначена для людей, которые обожают кодировать, но при этом способны делать дизайн и держать его в голове/на карточках. XP не терпит дилетантов. Вкратце - без дизайна может обойтись тот, кто "и так, в уме" может сделать, покритиковать и передалать хороший дизайн.
Да, высшее умение делать дизайн и документацию, наверное, может состоять в том, чтобы работать без дизайна и документации. У Бека и Фаулера это может получаться. Может быть, это может получиться у нас. У начинающих это не получится в принципе: они не знают, как писать тесты, в какую сторону рефакторить.
И - что важно - это сработает на не очень больших системах. Предположим, объёмом кода до 20М и со структурой БД менее чем на 200-500 таблиц - в зависимости от таланта разработчиков. На таланте разработчиков и держится первый из пяти уровней технологической зрелости по CMM. Подчеркиваю, первый.
Интересные линки на комменты внутри статьи dz:
первый коммент
второй коммент

Comments

[singalen]

Со вторым согласен, первое не понял. Методологя XP, особенно при наличии школы работы по "тяжеловесным" методикам, будет работать как надо.
Можно составлять проектные документы (use cases, функциональные и нефункциональные требования) и получать на них подпись заказчика в самом начале работы. Да, такого я в теории XP не видел, но я себе не представляю - как можно без этого :)

[singalen]

Вернее, не "будет работать", а "может работать".
И milestones с проставленными датами, объёмами функциональности и рисками тоже будут подписаны заказчиком и исполнителем.
Собственно, это даже не разработка, а менеджмент, который вполне может осуществляться за пределами XP.
Вот и ответственность за риски от разработчиков никуда не делась.

[johndegree.livejournal.com]

1. Можно получить подпись заказчика под любым документом.
2. Всегда и в любой ситуации можно жоказать что заказчик не прав а исплнитель ангел и все сделал по требованию заказчика
Но... Ежели продукт не нужен рынку в том виде в котором он вышел, проект не может считаться успешным. Идея размежовываться на заказчиков и исполнителей достаточно ущербна, цель должна быть общей - успешный проект/продукт из успеха которого каждый извлечет свои выгоды.
По поводу спецификаций, в сэйле есть такая категория untouchable things, эти вещи нельзя задокументировать или описать, я пока еще не нашел ни одной методологии которая помогала бы оперировать с такими вещами как overall product impression, stakeholders product expectations etc. большинство методологий излишне симплифицируют процесс разработки и постановки забачи пытаясь втиснуть его в некие формальные рамки, расписать по шагам и дать инструкции для чайников, XP тут превзошла всех и вся.

[singalen]

Тогда давайте кое-что оговорим. Начнем с тех же "Пяти миров". Я специализируюсь по корпоративным информсистемам. Перечисленные вами нематериальности, как я понимаю, относятся к неблагозвучной категории "Ширпотреб". Поэтому мы несколько по-разному смотрим на процесс и результат.

Мы - техники. Нам противопоказано заниматься мистикой, мы должны решать поставленные задачи. Product impression может измеряться во времени отклика системы, каноничности сочетания цветов, проценте пользователей, интуитивно разобравшихся в интерфейсе в течение минуты, или количестве профессиональных художников, хорошо отозвавшихся о продукте - но критерий должен быть измеримым.

1. Можно получить подпись заказчика под любым документом - опровергаю примером. Вот документы: "Заказчик платить мне $100 000 просто так", "Заказчик платить мне $10 000 за программу hello-world", "Заказчик платить мне $10 000 за такую-то информсистему".
Если бы можно было регулярно проделывать трюк №1, мы бы тут не обсуждали всякую заумь.
2. Всегда и в любой ситуации можно жоказать что заказчик не прав а исплнитель ангел и все сделал по требованию заказчика - опять "не верю". Если заказчик не клинический идиот, конечно, тогда см. пункт первый.
Идея размежовываться на заказчиков и исполнителей достаточно ущербна - эта идея обусловлена системой разделения труда и частной собственности, соотв., ничего лучше у нас нет.
цель должна быть общей - успешный проект/продукт - вы о проценте от продаж для каждого участника проекта? Интересная идея, но на практике нецелесообразна.
большинство методологий излишне симплифицируют процесс разработки и постановки забачи пытаясь втиснуть его в некие формальные рамки, расписать по шагам и дать инструкции для чайников, XP тут превзошла всех и вся. - не надо валить всё на XP. Она во много раз менее формальна, чем прочие методики - MSF, RUP, IDEF, SSADM...
Именно тяжеловесные методики на порядки сильнее формализуют процесс разработки.
Вы против формализации процесса разработки вообще, даже такой лёгкой, как в XP?

[johndegree.livejournal.com]

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

Я не против формализации процесса но я чувствую что во всех этих UP/agile/IDEF/SSADM/etc чего то не хватает, поэтому уже во второй конторе впаиваю некий гибрид, работает не везде гладко но результат есть.

[singalen]

Ну, я стараюсь звездеть исключитеьлно технически обоснованно :)
А вы можете обучить джуниора тому, чего не хватает в UP/agile/etc так, чтобы он правильно делал это самое недостающее в ваше отсутствие?

[johndegree.livejournal.com]

Ну за полтора года одного человека вытащить на уровень удалось, ща рулит там пока я в командировке, пока удачно ;-)