Entries Tagged 'Agile' ↓

Max Pool over at codesqueeze has a great article on how to write a good user story. I’ve seen developers equate a user story with a software requirement before without realizing the subtle differences between the two (mainly that a user story is short and focused on something that the user needs to do). By using Max’s template, you can ensure that you keep your stories short and focused on solving a user task.

John Reynolds has some tips on Iterative Development on his blog. He goes into what exactly iterative development is and points out how it differs from incremental development. It is easy (especially for managers) to get the two confused and fall into the incremental development trap. Good read and something you may want to forward on to your team lead or boss.

Gustavo Duarte writes today about Reality Driven Development. This is meant to be a further explanation of a post of his that got Slashdotted last week. It’s a good read that advocates experimenting during the software process and getting feedback (from reality/the user) often.

Gojko Adzic has a list of Test Driven Development anti-patterns on his blog. Unfortunately, I’ve seen many of these crimes practiced in real life and can say that they generally always come back to bite you. The list includes activities such as commenting out a test to make the build pass, sensitivity to the UI, and sensitivity to 3rd party APIs.

A group of students at the Hasso-Plattner-Institut (HPI) in Potsdam, Germany came up with a novel way of communicating their project status. They hooked up a homemade stop-light system, dubbed “The Golight” to their continuous integration system that switches the lights on and off based on whether or not their unit tests passed. 

There is an interesting post on the Agile Ajax blog at Pathfinder regarding Software Architects on small development teams. Personally, I’m uncomfortable with the position because it implies that there is one or two “architects” on a team and everybody else is doing the grunt work.

Phil Haack has an interesting article on his blog this morning regarding the amount of scientific research behind Test-Driven Development. As a developer, I’ve had the displeasure of trying to convince multiple management types and teams of developers that Test-Driven Development would lead to better, cheaper, and easier to maintain software. Maybe armed with some of the research pointed out in this article you will have an easier time than I.