Read mountain migration and modern software engineering Handouts

I have read some experiences from the migration path and modern software engineering handouts of Mr. Yan Xin. Let's talk about it here. As a college student, without a real software engineering practice, there must be something short-sighted and lacking in words ..

I mainly want to talk about agility and some questions about team roles.

Agility

Agility first. English is aglie, a very popular development model. The values of agile development are different from those of previous Software Engineering:

Individuals and interactions over processes and tools
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Available Software over complete documentation

Customer collaboration over contract negotiation
Collaboration with customers over contract negotiation

Responding to change over following a plan
Response to changes over compliance plans

From its values, we can see that agile development emphasizes changes and communication over planning and tools. This is not a denial of the importance of the program, but agility is more concerned with the former, that the impact of changes in the development process on the final quality of the software should be greater than the various rules set at the initial stage of the project; it is believed that the communication and discussion between developers can improve the quality of software products better than simply relying on excellent tools.

So, if a software decides to adopt an agile development model, is it necessary to completely follow the agile step? Here, Mr. Yan Xin introduced two kinds of agility in his handout: We follow an agile process and We follow the Agile process. The former means that the team is flexible, while the latter means to act in full compliance with agile "regulations. Obviously, the latter should be abandoned, just as agile is intended to be flexible and fast. If we fully abide by a "Charter", what should we talk about flexibility and speed? Focuses on the essence rather than the appearance, not just on agility, but on other places.

What are the characteristics of agile with so many arguments? I think its biggest feature is fast iteration and change inclusiveness. In the process of multiple iterations, problems are constantly corrected, solved, and changed. Thus, an excellent software product is generated.

What kind of teams can use agile models? From the mountain migration and modern software engineering handouts, as well as some of my own views, I believe that there are not many teams and members are familiar with each other and have a tacit understanding of each other, there are no major technical difficulties, members are responsible, and Members understand the essence of agility.

Is agility omnipotent? Obviously not. Obviously, for software engineering, there will be no silver bullet, and any method will have its strengths and weaknesses. This is already explained in his blog. Here, I have a question. This is also the most controversial question in the blog comment of Dr. Yan Xin-Does agility mean low reliability? "Not high, tolerance and frequent mistakes" is a comment on agile in the blog, but the following comments have a big objection to this. What is the scope of application? What kind of engineering absolutely cannot use agile methods, and what kind of engineering is most suitable for agile methods?

For agility, many people have raised questions about their own ideas. For example, @ Chen Hao, a left-ears mouse, claimed to be an agile development terrorist, some of his articles, such as "more time to write less code", have written some of his views.

Role

Here I am talking about PM, Dev, and Test. Here, I only have a few questions. I hope I can get some answers. As for my experience, because I have no experience, I simply rely on reading and I may just say something that is not nutritious ..

About PM: responsible for communication and coordination, master the project progress, the quality of PM has an important impact on the quality of software.

About Dev: The most important group of people in the team. In a team without a boss, Dev should be the right person (pig in pigs, chickens, and parrots ). Write code and perform unit tests on your code to avoid bugs.

About Test: identifies bugs in the project. Now, I have a question. In our current project, if there is only one Test, should this Test have a clear understanding of the project as a whole? Normally, Test should be responsible for Module Testing and integration testing, but the modules of our project cannot be integrated together (for backend functions without interface ), how should we perform integration testing or not?

That's it.