| |
Agile Software Development Made Easy! |
Hey Stevio, A1: Go to Bill Wake's website (XP123.com) and look for the article "Twenty A2: Create a release, starting with release planning, and a number of A3: I don't have one documented (did see the AOL Video API team do this Success, Hubert > Q1. Is there any very clear and concise presentation/material > Q2. If a new feature requires a major investment in terms of new > Q3. Does anyone know of a real world example that is well documented > Both of the above are being given as objections to us adopting Scrum > Thanks for any suggestions,
ways to split stories"
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.
successfully). Browse around the yahoo groups for the Embedded Agile group.
> 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?
> 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.
> somewhere which shows the power of Agile in a complex embedded
> development environment (not applications)?
> and I'd like some help removing these blockages.
> Stevio