Visual Studio Team architect Agile Software Development (Part III)

Before we begin, let's look at how we get to the user story list that we need to implement in the sprint: First, the team will evaluate the team development speed that the development team has developed in previous sprints, as well as the products to be developed (product Story). Backlog) a rough cost estimate. Based on these two evaluations, the development team picks up a candidate list of user stories from the product backlog and submits it to the product stakeholder (stakeholder) for discussion. In the process of discussion, with the further clarity and refinement of user requirements, the priority of the list may be adjusted accordingly. Does reviewing this process be the biggest difference between the agile development process and the traditional waterfall development process?

In the previous article, I introduced how the three core roles of the team in the development process (project management, development, testing) collaborate to define user stories. This collaboration mechanism is important because it not only enables all participants in the team to have a unified understanding of the product's design, but it also helps the team find some potential vulnerabilities in the product before entering the coding phase.

Of course, the communication collaboration mechanism within the team can also be extended to the implementation design and test planning phase. As I mentioned earlier, agile development does not imply that architectural design and documentation are not required. For any project with a certain degree of complexity, especially for projects where development teams are distributed in different places (like our visual Studio Team architect teams), writing and reviewing design documents is critical to achieving those complex functions. Our team has two ways of dealing with this. One way is: if the functionality is not very complex, and the parties have a good understanding of the design, the design itself is not a significant uncertainty, we will convene a brief review meeting, the development engineer responsible for this feature will prepare some simple design documents (such as class diagram and sequence diagram), in Explain his/her whole design ideas to the other team members. Team members review the design together and make comments about where the development engineer may be ignoring it. Test engineers can use this process to understand the underlying implementation ideas of development engineers, so that they can add the required white-box tests to their test plans. At the same time, the review process provides a chance for development engineers and test engineers to better differentiate between unit, acceptance, and functional testing.

[Note: This is a controversial point of view and can even be debated as a topic. My personal view is that redundant testing is a waste of valuable resources (such as engineering teams and machines) in the project team. I think since the ultimate goal of the test engineers is to ensure the quality of the product, why can't they use unit tests written by development engineers as part of product quality validation? ]

Alternatively, when the functionality is very complex or the design content is not well understood, we try to do a "Spike" (i.e., build a prototype system) and record the discovery. Our team, as well as some of the teams I've recommended to use this practice, have found that "temptation" is definitely a useful way to achieve specific functional implementations. Now let me show you the document template for the "Tempted" result: