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

RE: [scrumdevelopment] Scheduling Defect Fixes

Expand Messages
  • Roy Morien
    At the moment there is not a lot of emphasis on defect prevention , apart from the conventional and traditional code inspections , user-driven testing and
    Message 1 of 347 , Jan 31, 2011
    • 0 Attachment
      At the moment there is not a lot of emphasis on 'defect prevention', apart from the conventional and traditional 'code inspections', user-driven testing and good advice about how it is a good idea.
       
      At this university, which I frankly believe to be reasonably representative of IT / CS / BC curriculum generally in universities, the unfortunate fact of the matter is that testing and 'defect prevention' is under-represented, shall we say, in curriculum. In my situation, trying to change the direction of the curriculum is a bit like steering a large ship ... it takes a long time to change course. In many countries, Thailand and Australia to my sure knowledge at least, Government Ministries of Education have a lot of say in curriculum, even at the University level. So in many respects what the education bureaucrats know and understand is what is included in the curriculum.
       
      But I am trying! There is another professor here in the IT Engineering Faculty who teaches esentially introductory TDD, and emphasises good testing and QA practices. But he is a bit of a standout.
       
      As for me, well, I am so busy trying to get the students to understand even the basics of iterative development, good documentation practices, thinking instead of copying, the difference between reuse and plagiarism etc. that it is difficult to introduce these things. But I try! At the moment I am starting to oversee student projects, and it is obvious to me that the first thing the students do is try to design some tables without much understanding of the business requirements. I am in a position of being able to have some influence on future curriculum, so I am as busy as a lizard drinking introducing these basic ideas. A difficult part of my job is to convince others, such as the (Java) programming mahaguru (Malay for Higher Teacher) to think about TDD, things like ANT or JUnit etc. and to get them to change their curriculum. At the same time I can't give an appearance of being 'The Wise Man from the West' ... these are competent people in their own right and in their own sphere. They do have one major drawback, and that is, most of the literature available on Agiule etc. is in English, which many of them do not understand.
       
      Regards,
      Roy Morien
       

      To: scrumdevelopment@yahoogroups.com
      From: chuck-lists2@...
      Date: Mon, 31 Jan 2011 22:12:03 -0800
      Subject: Re: [scrumdevelopment] Scheduling Defect Fixes

       
      Roy,

      Do you have a section of your course dedicated to defect prevention?  If so, what techniques do you teach?

      Many in the "Agile" and "agile" movements have tried to shift the focus to be more on defect prevention and less on defect detection. Do you cover that topic at all?  If so, what do you teach on that topic?

      Charles



      From: Roy Morien <roymorien@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Mon, January 31, 2011 8:32:49 PM
      Subject: RE: [scrumdevelopment] Scheduling Defect Fixes

       

      Yes, I am sure that you can Ron, and obviously the ultimate desirable outcome is not to have bugs at all. Then the discussion on how to handle bugs becomes irrelevant and unnecessary.
       
      But the fact is, the original posting was about how to handle bugs. This obviously meant that the poster had bugs, as awful as that may be.
       
      So, by all means advise on how to not have bugs.
       
      But also it must be accepted that bugs happen, or are created, or whatever euphemism is applied to that awful situation. So the best way to handle bugs needs to be discussed. It is no advice at all to say "don't have 'em" in this situation.
       
      This is really the central theme of everything I have said ... bugs are certainly not a good idea to have, you should do everything that you can to not have them, but if it happens, 'this' is a good way to handle it.
       
      I am, as you know, a teacher at a university. If I teach students about programming or analysis and cover the problem of code errors, bugs, defects etc. by telling the student 'OK, don't have them,! Got it? Good!' then this would not be very useful, would it?
       
      Why is this controversial and worthy of extensive disputation and argument?
       
      Regards,
      Roy Morien
       

      > To: scrumdevelopment@yahoogroups.com
      > From: ronjeffries@...
      > Date: Mon, 31 Jan 2011 21:42:59 -0500
      > Subject: Re: [scrumdevelopment] Scheduling Defect Fixes
      >
      > Hello, Roy. On Monday, January 31, 2011, at 9:29:29 PM, you wrote:
      >
      > > "The best solution, as Ron mentions, is probably to reduce
      > > defects to such a small rate that there is no material amount of defect fixing time. "
      > >
      > > Oh, I heartilly agree ... and the best solution to poverty is to
      > > have more money. The best solution to poor child health is to not
      > > have child illness. The best solution to traffic jams is to stop cars going on the road.
      >
      > FYVM. I can teach people how to reduce defects.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Testing quality into a program is like spinning straw into gold.
      > -- George Cameron.
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      >
      > <*> To visit your group on the web, go to:
      > http://groups.yahoo.com/group/scrumdevelopment/
      >
      > <*> Your email settings:
      > Individual Email | Traditional
      >
      > <*> To change settings online go to:
      > http://groups.yahoo.com/group/scrumdevelopment/join
      > (Yahoo! ID required)
      >
      > <*> To change settings via email:
      > scrumdevelopment-digest@yahoogroups.com
      > scrumdevelopment-fullfeatured@yahoogroups.com
      >
      > <*> To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      >
      > <*> Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
      >


    • Vikrama Dhiman
      ... Although, this is not Twitter. I really want to do a+1. Echoes my thoughts completely. Won t have been able to put it better myself. Thanks Vikrama Dhiman
      Message 347 of 347 , Feb 2, 2011
      • 0 Attachment
        >>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.

        Although, this is not Twitter. I really want to do a +1.

        Echoes my thoughts completely. Won't have been able to put it better myself.
         
        Thanks

        Vikrama Dhiman
        ================================================================
        Personal Blog : http://www.vikramadhiman.com/
        My Blog about all things Agile : http://agilediary.wordpress.com/



        From: George Dinwiddie <lists@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wed, February 2, 2011 11:09:28 PM
        Subject: Re: [scrumdevelopment] Re: Scheduling Defect Fixes

         

        On 2/2/11 5:48 AM, Ron Jeffries wrote:
        > Hello, kbs_kulbhushan. On Wednesday, February 2, 2011, at
        > 12:23:59 AM, you wrote:
        >
        >> Does this make sense?
        >
        > Not really, but it was a delightful demonstration of how many
        > numbers can dance on the head of a pin.

        It (and the length of this thread) is a great illustration of why I
        recommend that teams not get too wrapped up in estimation. They start
        looking for numerical precision, and that starts consuming the energy
        that could be put toward accomplish goals.

        I suggest that the primary reason for estimating stories & tracking
        velocity is to help the team decide how much work they can do in the
        next iteration. I've found that developing clear acceptance examples
        (a.k.a. tests) helps them do that much better than more time spent
        honing estimates.

        I suggest that the secondary reason for estimating stories & tracking
        velocity is to help the PO predict how much functionality can be done by
        a certain date, or how long it will take to build a certain amount of
        functionality. When doing so, one has to remember that these are just
        estimates, no matter how much work you put into them. You need to allow
        some leeway for the things you don't know and can't predict. You need
        to track actual progress, and give that more weight than any predicted
        progress. And you need to measure actual progress in ways that don't
        mislead you. The more calculations you put in, the more likely you're
        going to fool yourself.

        - George

        P.S. Remember that the abbreviation for "estimation" is "guess."

        --
        ----------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------


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