Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
1. Необходима большая вовлечённость пользователя в процесс разработки
2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
4. Тестирование задейстовано в течение всего процесса разработки.
5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки
Для разработчиков IMHO это как раз то, что нужно — что бы не гадать, как хочет заказчик. Это недостаток только для ленивого или вредного заказчика, который хочет что бы сделали проект который ему нужен, но без его активного участия К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)
Обычно новые требования начинаются когда заказчик видит уже хоть что-то. А agile прекрасно применим и для "fixed price" проектов К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)
Чего-то я непонимаю где здесь недостаток? К>4. Тестирование задейстовано в течение всего процесса разработки.
То же самое... К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными
да, тут есть немного... К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
и тут тоже ощутимо...
В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут.
Основополагающие практики ХР
В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. А как мы уже выяснили, использование эволюционного проектирования не может привести ни к чему хорошему из-за обилия сиюминутных проектировочных решений и энтропии программного продукта.
В основе этого утверждения лежит кривая стоимости изменений в программном продукте. Согласно этой кривой, по мере развития проекта стоимость внесения изменений экспоненциально возрастает. Как правило, в ней используются понятия "фазы развития проекта" (как говорится, "изменение, которое на стадии анализа стоит 1 доллар, после поставки системы будет стоить многие тысячи"). В этом есть некая доля иронии, поскольку в большинстве проектов процесс разработки вообще не определен, и там просто нет стадии анализа, а экспоненциальная зависимость остается в силе. Получается, что если экспоненциальная кривая верна, то эволюционное проектирование вообще нельзя использовать в работе. Отсюда же следует, что нельзя делать ошибки в предварительном проектировании — затраты на их исправление будут определяться все той же зависимостью.
В основе XP лежит предположение, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. Именно это является основным предметом споров вокруг XP. Многие начинают критиковать использование, не разобравшись в том, как его нужно достигать с помощью осуществления. Зачастую тому виной собственный опыт критикующего, который упустил в разработках те практики, которые позволяют осуществлять другие. В результате, раз обжегшись, такие люди при упоминании об ХР и на воду дуют.
У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Непрерывная интеграция необходима для синхронной работы всех разработчиков, так чтобы любой человек мог вносить в систему свои изменения и не беспокоиться об интеграции с остальными членами команды. Взятые вместе, эти две практики могут оказывать существенное влияние на кривую стоимости изменений в программном продукте. Я получил еще одно подтверждение этому в компании "ThoughtWorks". Даже применение всего двух практик, тестирования и непрерывной интеграции, существенно сказалось на результатах. Можно даже усомниться, действительно ли нужно (как это принято считать в ХР) следовать всем практикам, чтобы получить заметный результат.
Подобный эффект имеет и рефакторинг. Те, кто делают рефакторинг в той строгой манере, что принята в ХР, отмечают значительное повышение его эффективности по сравнению с более бессистемной реструктуризацией. Именно это я и ощутил, когда Кент наконец-то научил меня, как правильно делать рефакторинг. В конце концов, это так меня впечатлило, что я даже написал об этом целую книгу.
Джим Хайсмит (Jim Highsmith) в своем великолепном изложении методологии XP использует аналогию с обычными весами. На одной чаше лежит предварительное проектирование, на другой — рефакторинг. В более традиционных подходах к разработке ПО перевешивает предварительное проектирование, так как предполагается, что передумать вы не можете. Если же стоимость изменений снизится, то часть проектирования можно делать и на более поздних стадиях работы, в виде рефакторинга. Это вовсе не означает отказа от предварительного проектирования. Однако теперь можно говорить о существовании баланса между двумя подходами к проектированию, из которых можно выбрать наиболее подходящий. Что касается меня, то иногда мне кажется, что до знакомства с рефакторингом я работал, как однорукий калека.
Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. Впрочем, мы еще не выяснили, где же у этих весов точка равновесия. Лично я уверен, что не смотря на поверхностное впечатление, методология ХР — это не просто тестирование, кодирование и рефакторинг. В ней найдется место и для предварительного проектирования. Частично оно производится еще до написания первой строчки кода, но большая его часть приходится на то время, которое предшествует реализации конкретной задачи в течение итерации. Впрочем, такая ситуация представляет собой новое соотношение сил между предварительным проектированием и рефакторингом.
Здравствуйте, mr_kern, Вы писали:
_>Здравствуйте, Курилка, Вы писали: К>>1. Необходима большая вовлечённость пользователя в процесс разработки _>Для разработчиков IMHO это как раз то, что нужно — что бы не гадать, как хочет заказчик. Это недостаток только для ленивого или вредного заказчика, который хочет что бы сделали проект который ему нужен, но без его активного участия
Вот тут-то весь и фикус — часто играет роль мысль "заказчик всегда прав". Всё что он хочет — дать тебе задачу, заплатить и получить готовый результат решающий проблему (а лучше любые проблемы ), он вероятно будет не готов выделять своих людей и отдавать их разработчикам вместо того чтоб "делать бизнес" (т.е. терять реальные деньги).
К>>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов) _>Обычно новые требования начинаются когда заказчик видит уже хоть что-то. А agile прекрасно применим и для "fixed price" проектов
А какой же будет agile, если ТЗ уже есть и сроки прописаны? К>>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее) _>Чего-то я непонимаю где здесь недостаток?
Не встречал клиентов для которых нужны талмуды документации в которых было бы всё описано "от и до"? К>>4. Тестирование задейстовано в течение всего процесса разработки. _>То же самое...
Заметно повышает стоимость проекта (на время тестеров), хотя снижает риски.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов: К>1. Необходима большая вовлечённость пользователя в процесс разработки К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов) К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее) К>4. Тестирование задейстовано в течение всего процесса разработки. К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")
Согласен с пунктом 2, agile действительно не подходит для fixed price. По остальныем пунктам не видно в чем же собственно недостатки.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Согласен с пунктом 2, agile действительно не подходит для fixed price. По остальныем пунктам не видно в чем же собственно недостатки.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Андрей Коростелев, Вы писали:
АК>>Согласен с пунктом 2, agile действительно не подходит для fixed price. По остальныем пунктам не видно в чем же собственно недостатки.
К>И из статьи не видно?
Честно говоря, я не нашел в этой статье убедительных доводов.
Частое дерганье пользователей? А сушествуют ли пользователь, который ясно и четко знает что ему нужно и что никогда не меняет своего мнения?
С самого начала нужно тратиться на тестеров? Юнит-тестирование — дело разработчиков, а не тестеров.
Отсутствие всеобъемлющей документации мешает влиться новичкам? Новички получают только то, что нужно и не стеснены рамками существуещего дизайна.
Требуется более интенсивная коммуникации между разрабочиками? Решается небольшими размерами групп.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Частое дерганье пользователей? А сушествуют ли пользователь, который ясно и четко знает что ему нужно и что никогда не меняет своего мнения?
Ну тут имеем противодействие заказчика. Просто всёж он тратит деньги за продукт и если вы его не убедите, что ему нужно отдать часть своих специалистов для процесса разработки, то он просто не заключит с вами контракт или же agile получится как минимум фиговый. АК>С самого начала нужно тратиться на тестеров? Юнит-тестирование — дело разработчиков, а не тестеров.
Довольно странное заявление, модульное тестирование, хоть и важная часть тестирования, но не единственная. Интеграционное и приёмочное тестирование у вас совсем не используется? АК>Отсутствие всеобъемлющей документации мешает влиться новичкам? Новички получают только то, что нужно и не стеснены рамками существуещего дизайна. АК>Требуется более интенсивная коммуникации между разрабочиками? Решается небольшими размерами групп.
Там же отмечено — есть тестеры (скажем на приёмочном тестировании), как ты решишь проблему взаимодействия их с разработчиками при помощи небольшого размера групп?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Андрей Коростелев, Вы писали:
АК>>С самого начала нужно тратиться на тестеров? Юнит-тестирование — дело разработчиков, а не тестеров. К>Довольно странное заявление, модульное тестирование, хоть и важная часть тестирования, но не единственная. Интеграционное и приёмочное тестирование у вас совсем не используется?
У моменту интеграционного, а тем более приёмочного тестирования, agile процесс уже должен произвести некотороое количество докуменации, достаточное для тестирования модулей как blackbox-ов. Таким обазом, процесс интеграционного и приёмочного тестирование не должны различаться для agile и для не-agile методик.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут.
Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды.
В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие:
1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек.
2) Реальный жизненный цикл реального продукта только начинается созданием первой версии. Все сложности только начнутся с ее выходом — тут же выяснится, что оказывается продукт надо а) поддерживать, внося туда исправления дефектов и разнообразные докрутки, а также б) выпускать новые версии с серьезно улучшенной функциональностью и адаптировать их под постоянно меняющиеся требования, диктуемые бизнесом и рыночной ситуацией.
3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать).
Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее.
Увлечение ХР — это что-то вроде увлечения НЛП. Человек выполняет набор эффектных и бесполезных фокусов, и чувствует при этом свою якобы причастность к психологии, и якобы появившийся контроль над собой и окружающими людьми. Впрочем, увлечение НЛП быстро проходит, как только человек попадает в действительно серьезную жизненную передрягу. Так же, думаю, и с agile. Нельзя полагаться на технику и формальные подходы, особенно если они вводят необоснованные постулаты, противоречат здравому смыслу, или используют собственную терминологию для всем известнх вещей (последнее — верный признак что ничего нового в предлагаемой штуке нет — автор так маскирует ошибки и общую бредовость, затрудняя сопоставление с классикой — это типичный прием "экстремальных учонах" в науке). Головой думать надо.
Здравствуйте, Gaperton, Вы писали:
G>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
А можно хотяб пару ссылок откуда копать по поводу выделенного? А то как-то чёткого понимания нет, всплывают только мысли по поводу CMMI и RUP.
Вы писали:
G>ИМХО, ХР — это игрушка для создания одноразовых поделок.
Нет. Для agile есть одна полноценная ниша в больших проектах: макетно-исследовательский этап.
Но в этом случае действительно не более 2-3 человек и ограничение по времени.
А потом, по результатам agile-проекта зачудительно пишется хорошая постановочная документация для "дедовских способов".
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
К>А можно хотяб пару ссылок откуда копать по поводу выделенного? А то как-то чёткого понимания нет, всплывают только мысли по поводу CMMI и RUP.
RUP — это очень хорошо. Это концентрированный здравый смысл. Мы у себя применяем жизненный цикл RUP — "контроллируемая итерация". В нем основной ахтунг — RUP это шаблон, который подлежит обязательной кастомизации.
CMMI — набор критериев зрелости процесса разработки, не сам процесс. Дает ответ на вопрос "что, в принципе, хорошо", но не дает ответа на вопрос "как надо".
Микрософтский MSF — весьма приятная штука, методика для одной маленькой рабочей группы. Там надо обратить внимание на распределение ролей — у них весьма неплохо роли проработанны.
А вообще — блин, какие ссылки — всегда есть требования, дизайн, кодирование, отладка. Однажды я спросил одного из директора R&D CQG, только что заступившего в должность, какой цикл разработки он собирается применять и вообще — какую методологию? Может быть, RUP? Или, все-таки, XP? Ян МакФэйден, который перед этим возглавлял отдел разработки крупнейшего американского банка (Wells Fargo, кажется), засмеялся, и сказал что-то вроде этого: I don't really care. It's always something like requirements, design, coding, and testing. Whoops, I'm sorry guys, I need to take some evening beer with Dmitry (директор московского офиса)? Have you ever told that it's very dangerous — to stand between me and beer? И довольно заржал в одну калитку, манера у него была такая. Короче, мы были в шоке, и решили что пропал дом. Фигассе, не волнует его, пнимаешь.
Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать. Теперь я понимаю, что более компетентного, эффективного, простого в общении, и вообще — классного директора R&D я в жизни не видел. Хардкорный профи. Впрочем, я их вообще не так много видел . Только в CQG — человек 5.
Здравствуйте, Gaperton, Вы писали:
G>Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды.
Два утверждения:Небольшой размер команды обычно приводит к сглаженной кривой стоимости изменений.
Единственной причиной сглаженной кривой стоимости изменений является малый размер команды.Может с логикой у меня что-то не так, но из первого утверждения вовсе не выплывает второе.
G>В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие: G>1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек.
Да, есть такая проблема, Фредерик Брукс достаточно детально ее рассматривал в своем "Мифическом человеко-месяце или как создавать программные системы". Непонятно только, причем тут XP?
G>2) Реальный жизненный цикл реального продукта только начинается созданием первой версии. Все сложности только начнутся с ее выходом — тут же выяснится, что оказывается продукт надо а) поддерживать, внося туда исправления дефектов и разнообразные докрутки, а также б) выпускать новые версии с серьезно улучшенной функциональностью и адаптировать их под постоянно меняющиеся требования, диктуемые бизнесом и рыночной ситуацией.
Не понял, а собственно причем тут XP?В XP используют итерации в 2-3 недели, в связанной с XP методологии Scrum декларируются спринты до одного месяца. Правильно класть колбасу итераций на хлеб — это заниматься планированием (его вовсе никто не выкидывает в XP), только планирование оперирует более обозримыми масштабами — итерациями.
Итеративность разработки тесно связана (скажем, одно без другого — непонятно зачем) с ранним прототипированием: каждая итерация заканчивается демонстрацией результатов заказчику (в лучшем варианте — конечному пользователю). Это позволяет заказчику оценить, что было сделано из запланированного на прошедшую итерацию, а также выставить приоритеты на следующую итерацию — планирование замыкается на новую итерацию.В итоге планирование становится прозрачным и меньше зависит от посторонних факторов.
G>3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать).
XP вроде бы всеми руками-ногами за пересмотр кода: XP != code and fix.
G>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес.
Ага-ага, но причем тут XP?
G>ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее.
Непонятно, почему вы решили, что:XP и планирование в контрах. XP просто предлагает сделать его:
прозрачным, то есть понятным всем участникам проекта: и исполнителям, и заказчикам;
эффективным: результаты планирования, а это как успехи, так и промахи, видны участникам периодически (в конце каждой итерации), что потенциально позволяет вносить соответствующие коррективы в момент, когда еще не слишком поздно (а не в конце проекта в виде компресса на лоб мертворожденного проекта, которому планировщики запланировали светлое будущее на лета, а то как он помер в один день и не заметили, пребывая в восторженных заоблачных размышлениях).
XP == code and fix.
G>Увлечение ХР — это что-то вроде увлечения НЛП. Человек выполняет набор эффектных и бесполезных фокусов, и чувствует при этом свою якобы причастность к психологии, и якобы появившийся контроль над собой и окружающими людьми. Впрочем, увлечение НЛП быстро проходит, как только человек попадает в действительно серьезную жизненную передрягу. Так же, думаю, и с agile. Нельзя полагаться на технику и формальные подходы, особенно если они вводят необоснованные постулаты, противоречат здравому смыслу, или используют собственную терминологию для всем известнх вещей (последнее — верный признак что ничего нового в предлагаемой штуке нет — автор так маскирует ошибки и общую бредовость, затрудняя сопоставление с классикой — это типичный прием "экстремальных учонах" в науке).
Эмоции.
G>Головой думать надо.
А вот с этим согласен на все сто. Если не думать головой, то даже XP не спасет.
PS Оговорюсь сразу (чтобы не записали в фанатика-идолопоклонника Кента Бека), что вовсе не считаю XP приемлемым для всех проектов, выше в теме писал об этом.
R>В статье Проектирования больше нет? Фаулер приводит причины, по которым использование только части взаимосвязанных практик XP приводит к тому, что остальные не приносят ожидаемого эффекта. Фаулер, как кот Матроскин, утверждает, что критиканы XP просто не так колбасу на хлеб кладут.
Такие утверждения сильно подрывают доверие, поскольку делают разумные, в принципе, вещи похожими на шарлатанские методики похудания и исцеления, которые тоже накладывают строгие и сложноисполнимые требования, и неуспех естественным образом сваливается на даже минимальные отступления от них.
Не используешь парное программирование — все, привет. XP не работает.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Все было бы так, только есть один нюанс. При размере команды в два человека можно применять эволюционное проектирование — основной фактор состоит в том, что эти двое просто не успеют сделать настолько много кода и реализовать настолько много противоречивых требований, чтобы система начала расползаться — т.е. "сглаживание кривой" обеспечивается в основном не магическими практиками ХР, а небольшим размером команды. R>Два утверждения:Небольшой размер команды обычно приводит к сглаженной кривой стоимости изменений. R>Единственной причиной сглаженной кривой стоимости изменений является малый размер команды.Может с логикой у меня что-то не так, но из первого утверждения вовсе не выплывает второе.
Я поясню свою мысль. Второе утверждение на самом деле звучит по другому: основной причиной несглаженной кривой являются проблемы взаимодействится при большой команде + особенности поддержки и развития продукта + большая сложность софта, такая, что в голове одного разработчика она не укладывается, обусловленная объемом и возрастом исходников, большим объемом противоречивых требований, изменением этих требований во времени, наличием приоритетов по срочности работ (что приводит к "грязным решениям"), ротацией кадров (происходит постоянная утеря компетенции). Друг из друга они напрямую не следуют, но они связанны. Малая команда во-первых малая, и не имеет проблем взаимодействия, а во-вторых — просто не сможет создать достаточно большой и сложный софт, чтобы появились проблемы с его сложностью. Посему, определяющей причиной, основной, но не единственной, таки является малый рамер команды.
С логикой что-то не так?
G>>В реальности, основные движущие факторы, определяющие "экспоненциальность кривой", и прводящие ХР проекты к провалу на практике, — следующие: G>>1) Разработка отвратительно масшабируется при росте команды. Если сроки и функциональность таковы, что в проекте надо задействовать 10 человек и более, то практика ХР приведет к катастрофе по причине издержек коммуникации внутри команды, и отсутствия людей, владеющих общей картиной. Контроль над разработкой будет утерян в самом начале. 10 — это я для верности взял, чтобы наверняка. А вообще проблемы начнутся при количестве людей больше двух, и станут заметны невооруженным глазом начиная с 5 человек. R>Да, есть такая проблема, Фредерик Брукс достаточно детально ее рассматривал в своем "Мифическом человеко-месяце или как создавать программные системы". Непонятно только, причем тут XP?
При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
G>>3) Кроме этого, выяснится, что оказыватеся среди программистов бывает текучка — приходят новые, а старые уходят. А еще бывает, что у работ бывает высокий приоритет, и новые люди по быстрому вкручивают что-то в код, не имея времени в нем тольком разобраться (и боже упаси, рефакторинг делать). R>XP вроде бы всеми руками-ногами за пересмотр кода: XP != code and fix.
Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где
G>>Полноценные и "дедовские" (классические) методологии рассчитаны на эффективную работу именно в этих, реальных условиях — большие организованные команды разнопрофильных профессионалов (потому что сроки поджимают и софт сложный, группа "два тракториста-универсала" такой сделать просто не успеет), реальные живые люди (которые могут быть, например, склонны к индивидуальной работе по складу характера), цикл поддержки и развития с трассировкой требований (вместо наколеночного хакания всякой херни на авось). Написание софта — это бизнес, и ошибки в разработке и управлении имеют цену. Подчас — очень высокую, они могут убить бизнес. R>Ага-ага, но причем тут XP?
По моему, я объяснил.
G>>ИМХО, ХР — это игрушка для создания одноразовых поделок. Реальные проекты надо планировать, надо проектировать, и более того — считается хорошей практикой тратить больше времени на дизайн, и меньше на кодирование. Думать побольше, прыгать поменьше. Это элементарный здравый смысл, подкрепленный замерами метрик с реальных проектов. Это способ, к которому интуитивно приходит большинство опыных рахработчиков. Deadline ДеМарко читали? Вот и ДеМарко, светоч девелоперского здравого смысла посреди мрака безумия, считает так же. "Кодируйте в последний момент" — так быстрее. R>Непонятно, почему вы решили, что:XP и планирование в контрах. XP просто предлагает сделать его:
прозрачным, то есть понятным всем участникам проекта: и исполнителям, и заказчикам;
R>эффективным: результаты планирования, а это как успехи, так и промахи, видны участникам периодически (в конце каждой итерации), что потенциально позволяет вносить соответствующие коррективы в момент, когда еще не слишком поздно (а не в конце проекта в виде компресса на лоб мертворожденного проекта, которому планировщики запланировали светлое будущее на лета, а то как он помер в один день и не заметили, пребывая в восторженных заоблачных размышлениях).R>XP == code and fix.
А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда?
Здравствуйте, dmz, Вы писали:
dmz>Такие утверждения сильно подрывают доверие, поскольку делают разумные, в принципе, вещи похожими на шарлатанские методики похудания и исцеления, которые тоже накладывают строгие и сложноисполнимые требования, и неуспех естественным образом сваливается на даже минимальные отступления от них.
Утверждения — да, согласен, но аргументация — вовсе не обязательно. К примеру, по ссылке выше Фаулер аргументирует, а в процитированном абзаце непосредственно выше вы всего лишь утверждаете.
dmz>Не используешь парное программирование — все, привет. XP не работает.
Вы утрируете. Фаулер говорит о конкретных взаимосвязанных практиках, а вовсе не о догматичном следовании всем-всем диктуемым действиям (на самом деле даже наоборот — прочтите статью полностью).
R>Вы утрируете. Фаулер говорит о конкретных взаимосвязанных практиках, а вовсе не о догматичном следовании всем-всем R>диктуемым действиям (на самом деле даже наоборот — прочтите статью полностью).
Честно говоря, не буду. У меня нет озабоченности методологией. Методология может быть любой удобной для конкретного проекта исходя из его реалий; Единственное требование — что бы ее элементы были осознанны, и что бы на любое КАК у нас было понимание ЗАЧЕМ. В противном случае это будет поклонение самолётам, а вот оно точно не работает.
Здравствуйте, Gaperton, Вы писали:
G>С логикой что-то не так?
Теперь понятно. Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах.
Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
Аналогично: не знаю, но сомневаюсь.
G>Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где
А здесь не согласен: вы пропустили основной акцент, уцепившись за частность в стиле "в XP нет ничего принципиально нового". Почему вы пропустили главное: прототипирование в XP/Scrum не догма в виде автономно летающего в вакууме сферического коня, а именно фактор повышения эффективности планирования по сравнению с водопадом? Ведь самое важное в любом agile: иной, нежели стандартный, подход к планированию.
G>А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда?
Разницу между XP и code and fix Фаулер описывает в статье, ссылку на которую давал выше. В его аргументации нашел параллели с обстоятельствами своей работы, потому считаю его позицию отчасти своей, но, честно говоря, начинаю чувствовать себя попкой-дураком, приводя краткое содержание его мыслей; думаю, лучше прочитать первоисточник.
И вы спрашиваете меня, почем я решил, что XP == code and fix? 