Loading ...
Sorry, an error occurred while loading the content.
Skip to search.
 

Re: [scrumdevelopment] Completeness definition

Expand Messages
  • David H.
    ... I beg to differ. But I guess that is purely philosohpical. To me it is part of Scrum because scrum does define a methodology that leads to certain
    Message 1 of 15 , Mar 3, 2005
      > > >
      > > > This is the sort of stuff I can live with and makes sense. I *have*
      > > > wondered about the "Code has been refactored" requirement. What if
      > > > code is well factored to start with? Do we always need to refactor?
      > > >
      > > Refactoring is a big part of Scrum and test driven development in my
      >
      > Scrum defines no engineering practices. That is not to say that
      > refactoring or TDD isn't important, it is just not part of Scrum.
      >
      I beg to differ. But I guess that is purely philosohpical. To me it is
      part of Scrum because scrum does define a methodology that leads to
      certain processes. Maybe one could argue that it is more part of test
      driven development than scrum. But then again, who cares :)

      -d
    • Chris Brooks
      ... I should clarify my original comment. Fowler s definition of refactoring is the process of changing a software system in such a way that it does not
      Message 2 of 15 , Mar 3, 2005
        On Thu, 3 Mar 2005 19:55:23 +0100, David H. <dmalloc@...> wrote:
        >
        > > > >
        > > > > This is the sort of stuff I can live with and makes sense. I *have*
        > > > > wondered about the "Code has been refactored" requirement. What if
        > > > > code is well factored to start with? Do we always need to refactor?
        > > > >
        > > > Refactoring is a big part of Scrum and test driven development in my
        > >
        > > Scrum defines no engineering practices. That is not to say that
        > > refactoring or TDD isn't important, it is just not part of Scrum.
        > >
        > I beg to differ. But I guess that is purely philosohpical. To me it is
        > part of Scrum because scrum does define a methodology that leads to
        > certain processes. Maybe one could argue that it is more part of test
        > driven development than scrum. But then again, who cares :)

        I should clarify my original comment. Fowler's definition of
        refactoring is "the process of changing a software system in such a
        way that it does not alter the external behavior of the code yet
        improves its internal structure."

        My issue was with this statement as a suggested criteria for
        completness: "Code has been refactored". Refactoring describes a
        process, not an end state. I would rather make the criteria something
        like "Code is well factored" and describe a desirable state. To
        suggest that all new code written must be refactored is a bit strong,
        IMHO. Certainly there are cases were the initial implementation of
        software is reasonably well factored.

        --
        Chris Brooks
        http://www.chrisbrooks.org
      • David A Barrett
        ... I think, just like the pigs and chickens thing (which is only about who gets to speak in a daily scrum), people lose track of what the Scrum rule about
        Message 3 of 15 , Mar 4, 2005
          >Sure, the work can be chunked into 30
          >day sprints, and we can build the application with localized testing for
          >the module we just completed, but it can't go to production until
          >everything's done.

          I think, just like the "pigs and chickens" thing (which is only about who
          gets to speak in a daily scrum), people lose track of what the Scrum "rule"
          about "potentially implementable" features is all about.

          There isn't any rule that your entire product has to be deployable at the
          end of every Sprint. IMHO, the rule about making each Sprint Backlog item
          a "potentially implementable" feature has two purposes:

          1. To keep the team focused on "functionality". Creating an artifact, or
          investigating an approach is not a valid SB item. You need something that
          you can demo to the user at the end and show forward movement on
          functionality.

          2. To keep the team focused on finishing. Starting something doesn't
          count. Finishing it does. Size things so that they can be completed, even
          if this means that the incremental gain in functionality is so small as to
          be useless to the end user as a practical matter.


          I don't see any conflict here with scheduling releases to occur some
          quantity of Sprints in the future, nor do I see any conflict with dealing
          with necessary pre-release activities. I don't think you need to be filled
          with angst because some feature that you've developed can't be "released"
          until the whole system has been stress tested for 2 weeks in a lab. The
          rules do make you think about what you are doing, and potentially knock out
          a whole pantload of activities as valid SB items. For instance:

          1. Documentation
          2. UAT
          3. Unit Testing
          4. User Training
          5. Investigation
          6. Bug fixing (as an open-ended, general activity)

          Wouldn't ordinarily qualify. Instead if a feature needs those items
          completed in order to be considered "potentially implementable", then they
          should be included in the SB item for the development of that feature.
          Even here, though, you may need to make exceptions. For instance, you may
          have a separate documentation department, who work on their own schedule
          and need to see a final version of the product before they will update
          documention. The spirit of the thing is the most important: Only take on
          as much stuff as you can finish, and be clear about what "finishing" means.

          Dave Barrett,
          Lawyers' Professional Indemnity Company
        Your message has been successfully submitted and would be delivered to recipients shortly.