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

RE: [XP] Get all the requirements early?

Expand Messages
  • Charlie Poole
    Hi Ron, ... Yes, up-front design - like requirements - can have multiple levels of failure and would need similar reassurances. But requirements have a
    Message 1 of 44 , Sep 28, 2007
      Hi Ron,

      > >> Exactly, if we can get all requirements early, may be
      > waterfall work
      > >> better than XP/Agile...
      > > Not quite... there are several prerequisites to not needing
      > to be agile:
      > > 1) You get all the requirements early
      > > 2) All the requirements are right
      > > 3) The requirements cannot change
      > > 4) You know that items 1 to 3 are true in advance and with
      > certainty.
      > > Not using agile means not havig a plan B.
      > What about design?

      Yes, up-front design - like requirements - can have multiple levels
      of failure and would need similar reassurances. But requirements
      have a different feel from design for most developers, because
      they imagine that they pre-exist somewhere and only need to be
      discovered or elicited.

    • Wilson, Michael
      It might mean you ve got to split up your big requirements doc in to a few smaller stories for us to consume more easily ;) ... From:
      Message 44 of 44 , Sep 28, 2007
        It might mean you've got to split up your big requirements doc in to a
        few smaller stories for us to consume more easily ;)

        -----Original Message-----
        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
        Sent: Friday, September 28, 2007 2:50 PM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] Get all the requirements early?

        So, no response. Does that mean we are tired of the discussion?
        Does it mean that no one wants to talk to someone that just don't get
        Does it mean I am right! Woohoo! Or is it what it is and it means no one
        has responded!


        > Here is my take on requirements. Requirements are necessary for
        > planning. Planning and requirements are inseparable.
        > Planning is essential to controlling workload, reducing programmer
        > stress, increasing productivity, and keep projects on track.
        > It is important to estimate the cost and time for each requirement,
        > determining its priority, and planning software releases accordingly.
        > Planning must try to create visibility, so everyone involved in the
        > project can really see how far along a project is. This means you need

        > clear milestones, ones that cannot be fudged, and clearly represent
        > progress. Plans must be honest, including all the information you have

        > to date. Plans should make it difficult for anyone to be fooled by
        > reports of progress unrelated to reality.
        > The customer has the right to an overall plan, to know what can be
        > accomplished when and at what cost.
        > The developer has the right to know what is needed, with clear
        > declarations of priority.
        > Planning is to ensure we always work on the most valuable thing
        > possible at any given time. We have to begin development by taking a
        > quick look at everything that might be valuable.
        > The first plan to be made answers the question "Does this project make

        > any sense at all?". If so then invest enough to prepare a plan you
        > have some confidence in. This is the big plan. As you break out the
        > requirements you estimate them. You can only estimate from experience.
        > If you don't have any experience then write a little prototype or find

        > someone who does have experience. The goal is to quickly capture a
        > picture of the WHOLE system.
        > We break up the whole system into sets of requirements that make
        > releases. Take the requirements and break them into smaller pieces
        > that make up the requirement. Estimate each of these smaller pieces
        > and warn the customer of technical risks. Of course we feedback into
        > the system information as it comes available. During development when
        > we learn something new about the speed of doing things this changes
        > the plan.
        > The further ahead we plan the less accurate it will be, so there's
        > little point going into great detail for years into the future.
        > Planning releases for four to six months is reasonable. This is based
        > on a release being a few months, so a couple of releases could be four

        > to six months. Release planning is a business task. Iteration planning

        > is a technical task and programmers need one or two iterations worth
        > of requirements which is around 2 weeks to a month. (Often the
        > argument of requirements is confused by the fact some are talking
        > about the business requirements and some are talking about the
        > technical requirements. I am usually speaking about the business
        > requirements). For the situation you plan as far in advance as
        > possible while watching the cost of keeping the plan up-to-date versus

        > the benefit you get when you know that plans are inherently unstable.
        > (As the requirements are gathered they should not include
        > implementation details)
        > Each requirement captured in the plan represents a concept and not a
        > detailed specification. (However, each requirement is captured.) These

        > requirements are defined by something that provides value to the
        > customer. Developers do not write the requirements, thus it is not a
        > technical task. Estimates for the "size" of the requirement starts as
        > soon as you start gathering the requirements. Remember, estimates are
        > not commitments.
        > The first plan has two main areas of uncertainty: the speed at which
        > the team can deliver completed requirements and the size of the
        > requirements. (But you start with all of the requirements that could
        > be discovered that would make up a release which is four to six months

        > worth of requirements. The uncertainty is based on speed of delivery
        > and size and is not initially based on the idea that the requirements
        > are mostly incorrect or will change for a release).
        > These requirements are divided up into releases and prioritized by the

        > business/customer, not by the developer. The developer points out
        > technical risks and dependencies but does not set the priority. After
        > the one or two releases are planned then the developers step up and
        > plan the iterations. The programmers put estimates on each task of the

        > iteration. Inside the iteration the technical issues are in control
        > and the developers make the decisions. The customer has their input.
        > While planning the iteration the requirement is read and conversations

        > take place as needed.
        > Sincerely,
        > Geoff
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > > These ideas come from Beck and Fowler. See Planning Extreme
        > > Programming.
        > > I have taken the word user story and changed it to requirement.
        > > I am curious if people feel it is wrong once they realize that this
        > > comes from others. No plagiarism intended.

        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:

        ad-free courtesy of objectmentor.com
        Yahoo! Groups Links

        This message is for the named person's use only. This communication is for
        informational purposes only and has been obtained from sources believed to
        be reliable, but it is not necessarily complete and its accuracy cannot be
        guaranteed. It is not intended as an offer or solicitation for the purchase
        or sale of any financial instrument or as an official confirmation of any
        transaction. Moreover, this material should not be construed to contain any
        recommendation regarding, or opinion concerning, any security. It may
        contain confidential, proprietary or legally privileged information. No
        confidentiality or privilege is waived or lost by any mistransmission. If
        you receive this message in error, please immediately delete it and all
        copies of it from your system, destroy any hard copies of it and notify the
        sender. You must not, directly or indirectly, use, disclose, distribute,
        print, or copy any part of this message if you are not the intended
        recipient. Any views expressed in this message are those of the individual
        sender, except where the message states otherwise and the sender is
        authorized to state them to be the views of any such entity.

        Securities products and services provided to Canadian investors are offered
        by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
        Technology Group, Inc.

        ITG Inc. and/or its affiliates reserves the right to monitor and archive
        all electronic communications through its network.

        ITG Inc. Member NASD, SIPC
      Your message has been successfully submitted and would be delivered to recipients shortly.