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

Definition of Done: Code Review practices

Expand Messages
  • Charles Bradley - Professional Scrum Trai
    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
    Message 1 of 7 , Apr 22 5:57 PM
    • 0 Attachment
      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


    • 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 2 of 7 , Apr 23 12:50 AM
      • 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 3 of 7 , Apr 23 4:08 AM
        • 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 4 of 7 , Apr 23 11:51 AM
          • 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 5 of 7 , Apr 23 12:02 PM
            • 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 6 of 7 , Apr 23 12:14 PM
              • 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 7 of 7 , Apr 24 12:53 AM
                • 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.