A reflection on the eight principles of MSF

The first principle is also one of the most fundamental principles in MSF that promotes information sharing and communication. One feature of this principle is that all the work of a team member is recorded, including a detour, a bug that has been debugged, and the part that has been resolved. For new members of the team or members who have not previously participated in MSF development, the first step is to learn to "hide your own mistakes" because everyone wants to show their perfect side, but in order to provide experience for team members and to truly share information, the work that has been submitted cannot be deleted. This reminds me of the first pair programming because I was not familiar with TFS, I accidentally checked my code into the server, and then contacted the TA to modify it, but the TA said no, now I understand why not.

The second principle is to require team members to have a common vision. The author has put forward three requirements for this vision: clear, through efforts to achieve and have a guiding role. Such requirements can be said to be not only applicable to MSF, but almost all of the vision should meet these three requirements. An ambiguous vision, or a vision of what a team has achieved, or a vision of what a space pan does not know what to do, is not conducive to project realization. However, for the project's vision by WHO, the author said that should be a "visionary person" proposed, and then to everyone to discuss, the problem here is that the author does not seem to have much to tell the prospect of the proposed based on some of the considerations, user needs? Technical difficulty or level of developer? The other question is, how does the vision of such a great-sounding word play such an important role in the software development process?

The third principle is the empowerment and trust between team members. What attracts me most is a proposal for a team event: The Next top-up time, by the member responsible for the development of their own timetable, the benefits of this is to improve everyone's initiative, because it is their own plan, should have already considered the development of the problems encountered, but also consider their own technical level, It is certainly a very good way to give full consideration to the role of personal factors in development, which is more motivating than others to deadline for themselves. So as the project manager, since the plan is developed by the developers themselves, then what does he do? In the author's opinion, developers need to follow up the progress of the project in real time, and timely status developers to provide technical assistance, such as through organizational learning to solve some new technical problems, in order to avoid failure to submit work on time, managers can certainly not wait for acceptance, but participate in the whole process. Finally, the ability to give full play to team members, that is, each member can be a leader in their own areas of expertise, leading the team to do better in the relevant work, which is of course, the performance of full empowerment and trust.

The fourth one checks with the third principle. At the end of the third principle, the author raises a question: How to avoid "empowerment and trust", everyone has a lot of ideas, but can not reach a consensus. The fourth principle speaks for each of its duties. The core is that everyone is responsible for their own project responsibility, mainly reflected in which link appeared the problem, the person in charge of this link to make explanations and even bear the corresponding punishment, we in the completion of a module task, of course, will ask other people's opinions, others will be willing to help us, But others suggest that the proposal may be too idealistic, because he is not responsible for the completion of the task, nature can not put himself in the thinking, so, only the responsibility of binding to the developer, can be urged to seriously think of other people's advice, serious decision-making, will not appear to be led by others to walk and delay the progress of the situation. And, on the other side, when we make suggestions for others, we should also pay attention to the feasibility of the proposal, and do not put forward some meaningless or even counterproductive proposals in a bystander manner.

The fifth principle is a principle that I doubt the comparison. The principle itself is simple, because after all, software development is a business process, and most of our software projects are expected to be profitable, which is understandable. But are there some software projects in itself that are not intended to be profitable? My answer is yes, happily, the author also mentioned the issue of open source and closed sources, unfortunately I do not have so much knowledge reserves, and can not find a good "open source" project to analyze, but in my opinion, some of the open source project itself is motivated by some deeper ultimate value, Specifically what the ultimate value in this article is also inconvenient to explain, I would like to express the question is more like reading through the process of the book is always a problem: This book is a real-combat book, resulting in its style is too professional, with my very annoying entrepreneurs, very appreciative speaker Yonghao words, this is too no feelings. With this principle in mind, I would like to take this opportunity to pay tribute to some of the great open source projects, such as the Goagent project group based on Google AppEngine, to pay tribute to a number of projects dedicated to providing fair Internet services for all.

The next principle is about agile development. This is a soft work with our practice closer to the principle, it happened that we recently just because of the changes in demand on the back of the plan to make a corresponding adjustment, the original to do a more interesting function to give up, because the next group does not use this data. The author said that a paranoid pursuit of quality causes software to keep up with the changes in customer demand, which is of course the software development team must balance the quality and needs of the warning, at present, my experience is not profound, but this is the first time to compare academic contact with the guiding ideology of software development, need to study seriously.

One of the following principles is still related to quality, accurately speaking and how quality is treated. Quality is, of course, the most important delivery condition in the software development process, you can not give users a bug flying software? Is that a developer who has to pay the user a bug-free software? The answer is straightforward, but it is: Impossible, the quality of excessive effort means that in order to meet customer needs, improve the user experience, and so the cost of less effort, and a software is the most important to solve the user's problem, if you can solve the user's current problems, should be delivered sooner, not to wait until the software is perfect, There may be a tragic example of the last principle. So the author calls this principle investment quality, investment means quality is not the ultimate pursuit, but through the pursuit of quality to achieve greater purpose: to solve the user's problems.

The last principle is about learning experience, we also do the alpha stage of the hindsight meeting, and this principle is also throughout our study life, I will not repeat.

A reflection on the eight principles of MSF