Using three hours to read through this software in the field of st, wanted to read more carefully, but our project experience and the author, plus from the English translation, some words cannot smoothly to understand, read this again is swallowed, but many of the concepts or left a deep impression on me, It may be more rewarding to repeat it later when you have more experience in team operations or management. Now let’s talk about the crude new understanding of software engineering that I’ve read.
Crisis in the field of software engineering
Estimating techniques surrounding costing confuse effort with project progress. The man-month is a dangerous and deceptive myth because it implies that numbers and times are interchangeable.
Programmers also develop an optimistic attitude in the process of fighting bugs day and night. Naturally, they are also optimistic in the estimation of time, cost and manpower of software projects. This optimistic color is also a double-edged bug in our thinking. The reality, however, is that real software projects often face delays.
We often think that the strength of many people is great, and the strength of many people is broken. If it is an activity that can be allocated at one time and each can start work without interference, then this saying is undoubtedly true. As long as the cost is controlled, the more people, the faster the task will be completed.
But when a software project splits tasks among several people, it causes additional work-the training and communication. It all costs time, money and people. The addition of new staff to the project adds to the overall workload necessary for the project in three ways: the reassignment itself and the resulting disruption of the task; the training of new staff; and additional communication.
The author mentions a Brooks Rule in his book:
Adding staff to a project that is behind schedule will only make it more behind schedule.
Two, practical experience and management methods
Experience in 1.
A good professional programmer with two years of experience and the same training is 10 times more productive than a bad programmer.
It’s hard to imagine that a programmer with a salary difference of one is ten times as bad in skill, so hiring a good programmer is nine times as productive for the company, which is a huge return.
2. Management methods
Small, lean teams are best, with as little thought as possible. But for truly large systems, small, lean teams are too slow.
So what’s a better way to manage a large system? This is a classic example in the book: the surgical team.
For the vast majority of large programming systems, the development method is high cost, slow speed, low efficiency, the product can not be developed on the concept of integration.
A surgical team structure with a single lead programmer achieves a complete product concept from a few heads, overall productivity from multiple helpers, and a radical reduction in communication.
3. Conceptual consistency
1) Why conceptual consistency
To achieve conceptual integrity, the design must be done by one person or a small team with consensus.
Regardless of the size of a project, it is necessary to separate its design from its implementation as a powerful means of achieving conceptual integrity. Like decoupling, an important concept we learned in software architecture, we encapsulate abstract methods in a separate class, which is called when implemented, making programming free of complex implementation details and easy to maintain and modify. This is what architects are all about.
Certain rules for the propulsion of software project is beneficial, the system structure of external regulation is, in fact, enhancing the creative individual or small group, because they frequently in programming the border of a unified, racking their brains without having to spend a lot of time thinking and communication software architecture of these abstract, which focus on the realization of the software, thus enhance the development efficiency, It also improves the quality of software.
2) How to design the concept
For the sake of accuracy, we need to design definitions formally, as well as narrative definitions for further understanding.
Just read here, I don’t really understand the formal definition, then think of logic knowledge learned in the discrete mathematics, probably understand the so-called formalism should be in a particular language rules will be defined, to ensure its precision in logic sense, at the same time, in order to increase the readability, again complementary with narrative text, to reduce the communication cost.
4. Team organization
1) communication
“The left hand does not know what the right hand is doing, resulting in schedule disasters, unreasonable functions and system defects.” Team members begin to misunderstand each other due to assumptions about others.
I just started to join the teacher project team, responsible for the design of the front page, but since the project is not very urgent, so in learning new technology somewhat sluggish, and communication between the team is not very much, so in the first project node, I accumulate doubts because of lack of team communication and not been solved, also good at project division of labor is clear, There is no need to connect my part with other students’ parts for the time being, but it is really a little awkward when we communicate our respective achievements.
2) Project work manual
A project workbook is not a single document, but a structure that organizes a series of documents that a project must produce.
We need to design the workbook structure early and carefully, and each member should know all the materials. Had several times before the team cooperation experience, from the start of the school training, project documents each family – everyone holding their own part, until the last moment of need to come together, then make the language finches platform management all the documents of the project, from requirements analysis to the database design to the interface design and updated in real time online, As a result, the team can reduce some unnecessary communication, improve the development efficiency, and reduce the trouble caused by not timely informing project team members due to document update.
3) Organizational structure
The goal of team organization is to reduce the amount of communication and collaboration necessary. To reduce communication, organizational structures include division of manpower and defined areas of responsibility.
The traditional tree organization reflects the principle structure of power, that is, dual leadership is not allowed. However, communication in an organization is a network, so the dotted lines in the organization chart are to adjust communication paths to overcome the lack of communication in a tree-like organization.
Each subproject has two leadership roles — product owner, technical lead, or architect — who act as each other’s right hand with very different functions.
5. Schedule control
The first step in controlling a large project according to a strict schedule is to specify a schedule, which consists of milestones and dates.
Milestones must be concrete, measurable events that can be clearly defined so that programmers can’t fool themselves into lying about their progress.
There must be a review mechanism through which all members can see the true state.
Reviews allow us to keep track of discrepancies between individual progress and team progress, and having a planning and control group that maintains milestone reports can be a great help in timely project delivery.