I just finished reading the book User Stories Applied. It was interesting. A co-worker lent me the book and suggested I read it. I can't remember the last time I read a work related book on my own. It's been a long time. I guess my interests outside of work are more, well, "interesting" than studying up further on what I do during the daytime to get paid.
It's good for me to get more of a grasp on what all this agile stuff I hear about all the time is about. I still don't really get it. As I read through User Stories Applied I kept thinking to myself did you actually build real software this way? Although the author is careful to consistently back up his talk with examples from real projects. So it apparently has been used on real projects and isn't just some academic thought experiment.
I guess it's hard to get comfortable with something that is such a departure from the projects I've always worked on. Still over the years people have attempted to introduce some of the concepts of agile into the software development project management. I think that's the thing with agile among established companies. We want to pick and choose the more interesting and useful aspects without going whole hog and having say 2 programmers to a workstation.
For example iterative development with feedback is good. We've all known from hard experience for a long time that the "late and large" integration at the very end of a software project is a bad way to go. So we try to build earlier and keep it in a usable working state where people outside the team can use it and give feedback. That said we were using milestones back at PRIOR on the CMS SB3 project in 1998.
One thing that really struck me was pretty much every chapter kept going on about this individual called the "customer". The customer writes the user stories (NOT the programmers!). The customer writes the acceptance tests (hmmm). The customer provides feedback between iterations and determines which stories are to be done in each sprint. This is a certainly a departure from the past with that level of customer involvement. In my experience I'm reading this and thinking, Who is this customer? I don't recall seeing him around very much in my 12 years in the cubes.
So that's something that's important and different. Agile isn't some internal fad or thing that the programmers do on their own that is opaque to everyone else. The customers have to be more involved. That involves organizational change. If the organizational change doesn't happen and it ends up being the programmers writing the stories and the acceptance tests and planning the sprints, etc. then agile probably won't be very successful.
It was a good book. I did learn a lot more about agile. It's part of the Kent Beck signature series. I think I've grasped enough for now and I'm not planning to read the rest of that Beck series. I've got some other books outside of work related lined up to read.
I remember back at TUNS in the software engineering course. The prof did a series on 4GL and code generators. He showed us this demo of some TI system called IAF or something like that. After you set up all of the screens and described the data and workflows it set about generating C code at a rate of about 100,000 lines and hour.
The prof made an interesting observation. IAF was very good at the traditional integrated order entry - inventory - shipping problem for mid to large manufacturing companies. That one specific scenario. However you wouldn't build a compiler with IAF. You wouldn't build IAF itself using IAF.
I think that would also apply to user stories as well. For example I wouldn't specify the emergency shutdown software for a nuclear power plant using user stories. I wouldn't design air traffic control software with user stories. I think user stories and agile may be useful in certain categories of software development; and inappropriate for others.
Software development is a large and diverse space. Internal IT department. Systems integrators. Shrink wrap software installed at a remote site. Web apps running off one big live website. Within this large space there are probably some situations where user stories and agile work well.
