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

[singalen]

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

Comments

[johndegree.livejournal.com]

Помоему ХР есть не более чем попытка переложить риски проекта на заказчика. На больших проектах ХР смерть, маленькие-средние можно делать на коленке без всякой методологии при наличии в команде пары-тройки хороших специалистов.

[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]

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

[rioman.livejournal.com]

Внутрь лезть облом. ХР - это какое programming?

[singalen]

И этот человек когда-то занимался - начинал заниматься - программированием :)
Extreme.

[rioman.livejournal.com]

Иди на фиг ;)

Была у меня такая версия, но мало ли, что там имеется в виду.

[sanyok-ua.livejournal.com]

> Да, высшее умение делать дизайн и документацию, наверное, может состоять в том, чтобы работать без
> дизайна и документации. У Бека и Фаулера это может получаться. Может быть, это может получиться у нас.
> У начинающих это не получится в принципе: они не знают, как писать тесты, в какую сторону рефакторить.

Так будем их этому пытаться обучать.
Какие-то техники XP могут использовать новички, какие-то требуют определённой квалификации, и это - нормально. Вот если вся команда, кроме тебя, состоит из начинающих - это уже куже. Как писал Джоэль,
http://www.joelonsoftware.com/articles/fog0000000072.html,
===========
One of the most important things that made Microsoft successful was Bill Gates' devotion to hiring the best people. If you hire all A people, he said, they'll also hire A people. But if you hire B people, they'll hire the C people and then it's all over. This was certainly true at Microsoft. There were huge branches of the Microsoft tree filled with great people; these businesses were perennially successful (Office, Windows, and the developer products). But there were also branches that were just not as successful: MSN failed again and again and again; Microsoft Money took forever to get going, and Microsoft Consulting Services is full of airheads. In each of these cases it's pretty clear that a B leader built up a business unit full of C players and it just didn't work.
===========


> Игра в планирование

Делаем все вместе, новички смотрят и учатся. Когда-то наступит момент, когда 1) они внесут свои 5 копеек; 2) они примут активное участие

> Небольшие выпуски
> Метафора системы
> Стремление к простоте при проектировании
> Постоянное тестирование (модульное и приемочное)

Угу. Этому надо учить.

> Переделка кода (refactoring)

новички знают, что "в этом коде есть что переделать, есть такие задачи". Сеньоры переделывают. Новички смотрят на этот процесс с помощью:
> Парное программирование

> Коллективное владение кодом
> Частая интеграция
> 40 часовая рабочая неделя
> Постоянное присутствие клиента
> Единый стиль кодирования