3. Десятки userstory (бумажки с несколькими предложениями, характеризующими прецедент пользователя), оставшиеся после завершения проекта, не могут служить в качестве надежной документации. Получается, что ХР нацелена на быструю разработку ПО, но не на его сопровождение. Приведу цитату из книги [4] по поводу неудачи проекта 3C, выполненного посредством ХР (расчет зарплаты для Chrysler – могу подтвердить, что зарплата при своей внешней простоте одна из самых трудных областей бухгалтерии, в которой «утонула» не одна команда программистов). «Когда ушло достаточно много сотрудников, незаписанные сведения о проекте и групповая память были утрачены». Я думаю, что апологеты ХР переусердствовали с минимизацией документации. Что для студентов может выглядеть привлекательным, серьезных разработчиков должно насторожить.
Должен поделиться собственным ощущением от «работы в стиле ХР». В отличие от RUP (или любой другой методики с фиксированием результатов этапов, посредством тех. задания, тех. проекта и т.п.) ХР дает ощущение неуверенности и анархии в начале проекта. Бизнес-требования и архитектура меняются так быстро, что, просидев пару дней дома можно потом не узнать структуру базовых классов (даже если ты сам её придумал).
Сразу начинаешь понимать положение ХР о 40-часовой рабочей недели без переработок. Зачем до 22_00 трудиться в поте лица над модулем, который завтра может вообще не понадобиться?
В середине архитектура стабилизируется, конец же проекта характеризуется полной уверенностью в себе. Никакое из изменений требований, которое может высказать заказчик, не кажется ужасным. За время постоянных модификаций архитектуру приходится перерабатывать таким образом, чтобы изменения выполнялись максимально просто.
Программисты выступают в роли пользователей созданного дизайна программы – если он имеет дефекты, то систему трудно менять ещё на этапе разработки и это вызывает дискомфорт. В результате, дизайн вынужденно улучшается, а система легко переносит любые изменения бизнес-требований.
Продуктов, поддерживающих методику просто нет. И это, наверное, самое главное достоинство. Не станешь же, в самом деле, считать «ХР-продуктом» текстовый редактор или средство обеспечения версионности.
SADT
Structured Analysis and Design Technique – Методология структурного анализа и проектирования.
Известна как разработка компании SofTech, либо как только функциональный вариант в правительственной версии (IDEF0). Её начали применять с 1973г. во многих областях, таких как бизнес, производство, оборона, связь и организация проектирования.
Диаграммы в стандарте IDEF0 имеют несомненное преимущество для функционального моделирования системы. Однако представление модулей системы в виде блоков с набором входов и выходов и набором управляющих воздействий на них хорошо раскрывает только высокоуровневые структурные особенности системы. В этом SADT успешно конкурирует с диаграммами деятельности языка UML.
В SADT я не нашел механизмов для дальнейшей разработки системы, от сбора требований к реализации, тестированию и внедрению. Возможно, такая задача и не ставилась идеологами. Методика серьезно проигрывает остальным по охвату этапов ЖЦ ПО, сконцентрировавшись только на сборе требований и бизнес-моделировании.