- I apologize if you thought I was trying to imply that using User Stories (or anything other than use cases) was jumping in and hacking. I simply meant toMessage 1 of 28 , Jul 31, 2006View SourceI apologize if you thought I was trying to imply that using User Stories (or anything other than use cases) was "jumping in and hacking." I simply meant to imply that most straight-out-of-college CS grads have little to no exposure or appreciation for any type of requirements gathering. However, I would also suggest that the use of use cases (or any type of development tool) does not indicate a lack or presence of flexibility. The process by which you develop software, and how it adapts to the different and changing constraints on the software system you're trying to construct, is the only thing that REALLY determines flexibility, IMHO.~Tim
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Ron Jeffries
Sent: Monday, July 31, 2006 5:38 PM
Subject: Re: [scrumdevelopment] Re: User stories - has it worked for you?
Thanks for your email. On Monday, July 31, 2006, at 3:00:38 PM, you
> Whether or not it is useful to deliveronly the main path would depend
> on the use case, I wouldthink.
Yes. For example, if they didn't really want it ever to work, then
the main path wouldn't be useful.
But otherwise ... it seems to me to be pretty useful in every case.
> My strategy using use cases has been to address them as a living form
> requirements documentation during a sprint, and then baselinethem
> (along with the code) at the end of the sprint. My QA guy does mostof
> his testing a sprint behind and bases alot of it on the use cases.He
> receives both a nicely packaged version of the application andthe
> corresponding use cases for the newly implemented features at theend of
> a sprint.Ah. Well, if you want to test a sprint behind, then I suppose
tossing a bunch of paper (probably electronic but you get my point)
over the wall to your QA guy is as good a way to do it as any.
> Therefore, if it were useful to deliver "just the main path" for
> sprint, that's the only thing that would be in the use casecorresponding to a given feature at the end of the sprint. If the team
>decides to add an alternate scenario during a later sprint, they add
>that to the use cases and that functionality will be expected in the
Yes. I think the OP was talking about a full-on use case with all
its paths ... in fact I think he verified that. In that case, I'd
think that the main part of the case could be quite valuable.
> It should be noted that I'm working in a smaller company where
> development team is 9 recent CS grads who have a total of about10-15
> years experience between them. I chose use cases because I feltthey
> would help show the value of exploring your requirements beforejumping
> in and hacking, even if they are a bit more formal. It seemslike most
> of you fight the opposite battle -- getting changes done wherealot of
> people are set in their ways.Well ... if I were starting with recent graduates, I wouldn't choose
to contaminate their minds with use cases, but instead would
contaminate their minds with flexibility. That's because I don't
recommend jumping in and hacking, I recommend jumping in and
implementing in a professional manner.
But to each his own ...
That's my opinion and I agree with it. -- Julio Santos