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

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

В отличие от некоторых обсуждений, которые мы наблюдаем в сообществе разработчиков ПО, Agile разработка не является принятием Scrum или любого другого процесса, инструментария или методологии в качестве культа «карго», хотя мы, разумеется, следим за этим и считаем это проблемой. В основе гибкости (agility) лежит быстрое реагирование, обучение и достаточность. Гибкость отображается в надежности и качестве программного обеспечения. По определению, ненадежность и низкий уровень качества разработки препятствует и уменьшает ее гибкость. В манифесте указано, что “постоянное внимание, уделяемое техническому совершенству и качественному проектированию, увеличивает гибкость процесса”, предлагая архитектуре четкую роль в контексте Agile среды.

Понятие «архитектура» обычно определяют как “структурная декомпозиция системы, включающая ее разделение на части, их связность, механизмы взаимодействия и руководящие принципы, которые формируют проект системы.” [1]

Хотя, с технической точки зрения это не такое уж ошибочное определение, оно все же достаточно вольно интерпретируется.

В продолжение темы Архитектор в команде - лидерство или полномочия? хочется привести цитату из широко рекламируемой книги "Балдеющие от адреналина и зомбированные шаблонами" Тома Демарко, Тима Листера и прочих соавторов.