Development Team
This document describes how our developer team works at Agile Codex from the perspective of Agile principles. A developer team includes coder, designer, architect, graphic designer, and tester.
At Agile Codex, developers and customers collaborate closely via online project management tools. We follow the following processes and tools in our development projects:
Tools and Processes
Tools don’t solve your problems; people do. Tools just help. It’s important to choose the right processes to go with your tools and the right ways to use your tools so that they do the most for you.
We evaluate how our tools are helping us, and how they could work better for us. When things aren’t working quite right, we improve our ways of using the tools and occasionally change the tools as well.
Pair Programming
In Pair programming, two programmers work together on a single task at one computer with separate monitor and keyboard of each individual. As a pair, they deliver a high quality and ensure a broad perspective on problem solving.
When used effectively, pair programming reduces the overall cost of development and maintenance.
At Agile Codex, we look at each coding and design task to determine if pairing is appropriate, many coding tasks are performed solo. When this happens, the code must pass code review before moving on to QA.
Test-Driven Development
At Agile Codex, we write most of our code in a “test-driven” style. Test-driven development (TDD) means that, before writing a bit of production code that’s required, we’ll first write an automated test that verifies that the code is working correctly. Then we write the code that’s necessary to make the test pass. That whole cycle often takes a minute or less.
Behavior-Driven Development
Behavior-Driven Development (BDD) is another style of test-driven development that focuses on a different way of performing the tests so that its purpose is clearly related to business outcomes.
Doing everything of TDD, BDD emphasis on only those behaviors which contribute most directly to these business outcomes.
Code Review
Although many tasks call for pair programming, it is simply not practical or efficient to pair on every task. When tasks are tackled by a solo developer, their work must always be reviewed by another developer on the team.
Code Coverage
Code coverage has many definitions, but it normally represents the percentage of lines (or branches) in a software project that are covered by automated tests. A low score probably means bad code, but a high score doesn’t necessarily mean good code!
At the start of a project, the project team can choose what code coverage standard to enforce. There are many subtleties here: see series of essays and conference talks for a more in-depth discussion of using code coverage on projects.
Distributed Source Control
Agile Codex uses a distributed source control system called Git (GitHub and BitBucket) to store and track source code and other development-related artifacts.
To support collective ownership, we use a concurrent model of version control. We support time travel by storing tools, libraries, documentation, and everything else related to the project in version control and keep the entire project in a single repository.
We avoid long-lived branches, particularly for customized versions; they’ll cripple your ability to deliver on a timely schedule. Instead, we use configuration files and build scripts to support multiple configurations.
We keep the project repository clean. All versions are built and passed with all tests.