Hi everyone,
I'm currently working on a Masters degree, and part of my thesis is going to be an investigation into the preceived failures of agile methodologies from the software development team perspective.
I'm interested in what your views on this are.
Having used FDD a bit, I haven't noted any specific failings, but there are (to me, at least) some very problematic areas in implementing XP, especially from my perspective as a business analyst.
Any help would be awesome.
Thanks
Dominic
Dominic, You may want to rea
Dominic,
You may want to read my document XP vs FDD in the downloads section of this site. I wrote it when working on my Master degree.
Additionally, here are the couple of notes on FDD:
- It works best when you write the brand new project. When implementing phase 2, people often do not want to reserve time for modeling. This leads to all kind of problems later.
- FDD is an agile development methodology. This means that it drops some phases that exist in a standard development process: writing user requirements docs, doing use cases etc. This often contradicts with the standards that exist in corporations. As a result development team does FDD development + writes all the documents required by standard methodology - big overhead.
- The love for tools. While FDD tools are a big help for FDD development, sometimes people use the FDD tool only for the sake of the reports. Without modeling, design inspections, code reviews and iterative releases - it is not really FDD.
Thanks
Thanks Skhramtc, I'll have a look at your doc (I have an idea that I read it a few months ago).
I've been giving the whole issue some more thought, and another issue that could be raised with FDD is one that I'm currently experiencing now: that of the time taken to write features for a tightly-deadlined project.
I'm finding that it's taking a long time to get features written on a project, due to the requirements gathering process being somewhat slow. As a result, we've eaten into development time.
Again, thanks for the help,
Dominic
Requirements and FDD
FDD doesn't "drop" out the requirements phase - it just doesn't cover it. You should still do them, the same as testing. The details on techniques for testing aren't covered either, but that doesn't mean you don't do it.
The practices that are covered are included because that's what Jeff has built up (over 20 years) as a repeatable process, from experience, that works for that part of the development process. The same can't be said for the requirements process - it's usually still a case of having a large bag of techniques and having the experience to know which ones to apply to various situations. Some even argue that requirements will always be that way (e.g. the Parnas article on "How and when to fake a rational design process", I think - from memory).
FDD takes whatever requirements you have - they are the input to process one "develop an overall model". If you have no requirements up front things can take longer, as you're doing more requirements elicitation and analysis while you're modelling.
I've seen it work fine where use cases were the method of choice for documenting the requirements, in one case with over 2,000 pages of use cases. Given a choice I'd certainly avoid use cases, but that doesn't mean they can never be used.
So yes, do requirements as well as you can. If you've got an approach that works for you - keep using it. If you've got a technique that works again and again - tell people about it.
Paul.
No design == bad results
I don't think this particular problem is unique to FDD:
"...people often do not want to reserve time for modeling. This leads to all kind of problems later."
Adding enhancements to an existing system is often more difficult than starting with a clean slate. You are always trying to balance the amount of effort to add in the change vs. the amount of rewrite. Sometimes shortcuts are taken, where a less than ideal design is settled on in order to get it done quicker. There's no right answer here - it just depends.
The other common case is where you have no design for the existing system. What then? Do you reverse engineer one from the current implementation, and then use that as the starting point for modelling the enhancements? Or do you just model the new stuff, and then somehow figure out how to graft that onto the existing code? Any way forward is scary.
I think these are usually the reasons people hesitate to use any technique that tries to design the enhancements before trying to build them. FDD just makes this more obvious, since the starting point is the shape modelling.
On the other hand if you have the design for the current system already, e.g. the class diagram, you simply use this as the starting point for the modelling in process one next time around. That's another reason why tools that keep the model "alive" are so valuable. Tools that don't allow simultaneous round-trip between tour code and model mean that the model is dead on day 2. It decays very quickly, and you have to eithet let it die or spend a lot of time trying to manually update it.
Since few tools do this at all, including the market leader, most people just let the model die. And so most people are in trouble when it comes to phase 2, since they tend to just skip the design part and "hack in the changes". I don't see it as a methodology problem, but still a very real problem.
Paul.