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

RE: [XP] Function points and XP

Expand Messages
  • Fuqua, Andrew (ISSAtlanta)
    Yes, here is my experience with it: http://groups.yahoo.com/group/extremeprogramming/files/XP%20and%20FPA.pdf Enjoy. ... From: Alan Gladman
    Message 1 of 10 , Jan 30, 2003
    • 0 Attachment
      Yes, here is my experience with it: http://groups.yahoo.com/group/extremeprogramming/files/XP%20and%20FPA.pdf

      Enjoy.

      -----Original Message-----
      From: Alan Gladman <alan.gladman@...>
      [mailto:alan.gladman@...]
      Sent: Thursday, January 30, 2003 10:48 AM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Function points and XP


      Anyone used function points when trying to measure XP deliverables?


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

      To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Fuqua, Andrew (ISSAtlanta)
      ... I d really like to hear more about this Jessica. Can you give some detail? THANKS ... From: Jessica Luchesi [mailto:jessica@apaixonadas.net] Sent: Friday,
      Message 2 of 10 , Jan 31, 2003
      • 0 Attachment
        Jessica wrote:
        > and is also
        > forced by contract to adhere to the number of hours obtained through our
        > measured productivity by function point to estimate the schedule )

        I'd really like to hear more about this Jessica. Can you give some detail?

        THANKS

        -----Original Message-----
        From: Jessica Luchesi [mailto:jessica@...]
        Sent: Friday, January 31, 2003 5:13 AM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] Function points and XP


        Alan,

        I didn't have the opportunity to read to Andrew Fuqua's article yet,
        but in case you have further doubts, the company I work with charges our
        major client ( government agency ) by function points ( and is also
        forced by contract to adhere to the number of hours obtained through our
        measured productivity by function point to estimate the schedule )...
        so, you could contact me also.

        []s

        Jessica Luchesi

        Alan Gladman wrote:

        >Anyone used function points when trying to measure XP deliverables?
        >
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        >ad-free courtesy of objectmentor.com
        >
        >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
        >
        >



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

        To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

        ad-free courtesy of objectmentor.com

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Jessica Luchesi
        Andrew, I am reading your article as I write this reply... hope to be able to send if as soon as I get home ( am at work now, on my notebook, but I am not
        Message 3 of 10 , Feb 1, 2003
        • 0 Attachment
          Andrew,

          I am reading your article as I write this reply... hope to be able to
          send if as soon as I get home ( am at work now, on my notebook, but I am
          not allowed to plug it to our network, so, as they also don't allow us
          to read our webmails
          except during lunch - to avoid people reading non-tech stuff during
          work-hours - I could read your Email, but as I
          didn't want to reply instantly, and to read your article first...
          well... I am writing it offline and will send later, hope you don't mind ).

          I am a novice function point counter myself, and I didn't count even 500
          function points untill now. But there is something I can tell you about
          one reason you might have got to a wrong estimate for your project based
          on FPA: function points won't work well for systems such as yours ( no
          databases, no external queries, etc ) and plenty of business logic ( ie:
          parsing and editing your XML file ).

          Well, from our experience, FPA proves to be a very precise mean of
          estimating the effort involved in your project, if:

          1- You have a reliable productivity history in your company.
          Function Points are only meaningful for a estimate on the number of
          hours you take to finish a project if you know how much hours your team
          usually takes to fulfill a single function point. This kind of
          information takes time to build.

          2 - Your team is used to developing projects similar to the one you
          have at hand now, and your productivity factor was based on such
          historical database. This one is dependant on your historical
          productivity database. If your company is used to building websites, FPA
          will provide a good way for measuring their productivity on building
          similar websites ( there are adjustments depending on the project's
          particular complexity and on other influencial factors, such as your
          system being real time and interactive, etc ), but you may fail if all
          of a sudden you face a radically diferent kind of project, in which your
          team is not familiar with. Why? Because even if the FPA will provide a
          correct count, your productivity factor will need to be adjusted.

          Even so, FPA is entitled a slight margin of error. When I got hired, I
          heard stories about the first Java projects estimated by FPA they did...
          in one of them, the presumed productivity was taken from a standard
          chart, and the count was made wrong, and the system was far too more
          complex than people inferred. The end result was the manager being
          fired, after a 200% negative margin of error ( and profits ), which they
          could only spot after the project was already sinking.

          Well, here we work basically for the Brazilian government and some
          government institutions. The Productivity Factor is now based on three
          years of work, and proves to be very precise. When a new project
          arrives, after requirements are obtained in user interviews, a
          non-functional ( but fully navigational ) prototype is made, and that,
          plus all mapped ILFs and EIFs, are the basis for the FPA.

          From the function point count, applying the productivity factor, we can
          estimate the number of hours needed for the project. The client pays
          based solelly on the function points count, and the language the system
          will be developed on. So, doing FPA is a requirement we cannot run from.
          Also, they will use the estimated productivity to measure if our
          deadlines are realistic or not, and once a deadline is issued, we
          seldomlly can change that, since the client pays per function point, and
          our company's profits are based on the teams delivering on date or
          sooner ( it's a cat and mouse game... if we manage to deliver sooner and
          sooner, the productivity factor is influenced and so will be the
          estimate number of hours needed for the following projects ).

          So, with this estimative, we can now plan the iterations, and define the
          user stories, based on the requirements. Usually, we don't do pure XP,
          but a slight deviation. Instead of defining user stories, we simply
          split the project into modules, which are then split into functions,
          ordered so that core business modules are issued as soon as possible,
          and trying always to issue a release to the client every two iterations
          ( two week iterations, so, a monthly release ) resulting in two or three
          releases on our usual project ( usually a big project is broken into
          phases, with the first ones focusing on core business features, and the
          later ones, on adding value and more features to the system, and each
          phase faces FPA - focusing on the new features - and dealt as a if it
          were a brand new project ). The requirements are already defined and
          usually, they are a closed matter, so, the most experienced analyst
          plays the client role ( usually, our "client" will work better than the
          actual client, since this client is usually a very large group of people
          split amongst diferent departments, making it extremelly dificult even
          to settle a single doubt over a specific requirement - it would be
          nightmare to expect their aid, or presence, during the development phase ).

          Usually, the FPA will give a very precise estimate... precise to the
          point of leaving almost no slack space. In our last project, the FPA
          gave us a estimative of three months ( something around 12 weeks ) for
          developing a system... we lost almost three weeks due to our own
          company's bureaucracy ( new computers couldn't be configured in time by
          support analysts, and we didn't have permission to do that ourselves...
          DBA won't create the test database on Solaris so we can run, nor support
          will allow us to install Oracle on a single Win2K workstation to start
          development... client uses Oracle 9i... our DBA insisted on Oracle 8i...
          client dump with test data couldn't be imported... , etc ), so, when the
          deadline was comming upon us, this lost time made a HUGE diference.

          Regarding that project, we were then increasing our productive ( team
          was really motivated to issue the final release in time and bugproof...
          this is REALLY important... gaining your team's commitment towards the
          project makes a huge diference in the results achieved), so, I think we
          could have finished in time... only one module and three weeks to go,
          the client called off the project, since they needed a drastic design
          change. They new internal policy would require our system to integrate
          with their client database on the mainframe trough an ISO interface, so,
          the project went back to the workbench and then for the re-counting...
          which was finished two weeks later... but the client didn't issue the
          "go" order again. We were told it will happen in Febuary's end (
          remember, we work for the government... those guys take ages to make up
          their minds... here in Brazil you can't just fire a government employee
          unless he does something REAL bad, so, they are pretty much assured they
          don't have to commit their best efforts to stay employed, so... ). In
          the end, we gained another month ( plus the three remainder weeks ) to
          finish out the project and are safe again schedule-wise, but I will
          still keep the last three weeks in mind, to see if we can still finish
          the remainder parts in three weeks:)

          I hope I have been of some help... if you still have further doubts ( or
          critics ) I am totally available:) Just don't trust FPA blindly. Our
          particular circumstances do lean us that way ( and the upper staff leans
          TOTALLY that way and try to push us alongside ), but even if the best we
          can do is pick the estimated time schedule FPA gives us and see how we
          can put it to it's best use, it may fail, and you must know your
          historical background well to know if the analysis you have can be
          trusted and is acurate enough so you don't have to adjust your
          productivity factor a bit to reflect what your common sense knows...
          like the system being way more complex than the ones you are used to
          deal with, and the FPA resulted in so little points, you must KNOW
          trusting blindly on a simple math operation without further
          considerations will be a sure step toward doom:)

          Kisses,

          Jessica

          Fuqua, Andrew (ISSAtlanta) wrote:

          >Jessica wrote:
          >
          >
          >>and is also
          >>forced by contract to adhere to the number of hours obtained through our
          >>measured productivity by function point to estimate the schedule )
          >>
          >>
          >
          >I'd really like to hear more about this Jessica. Can you give some detail?
          >
          >THANKS
          >
          >-----Original Message-----
          >From: Jessica Luchesi [mailto:jessica@...]
          >Sent: Friday, January 31, 2003 5:13 AM
          >To: extremeprogramming@yahoogroups.com
          >Subject: Re: [XP] Function points and XP
          >
          >
          >Alan,
          >
          > I didn't have the opportunity to read to Andrew Fuqua's article yet,
          >but in case you have further doubts, the company I work with charges our
          >major client ( government agency ) by function points ( and is also
          >forced by contract to adhere to the number of hours obtained through our
          >measured productivity by function point to estimate the schedule )...
          >so, you could contact me also.
          >
          > []s
          >
          > Jessica Luchesi
          >
          >Alan Gladman wrote:
          >
          >
          >
          >>Anyone used function points when trying to measure XP deliverables?
          >>
          >>
          >>To Post a message, send it to: extremeprogramming@...
          >>
          >>To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >>
          >>ad-free courtesy of objectmentor.com
          >>
          >>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >>
          >>
          >>
          >>
          >>
          >>
          >>
          >>
          >
          >
          >
          >To Post a message, send it to: extremeprogramming@...
          >
          >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          >ad-free courtesy of objectmentor.com
          >
          >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >
          >To Post a message, send it to: extremeprogramming@...
          >
          >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          >ad-free courtesy of objectmentor.com
          >
          >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >
          >
          >
          >
        • Phlip
          ... That sounds like a Process Smell, or a Business Culture Smell. -- Phlip http://www.greencheese.org/LucidScheming -- The first few lines of code must
          Message 4 of 10 , Feb 1, 2003
          • 0 Attachment
            Jessica Luchesi sez:

            > I am reading your article as I write this reply... hope to be able to
            > send if as soon as I get home ( am at work now, on my notebook, but I am
            > not allowed to plug it to our network, so, as they also don't allow us
            > to read our webmails
            > except during lunch - to avoid people reading non-tech stuff during
            > work-hours

            That sounds like a Process Smell, or a Business Culture Smell.

            --
            Phlip
            http://www.greencheese.org/LucidScheming
            -- The first few lines of code must "hook" the
            computer, and make it "care" about the program --
          • Phlip
            ... Firestone has an ISO 900x certification. Guess this should have meant all
            Message 5 of 10 , Feb 1, 2003
            • 0 Attachment
              Jessica Luchesi sez:

              > But we are an exception. The company has an ISO 9001 certification,

              Firestone has an ISO 900x certification. Guess this should have meant >all< of
              their tires should have exploded...

              --
              Phlip
              http://www.greencheese.org/PeaceAndCalm
              -- Bad nanoprobe! Bad! --
            • Jessica Luchesi
              ... Yup... they are much Process centered ... they because our team is a huge exception for two reasons... 1 - We apply agile techiniques whenever we can,
              Message 6 of 10 , Feb 1, 2003
              • 0 Attachment
                Phlip wrote:

                >Jessica Luchesi sez:
                >
                >
                >
                >>I am reading your article as I write this reply... hope to be able to
                >>send if as soon as I get home ( am at work now, on my notebook, but I am
                >>not allowed to plug it to our network, so, as they also don't allow us
                >>to read our webmails
                >>except during lunch - to avoid people reading non-tech stuff during
                >>work-hours
                >>
                >>
                >
                >That sounds like a Process Smell, or a Business Culture Smell.
                >
                >
                >
                Yup... they are much "Process centered"... "they" because our team is a
                huge exception for two reasons...

                1 - We apply agile techiniques whenever we can, be it an XP
                deviation, an XSA deviation, or a strange offspring of both. We focus on
                delivering good and reliable software, and documentation that will be
                usefull for the client and will aid our development process.

                2 - We deliver on time:)

                But we are an exception. The company has an ISO 9001 certification,
                which means we cannot use our own notebooks and palms to aid our work,
                since ( they claim ), it would be against the quality certification, as
                we can only work with means provided by the company... I wonder if I
                should leave my fancy pens home also:) Added to that, system analysts
                are used to deliver huge ammounts of useless documentation. And the
                client also got used to that. I am sad to announce that, when we deliver
                a installable build to the client, they don't put it to run, and also,
                we hear complains about the lack of (useless) documentation... mostly
                because their tech guys can't read UML diagrams, so, everything must be
                written out for them.:(

                My manager is a huge example. He is a great person, but our team is
                giving him a hard-time:) The week usually ends with an integration build
                and deploy on the target plataform, and a few integration tests ( we use
                unit testing - JUnit - while developing, but still have to sit in front
                of the system and test it's navigation and see if things plug in
                nicelly... we still have to build better ways to do such tests, and
                build an enviromento for stress analysis and tests ). With that done, we
                tell him the module is ready and tasks are fullfilled. When we started
                working that way, he would turn to us and ask "Ok, but what evidence do
                I have that the tasks are done?". Someone would say "You have the source
                code, and you can see it running!". He would still reply "Yeah, but how
                can I see if nothing is missing? How can I see you did it all and well?
                Do You have evidence the work is done?". To make a long story short,
                what he would mean is: his chief manager won't read source code or care
                if the system works, since they are used to measure the ammount of work
                done by the ammount of paper generated. That's his evidence... (useless)
                documentation. Tons of paper sheets piled and signed on a desk...
                evidence "work was done".:(((

                Well, in the end, most teams end with outdated documents, that are
                forwarded to programmers to do their job, which will usually result in
                low quality software, made by uncommited people, who may even differ
                from the architecture planned by analysts. Some months ago, a project
                took so long to document, when they noticed, there were only 20 days to
                deliver a system... and documents weren't still ready. They picked me
                and some guys at the company to help code... for the reason we could be
                trusted to deliver it fast. We worked as an independant cell in the
                programming team, and all we could see was contradictory documents,
                which didn't cover the business well... as a matter of fact, the result
                of much copy and paste to document the system before actually coding it.

                Anyway, the future seems a little brighter... my team was recently
                split... and gave birth to two teams following the same ideal, of
                delivering high quality code and document it enough so people won't get
                lost looking at the system later, but which is concise, clear and
                meaningfull:) Alex is coaching the other team, and even if I am not the
                leading analyst in this one ( I am on the lead of someone older in the
                company ), people look up at me to actually coach the development
                process... so, I think we have a clear path ahead of us:)

                So, if your company is also process centered, focusing on layers and
                layers of bureaucratic control methods to have the illusion things are
                going on the right way... don't get desperate. If you are given the
                chance, lead the change by example. Alex and Daniel did that a long time
                ago in our company, and now, even if Daniel left us last year, they
                efforts gained voice, and are changing slowlly the way we work. And I am
                proud to have helped a bit. Today, our first XP/XSA project is
                considered a success, and we have now two projects being led that way...
                and we are beginning to become an internal reference of a good way to work:)

                Sorry for being a chatterbox:)) But this is a story that thrills me,
                and seeing change happen is one of the things that make me feel good
                when I get at work every monday morning:)

                Kisses,

                Jessica Luchesi
              • Phlip
                ... Farbeit from me to complain not accepting XP is a sure sign of bad management , but... Statistical Process Control teaches us the difference between
                Message 7 of 10 , Feb 1, 2003
                • 0 Attachment
                  Jessica Luchesi sez:

                  > Fortunatly, we have a new director in the local office board, and he
                  > wants to change things a bit:) Maybe we should expect to see more room
                  > for XP programmers in here soon:)

                  Farbeit from me to complain "not accepting XP is a sure sign of bad
                  management", but...

                  Statistical Process Control teaches us the difference between steering and
                  over-control. In the former you sample data over a long period, then use it
                  to make small adjustments. In the latter, you read each data point and then
                  immediately make large adjustments. Response wanders all over the map, kind
                  of like the US Justice "system".

                  SPC is >said< to have lead to CMM[I], but I wouldn't know anything about that.
                  Of course fretful managers wishing they had control might use CMM (and XP) to
                  beat people over the head with...

                  --
                  Phlip
                  http://www.greencheese.org/HatTrick
                  -- Temporomandibular joint disorder
                  keeping the neighbors awake again? --
                • Jessica Luchesi
                  True:) Having Quality Assurance doesn t mean you have a GOOD quality assured for your products... just that their quality is assured to remain the same, as
                  Message 8 of 10 , Feb 1, 2003
                  • 0 Attachment
                    True:) Having Quality Assurance doesn't mean you have a GOOD quality
                    assured for your products... just that their quality is assured to
                    remain the same, as well as the processes involved in producing them. I
                    personally think ISO900* for a software company is something useless...
                    but again, if I recall, only the two teams I drescribed do not
                    correspond to the standard software quality they deliver... usually they
                    deliver crappy software that will be delivered much later than expected,
                    and not attending what the client needs:) So, I believe ISO falls pretty
                    well here... you can be assured to get crappy software from buying from
                    them:)

                    Fortunatly, we have a new director in the local office board, and he
                    wants to change things a bit:) Maybe we should expect to see more room
                    for XP programmers in here soon:)

                    Jessica


                    Phlip wrote:

                    >Jessica Luchesi sez:
                    >
                    >
                    >
                    >> But we are an exception. The company has an ISO 9001 certification,
                    >>
                    >>
                    >
                    >Firestone has an ISO 900x certification. Guess this should have meant >all< of
                    >their tires should have exploded...
                    >
                    >
                    >
                  • George Dinwiddie
                    ... Yep, see http://www.business2.com/articles/mag/0,1640,46179,00.html -- ... George Dinwiddie agile programmer for hire Baltimore/Washington area
                    Message 9 of 10 , Feb 2, 2003
                    • 0 Attachment
                      Phlip wrote:
                      > Jessica Luchesi sez:
                      >
                      >
                      >>I am reading your article as I write this reply... hope to be able to
                      >>send if as soon as I get home ( am at work now, on my notebook, but I am
                      >>not allowed to plug it to our network, so, as they also don't allow us
                      >>to read our webmails
                      >>except during lunch - to avoid people reading non-tech stuff during
                      >>work-hours
                      >
                      >
                      > That sounds like a Process Smell, or a Business Culture Smell.

                      Yep, see http://www.business2.com/articles/mag/0,1640,46179,00.html

                      --
                      -------------------------
                      George Dinwiddie
                      agile programmer for hire
                      Baltimore/Washington area
                      gdinwiddie@...
                      -------------------------
                    • Fuqua, Andrew (ISSAtlanta)
                      Hi Jessica, I don t disagree with anything you wrote about Function Points, including your point that it might not have been suitable for my project since I
                      Message 10 of 10 , Feb 3, 2003
                      • 0 Attachment
                        Hi Jessica,

                        I don't disagree with anything you wrote about Function Points, including your point that it might not have been suitable for my project since I had no database access.

                        That said, the premise of my paper, the main thing that I took away from the experience, is that while FPA can be great for estimating a project, Function Points were lousy as a measure of iteration velocity.

                        Thanks for the feedback and additional info on your project.

                        andrew fuqua
                      Your message has been successfully submitted and would be delivered to recipients shortly.