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

Agile toolset questions (particularly code inspections....)

Expand Messages
  • Craig A
    Hi all, We ve been using scrum for a while now, and are investigating a few different toolsets to solve some of the things we wanted addressed. One toolset
    Message 1 of 9 , Dec 1, 2008
    • 0 Attachment
      Hi all,
         We've been using scrum for a while now, and are investigating a few different toolsets to solve some of the things we wanted addressed.  One toolset we've been looking at is the Atlassian toolset (ie. JIRA w/Greenhopper for story management/etc, Confluence, Crucible, etc) and I'm really liking using Crucible for code inspections.  However, it has a few shortcomings that won't be addressed in the short term, so I was just wondering what types of toolsets (or more specifically: what tool for code inspections) other folks were using out there?

      Thanks,
      Craig.
    • joscha_jenni
      Hi Craig Which other tools did you evaluate? What kind of things would you like to solve (except code reviews)? We use the Atlassian toolset (JIRA, Confluence,
      Message 2 of 9 , Dec 2, 2008
      • 0 Attachment
        Hi Craig

        Which other tools did you evaluate?
        What kind of things would you like to solve (except code reviews)?

        We use the Atlassian toolset (JIRA, Confluence, Greehopper Plugin,
        Bamboo, Crucible, FishEye). Tho tools are very well accepted.

        Best, Joscha

        --- In scrumdevelopment@yahoogroups.com, "Craig A" <tabmow99@...> wrote:
        >
        > Hi all,
        > We've been using scrum for a while now, and are investigating a few
        > different toolsets to solve some of the things we wanted addressed.
        One
        > toolset we've been looking at is the Atlassian toolset (ie. JIRA
        > w/Greenhopper for story management/etc, Confluence, Crucible, etc)
        and I'm
        > really liking using Crucible for code inspections. However, it has a
        few
        > shortcomings that won't be addressed in the short term, so I was just
        > wondering what types of toolsets (or more specifically: what tool for
        code
        > inspections) other folks were using out there?
        >
        > Thanks,
        > Craig.
        >
      • Mark Levison
        ... different toolsets to solve some of the things we wanted addressed. One toolset we ve been looking at is the Atlassian toolset (ie. JIRA w/Greenhopper for
        Message 3 of 9 , Dec 2, 2008
        • 0 Attachment
          On Mon, Dec 1, 2008 at 10:40 PM, Craig A <tabmow99@...> wrote:
          >
          > Hi all,
          >    We've been using scrum for a while now, and are investigating a few different toolsets to solve some of the things we wanted addressed.  One toolset we've been looking at is the Atlassian toolset (ie. JIRA w/Greenhopper for story management/etc, Confluence, Crucible, etc) and I'm really liking using Crucible for code inspections.  However, it has a few shortcomings that won't be addressed in the short term, so I was just wondering what types of toolsets (or more specifically: what tool for code inspections) other folks were using out there?
          >

          Why do you need tools in the first place? Are you distributed? Is there a trust issue? Tell us why and we can give you better advice.

          On the subject of electronically mediated code reviews, I wrote: http://www.notesfromatooluser.com/2006/12/online_code_rev.html
          a couple of years ago.

          Cheers
          Mark Levison

          Blog: http://www.notesfromatooluser.com/
          Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
          Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
        • Craig A
          Hi Mark, We are a large distributed team. We also have a large number of new grads & contractors in low-cost centers, so adding code inspections adds very
          Message 4 of 9 , Dec 2, 2008
          • 0 Attachment
            Hi Mark,
               We are a large distributed team.  We also have a large number of new grads & contractors in low-cost centers, so adding code inspections adds very little overhead (with the right tool) and increases quality.  This is in addidition to using things such as PMD, etc.



            On Tue, Dec 2, 2008 at 2:39 PM, Mark Levison <mark@...> wrote:

            On Mon, Dec 1, 2008 at 10:40 PM, Craig A <tabmow99@...> wrote:
            >
            > Hi all,
            >    We've been using scrum for a while now, and are investigating a few different toolsets to solve some of the things we wanted addressed.  One toolset we've been looking at is the Atlassian toolset (ie. JIRA w/Greenhopper for story management/etc, Confluence, Crucible, etc) and I'm really liking using Crucible for code inspections.  However, it has a few shortcomings that won't be addressed in the short term, so I was just wondering what types of toolsets (or more specifically: what tool for code inspections) other folks were using out there?
            >

            Why do you need tools in the first place? Are you distributed? Is there a trust issue? Tell us why and we can give you better advice.

            On the subject of electronically mediated code reviews, I wrote: http://www.notesfromatooluser.com/2006/12/online_code_rev.html
            a couple of years ago.

            Cheers
            Mark Levison

            Blog: http://www.notesfromatooluser.com/
            Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
            Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html

          • Craig A
            Hi Joscha, We also use JIRA, Confluence, Greenhopper plugin, Bamboo & fisheye and have no problems with those -we re quite happy with them. With Crucible,
            Message 5 of 9 , Dec 3, 2008
            • 0 Attachment
              Hi Joscha,
                  We also use JIRA, Confluence, Greenhopper plugin, Bamboo & fisheye and have no problems with those -we're quite happy with them.   With Crucible, there are certain things that are 'missing' (in our opinion) from it that are major hurdles - we do have issues open with Atlassian on them.     I'm not going to go into detail about what the issues are (unless someone is interested), because the general feeling I'm getting from this mailling list is that tools like Crucible don't seem to be used by people doing scrum (or at least there seems to be a lot of resistance to the question).

              In terms of code inspection tools, we've also evaluated:
              • an in-house tool developed by another part of our company - it has it's own shortcomings, but it also does a few things far better than Crucible.
              • Code Collaborator (from Smart Bear)
              • Review Board

              --
              Craig.

              On Tue, Dec 2, 2008 at 4:59 AM, joscha_jenni <joscha.jenni@...> wrote:

              Hi Craig

              Which other tools did you evaluate?
              What kind of things would you like to solve (except code reviews)?

              We use the Atlassian toolset (JIRA, Confluence, Greehopper Plugin,
              Bamboo, Crucible, FishEye). Tho tools are very well accepted.

              Best, Joscha



              --- In scrumdevelopment@yahoogroups.com, "Craig A" <tabmow99@...> wrote:
              >
              > Hi all,
              > We've been using scrum for a while now, and are investigating a few
              > different toolsets to solve some of the things we wanted addressed.
              One
              > toolset we've been looking at is the Atlassian toolset (ie. JIRA
              > w/Greenhopper for story management/etc, Confluence, Crucible, etc)
              and I'm
              > really liking using Crucible for code inspections. However, it has a
              few
              > shortcomings that won't be addressed in the short term, so I was just
              > wondering what types of toolsets (or more specifically: what tool for
              code
              > inspections) other folks were using out there?
              >
              > Thanks,
              > Craig.
              >


            • Mark Levison
              ... grads & contractors in low-cost centers, so adding code inspections adds very ... addidition to using things such as PMD, etc. I love code inspections
              Message 6 of 9 , Dec 3, 2008
              • 0 Attachment
                On Tue, Dec 2, 2008 at 9:30 PM, Craig A <tabmow99@...> wrote:
                >
                > Hi Mark,
                >    We are a large distributed team.  We also have a large number of new grads & contractors in low-cost centers, so adding code inspections adds very
                > little overhead (with the right tool) and increases quality.  This is in addidition to using things such as PMD, etc.

                I love code inspections (although I love pair programming even more), but at their core they're conversations between two or more human beings. Like any conversation the lower the bandwidth the less effective the communication. So when I must do code reviews remotely, I use tools like RealVNC and webcams, in a pinch I will use a telephone and VNC.

                I have used SmartBear's tool and it stank. Not only was a pain to use to but slowed the whole conversation, down. Net result fewer questions got asked and reviews were perfunctory.

                Is there nobody on site with these new grads who will do most of the code reviews? Are all your sr people in one location (North America) and the new grads somewhere else?

                Caveat emptor a good supply of people with weak skills can produce far more technical debt (garbage) than a small number of good (not necessarily sr) can possibly review. In the mean time the good people won't have the opportunity to do any development work since they will spend a lot of time reviewing and tidying up. I don't know the details of your situation, but if it's what it sounds like I would find small number of very good people and jettison the rest. Radical? Yes - but we will write less, code, have fewer bugs and eventually get more features shipped than the group I see being described.

                Where's Ron when you need him :-).

                Cheers
                Mark

                Blog: http://www.notesfromatooluser.com/
                Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
                Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
              • Adam Sroka
                ... Another one of the XP practices that really helps is collective ownership. The more often I have to modify something that someone else wrote the more I
                Message 7 of 9 , Dec 3, 2008
                • 0 Attachment
                  On Wed, Dec 3, 2008 at 11:35 AM, Mark Levison <mark@...> wrote:
                  >
                  >
                  > On Tue, Dec 2, 2008 at 9:30 PM, Craig A <tabmow99@...> wrote:
                  >>
                  >> Hi Mark,
                  >> We are a large distributed team. We also have a large number of new
                  >> grads & contractors in low-cost centers, so adding code inspections adds
                  >> very
                  >> little overhead (with the right tool) and increases quality. This is in
                  >> addidition to using things such as PMD, etc.
                  >
                  > I love code inspections (although I love pair programming even more), but at
                  > their core they're conversations between two or more human beings. Like any
                  > conversation the lower the bandwidth the less effective the communication.
                  > So when I must do code reviews remotely, I use tools like RealVNC and
                  > webcams, in a pinch I will use a telephone and VNC.
                  >

                  Another one of the XP practices that really helps is collective
                  ownership. The more often I have to modify something that someone else
                  wrote the more I implicitly review them. Also, when you see the same
                  things being done over and over it should lead to discussion. This
                  works for distributed teams as well although, as usual, the bandwidth
                  is greatly reduced.

                  > Caveat emptor a good supply of people with weak skills can produce far more
                  > technical debt (garbage) than a small number of good (not necessarily sr)
                  > can possibly review. In the mean time the good people won't have the
                  > opportunity to do any development work since they will spend a lot of time
                  > reviewing and tidying up. I don't know the details of your situation, but if
                  > it's what it sounds like I would find small number of very good people and
                  > jettison the rest. Radical? Yes - but we will write less, code, have fewer
                  > bugs and eventually get more features shipped than the group I see being
                  > described.
                  >

                  +1

                  > Where's Ron when you need him :-).
                  >

                  He's around. He's always around ;-)
                • John Stoneham
                  ... This mailing list likes to answer questions with questions to try to get to the root of problems. I don t think there s an intrinsic resistance to the use
                  Message 8 of 9 , Dec 4, 2008
                  • 0 Attachment
                    On Wed, Dec 3, 2008 at 9:03 AM, Craig A <tabmow99@...> wrote:
                    > ... the general feeling I'm getting from this mailling list
                    > is that tools like Crucible don't seem to be used by people doing scrum (or
                    > at least there seems to be a lot of resistance to the question).

                    This mailing list likes to answer questions with questions to try to
                    get to the root of problems. I don't think there's an intrinsic
                    resistance to the use of tools, but certainly an emphasis on choosing
                    them based on a need they fulfill and not using them as an excuse to
                    avoid a conversation or interaction.

                    - John Stoneham
                  • Adam Sroka
                    ... In other words: We value Individuals and Interactions over processes and tools. Does that sum it up?
                    Message 9 of 9 , Dec 4, 2008
                    • 0 Attachment
                      On Thu, Dec 4, 2008 at 7:19 AM, John Stoneham <sirlyric@...> wrote:
                      > On Wed, Dec 3, 2008 at 9:03 AM, Craig A <tabmow99@...> wrote:
                      >> ... the general feeling I'm getting from this mailling list
                      >
                      >> is that tools like Crucible don't seem to be used by people doing scrum
                      >> (or
                      >> at least there seems to be a lot of resistance to the question).
                      >
                      > This mailing list likes to answer questions with questions to try to
                      > get to the root of problems. I don't think there's an intrinsic
                      > resistance to the use of tools, but certainly an emphasis on choosing
                      > them based on a need they fulfill and not using them as an excuse to
                      > avoid a conversation or interaction.

                      In other words: We value Individuals and Interactions over processes
                      and tools. Does that sum it up?
                    Your message has been successfully submitted and would be delivered to recipients shortly.