How to get started with new Agile Team
Problem
Many teams start out with good intentions and then have quality erode as people go through the motions due to burn out or just no longer having fun.
Solution
1. For sustainability, the team really should own and evolve their standards instead of them being handed a bible.
2. Also, it is more critical to get early momentum through delivery of working software and feedback on that software than to get bogged down in the minutiae of a specific standard.
3. I suggest starting with the minimum that the team reaches a quick consensus on as necessary from the beginning and then add/subtract from it as feedback and experience indicates to the whole team. The standards can and should change over time. The key is clarity, testability, extensibility and maintainability of the code itself.
4. It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one team member.
5. Pair programming is the best way to get consistent adherence to standards. For traditional code reviews to be effective, they will take at least as much overhead as pair programming, but pair programming is more immediate and has lots of other quality benefits
-----------------------------------------Reference---------------------------------------------------
Reference Books
Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin
Refactoring: Improving the Design of Existing Code by Kent Beck, Martin Fowler
Refactoring to Patterns by Joshua Kerievsky
Test Driven Development: By Example by Kent Beck
Head First Design Patterns by Eric Freeman, Elisabeth Robson
Clean Code
http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code - 60 min
Robert C. Martin, during his keynote at QCon London 2010, tried to figure out why there is so much bad code written. He offers advice on writing good code talking about a bad code example, Boy Scout rule, functions, arguments, craftsmanship, TDD, continuous integration, pairing, small cycles, patterns, engineering, certification, and other elements
http://www.infoq.com/presentations/10-Ways-to-Better-Code-Neal-Ford - 60 min
Test Driven Development
http://www.infoq.com/presentations/tdd-ten-years-later - 60 min
In this session, we'll review some of the landmarks in the history of Test-Driven Development and what they tell us about how to develop software; the ideas, techniques, objections, and misunderstandings. We'll talk about our experiences of discovering TDD and what we've learned about how to do it well, how to adopt it, and how to bring it into existing code.
Many teams start out with good intentions and then have quality erode as people go through the motions due to burn out or just no longer having fun.
Solution
1. For sustainability, the team really should own and evolve their standards instead of them being handed a bible.
2. Also, it is more critical to get early momentum through delivery of working software and feedback on that software than to get bogged down in the minutiae of a specific standard.
3. I suggest starting with the minimum that the team reaches a quick consensus on as necessary from the beginning and then add/subtract from it as feedback and experience indicates to the whole team. The standards can and should change over time. The key is clarity, testability, extensibility and maintainability of the code itself.
4. It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one team member.
5. Pair programming is the best way to get consistent adherence to standards. For traditional code reviews to be effective, they will take at least as much overhead as pair programming, but pair programming is more immediate and has lots of other quality benefits
-----------------------------------------Reference---------------------------------------------------
Reference Books
Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin
Refactoring: Improving the Design of Existing Code by Kent Beck, Martin Fowler
Refactoring to Patterns by Joshua Kerievsky
Test Driven Development: By Example by Kent Beck
Head First Design Patterns by Eric Freeman, Elisabeth Robson
Clean Code
http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code - 60 min
Robert C. Martin, during his keynote at QCon London 2010, tried to figure out why there is so much bad code written. He offers advice on writing good code talking about a bad code example, Boy Scout rule, functions, arguments, craftsmanship, TDD, continuous integration, pairing, small cycles, patterns, engineering, certification, and other elements
http://www.infoq.com/presentations/10-Ways-to-Better-Code-Neal-Ford - 60 min
Test Driven Development
http://www.infoq.com/presentations/tdd-ten-years-later - 60 min
In this session, we'll review some of the landmarks in the history of Test-Driven Development and what they tell us about how to develop software; the ideas, techniques, objections, and misunderstandings. We'll talk about our experiences of discovering TDD and what we've learned about how to do it well, how to adopt it, and how to bring it into existing code.
Comments
Post a Comment