Test-Driven Development (TDD)
Behavior-Driven Development (BDD)
Continuous Integration (CI)
Static Code Analysis
You've got them all!
This practice requires the developer to describe the expected code functionality in a test and then write just enough code to fulfill the test. It also explicitly allows time for refactoring in each cycle.
Despite the name, the primary purpose of this practice is to create simple, clean, and focused code.
Where test-driven development often focuses on code functionality, this practice extends that approach to the application's behavior.
With tests written in plan language, you don't need any development skills to participate in this practice.
Changes to the application's code or architecture that improve performance, readability, or maintainability without changing the outward behavior of the application.
By building the application and running automated tests at regular intervals (or even every code check-in) this practice helps catch problems early and avoids the "it works on my machine" problem.
A type of backlog item, this is often a prototype or some other concrete artefact that helps the team answer a question, solve and problem, or gain knowledge. Unlike some research tasks, the resulting knowledge should be demonstrable, not speculative.
A practice based on the fact that most of the time spent in programming is not typing, but problem solving and while four hands can't type on a keyboard, two brains can often solve a problem faster than onewhile improving shared code knowledge and helping build a cross-functional team.
This practice automatically looks for coding standards violations and common patterns that may lead to problems. The team uses heuristics to identify lurking issues before they turn into bugs.