Ask any question about Agile development or the process of software development in general and I'll do my best to answer it. If you'd like to see a post on a particular subject, let me know and I'll consider it.
In the meantime, there's a lot of information on Agile here: "Zero to Hyper Agile in 90 Days or Less" .
Please note that I will continue to remove all spam comments.
4 comments:
We're doing Scrum on a 10-12 person team (depending on what the DBAs are working on at the moment) and one of the more interesting problems I've been talking about with people is how to scale the process. I have a friend on a 200+ person project and they do Scrum-of-Scrums every day so one person from each "lower level" scrum team goes to another scrum meeting and so on up to the meeting with all the main project heads. This sometimes ends up taking 2 hours out of people's days if they have to go to a bunch of the scrum-of-scrums. What are your feelings on scaling Agile processes up to larger teams? Do you sacrifice somebody to be the "meeting person"? To me communication has always been the most important part of any Agile process, how do you keep that in large teams?
That's too much for one question probably but you asked. :)
Matt,
Thanks for your question! You are right, it was a big question and it took me a while to compose an answer. Actually, I've created a new post to answer your question.
Damon
Hi Damon,
At college, I’m taking a course about "Requirements Engineering" and I've been assigned a presentation about requirements in eXtreme Programming.
I've read some blogs and I think that I got a general idea about how requirements are handled in XP: incremental requirements, onsite customers, the whole team sit together, express business rules through customer tests (fitnesse)... Also I’ve learned that User Stories are not requirements documents but an estimation tool for the weekly iteration.
In the course, my professor focuses on RUP and use cases. I want to share that use cases can be a helpful technique but XP focuses on personal interaction over documentation, and that use cases are not required or prohibited by XP.
Do you think I’m in the right track? Can you do XP and still apply use cases as technical documentation that is done just-in-time by the developer?
Hi Oscar,
At the end of the day, you can do whatever you want in software development, and most projects do! There are actually quite a few commonly agreed on software development best practices, but there is no name for this collection. Hmm, I think I've just stumbled on a new blog post. Anyway, with regards to your question, beyond this common set, no two groups do the same thing.
I would say that the quick answer to your question is that up to the part about user stories, you are on the right track, but that user stories do replace requirements documents and are not just for estimation.
There are of course two parts to requirements/user stories. The first part is gathering information from users as you have described. Then there is the recording of those requirements. XP tends towards fairly light recording, for instance via tests. However, many people use user stories.
Personally, I believe there is a lot to be learned from Requirements Engineering, but mostly on the elicitation of requirements, not on the documentation of those requirements. That is, finding out what users really need at a high level so that you can produce a product which meets their needs with high usability.
Two good resources on these subjects are:
Extreme Programming Explained – First and Second Edition, Kent Beck
User Stories Applied - Mike Cohn
Post a Comment