Now I basically read the whole book read it again, to my current experience, I can only recognize a portion of the contents of the book, the following is reading these days Harvest:
Why Tower of Babel is a failure of the project; they still lack what?
Two aspects - the exchange, as well as the results of the exchange - the organization. They can not talk to each other, so as to not cooperate. When cooperation is not possible, work came to a standstill. In this high soft engineering practice, I would have realized the importance of this sentence. Our project group of all code written by me, and my teammates helped me in charge of optimizing UI. I told him what I needed something, but he did exactly as he understood things a completely not what I want. I thought he and I said very clearly, but still lead our project here to waste some time. Concluded, I have a problem to communicate with him, there is his own for our project is not understood, it leads him to do according to his will and ideas when I was thinking errors.
How do teams communicate between each other it? By all possible means.
One. Informal means
a clearly defined relationship between internal groups and make full use of the phone, can encourage a large number of telephone communication to achieve a common understanding of the written document.
two. Conference
regular project meetings. Meeting, the team one by one brief technical presentation. This is useful, to clarify the hundreds of thousands of small misunderstanding.
three. Workbook
at the beginning of the project, should be prepared formal project workbook.
Tower of Babel may be a complete failure on the first project, but it's not the last one. The results of the exchange and communication - organization is key to success. Communication and organizational skills managers need to carefully consider and improve the accumulation of relevant experience and competence as important as the software technology itself.
The importance of the document;
I see the author read the whole book has been re-emphasized the importance of the document, he was very diligent about the need to respect the characteristics of lectures and excellent documentation document has to software engineers. But the results are very bad, they know how to write good documentation, but their lack of enthusiasm. Therefore, the authors used the method to move the carriage to the cash register to show them how to do the job. The results show that the effect of this approach is still quite good. What kind of documents we need in the process of developing it?
Different users require different levels of documentation. Some users only occasionally use the program, some users must rely on the program, some users have to modify the program according to changes in the environment and purpose. Use the program. Each user takes a while for the program described in the text. But most document provides only a very
small summary of the content, not user requirements, the verification process. In addition to use the program, but also must be accompanied by proof of some programs to run properly, that is the test case. Modify the program. Adjust or fix the program needs more information. Obviously, this requires an understanding of all the details, and these details have been recorded in the well commented list. And general user as a clear overview of the amendment by the urgent need.
I was impressed by the other's point of view is: To ensure the progress of a project is significantly delayed, the development schedule is very important. Schedule of milestones and completion time components. Milestones must be specific, clear, defined. Either reach a milestone or did not arrive, should not reach 80%. And my experience is that the development schedule is very important, and called for those who have a strong technical background, so as to problems encountered make more accurate estimates and may spend time.