Software Project Management Bible-man-month myth (medium)

Chapter 4 Implementation
6.1 even for a large design team, the design results must be completed by one or two people to ensure that these decisions are consistent.
6.2 The details of the definition must be clearly defined in the architecture that is different from the previous definition. The details of the definition should be consistent with the original description.
6.3 For accuracy, we need formal design definitions. Similarly, we need narrative definitions to deepen our understanding.
6.4 One of the formal definition and narrative definition must be used as the standard, and the other must be used as an auxiliary measure; both can be used as the standard of expression.
6.5 design implementation, including simulation, can act as a formal definition method; this method has some serious disadvantages.
6.6 direct integration is a way to enforce structural standards for software. [The same is true for hardware-consider the Mac wimp interface built in the Rom.]
6.7 "if there are at least two or more implementations at first, the (Architecture) definition will be more neat and more standardized ."
6.8 it is important for the architect to allow a telephone answer to the inquiries of the implementers and to record and sort and publish the logs. [Email is an optional medium.]
6.9 "the best friend of the project manager is the enemy he faces every day-an independent product testing organization/group ."

Chapter 4 Why does the tower of Babylon fail?
7.1 The Babylon tower project failed because of the lack of communication and the outcome of the communication-the organization.
Communication
7.2 "because the left hand does not know what the right hand is doing, the progress of disasters, unreasonable functions and system defects have emerged ." Due to various assumptions about others, the understanding of team members began to deviate.
7.3 teams should communicate with each other in as many ways as possible: informal and regular project meetings, briefing technical presentations, and shared formal project work manuals. [And email.]
Project work manual
7.4 The project work manual "is not an independent document. It is a structure that organizes a series of documents that a project must generate ."
7.5 "all documents of the project must be part of this (Work Manual) structure ."
7.6 The structure of the Work Manual needs to be designed as soon as possible and carefully.
7.7 a well-structured working manual has been developed in advance to "place subsequent texts in appropriate chapters" and to improve the quality of the product manual.
7.8 "every team member should understand all the materials (work manuals )." [What I want to say is that each team member should be able to see all the materials and the webpage can meet the requirements.]
7.9 real-time update is crucial.
7.10 The user of the Work Manual should focus on changes made after the last reading and comments on the importance of these changes.

The 7.11 OS/360 Project Work Manual began to use paper media, and was later replaced with a thumbnail.
7.12 today [even in 1975], shared electronic manuals are a mechanism that can better achieve all of these goals, be cheaper and simpler.
7.13 It is still necessary to mark the text using the change entry and the revision date [or methods with the same functions]; it is still necessary to follow the early-in-first-out (LIFO) Electronic change summary.
7.14 Parnas strongly believes that the goal of making everyone see everything is totally wrong; each part should be encapsulated so that no one needs or allows to see the internal structure of other parts, you only need to understand the interface.
7.15 Parnas recommendations are indeed a recipe for disaster. [Parnas makes me agree with this idea, and I have completely changed my mind.]
Organizational Structure
7.16 The goal of a team is to reduce the amount of communication and collaboration required.
7.17 to reduce communication, the organizational structure includes division of labor and specialization of function ).
7.18 The traditional tree structure reflects the power structure principle-dual leadership is not allowed.
7.19 communication in an organization is a network rather than a tree structure. Therefore, all the special organizational mechanisms (often reflected in the dotted line in the organizational structure) are for adjustment, to overcome the lack of communication in the tree structure.
7.20 each sub-project has two leadership roles: product owner, Technical Director, or structural engineer. The functions of these two roles are very different and require different skills.
7.21 any combination of the two roles can be very effective: