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

Re: [XP] Function points and XP

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.