Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут. 
Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды.
В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие:
1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек.
2) Реальный жизненный цикл реального продукта только начинается созданием первой версии. Все сложности только начнутся с ее выходом — тут же выяснится, что оказывается продукт надо а) поддерживать, внося туда исправления дефектов и разнообразные докрутки, а также б) выпускать новые версии с серьезно улучшенной функциональностью и адаптировать их под постоянно меняющиеся требования, диктуемые бизнесом и рыночной ситуацией.
3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать).
Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее.
Увлечение ХР — это что-то вроде увлечения НЛП. Человек выполняет набор эффектных и бесполезных фокусов, и чувствует при этом свою якобы причастность к психологии, и якобы появившийся контроль над собой и окружающими людьми. Впрочем, увлечение НЛП быстро проходит, как только человек попадает в действительно серьезную жизненную передрягу. Так же, думаю, и с agile. Нельзя полагаться на технику и формальные подходы, особенно если они вводят необоснованные постулаты, противоречат здравому смыслу, или используют собственную терминологию для всем известнх вещей (последнее — верный признак что ничего нового в предлагаемой штуке нет — автор так маскирует ошибки и общую бредовость, затрудняя сопоставление с классикой — это типичный прием "экстремальных учонах" в науке). Головой думать надо.
