Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] First User Story in an Embedded System

Expand Messages
  • Steven Woody
    On Thu, Oct 22, 2009 at 1:17 AM, James Grenning ... Thanks James, I am reading your papers on the net. ... -- Life is the only flaw in an otherwise perfect
    Message 1 of 5 , Oct 22, 2009
    • 0 Attachment
      On Thu, Oct 22, 2009 at 1:17 AM, James Grenning
      <james.grenning@...> wrote:
      >
      >
      >
      > A core behavioral story deals with the features of the system being
      > developed. For example, let's say you are building an alarm clock.
      > How the alarm is set is a function of the hardware and software: maybe
      > you press and hold the Alarm while pressing combinations of the Hour+,
      > Hour-, Minute+, and Minute- buttons.
      >
      > You can write a test for the core behavioral story of "setting the
      > alarm" without actually interacting with the hardware. I abstract the
      > hardware and simulate its interaction with the core of the system by
      > generating button press and button release calls into the core of the
      > system. These tests suggest that something near the hardware detects
      > a valid button press and release, and feeds the events to the
      > application. Notice the second test can also simulate that a button
      > is held for a while. The hardware abstraction also has an out going
      > interface for messages sent to the Alarm Display. Our tests can
      > intercept these messages.
      >
      > Test - increment alarm by one hour
      >
      > ResetAlarmToInitialState
      > Press(AlarmSetButton)
      > CHECK(AlarmDisplay == 00:00)
      > Press(HourPlusButton)
      > Release(HourPlusButton)
      > CHECK(AlarmDisplay == 01:00)
      > Release(AlarmSetButton)
      >
      > Test - auto increment alarm. After one second, two increments per second
      >
      > ResetAlarmToInitialState
      > Press(AlarmSetButton)
      > CHECK(AlarmDisplay == 00:00)
      > Press(HourPlusButton)
      > SimulateHoldingButtonFor(3 seconds)
      > Release(HourPlusButton)
      > CHECK(AlarmDisplay == 05:00)
      > Release(AlarmSetButton)
      >
      > These tests are testing the core of the alarm clock. The actual
      > implementation of the hardware implementation might not be known, or
      > may change. If we are making a family of alarm clocks this hardware
      > independent code could work with many different implementations.
      >
      > Once there is hardware, it is wise to run in the hardware ASAP. The
      > hardware independent tests should be kept and run regularly. They
      > maintain their value if you keep evolving them with the
      > implementation. You might need to keep track of hardware integration
      > stories, so they can be planned for iterations once the hardware is
      > ready.
      >
      > Regarding the "demonstrations".... In XP, the focus is on delivering
      > value. In an embedded system there is nothing to deliver when the
      > hardware is not ready. So instead of delivering value, we demonstrate
      > progress. These demonstrations are in the form of tests.
      >
      > I'll be posting a blog on story tests for embedded in the near future.
      >
      > You can find some articles here:
      > http://renaissancesoftware.net/papers.html
      > www.renaissancesoftware.net/blog
      >
      > James
      >

      Thanks James, I am reading your papers on the net.


      > -----
      >
      > James Grenning
      > james@...
      > www.renaissancesoftware.net
      > www.twitter.com/jwgrenning
      >
      > On Oct 20, 2009, at 11:56 AM, Steven Woody wrote:
      >
      > >
      > > I am not so clear about the 'core behavioral story'. Has is business
      > > values and is it real? And, why you said the story 'tests'
      > > interactions with some hardware 'abstraction' ( I don't understand
      > > what are exact meaning for the 'test' and 'abstraction' here).
      > >
      > > Another question about that is, in the later stage of the development,
      > > when hardware is fully ready, should we replace the hardware
      > > abstraction for the story? So, a completed story turns to be an
      > > uncompleted story, is it good?
      > >
      > >
      > >
      > >>
      > >> Another challenge is when you get real close to the hardware. To make
      > >> the progress visible might mean enlisting a hardware engineer to play
      > >> the role of customer for those hardware/software boundary stories.
      > >> The typical embedded engineering going away for a month or three to
      > >> work out the hardware interactions can be replaced with a series of
      > >> demonstrations. For example, implementing a flash driver might mean a
      > >> series of demonstrations like:
      > >> Flash device detectable
      > >> Flash responds to the CFI command
      > >> A flash location can be programmed and read back
      > >> A block can be programmed then protected
      > >> etc...
      > >
      > > I don't understand why you use 'demonstrations' here, who demonstrates
      > > who? In the example above, people are implementing a flash driver at
      > > that moment? If so, what are the stories exactly?
      > >
      > >
      > >>
      > >> The product owner might not be so interested in each little step a
      > >> long the way, but they do demonstrate progress and enable tracking by
      > >> working stories. It also gives the product owner the ability to ask:
      > >> "Why do I need block protect?", or "why do i need CFI?"
      > >>
      > >> I have some papers, presentations and blog articles about applying
      > >> agile/XP to embedded. Let me know if you need any pointers to them.
      > >>
      > >> James
      > >
      > > I so much interest the papers you mentioned. Please be kind to give
      > > me a link. Thank you very much!
      > >
      > >
      > >>
      > >> ----
      > >> James Grenning
      > >> james@...
      > >> www.renaissancesoftware.net
      > >> www.renaissancesoftware.net/blog
      > >> www.twitter.com/jwgrenning
      > >>
      > >> On Oct 20, 2009, at 7:04 AM, Steven Woody wrote:
      > >>
      > >>> Hi,
      > >>>
      > >>> In a embedded system, hardware and software engineer work together
      > >>> to
      > >>> build a product with hardware and software. So what is the first
      > >>> user
      > >>> story in this case? Does the user story method still suitable?
      > >>>
      > >>> Thanks.
      > >>>
      > >>> --
      > >>> Life is the only flaw in an otherwise perfect nonexistence
      > >>> -- Schopenhauer
      > >>>
      > >>> narke
      > >>> public key at http://subkeys.pgp.net:11371 (narkewoody@...)
      > >>>
      > >>
      > >> [Non-text portions of this message have been removed]
      > >>
      > >>
      > >
      > >
      > > --
      > > Life is the only flaw in an otherwise perfect nonexistence
      > > -- Schopenhauer
      > >
      > > narke
      > > public key at http://subkeys.pgp.net:11371 (narkewoody@...)
      >
      >


      --
      Life is the only flaw in an otherwise perfect nonexistence
         -- Schopenhauer

      narke
      public key at http://subkeys.pgp.net:11371 (narkewoody@...)
    Your message has been successfully submitted and would be delivered to recipients shortly.