민첩한 환경에서 건축 설계는 어떻게 이루어 집니까?


59

Agile Architect의 원칙을 읽었으며 다음 원칙을 정의했습니다.

원칙 # 1 시스템을 코딩하는 팀이 시스템을 설계합니다.
원칙 # 2 작동 할 수있는 가장 간단한 아키텍처를 구축하십시오.
원칙 # 3 의심 스러우면 코드를 작성하십시오.
원칙 # 4 그들은 그것을 만들고 시험한다.
원칙 # 5 시스템이 클수록 활주로가 길어집니다.
원칙 # 6 시스템 아키텍처는 역할 협업입니다.
원칙 # 7 혁신에 대한 독점은 없다.

이 백서에서는 대부분의 아키텍처 설계가 코딩 단계에서 수행되며 그 이전의 시스템 설계 만 수행된다고 말합니다. 괜찮습니다.

그렇다면 시스템 설계는 어떻게 이루어 집니까? UML을 사용하십니까? 아니면 인터페이스와 주요 블록을 정의하는 문서입니까? 다른 게 있을까요?


11
UML에서는 "디자인"을하지 않습니다. 디자인을 한 다음 UML을 사용하여 쓰거나 의사 소통합니다.
tdammers

4
@tdammers : 정확하게 말하면 UML을 사용하여 적어두고 UML이 충분하지 않다는 것을 알 수 있습니다.
Doc Brown

답변:


77

면책 조항 : 나는 나는 연장자, "어떤 전투 계획은 적과의 접촉을 살아 없다"라고 헬무트 폰 몰트 케와 같은 민첩한 환경에서 건축가하지만. 다시 말해, 실용성은 가이드 라인의 정확한 글자를 항상 따를 수는 없다는 것을 의미합니다.

위에서 제기 한 대부분의 포인트는 팀이 할 수있는 최선의 방법으로 따릅니다. 그러나 원칙 1 (시스템을 설계하는 시스템을 코딩하는 팀)은 팀이 다른 대륙과 시간대로 분산 된 수십 (또는 수백) 명의 개발자로 구성되어있는 경우 실제로 따르기가 어렵습니다 . 이것은 개발자의 기술이나 태도와는 아무런 관련이 없으며, 고객의 요구 사항을 수집하고 기존의 복잡한 시스템을 이해하기 위해 존재하는 모든 물류 문제가 존재합니다.

그렇다면 시스템 설계는 어떻게 이루어 집니까? UML을 사용하십니까? 아니면 인터페이스와 주요 블록을 정의하는 문서입니까? 다른 게 있을까요?

종종 설계자는 주요 구성 요소를 식별 한 다음 구성 요소 간의 인터페이스 (보안, 속도 및 안정성과 같은 비 기능적 요구 사항 포함)를 정의하고 구성 요소의 내부 디자인을 개별 팀에 위임합니다 . 이는 모든 사람이 시스템에 대한 모든 것을 알 필요없이 팀이 자체 구성 요소를 설계하게하는 것 사이의 타협점입니다.

모든 조직에는 건축 설계에 대한 자체 표준 세트가 있으며 때로는 조직 내 프로젝트마다 다릅니다. 이 디자인은 팀이 코딩을 시작하기 전에 또는 가능한 빨리 시작하며 일반적으로 전체 목록이 아닙니다.

  1. 확장 된 요구 사항 및 범위 정의. 여기에는 더 높은 수준의 비즈니스 요구 사항을 충족시키는 사용 사례 또는 사용자 사례가 포함됩니다. 저는 개인적 으로 비 기능적 요구 사항에 RFC 2119 를 사용하고 싶습니다 . 디자인은이를 기반으로하고이를 거슬러 올라갑니다. 디자인의 일반적인 정의에 맞지 않을 수도 있지만, 이것도 종종 중요합니다.
  2. 고급 네트워크 또는 구성 요소 다이어그램 및 텍스트 페이지로 구성된 개요. 이는 고위 경영진에서 개발자 및 QA에 이르기까지 매우 광범위한 사용자를위한 것입니다. 이는 청중이 많기 때문에 UML 또는 정의 된 표기법을 거의 사용하지 않습니다.
  3. 개별 구성 요소에 대한 세부 사항으로, 위에서 언급 한대로 인터페이스 또는 API 간의 인터페이스에 중점을 둡니다. 인터페이스는 전제 조건 및 사후 조건 세부 사항이있는 대상 언어에서 메소드 서명으로 지정 될 수 있습니다. 구성 요소에는 클라우드 또는 데이터 센터에서 VM의 레이아웃 및 네트워킹 배열을 보여주는 것과 같은 네트워크 다이어그램이있을 수 있습니다. 관계형 데이터베이스에는 일반적으로 엔터티 관계 다이어그램이 있습니다.
  4. 알려진 경우 아키텍처 위험 및 완화 목록. 요구 사항과 마찬가지로 디자인 결정 및 절충 사항을 보여줍니다.

