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

[XP] Re: Shouldnt done include everything.

Expand Messages
  • JackM
    My point being if you are the developer and you have just finished coding including unit tests and it s the end of the sprint well then there has to be no time
    Message 1 of 49 , Jun 2, 2010
      My point being if you are the developer and you have just finished coding including unit tests and it's the end of the sprint well then there has to be no time for a tester to do the exploratory testing. So you have to be done with coding at least a couple hours/days prior to end of sprint. You have to plan for this. You can't cram everything in at the last minute. All these activities take time. For example in our environment, we have to integrate with SAP. Just to compile the new code and setup the environments with the right config etc is a couple hours of work even though it's mostly automated.

      Agreed you can do shorter sprints for sure and this will help 100% agreed

      Jack
      www.agilebuddy.com
      blog.agilebuddy.com
      twitter.com/agilebuddy

      --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
      >
      > On Wed, Jun 2, 2010 at 2:35 PM, JackM <jack@...> wrote:
      > >
      > >
      > >
      > > While I agree that setting the bar high is good. I don't believe realistically that if you stop coding on the last day that you're Done on the last day.
      > >
      > > Not the Done in my books.
      > >
      > > Until you have integrated all the code on that last day and regression tested all the aspects of the code that was changed I don't believe you're done done.
      > >
      >
      > If it is the last day and you haven't integrated the code and
      > regression tested all of it (including the stuff that presumably
      > didn't change) then you are not doing something that resembles what I
      > understand as Extreme Programming.
      >
      > > So in my opinion you have to plan on being code complete and unit test complete at least a couple days prior to end of sprint. That leaves time for exploratory testing you're talking about and time to resolve any issues prior to end of sprint.
      > >
      >
      > Or you work in smaller increments so that these activities take less
      > time per unit of release.
      >
    • Adam Sroka
      Hi Jeff: Are you responding to what Tim wrote below? Or to one of the earlier messages that I wrote? Anyway, thanks ;-) On Wed, Jun 9, 2010 at 3:52 PM, Jeff
      Message 49 of 49 , Jun 9, 2010
        Hi Jeff:

        Are you responding to what Tim wrote below? Or to one of the earlier
        messages that I wrote?

        Anyway, thanks ;-)

        On Wed, Jun 9, 2010 at 3:52 PM, Jeff Anderson
        <Thomasjeffreyandersontwin@...> wrote:
        >
        >
        >
        > Adam
        >
        > Your description of your coding life cycle was a breath of fresh air,
        > I sometimes get so surrounded by the old schoolers that I forget how
        > profound and powerful the XP approach is.
        >
        > Bravo.
        >
        > On 6/9/10, Tim Ottinger <linux_tim@...> wrote:
        > > FWIW
        > >
        > > My current company (an awesome place) is two years into agile transition.
        > > They are still releasing by content rather than time, mostly because it
        > > hasn't sunk in to upper levels the way it has been embraced in lower levels.
        > >
        > > There is a large legacy code base still, though it is constantly being
        > > whittled down. It has less coverage than the newer code.
        > >
        > > The ideal we strive for is that someday release will be a nonevent. There
        > > are many versions of our software in git that have had a full batch of
        > > unit and automated acceptance tests. Eventually, we will have sufficient
        > > trust in them that we can release any of them at any time. That's when
        > > we have arrived.
        > >
        > > While the code base and product management haven't fully transitioned, we
        > > have a 'code freeze' (really a branchpoint, after which we continue on) and
        > > there is manual testing and exploratory testing before a release. We are
        > > not really blocked by it, and we are programming on the day of release (on
        > > the next release).
        > >
        > > But someday a release will be a total non-event. Someone will pick a release
        > > package from the CI system and run the automated deploy on it in our big
        > > SAAS farm and nobody will stay up late or worry about it. Until then, we
        > > have the ever-thinning vestiges of an earlier circumstance.
        > >
        > > Tim Ottinger
        > > http://agileinaflash.blogspot.com/
        > > http://agileotter.blogspot.com/
        > >
        > >
        > >
        > >
        >
        > --
        > Sent from my mobile device
        >
        > Jeff Anderson
        >
        > http://agileconsulting.blogspot.com/
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.