All the members of a development team, develop software; but only around half of the team are software developers. This is the sort of team we put together whenever we start a new project. Whether that’s a game or an app or a website, the roles requirement always tend towards this split of skills.
2 Designers : 4 Developers : 1 QA Technician : 1 Manager
Perhaps it’s that I work in a converted train-shed, but I like to imagine a 4–8–4 locomotive representing this split. The designers are at the front, steering the product. The developers are the four pairs of wheels in the middle, providing drive. QA and Management bring up the rear, ensuring we stay on track.
As a skill, design sits somewhere between art and engineering. These roles include game and product designers, as well as all sorts of visual designer and artist. Sound effects and music work would also fall under this group.
You would typically expect software to need heavy game (or product) design up front, with that role reducing to working closely with QA on user acceptance testing once all the developers are fully on-boarded. The early rush of game design would normally hand over to a similar burst of visual design, though the precise split of skills below that really depends on what you’re building. Later in the project, you may find you need something akin to level design. That’s a games software role, but many other projects need content too.
The sum of all these efforts tends to balance out, somewhere around a quarter of your team.
It’s not always best use of developers’ time or expertise to test their own code. It’s very easy to create code which works when used correctly, but your QA technician can define the requirements for a story to be completed in such a way as to be sure you’re creating robust software. For example, defining the functionality for when users stray from the guided path.
QA Techs do not just check the functionality of a dev’s code. They work closely with design to develop the idea of done — where done is the definition of the criteria by which a piece of work will be accepted as complete — into a series of tests which will prove that work.
This process starts early in development, and should not peak towards release. Their requirement is a product of developing software, not of releasing it.
I often find one QA is needed for around four devs.
We tend to think of these as splitting into two roles (though not always two or more people).
The product owner is responsible for ensuring what you’re building meets its business needs. They work closely with the design team and the project manager (see below) to ensure the correct tasks are planned, forecasted, and prioritised. Their other main task is collaborating with all stakeholders, so that they can act on their behalf.
The project manager enforces the roles of the rest of the team, and ensures the project — where a project is the plan for creating a product — meets the product requirements. They’re a mouth piece between the PO and the rest of the team, and they achieve this through careful measurement and forecasting. Their job is to make sure nobody’s surprised!
And these guys do the rest!
Developing software is half of developing software.