Entering SaaS: Engineering Side of Programming (Part 2: Agile)


INTRODUCTION TO AGILE

Plan-and-Document was a bust. Some people said that the problem was inherent and that we just needed to suck it up. Nah. In February of 2001, out popped the Agile Manifesto.

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over process and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

People got pretty heated when the Agile Manifesto was introduced, but success can be very convincing. Projects were finally getting finished on time and on budget, and according to survey results presented in Engineering Software as a Service: An Agile Approach Using Cloud Computing, 60% to 80% of programming teams in 2013 were using Agile as their primary development method. This is not very surprising since Agile integrates strategies that address problems that existed in the plan-and-document methods: higher customer collaboration and test-driven development. Essentially, test-driven development means writing tests that will make sure the code does what you want. This is done before the code is actually written.

VERSIONS OF AGILE

I’ve presented the ideals behind Agile, but what does it mean to use Agile as a development method? Let’s take a look at some versions of Agile: XP, Scrum, Kanban

Extreme Programming (XP): Test-driven development, pair programming, and behavior driven design. This is the one I’ll be working with. =)

Scrum: Self-organized teams work in 2–4 week sprints then come together to plan their next sprint. Usually, they’ll switch up the jobs over time if there are multiple roles.

Kanban: Members are given a fixed role that they are assigned to based on how to best prevent wait time.

WHICH IS BETTER?

In Software Engineering (9th Edition) by Ian Sommerville, there’s this nifty little chart which is supposed to help determine whether Agile or Plan-and-Document is the method for you. Apparently, it really depends on how you answer the following questions.

No = Agile, Yes = Plan-and-Document

  1. Is specification required?
  2. Are customers unavailable?
  3. Is the system to be built large?
  4. Is the system to be built complex (e.g. real time)?
  5. Will it have a long product lifetime?
  6. Are you using poor software tools?
  7. Is the project team geographically distributed?
  8. Is the team part of a documentation-oriented culture?
  9. Does the team have poor programming skills?
  10. Is the system to be built subject to regulations?