The more I work with BDD the more I realize how different this is from my previous experience. I now consider that part of the difficulty I have lies in establishing the proper scale for the features that I propose. My question lies in that vein. What size should a feature be? 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. Returning to my client case. Given that the system must permit administering clients then does one have a single feature called "System has clients..." and bundle all the activity related thereto in its scenarios. 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.
on 2009-03-02 16:07
on 2009-03-02 16:24
On 2-mrt-2009, at 16:07, James Byrne wrote: > The more I work with BDD the more I realize how different this is from > my previous experience. I now consider that part of the difficulty I > have lies in establishing the proper scale for the features that I > propose. My question lies in that vein. What size should a > feature be? It should be big enough to describe the functionality. Imagine a weblog system, with which a user can post articles. My typical approach would be 4 features, Creating/Editing/Destroying and Viewing a post. Imagine I have validates_presence for the title and contents of an article. The Creating feature would have 3 scenarios: - Creating an article - Creating an article without a title - Creating an article without the contents Updating, 4 scenarios: - Updating the title - Updating the contents - Removing the title (eg, a blank title) - Removing the contents Destroying and Viewing would be just 1 scenario. I am rather curious what other list members use though.. cheers, bartz
on 2009-03-02 18:04
On Mon, Mar 2, 2009 at 10:07 AM, James Byrne <firstname.lastname@example.org> 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@example.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org