Расширение кругозора человека приводит к тому, что у него появляется на вооружении больше КАК, а если человек разумный, то на каждом КАК его разум делает пометку ЗАЧЕМ.
PS И еще раз, только не нужно клеймить меня идолопоклонением.
R>Расширение кругозора человека приводит к тому, что у него появляется на вооружении больше КАК, а если человек разумный, то на каждом КАК его разум делает пометку ЗАЧЕМ.
Убедили. Просмотрел. Только оказалось, что это не статья, а что-то типа записи в блоге, набор тривиальных соображений, очередные "10 причин по которым нельзя курить", короче. Что обсуждать-то?
Большинство этих соображений высказывались, когда XP только входило в моду, потому как самоочевидны, т.е. лет восемь как не новость.
Здравствуйте, rsn81, Вы писали:
G>>С логикой что-то не так? R>Теперь понятно. R>Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах. R>Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде. R>Аналогично: не знаю, но сомневаюсь.
В таком случае должно быть какое-то простое и понятное объяснение — каким образом и почему разработка у них хорошо масштабируется. Я на слово даже уважаемым людям не верю — без понимания сути и причин пользы от такой веры никакой нет. А раз так — зачем себе голову забивать религиозными по сути штуками. Бритва Оккама.
G>>Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где R>А здесь не согласен: вы пропустили основной акцент, уцепившись за частность в стиле "в XP нет ничего принципиально нового". Почему вы пропустили главное: прототипирование в XP/Scrum не догма в виде автономно летающего в вакууме сферического коня, а именно фактор повышения эффективности планирования по сравнению с водопадом? Ведь самое важное в любом agile: иной, нежели стандартный, подход к планированию.
Прототипирование всегда повышает точность планирования, которая напрямую связана с представлением о структуре и сложности разрабатываемой штуки. Именно с этой целью прототипирование наиболее рискованных/критичных вещей и проводят — это common egineering sense. В ГОСТ на этапе "разработка эскизного проекта" предисывается проводить прототипирование непонятных и сложных штук. Других целей и причин прототипирования не существует, вне контекста agile или не agile. Если вам понятно, как будет устроена ваша штука, и точность плана и оценок вас устраивает, то разработка прототипа это просто выкинутые на ветер ресурсы. Дешевле как следует подумать, и сделать сразу начисто, чем по частям с постоянным допиливанием — в последнем случае вы серьезно рискуете словить очень крупные проблемы ближе к концу проекта.
G>>А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда? R>Разницу между XP и code and fix Фаулер описывает в статье, ссылку на которую давал выше. В его аргументации нашел параллели с обстоятельствами своей работы, потому считаю его позицию отчасти своей, но, честно говоря, начинаю чувствовать себя попкой-дураком, приводя краткое содержание его мыслей; думаю, лучше прочитать первоисточник.
Вы разве не в курсе, что все понимают одни и те же статьи/книги по разному? Меня интересовала краткая и емкая характеристика-определение в один абзац — ваше мнение. Ведь вы мне возражаете — не Фаулер?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, rsn81, Вы писали:
G>>>С логикой что-то не так? R>>Теперь понятно. R>>Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах. R>>Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>>>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде. R>>Аналогично: не знаю, но сомневаюсь.
G>В таком случае должно быть какое-то простое и понятное объяснение — каким образом и почему разработка у них хорошо масштабируется. Я на слово даже уважаемым людям не верю — без понимания сути и причин пользы от такой веры никакой нет. А раз так — зачем себе голову забивать религиозными по сути штуками. Бритва Оккама.
Объяснение у них, очевидно, такое.
1) regression-тестами все накрываем, тестами!
Действительно, при таком подходе у нас становится сложнее внести ошибку в софтину. Многие это понимают, и применяют автоматические тесты — ведь их применение соверешенно иррелевантно к процессу разработки и методологии, на самом деле. Только тесты — не панацея, количество тестов по мере увеличения покрытия растет экспоненциально. Обеспечить покрытие, при котором рефакторинг стал бы действительно безопасным, обеспечивая полную защиту от дурака — это начиная с некоторого момента слишком дорого обходится. Потому, мы применяли сочетание regression-тестирования с проверкой предусловий-постусловий и инвариантов в рантайме, а также специальные "тестовые режимы" при которых старый и новый код выполняются впараллель — так просто дешевле, это уменьшает требуемое тестовое покрытие.
При этом, тесты вас совершенно не гарантируют от внесения новых ошибок. Тесты ловят уже обнаруженные ошибки при повторном их появлении. Самые худшие и дорогие ошибки — ошибки дизайна и архитектурные. Лучшая гарантия от них — это предварительное проектирование. Тогда не будет появляться хрупкий код.
2) Есть способ делать рефакторинг так, чтобы он обходился дешево.
Описываю реальные, типовые ситуации рефакторинга в CQG, коду которого уже лет 17 и размером он в пару миллионов строк. Предваряя замечания — дай вам бог написать код, который не выкинут через 17 лет, и он будет актуален — в этом коде заложена великолепная архитектура и огромный запас "архитектурной прочности". Так вот, как врач говорю, пардон — как бывший руководитель группы разработки сервера. Рефакторинг представляет собой головную боль не тогда, когда надо механически класс на два побить, а когда вам сильносвязную подсистему с неизвестным или просто дико кривым дизайном надо привести к хорошо структурированной системе, которая была бы лишена целого класса известных проблем, плюс успешно, без потока дефектов, выдержала бы добавление известно новой функциональности. Причем, как правило, вы требования к системе в этом случае снимаете частично с описания проблем, частично проводя reverse engineering имеющегося кода. После reverse engineering вы будете долго думать, как вам изменить дизайн так, чтобы серия планируемых изменений прошла безболезненно, с одной стороны, и старая функциональность при этом легла хорошо — с другой (здесь нет никакого универсального метода "рефакторинга" — тут надо уметь прикладные кейсы в голове держать и представльять, как они на дизайн лягут). Возможна ситуация (в описываемом случае — почти наверняка), когда вы поменяете при этом границы подсистем и измените их интерфейсы (иначе новая функциональность может не лечь), вот тут ваши юнит-тесты написанные с таким трудом дружно и отвалятся. Всем скопом. И это типовая ситуацияпри развитии продукта — адаптации его к изменившимся требованиям. И рулить будет то, что я написал выше в пункте 1 — общесистемные regression tests, инварианты с условиями в коде, и "тестовые режимы" с включенным старым и новым кодом (так дешевле — не надо окружения под них готовить).
Так вот, у меня такое произойет в продукте которому 17 лет, а при agile подходе вы имеете неплохие шансы словить такое в течении первого-второго года разработки одного проекта. Или же, у вас неплохой шанс сильно раздуть базу кода на ровном месте — это уж я даю гарантию почти 100% для сложного проекта начиная с определенного объема. Суть в том, что не делая предварительного дизайна, вы пишете legacy code. Сразу. Right now. Да, он будет с тестами, но это still the same fuckin legacy code. А юнит-тесты вы по дороге потеряете, по сценарию описанному мной в п 2. Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .
Gaperton wrote: > 1) Разработка отвратительно масшабируется при росте команды. Если сроки > и функциональность таковы, что в проекте надо задействовать 10 человек и > более, то практика ХР приведет к катастрофе по причине издержек > коммуникации внутри команды, и отсутствия людей, владеющих общей > картиной. Контроль над разработкой будет утерян в самом начале. 10 — это > я для верности взял, чтобы наверняка. А вообще проблемы начнутся при > количестве людей больше двух, и станут заметны невооруженным глазом > начиная с 5 человек.
[skip]
Согласен, в общем-то. Еще XP неплохо работает для небольших команд,
делающих конкретные модули большой системы (которая управляется по
классическим методологиям). Хотя это, скорее, просто частный случай
"небольшого продукта".
Здравствуйте, Gaperton, Вы писали:
G>Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .
К>>>4. Тестирование задейстовано в течение всего процесса разработки. _>>То же самое... К>Заметно повышает стоимость проекта (на время тестеров), хотя снижает риски.
Если тестирование автоматизировано, то объём должен быть тот же или меньше.
Если обезьянки с клавиатурами — тогда судьба такая.
G>>ИМХО, ХР — это игрушка для создания одноразовых поделок.
AE>Нет. Для agile есть одна полноценная ниша в больших проектах: макетно-исследовательский этап.
Наверное, ты всё-таки путаешь agile и XP.
XP это agile. А agile — это не только XP.
Так что к гибкой методологии вообще критика Гапертона, я так понимаю, не относилась.
(Если не считать намёк на то, что ярлыки на самом деле значат меньше, чем многие думают)
G>Так вот, у меня такое произойет в продукте которому 17 лет, а при agile подходе вы имеете неплохие шансы словить такое в течении первого-второго года разработки одного проекта. Или же, у вас неплохой шанс сильно раздуть базу кода на ровном месте — это уж я даю гарантию почти 100% для сложного проекта начиная с определенного объема. Суть в том, что не делая предварительного дизайна, вы пишете legacy code. Сразу. Right now. Да, он будет с тестами, но это still the same fuckin legacy code. А юнит-тесты вы по дороге потеряете, по сценарию описанному мной в п 2. Вот такой примерно будет сценарий провала проекта. Советую запомнить — когда ЭТО начнется — вспомните гапертона, он конечно не фаулер, но предупреждал .
В этом отношении RUP должен, я думаю, быть поприятнее: в том смысле что гибкость проекта подбирается в зависимости от различных факторов. Без крайностей водопад/ХР.
Хотя в некоторых случаях и то и то приемлемо.
Смущает только его дороговизна.
Так что думаю лучше придерживаться некоторых идей RUP без внедрения RUP как такового.
Что в принципе советует Крачтен.
АК>У моменту интеграционного, а тем более приёмочного тестирования, agile процесс уже должен произвести некотороое количество докуменации, достаточное для тестирования модулей как blackbox-ов. Таким обазом, процесс интеграционного и приёмочного тестирование не должны различаться для agile и для не-agile методик.
А когда, интересно, в Agile наступает момент интеграционного тестирования?
Здравствуйте, VGn, Вы писали:
G>>>ИМХО, ХР — это игрушка для создания одноразовых поделок.
AE>>Нет. Для agile есть одна полноценная ниша в больших проектах: макетно-исследовательский этап.
VGn>Наверное, ты всё-таки путаешь agile и XP. VGn>XP это agile. А agile — это не только XP. VGn>Так что к гибкой методологии вообще критика Гапертона, я так понимаю, не относилась.
Гапертон несколько эмоционально обобщает.
И я позволил себе сохранить это обобщение.
P.S.
И вообще говоря, для его подхода есть основания.
Поскольку я практически не встречал случая, когда фирмы умели бы пользоваться полнофункциональными макетами.
Здравствуйте, VGn, Вы писали:
VGn>В этом отношении RUP должен, я думаю, быть поприятнее: в том смысле что гибкость проекта подбирается в зависимости от различных факторов. Без крайностей водопад/ХР. VGn>Хотя в некоторых случаях и то и то приемлемо. VGn>Смущает только его дороговизна.
Дороговизна RUP?! Это, извините за занудство, вы о чем, о дороговизне внедрения, что ли? Или о дороговизне отдельных людей на ролях?
Hello, !
You wrote on Wed, 05 Sep 2007 07:16:54 GMT:
К> Собственно наткнулся на К> [url=http://kw-agiledevelopment.blogspot.com/2007/09/disadvantages-of- К> agile-software.html]статью[/url], где автор выделяет следующие К> недостатки agile-подходов: К> 1. Необходима большая вовлечённость пользователя в процесс разработки К> 2. Требования меняются и развиваются (не подходит, как минимум, для К> "fixed price" проектов) К> 3. Требования создаются минимально достаточными (легче отрефакторить К> решение, чем спроектировать всё детально заранее) К> 4. Тестирование задейстовано в течение всего процесса разработки. К> 5. "Частые поставки" (Frequent delivery), которые могут быть К> достаточно накладными К> 6. Судя по откликам, agile-подходы напряжённы (intense) по отношению К> к разработчикам (100% реализация фич за итерацию и неукоснительность К> итераций "накладывет отпечаток")
Самое главное в статье — не подказано, для кого это недостатки
ЗЫ По мне — так одни достоинста
With best regards, Yury Kopyl. E-mail: hrg@yandex.ru
Думаю нужно добавить ещё парочку (частично применимы и к XP).
1. Высокие требования к квалификации разработчиков.
2. Зачастую низка заменяемость кадров на проекте, так как используется минимальный объем документации по проекту и часто отсутствует общее видение проекта в целом (нет четкой формализации критериев качества для данного проекта, все фактически опирается на квалификацию разработчиков).
Плюсы я думаю всем и так понятны
Насчёт XP и Agile согласен во многом ... Считаю правда что лучшее оттуда стоит заимствовать при необходимости.
P.S.:
Насчёт NLP не согласен . Вы Бендлера и Гриндлера читали? . Можем продолжить обсуждение в отдельной ветке.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
Я бы выделил еще несколько недостатков:
1. Очень часто команды "прячут" свою лень за термином agile при разработке систем. Когда требуется минимум документации, команды вобще не производят никакой документации, аргументируя тем, что они работают по agile. Грубо говоря, разработчику ставится задача на спринт (в SCRUMе) на словах и когда приходит время Demo, многие недовольны результатами.
2. Многие интерпретируют фразу из Agile Manifesto "Individuals and interactions over processes and tools" таким образом, что процессы при разработке по agile совершенно не нужны. Слово "interactions" подразумевает взаимоотношения. Тяжело эффективно управлять взаимоотношениями без какой-либо структуры или процесса.
Кроме того, считаю, что использование agile методологии, при теперешней острой нехватке квалифицированных кадров стоит дороже, чем формализированный процесс разработки, так как agile требует полной ответсвенности каждого члена agile команды. Наличие квалифицированных и в то же время ответственных сотрудников требует "сильного" HR и "жирного" бюджета. В то время, как постановка процессов разработки и установка автоматизированной системы управления процессом может потребовать меньше средств.
Все, что я здесь наговорил, совершенно не означает, что я не поддерживаю agile. Сам использовал, использую и буду использовать agile, так как на данный момент эта методология является эффективным средством создания систем среднего масштаба с высоким уровнем качества.
Здравствуйте, Курилка, Вы писали:
К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
По-моему агил — это формализация реального положения дел во многих проектах. Кавардак одним словом. И этому кавардаку пытаются придать великий смысл, и заставить разработчиков вкалывать еще сильнее. Ответственность размытая, оттого может получится так, что наиболее ответственные будут на себе тянуть других. По-моему эта модель хорошо подойдет для студентов. Им прикольно потуситься, и они хорошо управляемые.
Здравствуйте, Gaperton, Вы писали:
G>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
Вот не очень понимаю, что мешает побить большой проект на несколько команд, а потом в одной/нескольких/всех использовать XP?
Отдельный компонент большой системы — это, фактически, отдельный проект со своим заказчиком, требованиями, дизайном, пользователями, версиями, и т.д. Его можно разрабатывать как хочется, при условии, что взаимодействие с остальными командами налажено.
Здравствуйте, Gaperton, Вы писали:
G>2) Есть способ делать рефакторинг так, чтобы он обходился дешево. G>Описываю реальные, типовые ситуации рефакторинга в CQG, коду которого уже лет 17 и размером он в пару миллионов строк. Предваряя замечания — дай вам бог написать код, который не выкинут через 17 лет, и он будет актуален — в этом коде заложена великолепная архитектура и огромный запас "архитектурной прочности". Так вот, как врач говорю, пардон — как бывший руководитель группы разработки сервера. Рефакторинг представляет собой головную боль не тогда, когда надо механически класс на два побить, а когда вам сильносвязную подсистему с неизвестным или просто дико кривым дизайном надо привести к хорошо структурированной системе, которая была бы лишена целого класса известных проблем, плюс успешно, без потока дефектов, выдержала бы добавление известно новой функциональности. Причем, как правило, вы требования к системе в этом случае снимаете частично с описания проблем, частично проводя reverse engineering имеющегося кода. После reverse engineering вы будете долго думать, как вам изменить дизайн так, чтобы серия планируемых изменений прошла безболезненно, с одной стороны, и старая функциональность при этом легла хорошо — с другой (здесь нет никакого универсального метода "рефакторинга" — тут надо уметь прикладные кейсы в голове держать и представльять, как они на дизайн лягут). Возможна ситуация (в описываемом случае — почти наверняка), когда вы поменяете при этом границы подсистем и измените их интерфейсы (иначе новая функциональность может не лечь), вот тут ваши юнит-тесты написанные с таким трудом дружно и отвалятся. Всем скопом. И это типовая ситуацияпри развитии продукта — адаптации его к изменившимся требованиям. И рулить будет то, что я написал выше в пункте 1 — общесистемные regression tests, инварианты с условиями в коде, и "тестовые режимы" с включенным старым и новым кодом (так дешевле — не надо окружения под них готовить).
а где можно узнать побольше о таких "тестовых режимах"? правильно ли я понимаю, что при включенном таком режиме одновременно может работать и старых код (до рефакторинга) некой подсистемы и новый код (полученный после рефакторинга). Можно об этом рассказать подробнее?
И вы спрашиваете меня, почем я решил, что XP == code and fix? 
.
