Groups of professionals contributing to the same product that are working in isolated silos and not talking to each other is not helping your project one bit.
Break down these silos by having contributors talk to each other and involving them in the bigger picture.
The term full-stack-developer is used to describe a developer whom is fully capable of doing whatever is required. This is the essence of not working in silos.
Agile processes defies phases in the software development process. The 1st principle in the Agile Manifesto refers to continuously delivering software.
An agile approach is not a small waterfall or a interactive and incremental process speeded up to 14 days intervals. It literally has no phases - only continuous integration and continuous delivery with focus on minimizing work in progress and get the right thing done - at a constant pace.
Unit tests are used to test the semantics of your code; To verify it works as expected and keeps working as expected through changes.
Unit tests are light-weight and fast. Don’t get tangled up in hard-to-handle dependencies such as loading databases or instantiating long sequences of objects before you get to the actual testing, use mocks and stubs to simulate your first order dependencies. Or use Proxies to have non-local collaborators contribute to your test.
A unit test is quick to execute and it should be executable in the context of your development environment.
Every time the code changes, it traces back to some task being done. Think about it; Who’s feeding the process? How are tasks being created, prioritized and executed?
When a code change cannot be tied to a specific task, it’s likely something that has bypassed the normal chain of command. Somebody is working outside protocol.
Make all code changes part of an overall plan - simply pair commits with tasks. Besides generating valuable traces that can later be used in an audit or documentation of your trail, it also enables you to track the pace of the team and maintain a burn-down chart.
When code changes are committed to the repository, your CI server kicks in automatically and starts a build.
It might not even be an actual build, it can be any kind of automated action that is part of a verification process implied in the project’s “definition of done”.
If a build step fails, the developer is notified directly so he can start working on fixing the issue immediately. The shorter the feedback loop, the better.
Analyzing your code is cheap but valuable. Scouring your code and producing interesting metrics helps you keep check on all kinds of creeping issues.
Static code analysis, style checkers, cyclomatic complexity, code coverage and scanning for FIXMEs and TODOs are all examples of metrics that help you keep a watchful eye on codebase evolution. Adding thresholds to these measures as part of your verification protects it from corruption.
Monitor improvements but don’t waste time reaching arbitrary targets.