Читая дебаты у dz на тему ХР,
http://www.livejournal.com/users/dz/172061.html
http://www.livejournal.com/users/dz/170183.html
http://www.livejournal.com/users/dz/169843.html

захотелось написать о собственном опыте работе в ХР проекте и вынесенных оценках.

Я лично не являюсь рьяным противником или сторонником ХР. Выводы сделаны на основе одного конкретного проекта. Проект был интересен для меня в значительной мере возможностью посмотреть на ХР изнутри.

Проект.

Проект был (и есть) экспериментальный и успешный, организованный в одной команде в крупной конторе во Франции.

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

В качестве пользователя выступала отдельная команда спецификации (там ХР не было), которая занималась переводом с языка соединений и режимов на язык значений атрибутов объектов. Здесь от ХР отошли и спецификации они писали (иначе бы они просто балду пинали). В остальном они работали как клиент в схеме ХР, в режиме постоянного диалога.

Управление кадрами.

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

Как правило, численность проекта может меняться быстро и катастрофически. Сегодня в команде 10 человек, через месяц проект решат притормозить и сократить до 5. При ХР нет проблем выкинуть половину и затормозиться в 2 раза, а не совсем, потому что ушел дядя Вася, который был единственным специалистом в нашей подсистеме экспорта-импорта. Я понимаю, что по уму дядя Вася должен был оставить нормальную документацию. Но в реальной жизни (де факто) такого не происходит. Особенно, если это было разработано, когда надо результаты показывать (а это так почти всегда). Документация начальством к разряду результатов (опять же де факто) не причисляется.

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

Еще через 2 месяца, решат ускорить проект, расширят до 20 человек и захотят, чтоб эти 20 работали адекватно их численности. Эти изменения на практике (еще раз де факто) прогнозировать невозможно. Набрать готовых специалистов не получится, ибо в первую очередь в команду всучат мало-мальски пригодных людей, сокращенных из других проектов. Это корпоративная политика, иначе их некуда девать (уволить невозможно). Набор новых людей крайне запутан: решение о найме принимается на том уровне, где технических деталей программирования уже не понимают. Да и найти именно нужного специалиста (технологии программирования + предметная область) часто нереально.

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

Эффективность.

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

Это дало: быстрый (и главное беззатратный!) старт новых членов команды, моментальное распространения удачных приемов, трюков и т.п. Но как только возникала какая-либо нетривиальная архитектура (такое случалось лишь в нескольких уголках этой системы), машина начинала буксовать. С ходу, с нахрапа никто ничего не понимал, а во время парной работы знания об архитектуре от автора упорно никому не передавались. И дело было не в архитектуре и не в авторе (были разные подсистемы, разные решения и разные авторы), дело было в способе обмена информацией. В результате, все предполагаемые сроки задач, связанных с более сложными (структурно) частями летели, народ тупо разглядывал код и постоянно дергал автора, который и сам уже не помнил в деталях свою идею.

После вхождения всех в курс дела по моим оценкам эффективность падает не в 2 раза (за счет работы в паре), а раза в 3-4. Оставшись один (когда нас было нечетное число) я делал в 1,5-2 раза больше, чем наша пара. Из чего это складывается (или скорее множится) это падение производительности:

• В 2 раза, потому что двое вместо одного
• Время уходит на постоянную коммуникацию в паре, первый пилот (мы так называли роли) всегда объясняет второму, что и почему он делает.
• Время на несоответствие текущей (локальной) эффективности пилотов (а суммарная эффективность – по самому слабому):
• для него эта деталь очевидна, а мне надо детально объяснять
• наоборот, он тратит время на объяснение очевидных для меня вещей
• я с утра туплю, а он после обеда.
• Выигрыш за счет ошибок, замеченных вторым пилотом до тестирования или до окончательного кодирования алгоритма.

В сработанных парах потери меньше, но работа постоянными парами прекращает циркуляцию информации внутри команды.

Тестирование.

То, что мне понравилось, то, что я постараюсь применять в моих проектах, это глубокое унитарное тестирование.

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

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

И плюс к тому, глубокое тестирование дало возможность без страха заниматься постоянным редизайном и реинжинирингом кода. Если что-то было написано плохо – это переписывали, не трясясь над тем, сколько файлов или строчек кода при этом затронуто.

В результате, качество кода оказалось очень высоким.Код не деградировал со временем жизни проекта! Работа над улучшением кода стала нормой жизни, побочным процессом реализацией новых функций, который не проходил ни в каких планах.

То есть, код получается  супер (и по надежности и по правильности), но не оттого, что его вдвоем пишут. А оттого, что хотят и могут приводить его в порядок. Не не мусорят (вернее, не следят, чтоб другой не мусорил), а убирают.

К счастью, эта методика работает отделима от ХР и применима сама по себе.

Выводы:

ХР – схема сдерживаемого бардака. Мы не пытаемся организовать регулярную структуру, мы сдерживаем хаос в рамках. Эффективность получается низкая, зато предсказуемость высокая. Ползем медленно, но стабильно.

Физическая аналогия. Можно сделать систему синхронизированных источников. При «правильной» синхронизации мощность растет как квадрат их количества. Но результат сложно прогнозируем и капризен, можно и 0 получить на выходе. А можно сделать систему случайных независимых источников. Мощности просто складываются, постольку источники частично гасят друг друга. Зато просто и гарантированно.

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

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

ХР позволяет полностью удалиться из области управления кадрами (кроме знания их количества). Менеджмент ресурсов становится исключительно простым.

ХР уравнивает программистов. Более сильный (на фоне других) программист себя не сможет проявить (и не будет оценен).

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

Видимо, я не одинок. Проект отличался от других большим уходом людей по собственному желанию (хотя, статистических данных не достаточно).