Re: Application Framework and database design
Cory Foy <usergroup <at> cornetdesign.com>
2008-10-01 02:22:35 GMT
Hi Bill,
wfc_85283 wrote:
> I'm new to Scrum so please be patient.
We've all been there. Literally. Well, maybe not Ken, since he would
have been an old hat as soon as he designed it. But, for sure, the rest
of us.
> Being an old waterfall guy, I'm accustomed to planning the application
> framework (common objects, inheritance structure, error processing,
> ect.) and designing the database up front.
One of the common misconceptions I see often is that a move from
waterfallish practices to agilish practices also means going from Big
Design Up Front (BDUF) to No Design Up Front (NDUF).
The good thing is that it isn't true. Design up-front is encouraged -
you don't throw away your thinking cap. What you are encouraged to do is
do just enough architecture work. The balance can be tough to achieve
sometimes. The easiest way to think of it comes from the Toyota System.
Designing and cutting the dies that were used to make the cars was one
of the most vital (and expensive) parts of the process. In the U.S., the
manufacturers would freeze the design, and then send it to the die
cutters. This meant that any changes after the fact would be quite
expensive - possibly resulting in the die having to be recreated.
However, in Toyota, the designers worked closely with the die cutters,
who had the expertise to know which parts of the die were likely to
change. As such, they could work somewhat in parallel so that the final
die was completed very rapidly after the final design.
In a similar way, you want to design the architecture so that it meets
your needs, but stay agile enough to be able to have changes happen in
both sides.
> To add to the complexity, we are outsourcing the development. I am
> the Product Owner. The Scrum Master and the Team are outsourced and
> do not have strong industry knowledge or a good understanding of our
> day to day operations.
This will be a large challenge for you. What this means is that the
traditional communication fostered by an onsite team will be lost. There
are a couple of things that I would highly recommend:
- Frequent calls. They should be able to reach you any time they are
working if they have a question - and should be encouraged to contact you.
- Webcams - One of the best investments I've made with remote teams is
each end having a webcam. They can call on the phone, and you all can
stare at each other through it. It's amazing, and quite underrated, how
much of an impact this can have
- Daily Stand-Ups - The trick here is making sure that the team you are
working with is highly encouraged to report failures and successes. The
number one issue I run into with outsourced teams is a fear of reporting
bad news, or things that are blocking them. This may be because they
want the contract, or may be an aspect of their culture. Become very
aware when they always say every thing is rosy.
> Our application incorporates 24 functional areas. It is my
> understanding that each Sprint within the Scrum addresses a functional
> area or a subset of the stories within a functional area.
The goal of each Sprint is for the team to deliver Running, Tested
Features (http://www.xprogramming.com/xpmag/jatRtsMetric.htm). The work
they do is dictated by your prioritization based on the business value -
the highest business value items should come first.
> It sounds to me like we are going to end up with a bunch of objects
> pieced together and a database that is not all that relational. Or as
> each new Sprint is implemented, we will need to rework other functions
> and redesign the database.
It is possible that an aspect of a story in a Sprint will cause a change
to an earlier completed feature. However, unless you were one of the
rare success stories I've heard of with Waterfall, it's likely that you
all still had rework that happened there.
As far as the design and architecture - it's the responsibility of you
and the team not to work in a silo, but be cognizant of the details of
other stories around you. While stories should avoid being dependent on
each other, you all should stay aware of stories that are related and
should be completed together.
I'd also recommend looking at the User Stories Applied book by Mike Cohn
(http://www.mountaingoatsoftware.com/books), and the Agile Databases
book by Scott Ambler
(http://www.ambysoft.com/books/agileDatabaseTechniques.html)
> I've got the User Stories for the first Sprint complete and the Team
> wants to get started. Are we missing a step?
Yes. Get started. ;) You can always adjust as you go, and you can always
ask us here for help, or advice.
--
Cory Foy
http://www.cornetdesign.com
http://www.agileflorida.com
------------------------------------
To Post a message, send it to: scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:scrumdevelopment-digest <at> yahoogroups.com
mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com
<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe <at> yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
> > Mark > > --- In scrumdevelopment <at> yahoogroups.com > <mailto:scrumdevelopment%40yahoogroups.com>, Dan Rawsthorne > <dan.rawsthorne <at> ...> wrote: > > > > Actually, no. The Use Case was a Class, the Scenarios were the > > instances. And, to be more specific, in the UML the Use Case was a > > Classifier, which was an abstraction of Class. Then the implementation > > of a scenario was described with these other classes, the boundary, > > controller, entity, I think. It got a little carried away... but made > > for some pretty diagrams > >
RSS Feed