Reading the 6-7 chapters of the Law of construction

The sixth chapter Agile process

Agile Development Manifesto--
Individuals and interactions outweigh processes and tools
Work-ready software trumps all-encompassing documentation
Customer cooperation is better than contract negotiation
Responding to change is better than following plan

The above declaration is abstract, based on this concept, the following is the Thoughtswork consulting company's respected N Agile Development Practices:
Iteration
Iterative development. Working software trumps all-encompassing documentation. Therefore, agile development advocates dividing a complete software version into multiple iterations, each of which implements different characteristics. Significant, high-priority features are prioritized, and high-risk features are implemented first. The prototypes of the software were developed early in the project and based on this prototype in successive iterations of the night. The benefits of iterative development are: Early coding, exposing the technical risks of the project as early as possible. Enable customers to see operational software as early as possible, and offer optimization advice. You can deliver available versions to different customers in a phased and early stage.
iterationplanningmeeting
Iteration planning meeting. At the start of each iteration, the entire development team is convened, the iteration planning meeting is held, and all the team members speak freely, articulate the development tasks of the iteration, and answer the questions.
Story card/story wall/feature List
In each iteration, the architect is responsible for splitting all the attributes into multiple story Card. Each story can be considered an independent feature. Each story should be developed in up to 1 weeks and delivered in advance test (pre-test). After all the stories in an iteration have been developed, the Test team will perform a complete test. Throughout the testing process (Pre-test,test), based on daily build, the test group is always tested with the latest compiled version removed from the configuration library on a daily basis, and developers are also ready to modify the questionnaire submitted by testers and to fit into the configuration library.
One feature of agile development is open-work, full communication, including testers and developers working together. Based on the development of the story card, the team will place a whiteboard in the Open office area with all the story card affixed to the current development status in 4 regions, namely: untapped, developing, pre-testing, testing. The story card developer and tester moved the story card to update the status of the story card according to the development progress on story wall. This way you can have a very intuitive understanding of project development progress.
When developers start to develop a story, TA needs to find the corresponding tester to explain the story function, so that the testers have a consistent understanding, and begin to automate the development of system test scripts.
Standup Meeting
Standing meeting. Every morning, all the team members surround the story wall, open an efficient meeting, usually not more than 15 minutes, report development progress, ask questions, but not waste everyone's time to solve the problem immediately, but after the individual communication solution.
Pair Programming
Pair programming refers to a pair of two developer pairing codes. The benefit of pairing programming is that the code written after two people is more complete than one person, and some of the big directions are not biased, and some details can be fully taken into account. An experienced developer and a novice pair programming, can promote the growth of novice, to ensure the quality of software development.
ci/daily Build
Whether continuous integration and daily build capability is strong enough is an important foundation for the success of iterative development. Based on daily builds. The developer updates the written/modified code to the configuration library on a daily basis, automating the compiler to automatically remove code from the configuration library at least once a day, perform automated code static checks (such as pclint), unit tests, compile builds, install, system tests, and dynamic checks (such as purify). After the completion of these automated tasks, the report is output, and the message is automatically sent to the team members. If there are any problems, the relevant responsible person should be modified in time.
As you can see, the entire development group frequently updates the code, and some problems inevitably arise. The test department is continuously testing based on the latest code. Whether the new issues can be discovered and eliminated in time depends on whether automated unit testing and system testing capabilities are strong enough, especially automated system testing capabilities. If automated testing can only validate the simplest operations, the hidden dangers of new code will be difficult to discover and leave behind the project to create large risks. In fact, increasing the coverage of automated tests is the most difficult.
Retrospect
Summary and Reflection. After each iteration, the project team members convene a summary meeting to summarize the good practices and lessons, and follow up the development.
ShowCase
Demonstrate. After each story is developed, the developer calls the tester and demonstrates the software functionality so that the tester can fully understand the functionality of the software.
refactoring
Refactoring. Since the iterative development model developed a software prototype that could be run early in the project, the Code and architecture developed at the outset could not be optimal and exhaustive, so the code and architecture needed to be continually refactored in the subsequent story development. Iterative development requires a high level of architect. Because the architect wants to split a complete version into multiple iterations, each fall is split into a lot of stories, from an architectural standpoint, these stories must be very strong in succession, can be superimposed, not the subsequent development of the story completely overturned the early development of the Code and architecture, At the same time, it is inevitable that the code should be constantly perfected and constantly reconstructed.
TDD
Test-driven development. As mentioned above, iterative development is characterized by frequent code entry and frequent release. Test-driven development is an important means of ensuring that code is properly run and not broken at a later stage. The tests here mainly refer to unit tests.

Agile Software Approach

Corresponding to the people-oriented Agile project management and incremental delivery of agile requirements management, Agile Software Development provides a number of specific methods to guide the development of software practices, including refactoring, pairing programming, test-driven, continuous integration, etc., the following is a brief introduction to refactoring and pair programming.

1, refactoring.

Refactoring is to improve the design of code without changing the behavior of existing code. The purpose of refactoring is to eliminate the "bad smell" of code weight, and thus achieve the purpose of placing code rot.

