A checklist for modern development practices that improve the lives of people in a software development team
- Code Coverage is Commensurate with Market Demands
- Automated Tests Protect the Main Branch
- Team Uses a Task and Bug Tracking System That Everyone Can Edit
- People Can Work From Home As Needed
- Team Continuously Prioritizes Work
- Testers and Developers Share Testing Assets
- Code Is Easy to Locate
- Compiler Enforces Code Rules
- Can Build and Deploy in One Step
- Everyone Has Adequate Tooling
- Management Trusts Developers
- Team Favors Ad Hoc Communication Over Meetings
- There Is a Shared Wiki
- Developers Contribute To Open Source
- Hirers Avoid Bias
- Teams Plan Changes and Take Their Time
- Teams Minimize Code Duplication
- There is Dedicated Admin Person/People
- Everybody Has Access To Anonimized Test Data
Automated tests cover your code to the degree that allows you to refactor and release your software quickly with confidence and without a lengthy QA process.
It is impossible to push code to the main branch without the code going through the automated tests.
The team logs tasks and bugs in a centralized system. The system is easy to use, and anyone (including testers, support, and developers) can edit the items with an audit trail. The team assigns tickets to the developers and the assignment is clear.
There is no requirement to come to the office unless there are exceptional circumstances.
One or more people continuously prioritize tickets through a consensus approach. Feedback from stakeholders (including testers, support, and developers), usage stats, test results, and deadlines strongly influence prioritization.
Testers and developers share responsibility for the custodianship of testing assets. Test scripts and automated tests reside in the same place for testers and developers. Anyone can run the tests, and fast tests run in the pipeline.
The codebase exists in one location in groups by meaningful folder names. Where code exists in multiple repositories, an index points to its relations.
The codebase uses static code analysis to enforce a level of code quality and standardized formatting to which the team agrees. The pipeline enforces these rules, so there is no need to mention them on a pull request.
The team can create an increment of the software and deploy it in a single step.
Testers, designers, coders, and everyone else in the team has a set of tools that enables them to do their job effectively.
Developers work autonomously and don't need to justify their decisions repeatedly, but the two-way contract means developers always work toward the team's goals.
Team members communicate via the bug tracking system, chat or call, and rarely schedule meetings. Meetings of three or more people occur when it is more efficient.
Everyone can access and edit the Wiki. It contains simple documentation for things like building and running the automated tests locally. The bug tracking system links to the documentation here when lengthy documentation is necessary.
Developers log issues and fix bugs in open source repositories on which the team depends, and management does not create unnecessary obstacles for putting code in the public domain.
People who have the power to hire people actively seek out diverse skills and talent that the organization lacks. They actively attempt to remove biases that would otherwise lead to hiring people who look and act and approach software development in the same way as the company founders.
Consensus drives the approach and developers don't smash out work that will likely need rework soon.
Devs are careful to reuse existing code, and move code to easily accessible shared locations. Devs regularly automate the process of locating duplicate code across repos
At least one person is responsbile for adding or removing access to cloud resources, source control, software accounts and so on. This is the only role that is not a team responsibility seeing that they need to follow the Principle of least privilege
Developers can easily run the code against a data source which does not contain any private details of actual people, but is realistic.
This is an evolving text. Suggestions welcome. Star to give your support
I would also include "Is there an easy to access wiki that is actively being maintained", some big projects have a lot of parts and you may need a wiki to be in the loop for specific aspects that might not be day to day related but a one-off chance and then keep working kind of basis.