Đối với ngành công nghiệp phát triển phần mềm ngày trước, khi build các hệ thống lớn, họ đã dùng một nhóm các đội ngũ lớn các lập trình viên, tester, QA, manager trong cùng một đội. Điều này gây cản trở và khó khăn rất nhiều trong giao tiếp, khiến nhóm trở nên cồng kềnh hơn.
Trong phần 3 này, Brooks đã đưa ra đề xuất xây dựng tập hợp các nhóm nhỏ để xây dựng các hệ thống lớn đòi hỏi số lượng lớn nhân lực và hoàn thành trong một khoảng thời gian hữu hạn. Có thể nói từ đó, đã xuất hiện nhiều cải tiến trong quy trình và cách tổ chức nhóm trong việc phát triển phần mềm đòi hỏi sự linh hoạt và đáp ứng kịp thời các thay đổi, có thể nói đến như Agile methodology. Họ chia nhóm lớn ra thành các nhóm nhỏ được gọi là các nhóm chức năng để đảm nhận việc xây dựng 1 phần nhỏ trong một hệ thống lớn. Mỗi nhóm có thể hoạt động độc lập mà không bị phụ thuộc vào các nhóm khác, có nghĩa là để làm được điều này, một nhóm phải có đầy đủ các cá nhân để đảm nhận các vai trò khác nhau xuyên suốt quy trình phát triển.
Bài viết dưới đây được tóm tắt và trích lại từ blog https://leftcornernotes.wordpress.com/
These studies revealed large individual differences between high and low performers, often by an order of magnitude.
When managing a team there is a debate between small teams made out of sharp first-class people, or bigger teams with people of every kind. Appart from that there are the needs and size of the project, for which a small team runs short or reseources for doing it in a meaningful schedule.
Is it preferable to have small, sharp teams of very efficient programmers or a large team of no so efficient people able to deal with big tasks by, at the end, brute force?
The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?
Mills’s Proposal – THE SURGICAL TEAM
Harlan Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.
Much as a surgical team during surgery is led by one surgeon performing the most critical work, while directing the team to assist with less critical parts, it seems reasonable to have a “good” programmer develop critical system components while the rest of a team provides what is needed at the right time
THE SURGEON (The chief programmer).
- Defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation.
- Writes in a structured programming language such as PL/I
- Has effective access to a computing system which not only runs his tests but also stores the various versions of his programs, allows easy file updating, and provides text editing for his documentation.
- Needs great talent (10+ years experience) and considerable systems and application knowledge, whether in applied mathematics, business data handling, or whatever.
THE COPILOT. (The alter ego of the surgeon)
- Able to do any part of the job, but is less experienced.
- Main function is to share in the design as a thinker discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice.
- Represents his team in discussions of function and interface with other teams.
- Knows all the code intimately.
- Researches alternative design strategies.
- May even write code, but he is not responsible for any part of the code.
- Is boss, and he must have the last word on personnel, raises, space, and so on, but he must spend almost none of his time on these matters.
- Needs a professional administrator who handles money, people, space, and machines, and who interfaces with the administrative machinery of the rest of the organization.
- Has a full-time job only if the project has substantial legal, contractual, reporting, or financial requirements because of the user-producer relationship.
- Takes the draft or dictated manuscript produced by the surgeon and criticizes it, reworks it, provides it with references and bibliography, nurses it through several versions, and oversees the mechanics of production.
- The administrator and the editor will each need a secretary; the administrator’s secretary will handle project correspondence and non-product files.
THE PROGRAM CLERK
- Responsible for maintaining all the technical records of the team in a programming-product library.
- The clerk is trained as a secretary and has responsibility for both machine-readable and human-readable files.
- Logs and keys it all computer input. The output listings go back to him to be filed and indexed.
- Making all the computer runs visible to all team members and identifying all programs and data as team property, not private property.
- Relieves programmers of clerical chores, systematizes and ensures proper performance of those oft-neglected chores, and enhances the team’s most valuable asset—its work-product.
- Logs all updates of team program copies from private working copies, still handles all batch runs, and uses his own interactive facility to control the integrity and availability of the growing product.
- Responsible for ensuring the adequacy of “File-editing, text-editing, and interactive debugging” services and for constructing, maintaining, and upgrading special tools—mostly interactive computer services—needed by his team.
- Each team will need its own toolsmith
- The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries.
- Is both an adversary who devises system test cases from the functional specs, and an assistant who devises test data for the day-by-day debugging.
- Also plans testing sequences and set up the scaffolding required for component tests.
THE LANGUAGE LAWYER
- Masters the intricacies of a programming language, which uses to do difficult, obscure and tricky things
- Does small studies on good technique
- At the service of different surgeons
How It Works
The team just defined meets the desiderata in several ways. Ten people, seven of them professionals, are at work on the problem, but the system is the product of one mind—or at most two, acting uno animo.
Differences between a team of two programmers conventionally organized and the surgeon-copilot team.
- In the conventional team the partners divide the work, and each is responsible for design and implementation of part of the work. In the surgical team, the surgeon and copilot are each cognizant of all of the design and all of the code. This saves the labor of allocating space, disk accesses, etc. It also ensures the conceptual integrity of the work.
- In the conventional team the partners are equal, and the inevitable differences of judgment must be talked out or compromised. Since the work and resources are divided, the differences in judgment are confined to overall strategy and interfacing, but they are compounded by differences of interest. In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally.
These two differences—lack of division of the problem and the superior-subordinate relationship—make it possible for the surgical team to act uno animo.
Yet the specialization of function of the remainder of the team is the key to its efficiency, for it permits a radically simpler communication pattern among the members.