민첩한 프로젝트에서 아키텍처를 어떻게 제어합니까? [닫은

Question

유연한 소프트웨어 아키텍처를 가능하게하는 "좋은"디자인 결정으로 프로젝트가 구축되도록하려면 어떻게해야합니까?

한쪽에있는 팀에 건축을 완전히 떠나고 모든 아키텍처를 다른쪽에있는 몇 명의 개인에게 통제하게하는 것 사이의 균형을 어떻게 유지합니까?

"아키텍처 그룹", "아키텍처 레이블"또는 그와 같은 것들이 있습니까?

Answer 1

민첩한 접근 방식의 전제 조건은 이미 사용하는 방법을 알고있는 아키텍처입니다.

아키텍처가 잘 정의되지 않고 완전히 이해되지 않으면 실제로 민첩한 접근 방식을 취할 수 없습니다.

아키텍처의 작동 방식과 다양한 조각이 어떻게 맞는지 보여주는 기술적 스파이크가 필요합니다. 이를 수행 할 수는 있지만 예비 스프린트이지만 사용자에게 직접 릴리스로 이어지지는 않습니다. 그들은 당신이 사용할 수있는 아키텍처에 도달하는 데 필요한 특별한 경우입니다.

이 "아키텍처 이해"노력을 지나면 사용자를 위해 직접 릴리스로 이어지는 스프린트를 실행하기 시작할 수 있습니다.

Answer 2

I could explain how I would do it, but this says it better than I could.

Answer 3

I would also recomend reading fowlers document Is Design Dead, as far as I understand his arguments if you consider all the agile practices as a whole then you gain the freedom to make large changes and so can evolve an architecture.

Refactoring works most effectivly with continuous interation, testing is enhanced with TDD and continuous integration ... I could go on. Evolving 'architectures' are only limited if you are unable to make the large changes requied to correct 'mistakes'.

Additionally, I think you have an architect as a stakeholder in the project, they contribute user stories which are in turn delivered back to the architect.

This is also a good way to utilise pair programming with the architect working as part of the pair. In this context the architect is not so much a dedicated person more a hat that a member of the development team wears while pair programming.

I think XP does not diminish the role of the architect (and architecture) it just places the resonsibility on all team members to deliver and spreads the cost over the lifetime of the project.

[edit]

Per other comments dont be afraid of some upfront planning, itteration zero is a good time to try and chart a bit of a plan, just dont get to strict about delivering it to a specific time scale.

Answer 4

In my experience, the best way you do this is have experienced developers / architects working on the projects that drive the architecture vision on a day by day basis.

I would suggest its up to the dev lead on the project to control the architecture and to ensure that all new work fits in with it.

Answer 5

I handle this by doing some planning up front -- generally, I have some prior experience with a similar application to help with this. If not, I'll do some exploration in the space to get an idea. Once a basic architecture is laid out, I'll start developing with it in mind based on my prioritized stories. Then, I refactor as I go along to address shortcomings or errors in the architecture.

Answer 6

Without doing big design up-front, there is usually a basic design that applies to the each project. Usually, this defines basic layers to respect in the design of the application. Most other design decisions are made by each developer.

Our development process is based on short development bursts with frequent peer review. The quality of each developer's architecture decision is validated at peer-review time. This also includes validating that the code follows the product architecture.

Depending on the type of project and the tools that are available, we also use tools like macker to automatically validate the integrity of the layer-cake.