rspec users - Mar 2009 - Feature Size-Scope-Scale

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.
-- 
Posted via http://www.ruby-forum.com/.

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 Mon, Mar 2, 2009 at 10:07 AM, James Byrne <lists at ruby-forum.com>
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 (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org