I'm not much into the Agile & XP type of things - pair programming has a lot of value, but I don't do it much. The Stories (sort of like a Use Case?) seems pretty good - especially the testable part - very nice. Leads you into TDD development. Again, I don't really do TDD but I probably should - except when porting complex Cobol code with a small amount of time to do it.
I've been chatting with RC about the RT team and their approach to porting their application. They seem to be treating this port as 'new development' and are looking for an 'owner' who can help them develop stories that eventually become code.
The main problem I see is the legacy code is the 'owner'. So we need people to 'mine' the legacy code in order to develop the 'stories'. I'm wondering if the RT team is doing this? I doubt it. They appear to want to talk to people and develop stories this way. The problem is, no one person knows the app well enough. There are way too many one-off's.
From what I've heard and seen, the rest of the process doesn't seem bad - pair programming, testable stories, war room, etc. I wish they were using Fitness for real - I'd like to see that - seems like it would be difficult.
So what do the 2 people who read this think - I'm way off, dead on, somewhere in between?
Subscribe to:
Post Comments (Atom)
Posts
6 comments:
I'm thinking it can work. It seems like it should still be possible to capture a user story, even though you may not know every single "set this flag to T" situation. For example : "As a user, if I can't get a rate from a system I would like to have the daily rate editable so I can enter a daily rate". That's a story (probably an Epic, but regardless for simplicity let's go with it). Now, that doesn't mean the user knows that in order to do that, and satisfy the existing requirements of the legacy application, you need to set 3 flags underneath the covers (FLAG-A = "R", FLAG-B = "D", and FLAG-C = "Y"). Legacy acts as a Subject Matter Expert. The users of the system can tell you "what" it needs to do but maybe not "how" and all the "behind the scenes" goodies that need to occur.
The other argument is the ol' "if noone knows it does anything, is it that important"? For most things because of the coupling of legacy and web application to the same data the answer is "yes". But still it's worth asking that question.
Some of the agile things like "do the most important stories and what's not important don't do it" are hard to make work. If the "ONE BIG THING" is make a new Web version of the legacy application. But still, breaking stories down into small tasks, doing pairing, doing TDD, continuous integration, using actual results to communicate a completion date to stakeholders (burndowns/burnups). These are all good things that are definitely doable.
Great post. It is hard to wrap all these concepts around every situation, maybe the point should be to find the best tools for the current job and leverage them to make progress. But it's always easy to say what "should" work when your talking and not working. :)
I think they want someone to write the user stories and mine the cobol code so they can focus on development. An examplem, most of the weeks they have delivered between 15 and 24 story points. They week they had a fully writen backlog, they generated almost 40 story points in a week. so if they had one or two people mining code and writing stories, then could explain it and they were building fitness pages, then they could be producing 40 or even 50 story points a week.
Mark - sounds like they are getting a lot done. I wonder if 1 or 2 people mining Cobol code is enough to keep the other developers busy.
I just 'refactored' some code they had written and found a few problems with what they had done. It didn't appear to me that anyone had looked at the Cobol code to see what was being done.
I did find some Cobol code that your brother called 'non-cohesive' or something like that. The Cobol code was doing something totally unrelated to the task at hand. I'm sure it needs to be done, just not where it was being done.
one more thing - sitting around mining Cobol code for weeks on end is a job I would only wish on my worstest of enemys.
Yeah, sitting around mining code all the time is not fun, but I'm not sure how else to get it done.
Post a Comment