Title: Lessons from Chapter 48 of "The Law of Construction"
I. Introduction
First, briefly explain my current learning situation in software engineering in the past two weeks: because the learning progress in the classroom is relatively fast - the two-week course has been from software requirements analysis to structural analysis and design. Obviously, our software engineering team has The progress is definitely not that fast, so I had to speed up reading the book "The Method of Construction" while learning the textbook knowledge, starting from Chapter 4 Two-person Cooperation, Chapter 5 Team and Process, Chapter 6 Agile Process, From Chapter 7 MSF to Chapter 8 Requirements Analysis, I feel more and more that this book has something we can learn from in addition to a lot of business and commercial competition and development (after all, it is not a professional textbook for students) Yes, except that Chapter 7 is devoted to the Microsoft solution framework, I will not go into details, I will list what I think is the focus of each chapter. (especially the requirements analysis in Chapter 8)
2. Chapter 4 - Two people working together
If two people cooperate, they first talk about code style specifications and design specifications. Since two people want to cooperate to complete the code, they must first formulate the relevant specifications of the code. The main principle of the former is ** concise, easy to read, no ambiguity. ** , including indentation ( ** It is recommended to use 4 spaces instead of the Tab key, because the readability is just right, and it will not display different lengths due to different situations ** ), brackets ('{', '}' are on an exclusive line), Case ( ** All type/class/function names are in Pascal form - all words are capitalized, all variables are in Camel form - first word is lowercase followed by the word Pascal; class/type/variable: Nouns or compound nouns, functions: verbs or verb-object compound words ** ), notes (clear what, why and where to pay special attention). Design specifications involve programming, the relationship between modules, design patterns, etc., and many are closely related to specific programming languages. (The general principles also have many details, which are omitted here)
Then it emphasizes code review, first of all its correct definition should be ** to see whether the code solves the problem correctly within the framework of "code specification". ** , and code review is generally peer review, it is best to find and fix bugs in the review process early, he talked about adding specific tags such as $todo:-----,$review,$bug during review. .....discuss the issues marked with $review one by one. After the review, the flag should be cleared, and before a milestone or official version is released, the other two should also be cleared. ( **Here what he did after the code review also used a philosophical sentence from Ma Yuan's class: people can't step into the same river twice, and it means that programmers can't make the same mistake twice. PS: It feels a bit far-fetched**)
Finally, he talked about pair programming in textbooks, starting from the extreme programming embodied in the idea of maximizing the effective development methods of code review—being in a state of code review all the time, and talking about pair programming. the why and how. The key point is how to maximize the role of "navigator" among the two roles of pilot and navigator in pair programming! The relationship between the leaderless and the led is a gradual process of mutual learning and running-in. It needs to go through many stages, and it also reflects the three levels of evaluating people (from the innermost essence and inherent attributes, to the middle level). Habits and Motivations to Outermost Behaviors and Consequences) - on how to give feedback properly. ** , the blog URL of the case and discussion is attached at the end of this chapter: ** http://www.cnblogs.com/xinz/p/3852241.html **
3. Chapter 5 - Teams and Processes and Chapter 6 - Agile Processes
First of all, it introduces the mode of the software team, including the happy and casual swarm mode, the attending physician mode of "one person works and the other makes soy sauce", star mode, community (not meaning: casual), amateur theater, symphony, jazz (personality) expression), functional teams, bureaucratic (“boss-driven”) models, etc.
Then explained the development process of software development, which corresponds to Chapter 3 in the textbook. I have written the re-change model and the ** waterfall model - emphasizing the importance of documents and requiring the backtracking of adjacent steps, but at the same time the biggest limitation is that the final product appears at the end, the steps are separated, and it does not adapt to changing needs! ** , sashimi and sub-waterfall models after the deformation of the waterfall model, ** RUP (Rational Unified Process) - different types of work are called Discipline (subject) or Workflow (workflow), the stage is from Inception (initial, to life cycle) Target Milestone) -> Elaboration (refinement, reaching the life cycle structure Milestone) -> Construction (reaching the initial functional Milestone, at this time the product version is often referred to as the "beta" version) -> Delivery (focusing on product release milestones) ** , the so-called Milestone (milestone) is the end of a large stage, and there can be several iterations in each stage (the business value is incrementally delivered in different time periods and across iterative fields, and the RUP hump diagram reflects the role of different roles in each stage. The degree of involvement, including the workflows (business modeling, requirements, analysis and design, implementation, testing and deployment), thus RUP resembles a waterfall model on a large scale and an iterative model within each phase.
Among other processes, it mainly includes the agile process explained in Chapter 6, which corresponds to Chapter 4 of the textbook. First, I put forward 12 principles of agile development and translation types in the book. In fact, agile is a collection of many methodologies for software development. The employees in "The Mountain Company" are teased as love feet), explaining what agile is in the book - a trend of thought or values, covering methodology (the famous one is also caressing the younger brother FDD-Feature Driven Design, XP (extreme programming)), The methodology is based on proven best practice methods (eg Bumdown, Sprint Backlog, Stand Ups, CI, BDD, TDD).
In Analyzing SCRUM, the process is outlined in four steps: ** Find out what needs to be done to complete the product - Product Backlog (backlog, open issues or product orders) -> Decide on the current Sprint (implementation of the entire product) Divided into several interconnected sprints) Things to be solved - Sprint Backlog -> Sprint (involving Scrum Meeting, Daily Routine (Stand - Stand up to report what was done yesterday, what was done today and the problems encountered) ) will..) (Mentioned the concept of Burn Down Chart and Kanban, and explained that this stage is Time-boxed) -> Incremental Release ** Finally at http://www. cnblogs.com/xinz/p/3852390.html This blog discusses the appropriate time to choose agile, agile reference materials: http://www.cnblogs.com/xinz/archive/2012/02/20/2358888. html, Three Examples of the Daily Scrum Process of the Modern Software Engineering Student Group: http://www.cnblogs.com/ustc_msra_ase/archive/2011/02/17/1957382.html http://www.cnblogs.com/southseven/archive /2011/11/20/2255685.html http://www.cnblogs.com/Gun-N-Rose/archive/2012/09/29/2708889.html
Time reasons, and then continue to supplement this experience - focusing on the needs analysis in Chapter 8.
4. Chapter 8 - Requirements Analysis
First, it introduces several steps for software teams to accurately and comprehensively find requirements: 1. Obtaining and guiding requirements (Elicitation) 2. Analysis and defining requirements (Analysis & Specification) 3. Validation requirements (Validation) 4. Management in the life cycle of software products Requirements (Management): The software requirements are divided from different perspectives into: functional requirements for products, requirements for product development processes, non-functional requirements (service quality requirements) and comprehensive requirements. Since the author is more from the perspective of a company or an actual large software project to introduce how to analyze requirements, the process also includes focus groups, in-depth interviews, usability surveys, and card sorting with product stakeholders. Reference is not a great place. But he also talked about the method of user survey questionnaire in the 4th point method of obtaining user needs - user survey (we also completed a small-scale questionnaire survey in combination with our actual situation, which seems to have its advantages at present).
In User Survey, he mainly analyzes some common mistakes of investigators: ** a. Inaccurate definition of questions b. Use of ambiguous adjectives and adverbs to describe time, frequency, price, etc. c. Make users spend extra effort to answer questions d .The question has a guiding tendency f. The question involves privacy or commercial secret details, etc.** At the same time, he gives the suggested method: ** a. Fully open-ended questions (allowing users to speak freely) b. Two-choice questions ( Yes/No) c. Multiple-choice questions d. Ranked-choice questions (fill in 1.2.3. by priority) **
Then he analyzed the competitive requirements. In order to allow the team to come up with new innovations that surpass others, he proposed a more systematic framework - the NABCD model, specifically Need, Approach, Benefit, Competitors and Delivery. In the positioning of the subsequent functions, the four-quadrant method and two pairs of functions and requirements (killer function core/peripheral function Context and necessary requirements/auxiliary requirements) are defined. The four-quadrant method is given for the different combinations of two pairs of requirements and functions. The recommendations corresponding to each quadrant are ultimately to allow the ** team to clearly see the position of the functions they are interested in, and tilt to the place where differentiation and unique user value can be generated under certain resource conditions. **
Goals, plans, and determinations are defined at the end, with many examples to illustrate. Among them, he mentioned that ** in agile development projects, the team goal is to write software to satisfy users, not to hesitate to "guess correctly" - to quickly get a coarse-grained estimate, and then enter the implementation phase . After a team goes through successive milestones, it looks back at the difference between the initial estimate and the actual time spent. ** Gain experience from one project! Two blogs of the previous student software projects shared in the two books: http://www.cnblogs.com/bawangyishan/archive/2011/03/03/1969771.html http://www.cnblogs.com/se2011/archive /2011/03/04/1971185.html
This is probably some of the highlights of Chapters 4-8 of this book.