Tag Archives: technical practices

Technical practices for software development

Agile Requirements Snail: Feature to User Story to Scenario

Posted on by

The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.

I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.

The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:

Agile Requirements Snail

Agile Requirements Snail

Continue reading →

Pain Driven Development

Posted on by

Agilists love a good catch phrase. You Aren’t Gonna Need it (YAGNI), Do the Simplest Thing that Could Possibly Work, and Pain Driven Development are three of them. In fact these three are different ways to say the same thing.

All three phrases are about addressing a technical problem the team might face in the future. Immature teams will immediately attempt to solve the potential problem and thus add complexity to their product. More mature teams take a slower, more considered view.

In fact Agile teams should go through these stages when considering a potential problem/solution:

  1. Remember “YAGNI” i.e. point out the team don’t have a problem now, hence don’t need that solution now, so probably won’t need it in the future either.
  2. Wait until you feel some pain before accepting the problem is real.
  3. Once you feel the pain then do the simplest thing possible to solve the problem.
  4. Then wait until you feel more pain before trying anything else in that space.

That considered process is Pain Driven Development.
Continue reading →

Is Software Craftsmanship a Type of Martial Arts?

Posted on by

Code Kata, Coding Dojos, and White Belt Programmers. What is it all about?

In part seven of my series on software craftsmanship I have a look at how software craftsmanship is sometimes wrapped in the language of martial arts.

I confess from the outset that the use of martial arts language really put my off software craftsmanship. But behind the kung-fu I found fairly uncontroversial practices.

I’ll have a quick look at the three software craftsmanship practices I found with a strong martial arts flavour: Code Kata, Coding Dojos, and White Belt Programmers. Then go into a more general discussion of what it is about.
Continue reading →

Can Cucumber save Raja?

Posted on by

I’m worried about Raja. Unless I do something drastic he’s going to die. In a rather messy and unpleasant way. Crushed by the weight of a 60 person-year software product.

But I think I’ve got a solution. Cucumber might well save Raja from his gruesome fate.
Continue reading →

Agile Quality Management

Posted on by

Quality Management, in a project context, is concerned with having the right processes to ensure both quality product and a quality project. This article describes Traditional Quality Management, Agile versus Traditional Quality Management, Agile Product Quality, Agile Project Quality, Agile Product Quality, Agile Quality Assurance and Control, and Agile Quality Improvement.
Continue reading →

Agile Project Execution

Posted on by

Executing is one of the five project management process groups in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).

Project Execution is where you build the project deliverables and hand them over to your customer, i.e. where you build and deliver the software. This is where most of the project effort is invested. Agile Project Planning says what you intend to do, when, and Agile Monitoring & Control helps you stay on track but Agile Project Execution is where you do the business.
Continue reading →

XP Refactored by Stephens and Rosenberg

Posted on by

In their book “Extreme Programming Refactored: The Case against XP” Stephens and Rosenberg (2003) outline their reasons for not liking XP as it is published, but they also outline what they do like and how risk can be reduced when using an XP like process.   I found their book rather long (and the humour rather unentertaining) but they made some good points and I made a few notes about their conclusions.
Continue reading →