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

questions: going in production early,UML or user story,minimum set of pratices

Expand Messages
  • loicmidy
    Hello, I introduce my context : I m chief of an informatic development service (65 persons) at the french statistic institute ; we do informatic projetcts for
    Message 1 of 5 , Oct 28, 2009
    • 0 Attachment
      Hello,
      I introduce my context :
      I'm chief of an informatic development service (65 persons) at the french statistic institute ; we do informatic projetcts for our statisticiens ; we don't have a very clear methodology for project management but we are mainly waterfall ; I try with some colleagues to push in agiles methodology ; perhaps we will do a mix of SCRUM and XP. We work in java J2EE mainly.

      In my undestanding agile methodology has 2 parts : agile project management method and agile ingenierie pratices. SCRUM only covers the first part whereas XP covers both.



      I think that if I put in place an agile project management method without as leat some agile ingenierie pratices I will fail. What are the minimum set of agile ingenierie pratices that I should put in place in order to succede? I think I should put in place unit testing and Continuous Integration.
      What about automated customer tests? Is it compulsory to succeed?
      For web application : I'm thinking about using selenium for automated customer tests of web application. Does the cost of automation really outbalance the cost of manual testing?
      For batchs applications : in our current process the statisticiens made hand calculus on some test data and compare with our program or the statisticiens program the essential part of the batch quickly (no verification of the correctness of the input data, nothing done to deal with exceptions, no optimisation) in SAS and compare the results with our program. My plan for automation is :
      1- keep the tests data set and the results of the statisticiens programs/calculus 2-automate the comparison and the play of all the tests with Dbunit. Is the method right?



      I also have a problem with the way specifications are made in XP.
      All the example I've seen of user story are of simple actions made by the customer via the application (like web application). I think we could do the specifications that way for our web applications but what about the batchs treatments?
      In my field we need (because the field of statistic is very complicated) quite a lot of specifications for the statistical process (our batchs treatments) and we often use UML. I don't think we can go for a lighter specification like user story for complex statistics batchs treatments . What do you think? Can we have an agile method with UML specifications? (isn't it a to heavy process of specification for agility).



      XP suggests to go in production as quickly as possible. This is well explained in XP installed. I'm half convinced : I see all the advantages but here are a few drawbacks :

      1 : if the new system is replacing an old one, going in production early means that the customers will have to use 2 systems in parallel and progressively use the nex one for more and more functions. That's not easy to monitor and you have to explain often how to use the combinaison of the 2 applications.

      2 : if the new system is replacing an old one, you have to modify often the interface between the old and the new system and test it. This is a cost you don't have to pay with bing bangs.

      3 : i pick an example system that i worked on 4 years ago to explain.
      New system :We have investigators who do surveys of price in the market places on a tablet (C++ application) then they transmit the data to a central oracle database ; we have a J2EE application that uses the central oracle database to do the agregation og the data, the control of the data, the management of the investigators (remplacement, pay,...).
      Old system : the investigators did the collect on papers then others copied the data in an application and the we had the agregation of the data.
      If I want to go in production early I can do 80% on the new C++ application for the investigators and make interface with the old central application.
      BUT there is another choice :
      I do the central 20% of the new investigators application and the new central application and I put in into a test environnement for integration test. Advantages : I can test for 20% of the functionnality the integration of the 2 applications. Drawback : I can't go into production.
      So when the system is composed of severals applications you must choose :
      1 : do a big part of one application and put it in production.
      2 : do a small part of each applications and put it in integration test but not in production.
      What should i do?


      Yours sincerely
      loïc midy
    • M. Manca
      ... No, both covers both, XP provides more standardized practices then scrum. ... I may say that you don t use agile methodology if you don t apply at all,
      Message 2 of 5 , Oct 28, 2009
      • 0 Attachment
        loicmidy ha scritto:
        >
        >
        > Hello, I introduce my context : I'm chief of an informatic
        > development service (65 persons) at the french statistic institute ;
        > we do informatic projetcts for our statisticiens ; we don't have a
        > very clear methodology for project management but we are mainly
        > waterfall ; I try with some colleagues to push in agiles methodology
        > ; perhaps we will do a mix of SCRUM and XP. We work in java J2EE
        > mainly.
        >
        > In my undestanding agile methodology has 2 parts : agile project
        > management method and agile ingenierie pratices. SCRUM only covers
        > the first part whereas XP covers both.
        No, both covers both, XP provides more "standardized" practices then scrum.
        >
        > I think that if I put in place an agile project management method
        > without as leat some agile ingenierie pratices I will fail.
        I may say that you don't use agile methodology if you don't apply at
        all, but this couldn't be a problem if your goal is to
        improve your daily work.

        What are
        > the minimum set of agile ingenierie pratices that I should put in
        > place in order to succede?
        The most good development engineering practices on my point of view are
        pair programming, refactoring and continuous integration (including test
        driven development as a part of comtinuous integration).
        About requirements I love user stories/test stories and only if strictly
        necessary I am quite happy to transform user stories in
        textual use cases (a sort of more formal crc card).
        About project management short iterations (1 or 2 weeks) and burndown
        charts are very useful.

        I think I should put in place unit testing
        > and Continuous Integration. What about automated customer tests?
        I think that continuous integration without a sort of automated tests
        based on test stories is not complete.
        For my point of view the most important thing is to transform
        requirements in executable tests made with customer agreement and
        continuously verify them with some pass/no pass test is very effective.

        Is
        > it compulsory to succeed? For web application : I'm thinking about
        > using selenium for automated customer tests of web application. Does
        > the cost of automation really outbalance the cost of manual testing?
        It depends, for very little projects may be more cost conscious manual
        testing, but in general
        automatic testing is preferred if you will modify also little projects
        in the future.

        > For batchs applications : in our current process the statisticiens
        > made hand calculus on some test data and compare with our program or
        > the statisticiens program the essential part of the batch quickly (no
        > verification of the correctness of the input data, nothing done to
        > deal with exceptions, no optimisation) in SAS and compare the results
        > with our program.
        To me seems that they use this approach because realize a set of test
        data is a long tedious job.
        There are some testing tools to produce set of data to test, try google.

        My plan for automation is : 1- keep the tests data
        > set and the results of the statisticiens programs/calculus 2-automate
        > the comparison and the play of all the tests with Dbunit. Is the
        > method right?
        It seems ok, of course you need to know the correct results to make the
        comparison and so you have
        to calculate them manually or using a different statistic/math tool.
        >
        > I also have a problem with the way specifications are made in XP. All
        > the example I've seen of user story are of simple actions made by the
        > customer via the application (like web application). I think we could
        > do the specifications that way for our web applications but what
        > about the batchs treatments?
        Personally I use this approach also for embedded software; during the
        meetings also I found that using
        a mind mapping tool may help a lot (freemind and xmind are good examples
        of mind mapping tools).
        You may need some exercise to identify the "actors" and then write hte
        user stories in the form of a simple sentence
        where the actor is the subject.

        In my field we need (because the field
        > of statistic is very complicated) quite a lot of specifications for
        > the statistical process (our batchs treatments) and we often use UML.
        Probably I would use some sketches with some math formulas and just the
        data required and then I would transform
        this set of formulas with some meaning class identifiers specifing only
        external relations between classes and living
        to the coding phase all the rest. But could be better to tell having an
        example.

        > I don't think we can go for a lighter specification like user story
        > for complex statistics batchs treatments .
        In my opinion an high level user story may help a lot if you start from
        it to transform in a set of elementary user stories
        using a decomposition method. Remember that user stories have a short
        life cycle, generally they lives jsut for the iteration time, after that
        they will be closed.

        What do you think? Can we
        > have an agile method with UML specifications? (isn't it a to heavy
        > process of specification for agility).
        You can use some UML diagrams as sketches; I use statecharts, activity
        diagrams and a reduced
        form of class diagram only when I think strictly necessary to help the
        development process.
        One of the main ideas of agile method is to transform an heavy design
        phase in a more agile phase (freeing time to test
        the code) considering that the goal is to have an executable application
        working as the customer wants;
        normally the customer doesn't require to have a lot of formalism to
        obtain its end product
        (with some exceptions). Personally I think that if a test is initially
        made a lot of time after I wrote the source code
        it will not cover 100% of that code and it will not cover some fails
        that will be discovered after the final delivery.
        The quality of your application is strictly dependant of the quality of
        your tests.
        >
        > XP suggests to go in production as quickly as possible. This is well
        > explained in XP installed. I'm half convinced : I see all the
        > advantages but here are a few drawbacks :
        >
        > 1 : if the new system is replacing an old one, going in production
        > early means that the customers will have to use 2 systems in parallel
        > and progressively use the nex one for more and more functions.
        No, XP says to deliver your product early with all implemented functions
        working;
        this doesn't mean that your customer can use productively your
        application but he can
        practically evaluate what is ready and can say this is ok, this is not
        ok, I would prefer
        to change this label and so on.
        The basic idea is that the customer may see what developed and if it is
        what he wants.
        In this way you may have more time to correct the product for
        misunderstandings an refinements.
        This doesn't mean that the customer has to be productive with the
        released application if it isn't finished.
        But surely your customer will have a finished product (that he wants) in
        a shorter time then in a pure waterfall
        development model.
        Basically the agile idea is to decompose big problems in little problems
        completing and delivering at little problem level
        to short the time need to know what works and not works, what is
        accepted by the customer and what no.

        That's
        > not easy to monitor and you have to explain often how to use the
        > combinaison of the 2 applications.
        >
        > 2 : if the new system is replacing an old one, you have to modify
        > often the interface between the old and the new system and test it.
        > This is a cost you don't have to pay with bing bangs.
        I don't understand the problem. If you have to change an existing product
        you have a reason to modify it, so probably you need to improve something.
        If you may reuse some source code you may think about redesign/refactor
        the existing application.
        If you need to recode all the application you could learn what is good
        and what is bad with the old one
        making some interview to the customers. Could be a good starting point.
        >
        > 3 : i pick an example system that i worked on 4 years ago to explain.
        > New system :We have investigators who do surveys of price in the
        > market places on a tablet (C++ application) then they transmit the
        > data to a central oracle database ; we have a J2EE application that
        > uses the central oracle database to do the agregation og the data,
        > the control of the data, the management of the investigators
        > (remplacement, pay,...). Old system : the investigators did the
        > collect on papers then others copied the data in an application and
        > the we had the agregation of the data. If I want to go in production
        > early I can do 80% on the new C++ application for the investigators
        > and make interface with the old central application. BUT there is
        > another choice : I do the central 20% of the new investigators
        > application and the new central application and I put in into a test
        > environnement for integration test. Advantages : I can test for 20%
        > of the functionnality the integration of the 2 applications. Drawback
        > : I can't go into production. So when the system is composed of
        > severals applications you must choose : 1 : do a big part of one
        > application and put it in production. 2 : do a small part of each
        > applications and put it in integration test but not in production.
        > What should i do?
        If you need to realize a system made of 3 applications, you have to go
        in production with the entire system and this doesn't depend if you
        think in an agile or waterfall way.
        I suppose to develop 1 application with 1 team, so 3 applications = 3
        teams.
        Every team will develop its application and all the 3 teams will agree
        the interfaces between. So they will agree to a common planning and a
        common calendar and at
        some points they will deliver the system at some completeness degree.
        At every delivery the system will be more complete and it will work more
        as required.
        At every delivery the customer may see what is finished and if it is
        what he wants.
        This doesn't mean that the customer may use the application for
        productive purposes starting from the 1st delivery.
        >
        > Yours sincerely loïc midy
        >
        > <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family:
        > Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
        > 1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
        > font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
        > #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp
        > .ad a{ color: #0000ff; text-decoration: none; } --> <!--
        > #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor #ygrp-lc
        > #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
        > line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom: 10px;
        > padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px; font-family:
        > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
        > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
        > input, textarea {font:99% arial,helvetica,clean,sans-serif;}
        > #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
        > #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family: Georgia;
        > } #ygrp-text p{ margin: 0 0 1em 0; } dd.last p a { font-family:
        > Verdana; font-weight: bold; } #ygrp-vitnav{ padding-top: 10px;
        > font-family: Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{
        > padding: 0 1px; } #ygrp-mlmsg #logo{ padding-bottom: 10px; }
        > #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-reco
        > #reco-head { font-weight: bold; color: #ff7900; } #reco-category{
        > font-size: 77%; } #reco-desc{ font-size: 77%; } #ygrp-vital a{
        > text-decoration: none; } #ygrp-vital a:hover{ text-decoration:
        > underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; }
        > #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px 0;
        > font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
        > font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
        > margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding:
        > 8px 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight:
        > bold; color: #628c2a; font-size: 100%; line-height: 122%; }
        > #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad
        > a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin:
        > 0; font-weight: normal; color: #000000; } o{font-size: 0; }
        > .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
        > blockquote{margin: 0 0 0 4px;} .replbq{margin:4} dd.last p span {
        > margin-right: 10px; font-family: Verdana; font-weight: bold; }
        > dd.last p span.yshortcuts { margin-right: 0; } div.photo-title a,
        > div.photo-title a:active, div.photo-title a:hover, div.photo-title
        > a:visited { text-decoration: none; } div.file-title a, div.file-title
        > a:active, div.file-title a:hover, div.file-title a:visited {
        > text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
        > padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count
        > span { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg
        > p a span.yshortcuts { font-family: Verdana; font-size: 10px;
        > font-weight: normal; } #ygrp-msg p a { font-family: Verdana; }
        > #ygrp-mlmsg a { color: #1E66AE; } div.attach-table div div a {
        > text-decoration: none; } div.attach-table { width: 400px; } -->




        [Non-text portions of this message have been removed]
      • Charlie Poole
        Hi Loïc, ... Zero. Seriously. Lots of non-agile projects have some degree of success. Moving to an agile approach can be done as a big bang but it s often
        Message 3 of 5 , Oct 28, 2009
        • 0 Attachment
          Hi Loïc,

          > I think that if I put in place an agile project management
          > method without as leat some agile ingenierie pratices I
          > will fail. What are the minimum set of agile ingenierie
          > pratices that I should put in place in order to succeed?

          Zero. Seriously. Lots of non-agile projects have some degree
          of success. Moving to an agile approach can be done as a
          "big bang" but it's often done gradually.

          > I think I should put in place unit testing and Continuous Integration.

          This is one good place to start. But a better place is to
          start by asking the team. Of course, it's OK to ask us here
          and we'll give you the best answers we can but you should find
          out what changes will be appreciated - or at least not resisted -
          by the team members themselves. Each successful change makes it
          easier to do the next one. So pick where you'd like to start - CI
          is a good place - and then ask the team what they think.

          > What about automated customer tests? Is it compulsory to succeed?

          This is harder for most teams because it's farther away from
          the details of the software. Start with non-automated but
          clearly understood customer tests - i.e. make sure everyone working
          on something knows the criteria by which it will be judged. Work
          on automating those tests only after you're successful with unit tests.

          > For web application : I'm thinking about using selenium for
          > automated customer tests of web application. Does the cost of
          > automation really outbalance the cost of manual testing?

          It depends. However, automation is about more than cost. It's
          also (and primarily) about rapid feedback. You have to figure
          out the best balance for your project.

          > For batchs applications : in our current process the
          > statisticiens made hand calculus on some test data and
          > compare with our program or the statisticiens program the
          > essential part of the batch quickly (no verification of the
          > correctness of the input data, nothing done to deal with
          > exceptions, no optimisation) in SAS and compare the results
          > with our program. My plan for automation is :
          > 1- keep the tests data set and the results of the
          > statisticiens programs/calculus 2-automate the comparison and
          > the play of all the tests with Dbunit. Is the method right?

          It sounds odd to be using Dbunit to test statistical
          calculations. These are basically unit tests and don’t
          have much connection to a database except possibly
          to store your test cases. Most test frameworks can handle
          using a database as a source.

          Charlie
        • Steven Gordon
          On Wed, Oct 28, 2009 at 8:58 AM, Charlie Poole ... I believe Charlie means the you in the above answer to be plural. It is very important that the whole team
          Message 4 of 5 , Oct 28, 2009
          • 0 Attachment
            On Wed, Oct 28, 2009 at 8:58 AM, Charlie Poole
            <cpoole@...> wrote:
            >
            >
            >
            > It depends. However, automation is about more than cost. It's
            > also (and primarily) about rapid feedback. You have to figure
            > out the best balance for your project.

            I believe Charlie means the 'you' in the above answer to be plural.
            It is very important that the whole team doing the work incrementally
            and empirically decides what to do to hone in on the best balance of
            practices for their project.

            In many organizations, the team doing the work does not have the
            freedom to incrementally make changes in how they do their work,
            reflect on how those changes worked out, and retract those changes
            and/or make other changes. In such organizations, it is essential to
            get the agile management practices in place first to provide the teams
            both the autonomy to control their own process and the responsibility
            to do so in order to deliver value every iteration.

            >
            > Charlie
            >
          • Charlie Poole
            Hi Steven, ... Just so... ... Very true. And often missed by technically-oriented developers trying to figure out and introduce the best set of practices.
            Message 5 of 5 , Oct 28, 2009
            • 0 Attachment
              Hi Steven,

              > > It depends. However, automation is about more than cost. It's also
              > > (and primarily) about rapid feedback. You have to figure
              > out the best
              > > balance for your project.
              >
              > I believe Charlie means the 'you' in the above answer to be plural.

              Just so...

              > It is very important that the whole team doing the work
              > incrementally and empirically decides what to do to hone in
              > on the best balance of practices for their project.

              Very true. And often missed by technically-oriented developers trying
              to figure out and introduce the "best" set of practices. Focus on
              encouraging people and don't judge your success on how closely
              they follow your own preferences.

              > In many organizations, the team doing the work does not have
              > the freedom to incrementally make changes in how they do
              > their work, reflect on how those changes worked out, and
              > retract those changes and/or make other changes. In such
              > organizations, it is essential to get the agile management
              > practices in place first to provide the teams both the
              > autonomy to control their own process and the responsibility
              > to do so in order to deliver value every iteration.

              This is true but it's also the case that just about any
              manager can introduce a good deal of freedom for his or
              her subordinates. It's harder to exercise control upward. :-(

              Charlie

              > >
              > > Charlie
              > >
              >
              >
              > ------------------------------------
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.comYahoo! Groups Links
              >
              >
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.