Tom holander, Microsoft's Solution Architect in Australia, gave a speech entitled "architect role in Agile teams" at the teched Australia Conference. In his speech, he discussed his work as an architect leading the agile team.
When talking about the role of architect, holander refers to the "Solution Architect" or application architect. He is not an enterprise architect or other professional (specialized in specific fields, such as messaging or infrastructure ).
The team of holander adopted the four-week iteration and the final stabilization phase (several daysCodeImplementation of daily standing meetings, continuous integration of daily building and automated testing, and many roles:
- Pjm-- The project manager, similar to the scrum master, ensures that the team follows the process
- PDM-- The product manager, also known as the customer or product owner, determines what the product looks like.
- Architect-- Solution/Application architect
- Developers-- Development Team
- Tester-- Test team
- User Experience designer(UX) -- User Experience Team
- Publisher-- Responsible for building and releasing, and responsible for maintaining the building process
Hollander proposed ten most important things for the Solution Architect to succeed in the agile team:
- Exactly enough pre-design-- In addition to very simple projects, pre-design for a certain period of time (for example, one to two weeks) is absolutely necessary, and the length of time will depend on the type of application-network applicationsProgramWhat are the basic functional requirements of Smart Clients, mobile or batch processing, long-term solutions, or compromise and temporary solutions. The purpose of the pre-design is to determine what technology is used-for example, Asp. net or MVC, what types of applications are-2, 3, or service-oriented applications, how to access the database-stored procedures, entity frameworks, LINQ, and dependency injection (DI ). A short document contains all this information for your reference.
-
- Starting from vertical parts-- Starting from a small part of a function (such as a logon page), we try to vertically divide it into multiple layers, so as to combine all the technologies decided in the previous stage. This will verify the correctness of design decisions, and all technologies can work together, and will show developers the pattern they can follow when developing new code. If you find that the initial design decision is incorrect, it is a proper modification time.
-
- Just-in-time design in each iteration-- In the middle of each four-week iteration, project managers, product managers, and architects should gather to discuss the requirements to be fulfilled in the next iteration, so that each of them agrees to these requirements, more important things are put in front, and everyone is very clear about everything. These discussions will last for a week in a less obvious way in the current iteration. In the next week, that is, the last week of the current iteration, the architect reviews the requirements of the next iteration and makes necessary design decisions so that the team can work on these decisions in the next week. If the requirements are quite different from those in the past, the architect will develop some prototypes, write some code to prove the concept, and draw some charts, compile all these theme sets into five pages for reference. This is not to develop a detailed design solution that is conducive to developers, but to ensure that new requirements meet global requirements.
- Trust your team... but stay with them.-- This is related to the relationship between architects and developers. The architect needs to make sure that he has not exceeded his role and has no exclusive "Decision Making" pleasure, making the work of developers boring. At the same time, the architect needs to provide guidance to the team to solve the difficult problems that may cause the developer to pause. Every day, architects should contact every developer to learn what they are doing and help them when they encounter programming problems. This kind of help is especially needed when developers do not like to seek help and try to spend a whole week from solving the problem. This relationship also applies to pjm and the test/build/release team.
-
- Write code!-- The architect should know the quality of the Code so that he can have a better understanding of the impact of his decision. He can also understand when refactoring is necessary. Architects who write code have a better reputation in the development team. That is to say, holander does not agree with the distinct responsibilities of (design and development. He also believes that the architect is still an architect and he does not have to be as good at coding as a common developer.
-
- Participate in everything-- It is advantageous for architects to participate in all project-related meetings: design, development, code review, and requirement planning, because he can view what is happening from a broader and clearer perspective, and he can tell the product manager the potential consequences of his decision, this helps him/her avoid making wrong decisions in the early stages.
-
- Promote Quality Culture-- A successful team, a team that everyone wants to become one of them, is built on the Quality Culture: No one is cutting corners; no one submits poor code; if there is a major defect in the design, it will never be unknowingly mixed; everyone is honest and open, seeking the best results of the entire team. Hollander admitted that building such a team is difficult, but not impossible. First, architects should create some rules at the beginning, which will not change over time because developers do not like them. For example, you may decide to write unit tests, or perform code reviews before each submission, including the Code submitted by the architect. If the reviewer (or any one of the teams) does not recognize the code, the code cannot be submitted.
- Know when to change-The architect should be flexible and ready to change the design whenever the design needs to be changed. Early solutions may no longer be suitable, or new requirements may require different approaches.
-
- Shield random requests from external sources-- Although this is usually the responsibility of the Project Manager/scrum master, architects can protect the team from the influence of external requests, which often disperses the team's energy and waste of real work time. For example, a business team may want to accomplish certain things in a specific way, and their requests are not completely reasonable or necessary.
-
- Writing documents... but only when someone needs to read them-- Hollander does not advocate recording everything or writing any document at all. He believes it is necessary to strike a balance-write only a certain number of documents that are really helpful and someone will read. Documents are a good carrier for recording detailed design decisions (such as data models. Iterative Design Decisions, although they are discussed by the entire team at the beginning of the iteration, we recommend that you record them in five pages of documents, in case developers do not remember the comments of architects in the future. When developers and architects leave the project and join other projects, new project owners can also use these documents to understand the ins and outs of certain decisions.
To sum up, he pointed out that the architect should ensure that he is part of the team both theoretically and practically. The architect should not write all the code, but only a small part of it. He does not test or deploy the code, but must ensure that the entire process goes smoothly.
Source: http://www.infoq.com/cn/news/2010/09/Tips-Architect-Agile-Team;jsessionid=2126E466597A70D88AA98D82406777D5