요컨대, 민첩한 프로세스에서의 시스템 설계는 기존의 폭포 프로세스에서의 것과 동일합니다. 그러나 민첩한 환경에서는 적은 양의 설계가 선행 작업으로 이루어지고 더 많은 부분이 컴포넌트 팀에 위임됩니다 . 핵심은 처음에 얼마나 깊이 갈 것인지 결정하고, 언제 결정을 내려야 할지를 결정하고 결정하는 것입니다. 여러 개발 팀에 영향을 미치는 결정, 특히 확장 성과 보안을 먼저 결정해야합니다. 이미 국제화 된 제품에 언어를 추가하는 것과 같은 결정은 매우 늦게까지 연기 될 수 있습니다.

초기 설계가 생성 된 후 건축가는 각 팀과 함께 작업하여 설계를 검토합니다. 작업 단위 (예 : 스크럼 스프린트)에 대한 추가 디자인 또는 디자인 변경이 필요한 경우, 건축가는 작업 단위가 시작될 때까지이를 사용할 수있게하는 것을 목표로합니다. 또한 건축가는 영향을받는 팀이나 이해 관계자에게 변경 사항을 전달할 책임이 있습니다.


3
이것은 애자일 팀에서 아키텍트의 역할이 무엇인지에 대한 훌륭한 해답이지만 스프린트 개발이 시작되기 전에 시스템 디자인이 무엇인지 에 대한 질문 과 그에 대한 모범 사례 에는 실제로 대답하지 않습니다 .
maple_shaft

@maple_shaft 디자인에 더 집중하기 위해 답을 확장했습니다.
akton

3
중요한 다국적 환경에서 몇 년간 민첩한 환경에서 일한 다른 건축가로서 가치가있는 것은 바로 그 일입니다.
Rex M

12

면책 조항 : 나는 민첩한 코치 / 건축가가 아닙니다. 이것은 내가 일한 민첩한 프로젝트에서 보았으며 잘 작동한다고 생각합니다.

Agile이 아키텍처를 수행하는 방법에 대해 잘 정의되어 있다고 생각하지 않습니다. 애자일은 개발 방법론과 실습에 중점을 둡니다. 반면 UML은 민첩한 아키텍처를 전달하는 언어 일뿐입니다 (프로젝트와 팀에 적합한 경우 사용).

실제로 적용되는 아키텍처의 원칙 중 하나는 책임있는 마지막 순간에 결정을 내리는 것입니다. 프로젝트 시작시 모든 결정을 내리지 않은 경우, 특히이 단계에서 정보가 가장 적기 때문에 결정을 내리는 것이 좋습니다. 시간이 지남에 따라 아키텍처를 "진화"하는 결정을 내릴 수 있습니다. 예, 이것은 약간의 재 작업처럼 보일 수 있지만 환경, ​​요구 사항, 불가능한 것 등에 대해 새로운 것을 배웠기 때문입니다.

코드가 정말에 부합되지 않는다 - 당신이 피하려는 중요한 것은 아키텍처 부패입니다 어떤 특정 아키텍처 단지 얽힌 엉망이다. 진화하는 아키텍처와 비교했을 때의 주요 차이점은 후자의 경우 정기적으로 고의적 인 결정을 내리고 명확한 이유를 가지고이를 문서화 한 다음 코드가이를 따르는 지 확인하는 것입니다.


0

테스트 중심 개발을 수행 할 때 모듈을 독립적으로 테스트하는 테스트 코드를 작성합니다 (= 가능한 한 다른 모듈과 무관)

테스트 코드를 쉽게 만들 수 있도록 쉽게 조롱 할 수있는 다른 모듈에 대한 인터페이스를 소개합니다.

이 방법은 측면에 영향을 미치므로 모듈 간의 결합이 가능한 한 작은 아키텍처를 자동으로 얻는 것입니다.

제 생각에는 tdd도 건축 작업입니다.


예, TDD는 아키텍처 작업이지만 소프트웨어 구성 요소입니다. 내 질문은 실제로 대규모 프로젝트의 아키텍처가 민첩한 원칙을 사용하여 어떻게 작성되는지입니다.
BЈовић
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.