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

46228RE: [scrumdevelopment] iterative development with system design

Expand Messages
  • Roy Morien
    Apr 3, 2010
      Sorry Imran, my Farsi is a bit rusty. What was that you said?

      To: scrumdevelopment@yahoogroups.com
      From: ather.imran@...
      Date: Fri, 2 Apr 2010 15:47:33 +0000
      Subject: Re: [scrumdevelopment] iterative development with system design

      Hfrfgvhgggggggggggg gggggGggg.

      *** This Message Has Been Sent Using BlackBerry Internet Service from Mobilink ***

      From: Roy Morien <roymorien@hotmail. com>
      Date: Wed, 31 Mar 2010 14:02:23 +0000
      To: <scrumdevelopment@ yahoogroups. com>
      Subject: RE: [scrumdevelopment] iterative development with system design

      I agree entirely ... a basic tenet of good project management is to ensure the feasibility of the product, and that must include approaching the riskiest parts, or most complex parts,  of the system first. If they cannot be done, then there is little point in spending time on the easy bits.
      But that has little to do with the matter of whether or not you plan ahead, and try to second guess what might lie ahead to avoid refactoring etc.
      The question that I alway ask about database designs, usually done in a BDUF manner, is why (as an example) it is necessary to know about 'TEACHERS' when we are analysing 'STUDENTS'. To me, developing the database is a bit like 'How do you eat an elephant?' ... a little at a time. If you apply those basic tenets that Ron mentioned earlier about programming (high cohesion, low coupling, modularity) to the database then you can evolve the database without much refactoring, if any. To me, adding a new table to the database is not refactoring. Even adding new columns to a database table isn't really refactoring, in my book.
      The fundamental problem being addressed is where new requirements demand a destructive redevelopment of previously completed work. How often does this happen if good design principles are followed?
      This seems like a folk memory of olden days, of werewolves and ghoulies that aounded in an earlieer time, in the form of having to restructure an IMS schema, for example. Of having to rewrite the processing code to an X-Y addressed terminal, for another example. But times have changed!
      Roy Morien

      To: scrumdevelopment@ yahoogroups. com
      From: stephan.huez@ gmail.com
      Date: Wed, 31 Mar 2010 11:56:11 +0200
      Subject: Re: [scrumdevelopment] iterative development with system design

      Hi all,

      Personally, and maybe it's due to my RUP experience and architect's background, I tend to follow the RUP principle of identifying architecturally significant use cases, which
      will be stories in this case.

      I think it's worth identifying what stories bear the greatest technical risks and uncertainties and ask the PO whether the team can plan them in early iterations. The
      architectural value must of course be balanced with the business value. If a story were technically risky with a limited business value, it could wait for sure.

      Working this way allows for sort of securing, most probably only temporarily, architectural choices but for stories that bring value to the customer. You don't design and
      architect the solution for future stories but for those that you implement right away only. This also means that from one sprint to the next, there will nevertheless be
      refactoring because we don't do any big design upfront but instead implement the solution that serves the stories planned in the sprint.



      On Wednesday 31 Mar 2010 06:30:16 Roy Morien wrote:
      > Has this question arisen becaue you have a real situation that you need to
      > overcome (in which case could you give me / us a concrete example), or are
      > you asking 'just in case' you face the situation in the future?
      > I often think situations like this are more apparent than real, and are
      > usually brought about because of poor design and programming practices,
      > rather than being a problem in its own right.
      > For (a simple) example, if I write a function that reads the clock and
      > checks to find if a file exists, then I may very well run into a
      > refactoring requirement if someone in the future just wants to call a
      > function to read the clock. But this is, of course, bad programming
      > practice, which has caused the need for refactoring
      > If I design a database tale, that is subsequently found to need more
      > datafields, then I guess I am going to need to 'refactor' my database ...
      > is this poor analysis practice wherein I should have found ALL of the
      > datafields at the start? No, it is simply evolution of undersanding about
      > the requirements. Is it a huge problem? No, refactoring databases is
      > almost a trivial activity these days, but does have an impact on
      > processing code.
      > SO in one situation we have poor code, demanding refactoring, and on the
      > other situation we have an evolution of understanding, which is a good
      > thing.
      > If I must refactor my database because of efficiency concerns, because the
      > db traffic grew well beyond expectations, then maybe some better forward
      > thinking was in order ... but we are all wise in hindsight. This again
      > doesn't really seem to be an example of your apparent concern.
      > Let us know more.
      > Regards,
      > Roy Morien
      > To: scrumdevelopment@ yahoogroups. com
      > From: adam.sroka@gmail. com
      > Date: Tue, 30 Mar 2010 21:18:39 -0700
      > Subject: Re: [scrumdevelopment] iterative development with system design
      > On Tue, Mar 30, 2010 at 9:05 PM, zp.dai <tyitsf@hotmail. com> wrote:
      > > Hi guys,
      > >
      > > When the team is working on stories for the current sprint, how can they
      > > do a good design which can also covers stories in future well? In other
      > > word, how do you suggest to minimize refactoring existing code?
      > Keep the design simple, in large part by refactoring proactively.
      > Also, have frequent discussions about the general approach and how to
      > improve it - include everyone.
      > > In our team, we will write dev approach for the all defined user stories,
      > > no matter they will be done in this sprint or next. But I'm not sure
      > > this is the best practice, as this seems not so iteratively somehow.
      > I would suggest having discussions opportunistically - as close as
      > possible to the time when you actually do it. Writing it down is much
      > less important than talking about it. Designing it too soon is almost
      > certainly wasteful, because things will change. Designing it too late
      > will lead to more refactoring/ re-designing, as you implied. Designing
      > it just in time (As you are about to implement it) works very well.
      > ____________ _________ _________ _________ _________ _________ _
      > Get personal with Windows. Download a free gift for your PC.
      > http://experience. windows.com

      Meet local singles online. Browse profiles for FREE!

      Australia's #1 job site If It Exists, You'll Find it on SEEK
    • Show all 19 messages in this topic