agile

warning: Creating default object from empty value in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/modules/taxonomy/taxonomy.pages.inc on line 33.
Leeland's picture

BDD Crash Course Presentation

Last night 2 months of poking at my computer almost every evening ended with a room of 30 software professionals looking like the proverbial deer in the head lights. To be honest I was very concerned that I was being too basic and people would demand more in-depth details. I had a Linux build server all set up with source code repository, Hudson build services, a micro-development environment, and a handful of example projects ready to jump into once the questions / demands for details started.

Leeland's picture

Short Sprints vs. Long Goals

Running a development using SCRUM mixed with Agile has a lot of benefits. But, every once in a while (read as "yesterday") a requirement comes up that just seems to defy all logic and being able to be split down. This isn't the first time to run head on into this large wall (or immovable object). Although rare, this does happen.

Leeland's picture

Re-evaluating Project Requirements

In developing project criteria/use cases/stories a certain point is reached where it is concluded that "enough" has been done and the results are "good" to begin work. Which is to say that the requirements are "good enough."

It is not unusual to wonder, after work begins, if the information really was good enough. It is worth re-evaluating the requirements once a little effort has been done. This helps to flush out missing details. A reasonable set of questions to ask are:

  • Were any important variables missed in collecting the data used to produce the requirements?
Leeland's picture

It's Done When?

Been dealing a lot of SCRUM items and it seems to me that a lot of teams keep missing the mark because of not clear "done criteria". For the record I think a minimum done criteria is:
  • Code is checked-in into a central version control system
  • A detailed code review (including comparison to any company and/or team coding standards) has been complete, any suggested changes implemented and final code has been checked-in
  • Unit tests with demonstratable cover coverage of more 80% for non-integration / "out of container"
Leeland's picture

Agile Modile-Driven Development

A rather interesting message set went by today on model driven development. The article referenced is worth a read.

From Scott W. Ambler (Tuesday, June 3, 2008, at 6:35:39 AM):

In the current issue of Better Software Celso Gonzalez and I have an article entitled "Agile Model-Driven Development: Scaling Agile to Meet the Needs of Real-World Projects". The URL is http://www.nxtbook.com/nxtbooks/sqe/bettersoftware0608/

Leeland's picture

Behavior-Driven Development

I started poking at TDD (Test-Driven Development) a few years ago. I get really good at it, then I stop, then I get into again, then I stop and round and round I go.

Leeland's picture

Behavior-Driven Development

(moved from http://dreamingthings.blogspot.com/2007/12/behavior-driven-development.html)

I started poking at TDD (Test-Driven Development) a few years ago. I get really good at it, then I stop, then I get into again, then I stop and round and round I go.

Thread Slivers eBook at Amazon

Syndicate content