7
공식적인 아키텍처 사양은 민첩한 개발과 어떻게 맞습니까?민첩한 개발 및 아키텍처
나는 스크럼을 생각하고 있는데 공식적인 유물 가운데 건축에 대한 언급은 없다.
최초의 제품 백 로그를 조립하기 전에 아키텍처가 "우연히"(말하자면) 발전했거나, 비공식적으로 설계 했습니까? 아니면 4 + 1 스펙과 같은 일을 할 여지가 있습니까?
A
답변
14
민첩성은 "지금해야 할 일만 수행하면되고, 더 많은 일이 필요할 경우 나중에 리팩토링 할 수 있습니다"라고 종종 설명됩니다.
오해의 소지가 있습니다. 그것은 "빨리 지금 무언가를 교묘히 살펴본 후 미래에 더 많은 일을하기 위해 그것을 업그레이드하는 방법을 연구합니다"라고 읽을 수 있습니다. 고통과 기술적 부채의 세계로 이어질 것입니다.
어떤 시스템이든 디자인이 필요합니다. 작고 간단한 시스템의 경우이 디자인이 마음에들 수도 있지만 시스템을 시작하기 전에 생각할 필요가 있으며 최선을 다하는 방법에 대해 생각해야합니다.
그래서 IMHO는 설계를 애자일 방식에 포함시키는 올바른 방법은 시스템이 궁극적으로 수행 할 것으로 예상되는 사항을 충분히 이해하고이를 수행하는 방법을 설명하는 광범위한 스트로크를 작성하는 것입니다. 다리를 태우지 않는 유연한 디자인을 생각해보십시오. 그러나 모든 너트와 볼트에 대해 공식적인 세부 사양을 작성하는 데 시간을 낭비하지 마십시오. 하위 시스템의 위치와 방법을 알 수있는 수준까지 디자인 할 수 있지만 구현해야 할 때만 설계 할 수있는 "블랙 박스"로 간주 할 수 있습니다.
민첩한 개발은 공식적인 아키텍처를 배제해서는 안됩니다. 즉, 완성되었을 때 모든 비트가 잘 어울리는 공식 아키텍처 만 디자인하면된다는 의미입니다. 필요할 때만 가능합니다. 때로는 여전히 정교한 디자인이 필요합니다.
1
귀하의 범위에 따라 다릅니다. 주어진 수 그린 필드 수 있습니다. 단지 충분한 시간에 건축술. 첫 번째 테스트를 작성하고 지속적인 통합을 할 수있는 무언가가 필요합니다.
이 문서는 문서이므로 누가 그 문서를 필요로하고 무엇을 할 것입니까?
- 팀에는 기능을 배치 할 위치와 테스트 위치를 설명하는 데 필요한 것이 있습니다.
- 팀을 성장시켜야 할 때 새로운 사람은 소개를 좋아할 수도 있습니다.
- 마케팅에 아름다운 그림이 필요할 수 있습니다.
- 누군가는 하드 및 소프트웨어를 구입하고 설치해야 할 수도 있습니다. ...
1
스크럼은 주로 프로젝트 관리 기법으로, 아키텍처를 언급하지 않는 이유입니다.
가능한 한 아키텍처가 점진적으로 정의됩니다. 구현은 레이어별로 수행하는 것이 아니라 엔드 투 엔드 (end-to-end) 작업을 통해 각 계층의 일부를 구현하는 데 도움이됩니다.
아키텍처 의사 결정은 되돌리기가 어려울 수 있으므로 시스템 및 고객 요구 사항에 대한 지식이 많은 마지막 책임있는 순간에 잘 처리되어야합니다.
공식 사양에 대한 강력한 요구 사항은 없습니다.
0
애자일은 아키텍처에 중점을 두지 않습니다. 이렇게하면 나중에 소프트웨어를 사용할 수있는 가능성이 줄어 듭니다. 왕좌 게임 (Game of Thrones) 방법론은 애자일의 장점과 한계를 배웁니다. 보다 미래 지향적이고 확장 성이 뛰어난 소프트웨어를 만듭니다. Digital Animal은이 방법론을 수립하기 위해이 기사를 작성했습니다. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/
위의 품질 응답에 추가하여 : 사용자가 볼 수있는대로 요구 사항의 정의를 디자인에 지정하십시오. 이것은 사용자 및 결국 사용자 인터페이스 (모든 소프트웨어 프로젝트에서 최우선 적이어야 함)에 초점을 맞추면서 도메인 모델을 구상하는 데 도움이됩니다. –