I'm looking for some references or best practices with regard to the proportion of different skill sets that needs to me on a typical medium sized software development team.
Assuming 40 development staff, what proportion should be SQA, UI designers, project managers, data specialists etc?
The problem domain is general engineering. I realize this is seems like a vague question but the correct answer will provide references to industry standards and best practices as opposed to a bunch of numbers.
Opinions and words of wisdom also appreciated! Regards.
A typical software development team structure includes a business analyst, a product owner, a project manager, a product designer, a software architect, software developers, software testing engineers, including test automation engineers, as well as a DevOps engineer.
According to the Scrum Guide, the development team should be between three and nine people and should have all the skills necessary to deliver product increments. The number of developers is usually dictated by the needs of the product and usually is between two and five developers in a scrum team.
There are basically 2 broad ways in which a software package development organization is structured: Project format, and Functional format. These are explained as following below. Project format: The project development workers are divided supported the project that they work (as shown below diagram).
Often referred to as a bureaucratic organizational structure, the functional organizational structure is the most common and widely used organizational structure. A functional organizational structure organizes the company into different departments according to the area of expertise.
You may want to consider the "controversial" Surgical Team structure, first proposed by Harlan Mills, and described in detail by Fred Brooks in The Mythical Man Month.
The Surgical Team structure is led by one chief-person performing the most critical work himself while directing his team to assist with or overtake other important but less critical parts.
Books defines the surgical team as in the following summary:
The Surgical Team http://img705.imageshack.us/img705/1599/image022b.gif
The surgeon is the chief programmer of the whole team. He produces all the specifications, codes the entire system the team is responsible for, tests it, and drafts its supporting documentation.
The copilot is the surgeon’s right-hand man. His main purpose is to share in the thinking about design issues. The copilot represents the team in meetings with other teams. He knows the code intimately, and serves as insurance in case of disaster to the surgeon.
The toolsmith supports the surgeon and builds specialized utilities and tools as may be required by his surgeon. Each team has its dedicated toolsmith in addition to any central services provided by the rest of the project infrastructure.
The tester is responsible for maintaining test cases for testing the surgeon’s work as he writes it. He is both an adversary who devises test cases to measure against the formal specs and devises test data to be used in debugging.
The language lawyer, which can serve several surgeons, is a widely consulted specialist who delights in the mastery of the intricacies of the programming languages and the operating systems upon which the software must perform.
The administrator handles money, people, space, and machines. The surgeon is the ultimate boss, with the last word on all these issues, but the day to day management of the issues and interfacing with the administrative machinery of the project is the role of a professional administrator. One administrator may serve more than one team.
The editor edits and revises the documentation as drafted or dictated by the surgeon and oversees the mechanics of its production.
The program clerk, trained as a secretary, is responsible for maintaining all the machine-readable and human-readable technical records generated by the team. All the filing and indexing is the responsibility of the program clerk.
The secretaries handle the project correspondence and non-project files.
Sources and Further Reading (Pro and Against):
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With