Web development projects are always in a constant state of flux, requirements change, and scope is frequently altered and extended. In addition, the developer moving from a one- or two-person team up to a larger team of six or more will need to acquire a set of tools, work habits and mental models.
The “Agile” or programming movement is a non-traditional style of software development that vastly improves the functioning, efficiency and effectiveness of the team and the reliability and (??) of the project.
Like any dogma, the core tenets of Agile development are largely interpreted by its followers, and indeed, there are many schools of thought.
The Ruby on Rails framework has absorbed many of these concepts and integrated them within the core philosophy; newcomers will instantly benefit from the best practices enforced on them under the guise of “convention”.
These are the core principles you’ll need to apply to your work:
“Release early, release often”
Projects always run over scope, over budget, and over time. To help mitigate this, the scope for each version is set to a relatively small period of time – usually two weeks.
This two weeks includes planning, documentation, testing, coding, and deployment.
At the beginning of the project, the list of features is spread out into groups and assigned to an iteration. If one iteration goes over time, the rest of the iterations (obviously) slip; or, some of the features move into the next iteration.
New versions are deployed frequently, and the clients or customers see constant updates, which keeps them happy. Customers can give constant feedback at all stages.
Every part of the code has automated tests written for it. Often, the tests are written before the code itself has even been written (this is known as Test First Development). This allows the developers to think about and plan the implementation solidly before diving in, and the resulting codebase has less bugs and just plain works better.
Additionally, developers can work on different parts of the application knowing that other people’s code (they may be relying on) works as advertised.
describe User, "creating records" do
it "activates user only if an email address is entered" do
user = User.find_by_login('joe')
user.activate!
user.should_not be_activated
user.email_address = "joe@test.com"
user.activate!
user.should be_activated
end
end The code snippet above demonstrates a simple unit test; it runs the “activate!” method on the user
object, and then asserts (“.should”) that the user is now activated. If someone changes the activation
procedure, then this test will fail.
During development, all tests should always pass, unless you’re working on that code, or unless you’re writing tests first. This way the build is always deployable. See “Source control” for more information.
Really, no idea.
All code is kept in a version control system. This means, the code is kept in a repository which is accessible by all team members. Whenever a feature or bugfix is implemented, everyone has access to that code.
Developers will generally check out a copy of the codebase to their local machine, work on changes, and push the changes back to the original repository. Before pushing, they should check that all their changes work, by writing tests, as well as manually verifying the changes work (“monkey-clicking”).
The most important part of development is communication. Many developers work from remote locations, so it’s even more important to consciously increase the communication between team members.
There are several tools to encourage the procedure:
It’s best to use a forum where all team-members are active, and one that’s logged for future reference. (…expand…)
Phone calls are evil because no-one remembers what they decided upon and it disrupts workflow.
All issues should have a ticket created in the ticket tracker (for example, Lighthouse, or Trac). Bugs, new features and interaction issues are all valid tickets.
Tickets are generally assigned tags by developers, and are assigned to a milestone (or iteration) by the project manager.
Tickets can exist in several states:
All communication about an issue should be recorded in the ticket tracker, so that it can be searched later, and so that the project manager knows there is activity on an issue.