Hey Stevio,
A1: Go to Bill Wake's website (XP123.com) and look for the article "Twenty
ways to split stories"
A2: Create a release, starting with release planning, and a number of
Sprints. Every Sprint delivers the prioritized architectural stories, *proven
by user requirements*. The user material can be minimal, but it has to be
real and serves to prove that your architecture things are working in a real
environment. The first release can have a release goal to 'prove the
architecture'. More info in my paper on 5 levels of planning (see
www.rallydev.com). Try to keep this release as short as possible, you will
not to be able to predict architectural requirements any more then you can
predict user requirements.
A3: I don't have one documented (did see the AOL Video API team do this
successfully). Browse around the yahoo groups for the Embedded Agile group.
Success, Hubert
On Wed, Oct 15, 2008 at 12:00 PM, Stevio <st
...@jsbrewer.plus.com> wrote:
> Q1. Is there any very clear and concise presentation/material
> available anywhere which summaries to senior software chaps how to
> break complex features down into chunks that are small enough to
> implement and test within a single Scrum iteration?
> Q2. If a new feature requires a major investment in terms of new
> architectural infrastructure which is going to take multiple sprints
> to develop (it's 3 months work), what do you deliver as working,
> tested code at the end of an sprint? If you spend lots of time
> developing unit tests for this, they are pretty much useless later in
> the process once more of the design has been implemented and are
> therefore seen as wasted effort.
> Q3. Does anyone know of a real world example that is well documented
> somewhere which shows the power of Agile in a complex embedded
> development environment (not applications)?
> Both of the above are being given as objections to us adopting Scrum
> and I'd like some help removing these blockages.
> Thanks for any suggestions,
> Stevio
|
