Software Development for Small Teams: A RUP-Centric Approach
The goal of developing software is to deliver something of value to customers. To work effectively, you need to strike the right balance of people, process, and tools. Everyone seems to have favorite tools, techniques, and processes. Software companies sell tools and methods to help you be more effective at building software. Consultants evangelize their methods to convince you that they know how to help your organization and project teams do a better job. We as developers continually learn new techniques and apply new tools to help us do more, in less time, with higher quality. With over seventy-five years of combined experience working on and observing different software projects, we, the authors, have arrived at a conclusion that some enlightened folks have already figured out: Every project is different, and those things that help one team be a spectacular success might, if not applied with common sense, cause another team to fail miserably. Each team needs to decide how to use a specific process, and then continually adjust to make improvements. In the face of this continual change, how can a project team know what to change to be most productive? The answer, in our opinion, lies in learning as many different techniques as possible, learning how to effectively use tools that support the different techniques, and determining what combinations work well, and when they work. This suggests an ongoing process of learning. Good programmers learn from other programmers. They learn by looking at code and reading books on different programming methods. Testers improve by learning their craft from master testers, studying test designs, and learning how to use new techniques and tools. In fact, any individual practitioner learns from others doing the same job and by looking at examples. Each practitioner needs to develop a personal style for working effectively, both as an individual and as a member of a larger team. Teams too, need examples of how other teams work in order to develop their own style of working together. This book is an example of how a small team developed a software tool. It is a chronicle of what we did and why we did it. We have tried to explain why things worked (or didn't), and we discuss what we'll change next time. Along the way we identify the lessons we learned and offer some ideas for generalizing our experiences. Your job, as the reader, is to observe what we did and learn from our experiences.
Reviewer: Lasse Koskela (Helsinki, Finland)
This is what I call a "nightstand book". It's very readable and won't overload your gray brain cells while still stimulating you to analyze your conceptions of the real world you're faced with at work. It's a story about a voluntary software project implemented by the authors on their free time and provides a nice overview of how RUP can be applied to a small project, mixed in with certain ingredients from agile processes such as XP.
The focus of the book is to document what decisions and obstacles the four-member team encountered during the 6 months they spent on the project. The story is very entertaining and I read the book (almost) cover to cover in just 4 days. I found the tips and guidelines splattered around the book to be mostly common sense, but I did make some notes regarding what to do at work a.s.a.p. That's always a sign that the book you're reading was worth reading.
One thing that annoyed me though was the constant praise of the Rational product line knowing that all four authors worked for Rational Software during the project. Also, there were a couple of chapters dedicated for showing little islands of the implementation (code snippets etc.) of which value I frankly didn't see.
In summary, I'd classify this book as a good buy. Not great, but good. No big revelations, but a nice bunch of thought-provokers here and there.