Common refactoring techniques include "renaming", "Extracting new methods", "Packing members", "moving methods in the inheritance hierarchy" and so on.

Refactoring often targets design patterns and unit tests as a means of guaranteeing code correctness.

2, pair programming

Pair programming that is, two developers use a computer to develop, usually one person to operate another person, another to assist, after a period of time, two people exchange. This seemingly less than half of the development efficiency development approach has the following advantages:

First, all of the decisions are made by two people, and all the code is written in conjunction with two people, which greatly reduces the chance of bugs, thus shortening the time required for debugging.

Second, all of the code is understood by at least two people, which reduces the dependency of the code on the developer and prevents the impact of the developer's turnover on the project.

Agile Software development is tailored to modern commercial software. After several years of development, both in the development of the project, or in concrete practice, have formed their own characteristics, and the traditional way of development to contend with the chamber.

Agile Software Development is not a specific process, but an inclusive term (umbrella terms) that summarizes methods and methods that have a similar basis.

Chapter Seventh MSF

The Microsoft Solution Framework, MSF, is Microsoft's recommended methodology for software development, and MSF was launched in 1994, and MSF is constantly being updated as visual Studio releases, but no matter how it changes, There is still little change in the core of the MSF methodology.

MSF Fundamentals

1. Promote information sharing and communication (Foster open communication)The first principle, in the case of plain English, is that all information is retained and made public, that the discussion should include all the roles involved, decide to make it public, and inform everyone. Of course, the necessary protection measures should be taken for information involving technology secrets and security. 2. Working for a common vision (work toward a shared vision)we make a product, whether it is application software, industry software, or general purpose software, to define what the project aims to be.

(1) This goal must be clear, without ambiguity;

(2) This goal is not to be achieved at present and must be achieved through hard work;

(3) This objective is not vague, and it should be instructive to the work of the project members on a daily basis.

3. Full Authorization and trust (Empower team members)

Authorization (Empower) has two meanings: one is to give someone power and authority (Give authority to somebody: to Give somebody power or authority) The second is to give someone more confidence and self-esteem (Inspire Somebody with confidence: to give somebody a sense of confidence or self-esteem). in an efficient team, all members should be fully empowered, and they have the authority to fulfil their mandate within their own purview, while They also fully trust other colleagues to fulfill their commitments. Similarly, the team's customers (both internal and external) believe that the team can deliver on the commitments and plan accordingly.

4. Each role in the team responsible for the project (establish clear accountability and shared responsibility) has its own responsibilities , If there is a problem, the role will be responsible. 5. Value Business values (focus on delivering business value) The commercial value of a project can only be reflected when it is successfully released and run, soMSF Process patterns include the development and release phases. 6. Keep Agile and expect changes (stay agile, expect change)Software Engineering, the only constant is change. So just don't fantasize about the customer needs will be clear at the first moment, and then remain unchanged. Be aware that we are expected to change, not to expect change. Apart from external reasons, the team is also changing, and our mastery of technology is improving every day, and what we thought was impossible could become easier. Our understanding of the objective world and the software system is deepening every day, the original thought that the small details of the problem suddenly became a big problem. Even the original co-workers suddenly want to leave ... All of these require our team to remain agile. 7. Quality of investment (Invest in quality)The emphasis on quality leads to investment in quality, which leads to investment in people, processes and tools. 8, learn all the experience (learn from all experiences)MSF does a "milestone review" at the end of each milestone, and this review does not have to wait until the end of the project. The advantage of this is that you have a fresh memory of the recent successes and failures to provide more accurate and comprehensive feedback, and if you find an error, you can study the solution right away and validate it in the next milestone with practice. In addition, some good practices can be summarized and popularized in time.

At the end of the project, MSF recommends that experts outside the team be invited to host the "Hindsight" meeting, which will systematically summarize the team's success and failure lessons, as well as objectively evaluate some of the team's features and team development process management, which will enable team members to be objective, forward-looking, Problem-solving mentality to participate in the "hindsight" meeting, to avoid judgmental or mutual accusations.

9. Cooperation with customers (Partner with internal and external customers)

MSF Team Model

The MSF Team Model defines some roles and responsibilities for team sibling members, as shown in 2-2.

The MSF Team Model believes that any technology project must meet specific key quality objectives to be considered a successful project. If any of the roles fail to achieve their goals, the entire project is compromised. Therefore, each role is considered equally important and important decisions are made together. to put it bluntly, a project has many goals to achieve, and the MSF team model allows different roles to achieve these goals. At the end of a project, each character asks himself the question-have I reached my quality goal?

Finally, for example, the Test team (role: test) To ensure that "all the issues I find are resolved", the Test team will do the following two things:

(1) The problem of discovering products;

(2) Ensure that these issues are addressed.

It is important to note that ensuring that these problems are "handled" and "resolved" is not the same, some problems can not be solved at present, but there is a solution that satisfies the user, the project team cannot avoid these problems.

Read 6-7 chapters of the Law of construction