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

Re: Definition of Done: Code Review practices

Expand Messages
  • pascal.rieux@rocketmail.com
    Hi Charles, Among various practices you ve already listed, we often use a kind of pair review, the reviewee asking the reviewer to attend an informal meeting.
    Message 1 of 7 , Apr 23, 2013
    • 0 Attachment
      Hi Charles,

      Among various practices you've already listed, we often use a kind of pair review, the reviewee asking the reviewer to attend an informal meeting.

      BR

      Pascal Rieux
      Scrum Master
      Sierra Wireless Solutions & Services

      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
      >
      > Hi,
      >
      > I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition of done.
      >
      > In practice, I've seen:
      >
      > * A scheduled meeting for a code review, several show up and review code
      >
      > * Paired Programming
      > * Live review by one other programmer just before code commit.
      > * Code review published to code review system (like Atlassian Crucible, etc) with deadline by which reviewers can submit feedback.
      > * Code review published to code review system (like Atlassian Crucible, etc) where code cannot integrate until one person says "ship it"
      > * No code reviews
      > * Code reviews only on special occasions or in certain parts of the code
      >
      > What other code review type practices have you seen?
      >
      >  
      > -------
      > Charles Bradley
      > Professional Scrum Trainer
      > Scrum Coach-in-Chief
      > ScrumCrazy.com
      >
    • Jesse Houwing
      I remember a lot of discussion on before commit, after commit, before merge, after merge... With gated check-ins and without them... Tarun made a nice blog
      Message 2 of 7 , Apr 23, 2013
      • 0 Attachment
        I remember a lot of discussion on before commit, after commit, before merge, after merge... With gated check-ins and without them...

        Tarun made a nice blog post gathering the feedback from a lot of Microsoft MVP's and ALM Rangers


        On Tue, Apr 23, 2013 at 2:57 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:


        Hi,

        I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition of done.

        In practice, I've seen:
        • A scheduled meeting for a code review, several show up and review code
        • Paired Programming
        • Live review by one other programmer just before code commit.
        • Code review published to code review system (like Atlassian Crucible, etc) with deadline by which reviewers can submit feedback.
        • Code review published to code review system (like Atlassian Crucible, etc) where code cannot integrate until one person says "ship it"
        • No code reviews
        • Code reviews only on special occasions or in certain parts of the code
        What other code review type practices have you seen?
         
        -------
        Charles Bradley
        Professional Scrum Trainer
        Scrum Coach-in-Chief
        ScrumCrazy.com





      • Wouter Lagerweij
        On Tue, Apr 23, 2013 at 2:57 AM, Charles Bradley - Professional Scrum ... with a shared design session in front of a white board, then they go and develop
        Message 3 of 7 , Apr 23, 2013
        • 0 Attachment
          On Tue, Apr 23, 2013 at 2:57 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
          • Live review by one other programmer just before code commit.___
          A variation on this: tasks always get picked up by a pair, they start with a shared design session in front of a white board, then they go and develop either as a real pair, or one does the coding and there's a live review before it will be committed.

          Wouter


          --
          Wouter Lagerweij         | wouter@...
        • steveropa
          I had a boss once who utilized “code buddies”. The idea of a code buddy is that he or she can represent your code at a formal code review, and you can
          Message 4 of 7 , Apr 23, 2013
          • 0 Attachment
            I had a boss once who utilized “code buddies”.  The idea of a code buddy is that he or she can represent your code at a formal code review, and you can represent hers.  I found that it became a fairly nice stepping stone to true pairing.
             
            Steve
             
            Sent from Windows Mail
             
            From: Wouter Lagerweij
            Sent: ‎Tuesday‎, ‎April‎ ‎23‎, ‎2013 ‎12‎:‎51‎ ‎PM
            To: scrumdevelopment@yahoogroups.com
             
             

            On Tue, Apr 23, 2013 at 2:57 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
            • Live review by one other programmer just before code commit.___
            A variation on this: tasks always get picked up by a pair, they start with a shared design session in front of a white board, then they go and develop either as a real pair, or one does the coding and there's a live review before it will be committed.

            Wouter


            --
            Wouter Lagerweij         | wouter@...

             

          • Alan Dayley
            Nice idea, Steve! +1 Alan ... Nice idea, Steve! +1 Alan On Tue, Apr 23, 2013 at 12:02 PM, wrote:   I had a boss once who
            Message 5 of 7 , Apr 23, 2013
            • 0 Attachment
              Nice idea, Steve! +1

              Alan



              On Tue, Apr 23, 2013 at 12:02 PM, <steveropa@...> wrote:
               

              I had a boss once who utilized “code buddies”.  The idea of a code buddy is that he or she can represent your code at a formal code review, and you can represent hers.  I found that it became a fairly nice stepping stone to true pairing.
               
              Steve
               
              Sent from Windows Mail
               
              From: Wouter Lagerweij
              Sent: Tuesday, April 23, 2013 12:51 PM
              To: scrumdevelopment@yahoogroups.com
               
               

              On Tue, Apr 23, 2013 at 2:57 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
              • Live review by one other programmer just before code commit.___
              A variation on this: tasks always get picked up by a pair, they start with a shared design session in front of a white board, then they go and develop either as a real pair, or one does the coding and there's a live review before it will be committed.

              Wouter


              --
              Wouter Lagerweij         | wouter@...

               


            • Sebi
              Hi, From what I experienced the most effective were: * Paired Programming - but not always possible - due to several factors (such as buy in from management,
              Message 6 of 7 , Apr 24, 2013
              • 0 Attachment
                Hi,

                From what I experienced the most effective were:
                * Paired Programming - but not always possible - due to several factors (such as buy in from management, distributed teams)
                * Live review before commit - works well on somehow technically aligned teams
                * Code review published to code review system where code cannot integrate until one person says "ship it" - this is the standard approach we have now - ensuring the code is reviewed, the method goes well with distributed teams - you just have to have the tool :)

                Seb

                --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
                >
                > Hi,
                >
                > I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition of done.
                >
                > In practice, I've seen:
                >
                > * A scheduled meeting for a code review, several show up and review code
                >
                > * Paired Programming
                > * Live review by one other programmer just before code commit.
                > * Code review published to code review system (like Atlassian Crucible, etc) with deadline by which reviewers can submit feedback.
                > * Code review published to code review system (like Atlassian Crucible, etc) where code cannot integrate until one person says "ship it"
                > * No code reviews
                > * Code reviews only on special occasions or in certain parts of the code
                >
                > What other code review type practices have you seen?
                >
                >  
                > -------
                > Charles Bradley
                > Professional Scrum Trainer
                > Scrum Coach-in-Chief
                > ScrumCrazy.com
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.