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

Re: [XP] I m Working in a Parallel Program

Expand Messages
  • Steven Gordon
    What goals are you trying to accomplish? Documentation for the sake of documentation or modeling for the sake of modeling will not elicit much empathy on the
    Message 1 of 21 , Feb 1 12:05 PM
    • 0 Attachment
      What goals are you trying to accomplish?

      Documentation for the sake of documentation or modeling for the sake of
      modeling will not elicit much empathy on the XP mailing list.


      On 2/1/06, yperez_riverol <yperez_riverol@...> wrote:
      >
      > What documentation I can Use for modeling my program. - It's Rational
      > Rose a good tool for this type of application. What a documentation or
      > publications exist about UML and Parallel Applications. Please I need
      > Help about this quetions...
      >
      > Thakns yperez_riverol....
      >


      [Non-text portions of this message have been removed]
    • Ricardo Mayerhofer
      At my company we estimate stories and plan the releases and the iterations. After the iteration planning we break the stories into tasks and estimate them. But
      Message 2 of 21 , Feb 9 8:04 AM
      • 0 Attachment
        At my company we estimate stories and plan the releases and the
        iterations. After the iteration planning we break the stories into tasks
        and estimate them. But sometimes tasks estimation are higher than story
        estimation. In this case, what should we do? Update the story estimation
        and replan the iteration? Use a slack or buffer and try to prevent this?
        What do you suggest?

        Thanks in advance.

        Regards,
        Ricardo
      • Steven Gordon
        I would suggest not worrying about these deviations. Here are two rationales for not worrying: - Do the task estimations sometimes add up to be less than the
        Message 3 of 21 , Feb 9 10:01 AM
        • 0 Attachment
          I would suggest not worrying about these deviations. Here are two
          rationales for not worrying:


          - Do the task estimations sometimes add up to be less than the story
          estimation? Are there sometimes tasks that get reused by other stories in
          the same iteration? If so, then the deviations between story and task
          estimations would tend to even out.



          - Alternatively, if these issues come up in most iterations, then it
          will tend to affect velocity the same way every iteration, so "yesterday's
          whether" should have already taken this issue into account.

          Steven Gordon
          On 2/9/06, Ricardo Mayerhofer <ricardo@...> wrote:

          > At my company we estimate stories and plan the releases and the
          > iterations. After the iteration planning we break the stories into tasks
          > and estimate them. But sometimes tasks estimation are higher than story
          > estimation. In this case, what should we do? Update the story estimation
          > and replan the iteration? Use a slack or buffer and try to prevent this?
          > What do you suggest?
          >
          > Thanks in advance.
          >
          > Regards,
          > Ricardo
          >


          [Non-text portions of this message have been removed]
        • Rob Park
          Why do you feel compelled to break a story into tasks? And then estimate them? Once a story is selected for an iteration, isn t it the chosen pair s job to
          Message 4 of 21 , Feb 9 10:31 AM
          • 0 Attachment
            Why do you feel compelled to break a story into tasks? And then estimate
            them?

            Once a story is selected for an iteration, isn't it the chosen pair's job to
            just git'r'done?

            .rob.


            >From: Ricardo Mayerhofer <ricardo@...>
            >Reply-To: extremeprogramming@yahoogroups.com
            >To: extremeprogramming@yahoogroups.com
            >Subject: [XP] Task Estimation
            >Date: Thu, 09 Feb 2006 14:04:26 -0200
            >
            >At my company we estimate stories and plan the releases and the
            >iterations. After the iteration planning we break the stories into tasks
            >and estimate them. But sometimes tasks estimation are higher than story
            >estimation. In this case, what should we do? Update the story estimation
            >and replan the iteration? Use a slack or buffer and try to prevent this?
            >What do you suggest?
            >
            >Thanks in advance.
            >
            >Regards,
            > Ricardo
            >
            >
            >
            >
            >
            >To Post a message, send it to: extremeprogramming@...
            >
            >To Unsubscribe, send a blank message to:
            >extremeprogramming-unsubscribe@...
            >
            >ad-free courtesy of objectmentor.com
            >Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
          • Dave Rooney
            You can stick to just the story, but the brainstorming aspect of creating the tasks both spreads the knowledge about the story around the team, and allows
            Message 5 of 21 , Feb 9 10:38 AM
            • 0 Attachment
              You can stick to just the story, but the brainstorming aspect of
              creating the tasks both spreads the knowledge about the story around the
              team, and allows other team members to contribute ideas that the pair
              who picked the story may not have come up with.

              I've been in a situation where a team focused too much on the tasks.
              What happened was that there wasn't enough focus on delivering the
              stories as a whole. We did do one release where we didn't specify the
              tasks, and it went very well. In the retrospective, though, some team
              members expressed discomfort with the lack of tasks. So, tasks were
              reintroduced, although the team focused better on the stories.

              Dave Rooney
              Mayford Technologies
              http://www.mayford.ca


              Rob Park wrote:
              > Why do you feel compelled to break a story into tasks? And then estimate
              > them?
              >
              > Once a story is selected for an iteration, isn't it the chosen pair's job to
              > just git'r'done?
              >
              > .rob.
              >
              >
              >
              >> From: Ricardo Mayerhofer <ricardo@...>
              >> Reply-To: extremeprogramming@yahoogroups.com
              >> To: extremeprogramming@yahoogroups.com
              >> Subject: [XP] Task Estimation
              >> Date: Thu, 09 Feb 2006 14:04:26 -0200
              >>
              >> At my company we estimate stories and plan the releases and the
              >> iterations. After the iteration planning we break the stories into tasks
              >> and estimate them. But sometimes tasks estimation are higher than story
              >> estimation. In this case, what should we do? Update the story estimation
              >> and replan the iteration? Use a slack or buffer and try to prevent this?
              >> What do you suggest?
              >>
              >> Thanks in advance.
              >>
              >> Regards,
              >> Ricardo
              >>
            • Ron Jeffries
              ... It might be desirable to know whether all the stories selected can actually be gotten done. One way is to look at the tasks, though I generally don t favor
              Message 6 of 21 , Feb 9 10:49 AM
              • 0 Attachment
                On Thursday, February 9, 2006, at 1:31:29 PM, Rob Park wrote:

                > Why do you feel compelled to break a story into tasks? And then estimate
                > them?

                > Once a story is selected for an iteration, isn't it the chosen pair's job to
                > just git'r'done?

                It might be desirable to know whether all the stories selected can
                actually be gotten done. One way is to look at the tasks, though I
                generally don't favor signing up for them. It can be of value to
                discuss what they are.

                Ron Jeffries
                www.XProgramming.com
                If you want to garden, you have to bend down and touch the soil.
                Gardening is a practice, not an idea.
                -- Thich Nhat Hanh
              • Charlie Poole
                Hi Ron, ... This came up on one of my recent jobs. We sat down and listed what we might do with tasks: 1. Not use them at all. 2. Talk about them in order to
                Message 7 of 21 , Feb 9 11:15 AM
                • 0 Attachment
                  Hi Ron,

                  > > Why do you feel compelled to break a story into tasks? And then
                  > > estimate them?
                  >
                  > > Once a story is selected for an iteration, isn't it the
                  > chosen pair's
                  > > job to just git'r'done?
                  >
                  > It might be desirable to know whether all the stories
                  > selected can actually be gotten done. One way is to look at
                  > the tasks, though I generally don't favor signing up for
                  > them. It can be of value to discuss what they are.

                  This came up on one of my recent jobs. We sat down and listed what we might
                  do with tasks:

                  1. Not use them at all.
                  2. Talk about them in order to refine the estimate, but not track them.
                  3. Estimate them and track them on the story card.
                  4. Estimate them and sign up for them separately.

                  In our case, the team decided that they needed to think about tasks in order
                  to do estimates but that they wouldn't sign up for them separately. We
                  decided to track actual time on tasks for a short while - in order to
                  understand how we were doing in our estimating - and then fall back to not
                  tracking them at all.

                  In the end, "tasks" only existed for the duration of the planning meeting.

                  Charlie
                • Manfred Lange
                  Ricardo, here is a brief description of two different approaches currently being used by teams I m coaching: 1) In the first case, at the beginning of each
                  Message 8 of 21 , Feb 9 1:03 PM
                  • 0 Attachment
                    Ricardo,

                    here is a brief description of two different approaches currently being
                    used by teams I'm coaching:

                    1)
                    In the first case, at the beginning of each iteration the team has an
                    iteration kick-off. Sounds big, but is little effort. The team sits in a
                    circle around a table on which we have the story cards which are planned
                    for the new iteration. Now, starting with one team member each engineer
                    is reading out one story and the team discusses very briefly which tasks
                    are required for completing the story and what the estimated duration
                    for each of the tasks is. The tasks are also added to the iteration
                    backlog at that time. Then the duration for all tasks for each story are
                    totaled. At the end of the session the team typically finds that some
                    stories are now bigger, some are smaller than originally estimated.
                    Therefore, in some iterations it turns out that there are one or two
                    stories which do not fit into the iteration anymore. In some other
                    iterations, however, it turns out that one or two additional stories can
                    be put into the iteration.

                    In this particular case the iteration planning includes breaking down
                    the stories into tasks, and it worked for this team.

                    2)
                    In a different team, people tried a different approach. They simply
                    assume that once a story is similar to some previous story there is no
                    sense in figuring out what the particular tasks for the new story would
                    be. For these stories the assumption was made that the new, similar
                    story will take approximately as long as the previous one. Ultimately
                    this resulted in the team telling the customer that they could do x
                    stories per iteration. All stories eventually were more or less the same
                    size.

                    Although this was a different solution it worked for this team as well.
                    This approach takes time and is probably less suited for a team new to
                    XP, and an approach leaning more towards the solution described above
                    might be a better choice.


                    I don't believe that there is a "one-size-fits-all-solution". A
                    technique will not be used if the team does not feel comfortable with
                    it. The two cases might give you some additional ideas on what you want
                    to try with your team. It depends on the team's preferences. Also, you
                    might want to experiment for a while or even regularly.

                    Kind regards,
                    Manfred.
                    ---
                    Manfred Lange
                    www.manfred-lange.com


                    Ricardo Mayerhofer wrote:

                    >At my company we estimate stories and plan the releases and the
                    >iterations. After the iteration planning we break the stories into tasks
                    >and estimate them. But sometimes tasks estimation are higher than story
                    >estimation. In this case, what should we do? Update the story estimation
                    >and replan the iteration? Use a slack or buffer and try to prevent this?
                    >What do you suggest?
                    >
                    >Thanks in advance.
                    >
                    >Regards,
                    > Ricardo
                    >
                    >


                    [Non-text portions of this message have been removed]
                  • Steve Bate
                    ... Hi Rob, I d say it s the team s responsibility to complete the stories for an iteration. Some teams switch pairs more often than at story completion so
                    Message 9 of 21 , Feb 9 11:07 PM
                    • 0 Attachment
                      > Rob Park wrote:
                      >
                      > Why do you feel compelled to break a story into tasks? And
                      > then estimate
                      > them?
                      >
                      > Once a story is selected for an iteration, isn't it the
                      > chosen pair's job to just git'r'done?

                      Hi Rob,

                      I'd say it's the team's responsibility to complete the stories
                      for an iteration. Some teams switch pairs more often than at
                      story completion so it's possible that several pairs could be
                      involved with completing a story.

                      I don't feel compelled to break stories into tasks but I have
                      experienced benefits from doing it. These benefits are similar to
                      what other people here report from breaking customer stories into
                      increasingly smaller stories so they can be estimated more
                      accurately. The concern I have with tiny story technique is that the
                      business value of the small stories becomes less clear. With a
                      task breakdown, a developer can decompose the story based on
                      technical considerations within the business content of the
                      story. In my experience, the potential benefits of this are
                      increased estimation accurate (smaller units of work) and early
                      identification of technical risks compared to maintaining a pure
                      business focus. I also like the stories to have clear business
                      value (closer to a Minimally Marketable Feature). If the MMF is
                      split among many tiny stories across several small iterations
                      without any explicit dependency information, there's more risk
                      that useful business functionality will not be delivered as
                      effectively as it could be.

                      Although I haven't personally seen this, I can imagine the
                      risk with task breakdowns is that that some teams may focus
                      too much on technical details during the planning activities and
                      have difficulty making progress. Still, if I had a task-based
                      estimate that differed from a story estimate I'd pay attention to
                      that difference and would tend to believe the task-based estimate.

                      Steve
                    • Ricardo Mayerhofer
                      ... Thank you for the answers. Manfred, I liked your first suggestion. I m gonna try to use this one here. Regards, Ricardo
                      Message 10 of 21 , Feb 10 2:52 AM
                      • 0 Attachment
                        Manfred Lange escreveu:

                        >1)
                        >In the first case, at the beginning of each iteration the team has an
                        >iteration kick-off. Sounds big, but is little effort. The team sits in a
                        >circle around a table on which we have the story cards which are planned
                        >for the new iteration. Now, starting with one team member each engineer
                        >is reading out one story and the team discusses very briefly which tasks
                        >are required for completing the story and what the estimated duration
                        >for each of the tasks is. The tasks are also added to the iteration
                        >backlog at that time. Then the duration for all tasks for each story are
                        >totaled. At the end of the session the team typically finds that some
                        >stories are now bigger, some are smaller than originally estimated.
                        >Therefore, in some iterations it turns out that there are one or two
                        >stories which do not fit into the iteration anymore. In some other
                        >iterations, however, it turns out that one or two additional stories can
                        >be put into the iteration.
                        >
                        >In this particular case the iteration planning includes breaking down
                        >the stories into tasks, and it worked for this team.
                        >
                        >
                        Thank you for the answers. Manfred, I liked your first suggestion. I'm
                        gonna try to use this one here.

                        Regards,
                        Ricardo
                      • Rob Park
                        Ah true. I d agree that looking at tasks could help in that respect. And I wouldn t want anyone to sign up for the tasks. I d also want the tasks being
                        Message 11 of 21 , Feb 10 7:10 AM
                        • 0 Attachment
                          Ah true. I'd agree that looking at tasks could help in that respect. And I
                          wouldn't want anyone to sign up for the tasks. I'd also want the tasks
                          being estimated/counted to be on the same scale as the story itself. (E.g.
                          So don't say task 1 is 3 hours and task 2 is 2 hours so it's a story of 2
                          points.) ... but I guess that's just my opinion that you should always keep
                          hours out of it. Just talk in terms of points per story and per iteration.

                          .rob.

                          >From: Ron Jeffries <ronjeffries@...>
                          >Reply-To: extremeprogramming@yahoogroups.com
                          >To: extremeprogramming@yahoogroups.com
                          >Subject: Re: [XP] Task Estimation
                          >Date: Thu, 9 Feb 2006 13:49:31 -0500
                          >
                          >On Thursday, February 9, 2006, at 1:31:29 PM, Rob Park wrote:
                          >
                          > > Why do you feel compelled to break a story into tasks? And then
                          >estimate
                          > > them?
                          >
                          > > Once a story is selected for an iteration, isn't it the chosen pair's
                          >job to
                          > > just git'r'done?
                          >
                          >It might be desirable to know whether all the stories selected can
                          >actually be gotten done. One way is to look at the tasks, though I
                          >generally don't favor signing up for them. It can be of value to
                          >discuss what they are.
                          >
                          >Ron Jeffries
                          >www.XProgramming.com
                          >If you want to garden, you have to bend down and touch the soil.
                          >Gardening is a practice, not an idea.
                          > -- Thich Nhat Hanh
                          >
                          >
                          >To Post a message, send it to: extremeprogramming@...
                          >
                          >To Unsubscribe, send a blank message to:
                          >extremeprogramming-unsubscribe@...
                          >
                          >ad-free courtesy of objectmentor.com
                          >Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                        • Rob Park
                          excellent...
                          Message 12 of 21 , Feb 10 7:12 AM
                          • 0 Attachment
                            excellent...

                            >
                            >In the end, "tasks" only existed for the duration of the planning meeting.
                            >
                            >Charlie
                            >
                          • Rob Park
                            Agreed. Good clarifications. .rob.
                            Message 13 of 21 , Feb 10 7:15 AM
                            • 0 Attachment
                              Agreed.
                              Good clarifications.

                              .rob.


                              >From: "Steve Bate" <steve@...>
                              >Reply-To: extremeprogramming@yahoogroups.com
                              >To: <extremeprogramming@yahoogroups.com>
                              >Subject: RE: [XP] Task Estimation
                              >Date: Fri, 10 Feb 2006 08:07:21 +0100
                              >
                              > > Rob Park wrote:
                              > >
                              > > Why do you feel compelled to break a story into tasks? And
                              > > then estimate
                              > > them?
                              > >
                              > > Once a story is selected for an iteration, isn't it the
                              > > chosen pair's job to just git'r'done?
                              >
                              >Hi Rob,
                              >
                              >I'd say it's the team's responsibility to complete the stories
                              >for an iteration. Some teams switch pairs more often than at
                              >story completion so it's possible that several pairs could be
                              >involved with completing a story.
                              >
                              >I don't feel compelled to break stories into tasks but I have
                              >experienced benefits from doing it. These benefits are similar to
                              >what other people here report from breaking customer stories into
                              >increasingly smaller stories so they can be estimated more
                              >accurately. The concern I have with tiny story technique is that the
                              >business value of the small stories becomes less clear. With a
                              >task breakdown, a developer can decompose the story based on
                              >technical considerations within the business content of the
                              >story. In my experience, the potential benefits of this are
                              >increased estimation accurate (smaller units of work) and early
                              >identification of technical risks compared to maintaining a pure
                              >business focus. I also like the stories to have clear business
                              >value (closer to a Minimally Marketable Feature). If the MMF is
                              >split among many tiny stories across several small iterations
                              >without any explicit dependency information, there's more risk
                              >that useful business functionality will not be delivered as
                              >effectively as it could be.
                              >
                              >Although I haven't personally seen this, I can imagine the
                              >risk with task breakdowns is that that some teams may focus
                              >too much on technical details during the planning activities and
                              >have difficulty making progress. Still, if I had a task-based
                              >estimate that differed from a story estimate I'd pay attention to
                              >that difference and would tend to believe the task-based estimate.
                              >
                              >Steve
                              >
                              >
                              >
                              >
                              >To Post a message, send it to: extremeprogramming@...
                              >
                              >To Unsubscribe, send a blank message to:
                              >extremeprogramming-unsubscribe@...
                              >
                              >ad-free courtesy of objectmentor.com
                              >Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >
                            • Charlie Poole
                              Message 14 of 21 , Feb 10 9:48 AM
                              • 0 Attachment
                                > -----Original Message-----
                                > From: extremeprogramming@yahoogroups.com
                                > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Rob Park
                                > Sent: Friday, February 10, 2006 7:11 AM
                                > To: extremeprogramming@yahoogroups.com
                                > Subject: Re: [XP] Task Estimation
                                >
                                > Ah true. I'd agree that looking at tasks could help in that
                                > respect. And I wouldn't want anyone to sign up for the
                                > tasks. I'd also want the tasks being estimated/counted to be
                                > on the same scale as the story itself. (E.g.
                                > So don't say task 1 is 3 hours and task 2 is 2 hours so it's
                                > a story of 2
                                > points.) ... but I guess that's just my opinion that you
                                > should always keep hours out of it. Just talk in terms of
                                > points per story and per iteration.
                                >
                                > .rob.
                                >
                                > >From: Ron Jeffries <ronjeffries@...>
                                > >Reply-To: extremeprogramming@yahoogroups.com
                                > >To: extremeprogramming@yahoogroups.com
                                > >Subject: Re: [XP] Task Estimation
                                > >Date: Thu, 9 Feb 2006 13:49:31 -0500
                                > >
                                > >On Thursday, February 9, 2006, at 1:31:29 PM, Rob Park wrote:
                                > >
                                > > > Why do you feel compelled to break a story into tasks? And then
                                > >estimate
                                > > > them?
                                > >
                                > > > Once a story is selected for an iteration, isn't it the chosen
                                > > > pair's
                                > >job to
                                > > > just git'r'done?
                                > >
                                > >It might be desirable to know whether all the stories selected can
                                > >actually be gotten done. One way is to look at the tasks, though I
                                > >generally don't favor signing up for them. It can be of value to
                                > >discuss what they are.
                                > >
                                > >Ron Jeffries
                                > >www.XProgramming.com
                                > >If you want to garden, you have to bend down and touch the soil.
                                > >Gardening is a practice, not an idea.
                                > > -- Thich Nhat Hanh
                                > >
                                > >
                                > >To Post a message, send it to: extremeprogramming@...
                                > >
                                > >To Unsubscribe, send a blank message to:
                                > >extremeprogramming-unsubscribe@...
                                > >
                                > >ad-free courtesy of objectmentor.com
                                > >Yahoo! Groups Links
                                > >
                                > >
                                > >
                                > >
                                > >
                                > >
                                >
                                >
                                >
                                >
                                > To Post a message, send it to: extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to:
                                > extremeprogramming-unsubscribe@...
                                >
                                > ad-free courtesy of objectmentor.com
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                              • Charlie Poole
                                Hi Rob, Here s a trick we used on one project... To deal with the issue of larger stories having lower estimate accuracy, the stories were constrained to be
                                Message 15 of 21 , Feb 10 9:56 AM
                                • 0 Attachment
                                  Hi Rob,

                                  Here's a trick we used on one project...

                                  To deal with the issue of larger stories having lower estimate accuracy, the
                                  stories were constrained to be 1/2, 1, 2 or 4 points. This is, of course, a
                                  pretty standard trick.

                                  Of course, some folks would be convinced that a story would take 2.5 days
                                  and didn't like choosing between 2 and 4. So we allowed them to list tasks
                                  and use the same estimate levels for the tasks. If they could reasonably
                                  argue that the story consisted of three tasks of 1, 1 and 1/2 point, then
                                  they got their 2.5 estimate.

                                  This made people happier, but I'm not entirely convinced it improved our
                                  overall estimate performance. Being forced to choose between discrete point
                                  values has always seemed to have a positive effect on the team velocity
                                  whenever I've introduced it. Doing the breakdown as an option seems to make
                                  some individual estimates better, but I think it may have introduced a bias,
                                  because people only tended to use it when it would reduce the estimate.

                                  Charlie

                                  > -----Original Message-----
                                  > From: extremeprogramming@yahoogroups.com
                                  > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Rob Park
                                  > Sent: Friday, February 10, 2006 7:11 AM
                                  > To: extremeprogramming@yahoogroups.com
                                  > Subject: Re: [XP] Task Estimation
                                  >
                                  > Ah true. I'd agree that looking at tasks could help in that
                                  > respect. And I wouldn't want anyone to sign up for the
                                  > tasks. I'd also want the tasks being estimated/counted to be
                                  > on the same scale as the story itself. (E.g.
                                  > So don't say task 1 is 3 hours and task 2 is 2 hours so it's
                                  > a story of 2
                                  > points.) ... but I guess that's just my opinion that you
                                  > should always keep hours out of it. Just talk in terms of
                                  > points per story and per iteration.
                                  >
                                  > .rob.
                                  >
                                  > >From: Ron Jeffries <ronjeffries@...>
                                  > >Reply-To: extremeprogramming@yahoogroups.com
                                  > >To: extremeprogramming@yahoogroups.com
                                  > >Subject: Re: [XP] Task Estimation
                                  > >Date: Thu, 9 Feb 2006 13:49:31 -0500
                                  > >
                                  > >On Thursday, February 9, 2006, at 1:31:29 PM, Rob Park wrote:
                                  > >
                                  > > > Why do you feel compelled to break a story into tasks? And then
                                  > >estimate
                                  > > > them?
                                  > >
                                  > > > Once a story is selected for an iteration, isn't it the chosen
                                  > > > pair's
                                  > >job to
                                  > > > just git'r'done?
                                  > >
                                  > >It might be desirable to know whether all the stories selected can
                                  > >actually be gotten done. One way is to look at the tasks, though I
                                  > >generally don't favor signing up for them. It can be of value to
                                  > >discuss what they are.
                                  > >
                                  > >Ron Jeffries
                                  > >www.XProgramming.com
                                  > >If you want to garden, you have to bend down and touch the soil.
                                  > >Gardening is a practice, not an idea.
                                  > > -- Thich Nhat Hanh
                                  > >
                                  > >
                                  > >To Post a message, send it to: extremeprogramming@...
                                  > >
                                  > >To Unsubscribe, send a blank message to:
                                  > >extremeprogramming-unsubscribe@...
                                  > >
                                  > >ad-free courtesy of objectmentor.com
                                  > >Yahoo! Groups Links
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  >
                                  >
                                  >
                                  >
                                  > To Post a message, send it to: extremeprogramming@...
                                  >
                                  > To Unsubscribe, send a blank message to:
                                  > extremeprogramming-unsubscribe@...
                                  >
                                  > ad-free courtesy of objectmentor.com
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Kent Beck
                                  Ricardo, One of my goals in planning is to commit to as much work as I am confident I can complete. I wouldn t lightly ignore the feedback from the task
                                  Message 16 of 21 , Feb 13 11:47 AM
                                  • 0 Attachment
                                    Ricardo,

                                    One of my goals in planning is to commit to as much work as I am confident I
                                    can complete. I wouldn't lightly ignore the feedback from the task
                                    estimates. If necessary, I would discuss with the whole team which stories
                                    to drop from this week's promised delivery. Separately, I would also try to
                                    understand why the story and task estimates didn't match so I could improve
                                    future story estimation.

                                    Sincerely yours,

                                    Kent Beck
                                    Three Rivers Institute

                                    > -----Original Message-----
                                    > From: extremeprogramming@yahoogroups.com
                                    > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
                                    > Ricardo Mayerhofer
                                    > Sent: Thursday, February 09, 2006 8:04 AM
                                    > To: extremeprogramming@yahoogroups.com
                                    > Subject: [XP] Task Estimation
                                    >
                                    > At my company we estimate stories and plan the releases and the
                                    > iterations. After the iteration planning we break the stories
                                    > into tasks
                                    > and estimate them. But sometimes tasks estimation are higher
                                    > than story
                                    > estimation. In this case, what should we do? Update the story
                                    > estimation
                                    > and replan the iteration? Use a slack or buffer and try to
                                    > prevent this?
                                    > What do you suggest?
                                    >
                                    > Thanks in advance.
                                    >
                                    > Regards,
                                    > Ricardo
                                  • yperez_riverol
                                    ... I have not a particulary goal with this quetion, I need a methodoly as RUP or other for documentation a modelation of my software, and RUP dont have more
                                    Message 17 of 21 , Apr 11, 2006
                                    • 0 Attachment
                                      --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                      <sgordonphd@...> wrote:
                                      >
                                      > What goals are you trying to accomplish?
                                      >
                                      > Documentation for the sake of documentation or modeling for the sake of
                                      > modeling will not elicit much empathy on the XP mailing list.
                                      >
                                      >
                                      > On 2/1/06, yperez_riverol <yperez_riverol@...> wrote:
                                      > >
                                      > > What documentation I can Use for modeling my program. - It's Rational
                                      > > Rose a good tool for this type of application. What a documentation or
                                      > > publications exist about UML and Parallel Applications. Please I need
                                      > > Help about this quetions...
                                      > >
                                      > > Thakns yperez_riverol....
                                      > >
                                      >
                                      >
                                      > [Non-text portions of this message have been removed]
                                      >

                                      I have not a particulary goal with this quetion, I need a methodoly as
                                      RUP or other for documentation a modelation of my software, and RUP
                                      dont have more documentation in the case of parallel programming.
                                    • Keith Ray
                                      I suggest using UML sequence diagrams and lots of unit tests http://www.smartdraw.com/tutorials/software-uml/uml4.htm#whatseq ... -- C. Keith Ray
                                      Message 18 of 21 , Apr 11, 2006
                                      • 0 Attachment
                                        I suggest using UML sequence diagrams and lots of unit tests

                                        http://www.smartdraw.com/tutorials/software-uml/uml4.htm#whatseq

                                        On 4/11/06, yperez_riverol <yperez_riverol@...> wrote:
                                        > --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                        > <sgordonphd@...> wrote:
                                        > >
                                        > > What goals are you trying to accomplish?
                                        > >
                                        > > Documentation for the sake of documentation or modeling for the sake of
                                        > > modeling will not elicit much empathy on the XP mailing list.
                                        > >
                                        > >
                                        > > On 2/1/06, yperez_riverol <yperez_riverol@...> wrote:
                                        > > >
                                        > > > What documentation I can Use for modeling my program. - It's Rational
                                        > > > Rose a good tool for this type of application. What a documentation or
                                        > > > publications exist about UML and Parallel Applications. Please I need
                                        > > > Help about this quetions...
                                        > > >
                                        > > > Thakns yperez_riverol....
                                        > > >
                                        > >
                                        > >
                                        > > [Non-text portions of this message have been removed]
                                        > >
                                        >
                                        > I have not a particulary goal with this quetion, I need a methodoly as
                                        > RUP or other for documentation a modelation of my software, and RUP
                                        > dont have more documentation in the case of parallel programming.
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > To Post a message, send it to: extremeprogramming@...
                                        >
                                        > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                        >
                                        > ad-free courtesy of objectmentor.com
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >


                                        --

                                        C. Keith Ray
                                        <http://homepage.mac.com/keithray/blog/index.html>
                                        <http://homepage.mac.com/keithray/xpminifaq.html>
                                        <http://homepage.mac.com/keithray/resume2.html>
                                      • Kent Beck
                                        Keith, I think all the information in the sequence diagram is also contained in the tests. If so, it becomes a matter of how to present the information gleaned
                                        Message 19 of 21 , Apr 15, 2006
                                        • 0 Attachment
                                          Keith,

                                          I think all the information in the sequence diagram is also contained in the
                                          tests. If so, it becomes a matter of how to present the information gleaned
                                          from the tests.

                                          Cheers,

                                          Kent Beck
                                          Three Rivers Institute

                                          > -----Original Message-----
                                          > From: extremeprogramming@yahoogroups.com
                                          > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                                          > Sent: Tuesday, April 11, 2006 5:25 PM
                                          > To: extremeprogramming@yahoogroups.com
                                          > Subject: Re: [XP] I m Working in a Parallel Program
                                          >
                                          > I suggest using UML sequence diagrams and lots of unit tests
                                          >
                                          > http://www.smartdraw.com/tutorials/software-uml/uml4.htm#whatseq
                                          >
                                          > On 4/11/06, yperez_riverol <yperez_riverol@...> wrote:
                                          > > --- In extremeprogramming@yahoogroups.com, Steven Gordon
                                          > > <sgordonphd@...> wrote:
                                          > > >
                                          > > > What goals are you trying to accomplish?
                                          > > >
                                          > > > Documentation for the sake of documentation or modeling
                                          > for the sake of
                                          > > > modeling will not elicit much empathy on the XP mailing list.
                                          > > >
                                          > > >
                                          > > > On 2/1/06, yperez_riverol <yperez_riverol@...> wrote:
                                          > > > >
                                          > > > > What documentation I can Use for modeling my program. -
                                          > It's Rational
                                          > > > > Rose a good tool for this type of application. What a
                                          > documentation or
                                          > > > > publications exist about UML and Parallel Applications.
                                          > Please I need
                                          > > > > Help about this quetions...
                                          > > > >
                                          > > > > Thakns yperez_riverol....
                                          > > > >
                                          > > >
                                          > > >
                                          > > > [Non-text portions of this message have been removed]
                                          > > >
                                          > >
                                          > > I have not a particulary goal with this quetion, I need a
                                          > methodoly as
                                          > > RUP or other for documentation a modelation of my software, and RUP
                                          > > dont have more documentation in the case of parallel programming.
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > > To Post a message, send it to: extremeprogramming@...
                                          > >
                                          > > To Unsubscribe, send a blank message to:
                                          > extremeprogramming-unsubscribe@...
                                          > >
                                          > > ad-free courtesy of objectmentor.com
                                          > > Yahoo! Groups Links
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          > >
                                          >
                                          >
                                          > --
                                          >
                                          > C. Keith Ray
                                          > <http://homepage.mac.com/keithray/blog/index.html>
                                          > <http://homepage.mac.com/keithray/xpminifaq.html>
                                          > <http://homepage.mac.com/keithray/resume2.html>
                                          >
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to:
                                          > extremeprogramming-unsubscribe@...
                                          >
                                          > ad-free courtesy of objectmentor.com
                                          > Yahoo! Groups Links
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                        Your message has been successfully submitted and would be delivered to recipients shortly.