On Mon, Mar 2, 2009 at 10:07 AM, James Byrne <[email protected]> wrote: > > I have read a great deal about scaling features in terms of hours of > work. However, at my present level of inefficiency, that will probably > result in features that are too small just as I now believe that the > features I have now are too large. Besides which, I seem to grasp > examples better than metrics when conceptualizing such things.
Real features for a real project I'm working on: Feature: View Episodes As a listener I want to see a list of episodes So that I can experience the joy of consuming them Feature: Create Episode As a podcaster I want to add an episode So that I don't die like Emily Dickinson Feature: Edit Episode As a podcaster I want to edit an existing episode So that my listeners can catch my mistakes for me Feature: Add MP3 Enclosure As a podcaster I want to link to an MP3 file So that people don't confuse me for a blogger ...That's my basic feature size. An atomic unit of work, and generally one that comprises a single Web interaction. I'll usually put down 2-3 scenarios when I make the feature file (critical success path, and at least one exception case) and then add more if/when I think of them. These mostly fall out to a few hours of work each, but that seems to be a natural consequence of thinking at an atomic level and not a deliberate goal I'd planned for. If one of them took days, well, it'd take days. > [ . . . ] Or, as I begin to suspect, should one have separate features > like "Add a new client"; "Deactivate an existing client"; Reactivate an > inactive client"; "Report all active clients; ... and so forth. Here would be my suggestion: * Start by doing it the way you think makes the most sense. * If it feels good and seems to result in better code done faster, keep doing it that way. * If it hurts, or slows you down without a quality increase, either try changing the way you're doing it, or stop doing it entirely. * Whenever you next run across something that you think might be a good improvement in your working methods, repeat steps 1-3. Penultimately it's about people and product. But people build the product, so ultimately it's about people. You need to figure out what works for you and your task at hand. Others can offer advice or experiences but they can't give you the right answers. -- Have Fun, Steve Eley ([email protected]) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
