| Building Software Teams |
Authors: Joost Visser, Sylvan Rigal, Gijs Wijnholds and Zeeger Lubsen This book is a collection of lessions on how to create an efffective working environment for development teams. This slim volume outlining ten best practices for software development is a follow-up to a sister title, Building Maintainable Software, Ten Guidelines for Future-Proof Code. The authors are consultants with the Software Improvement Group, a software management consultancy, and the thrust of the lessons is to measure everything. 
The book opens with a chapter introducing ways to measure software development, in particular the ISO 25010 Standard, and the Goal-Question-Metric approach. The heart of the book begins with a chapter on how to derive metrics from your measurement goals. As with the rest of the practical chapters, this opens with a paragraph defining the best practices in this area, followed by the chapter in detail. In this case, the focus is on the Goal-Question-Metric approach. Most developers will agree wholeheartedly with the next chapter, titled 'Make Definition of Done Explicit'. The most interesting aspects of this chapter are the objections to this idea. Another idea that seems obvious comes next - control code versions and development branches. As with all such 'isn't that common sense?' ideas, the trick is in actually doing it rather than knowing it. The next chapter is titled 'Control development, test, acceptance and production environments'. In essence, the advice is to create separate environments for various stages in the development process, make the environments similar, and control the progression of code from one to another. Test automation is next on the list, along with the need to agree on guidelines and expectations for tests. A chapter on continuous integration is next. Essentially, this suggests setting up a Continuous Integration server that takes care of integrating code whenever code is committed to the CI server. Automated Deployment is the topic for the next chapter, using tools that automatically transfer code from one environment to the next. The final three chapters look at standardizing the development environment; managing usage of third party code; and documenting just enough. The definition of 'just enough' is that it should enable the development team to have a common understanding of design decisions and nonfunctional requirements. The book ends with a chapter on what to do next once you've put all the recommendations into place - essentially, keep doing it. The book is well written, concise, and explains the ideas clearly. A lot of what is in this book is well known, but in the experience of the authors, isn't done in practice. If development team leaders followed all the advice, it would undoubtedly lead to better quality software. To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
Related Reviews |
|||
| Last Updated ( Wednesday, 31 May 2017 ) |