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

Re: Where do you do all the ‘other’ stuff?

Expand Messages
  • davenicolette
    I guess you meant to say refactoring in each and every TDD cycle, and not just in each and every sprint, right?
    Message 1 of 32 , Mar 18, 2009
    • 0 Attachment
      I guess you meant to say refactoring in each and every TDD cycle, and not just in each and every sprint, right?

      --- In scrumdevelopment@yahoogroups.com, Mike Freislich <mike@...> wrote:
      >
      > In addition to this, it may not be obvious to someone new to "incremental"
      > development, but a critical aspect of incremental development is "continuous
      > refactoring". This means that we need to refactor the design (UI, Arc etc.)
      > in each and every Sprint. Without this, we would need to have a big up-front
      > design (which is not good for Agility, and so many other things). We need to
      > understand that it isn't possible to build the 'perfect' system from the
      > start. When we sit down to develop the first feature, we do so with the
      > knowledge of the requirements and design that we have at the time. The more
      > features we add, the more this knowledge will grow. We may need to refactor
      > some of the design in order to add the next "block" elegantly.
      >
      > -Mike
      >
      > 2009/3/16 davenicolette <dnicolet@...>
      >
      > > Sorry, I didn't answer your first question. In the first sprint I expect
      > > to see at least *some* amount of customer-visible value, even if it's just a
      > > trivial amount. I would not want to see old-style horizontal development
      > > starting to happen - bottom layer first, etc. I would want to see vertical
      > > slices of the solution starting to take shape - end-to-end through the
      > > solution architecture, even if that architecture isn't complete yet.
      > >
      > > An example: I was on a project to replace a COTS package with a home-grown
      > > solution. The customer was especially concerned with a certain portion of
      > > the logic that they weren't sure we could support easily with the home-grown
      > > solution. They defined that bit of functionality as the top priority item.
      > > We were able to build and demonstrate that logic with none of the technical
      > > infrastructure or the "real" UI in place. The customer was confident we knew
      > > how to do those things, and that we could put those things in place any time
      > > we wanted to. They really wanted to see that particular bit of functionality
      > > working, even if it was demonstrated outside the context of a
      > > realistic-looking version of the application. They were very pleased with
      > > the demo.
      > >
      > > The key thing is you can always add details later, including architectural
      > > details and UI details and whatever. We typically build the solution in
      > > small building blocks with everything surrounding each building block faked
      > > out. We do it that way so that we can write well-isolated tests for each bit
      > > of functionality. Another result of the approach is that we can build up the
      > > solution in just about any order; it isn't necessary to build all the
      > > infrastructure first, or to have all the details like look-and-feel
      > > standards defined in advance.
      > >
      > > I hope that helps.
      > >
      > > Dave
      > >
      > > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
      > > Neil Middleton <neil.middleton@> wrote:
      > > >
      > > > So, what sort of things would you expect to see in the first sprint?
      > > Where
      > > > would things like overall Design look-and-feel sit, even though it's not
      > > an
      > > > implementable item as--such?
      > > >
      > > > On Mon, Mar 16, 2009 at 6:27 PM, davenicolette <dnicolet@> wrote:
      > > >
      > > > > Imagine you had a list of 100 features that need implementing. Your
      > > > > customer chooses the #1 priority feature. You build the UI, the code,
      > > and
      > > > > whatever portion of the technical infrastructure is required to support
      > > that
      > > > > one feature. You deliver it. Then you move on to the #2 priority
      > > feature.
      > > > > Does that sound feasible to you?
      > > > >
      > > >
      > > >
      > > >
      > > >
      > > >
      > > >
      > > > --
      > > > Neil Middleton
      > > >
      > >
      > >
      > >
      >
      > --
      > Mike Freislich
      > Certified Scrum Practitioner
      > Scrum Sense CC
      > mobile: +27 82 377 4349
      > fax: +27 86 537 4349
      > skype: mike.freislich
      > web: http://www.scrumsense.com
      >
    • davenicolette
      I guess you meant to say refactoring in each and every TDD cycle, and not just in each and every sprint, right?
      Message 32 of 32 , Mar 18, 2009
      • 0 Attachment
        I guess you meant to say refactoring in each and every TDD cycle, and not just in each and every sprint, right?

        --- In scrumdevelopment@yahoogroups.com, Mike Freislich <mike@...> wrote:
        >
        > In addition to this, it may not be obvious to someone new to "incremental"
        > development, but a critical aspect of incremental development is "continuous
        > refactoring". This means that we need to refactor the design (UI, Arc etc.)
        > in each and every Sprint. Without this, we would need to have a big up-front
        > design (which is not good for Agility, and so many other things). We need to
        > understand that it isn't possible to build the 'perfect' system from the
        > start. When we sit down to develop the first feature, we do so with the
        > knowledge of the requirements and design that we have at the time. The more
        > features we add, the more this knowledge will grow. We may need to refactor
        > some of the design in order to add the next "block" elegantly.
        >
        > -Mike
        >
        > 2009/3/16 davenicolette <dnicolet@...>
        >
        > > Sorry, I didn't answer your first question. In the first sprint I expect
        > > to see at least *some* amount of customer-visible value, even if it's just a
        > > trivial amount. I would not want to see old-style horizontal development
        > > starting to happen - bottom layer first, etc. I would want to see vertical
        > > slices of the solution starting to take shape - end-to-end through the
        > > solution architecture, even if that architecture isn't complete yet.
        > >
        > > An example: I was on a project to replace a COTS package with a home-grown
        > > solution. The customer was especially concerned with a certain portion of
        > > the logic that they weren't sure we could support easily with the home-grown
        > > solution. They defined that bit of functionality as the top priority item.
        > > We were able to build and demonstrate that logic with none of the technical
        > > infrastructure or the "real" UI in place. The customer was confident we knew
        > > how to do those things, and that we could put those things in place any time
        > > we wanted to. They really wanted to see that particular bit of functionality
        > > working, even if it was demonstrated outside the context of a
        > > realistic-looking version of the application. They were very pleased with
        > > the demo.
        > >
        > > The key thing is you can always add details later, including architectural
        > > details and UI details and whatever. We typically build the solution in
        > > small building blocks with everything surrounding each building block faked
        > > out. We do it that way so that we can write well-isolated tests for each bit
        > > of functionality. Another result of the approach is that we can build up the
        > > solution in just about any order; it isn't necessary to build all the
        > > infrastructure first, or to have all the details like look-and-feel
        > > standards defined in advance.
        > >
        > > I hope that helps.
        > >
        > > Dave
        > >
        > > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
        > > Neil Middleton <neil.middleton@> wrote:
        > > >
        > > > So, what sort of things would you expect to see in the first sprint?
        > > Where
        > > > would things like overall Design look-and-feel sit, even though it's not
        > > an
        > > > implementable item as--such?
        > > >
        > > > On Mon, Mar 16, 2009 at 6:27 PM, davenicolette <dnicolet@> wrote:
        > > >
        > > > > Imagine you had a list of 100 features that need implementing. Your
        > > > > customer chooses the #1 priority feature. You build the UI, the code,
        > > and
        > > > > whatever portion of the technical infrastructure is required to support
        > > that
        > > > > one feature. You deliver it. Then you move on to the #2 priority
        > > feature.
        > > > > Does that sound feasible to you?
        > > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > >
        > > > --
        > > > Neil Middleton
        > > >
        > >
        > >
        > >
        >
        > --
        > Mike Freislich
        > Certified Scrum Practitioner
        > Scrum Sense CC
        > mobile: +27 82 377 4349
        > fax: +27 86 537 4349
        > skype: mike.freislich
        > web: http://www.scrumsense.com
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.