<< 1 >>
Rating: 
Summary: Good advice, but only if you are selective
Review: This book is a case study of a completed software development project done by a small, distributed team. What is unique about it is that the members of the team were all employed in full-time positions at different places doing other things. In that respect, their experiences are not those of the usual development team, but are more comparable to an open source project. However, since open source projects are largely driven by the passion and dedication of the project members, there are some significant differences. Combining all of this, there are some major questions as to whether their experiences can be transferred over to the development of software by a small team all employed by the same company. The answer to each question is very situation specific.
In the area of effective communication, there is no question that their experiences can serve as a model for all projects. Since any of the team members could have had their employment changed at any time without considering the consequences to the project, all planning had to incorporate the reality of staff change. This is one of the weaknesses of many projects, in that there is no allowance for team members being fired, being transferred to another position, resigning or the task being outsourced. Therefore, the situation for this project, which can be considered an extreme case, is a model for how the communication between the members, including future additions, should be managed. The strategy used in the selection of tools is also one that can serve as a model for all projects. Once again, the unusual nature of the team composition means that it can be considered an extreme case.
There are aspects of this project that I do not believe can be transferred to other projects. The people were all volunteers for the development team. In the real world, the selection of the team members is largely by being assigned by management, and is not always based on the quality of the skill set. In many cases it is based on nothing more than current availability. The situation described here immediately introduces a level of team cooperation that cannot be otherwise assumed. The team members all knew each other and were aware of the quality of each other's work. From this, it is clear that the selection of the team members would be skewed towards people who would more naturally work together and had the needed skills. While there was naturally some pressure to succeed, it was not the kind faced by developers working on an industry project. The kind of pressure you face there is the threat of job loss or the company folding if the project is not delivered on time and fully functional.
The last aspect is one that deals with the purpose of the project. If it was begun with the idea that their experiences would be recorded and used as the basis of this book, then there would be a natural tendency to complete the project and make it sound good. As someone who has written several books, I understand how the pressure to complete the book can be a powerful driving force. I have no direct evidence that their reporting is skewed in any way. In fact, it appears that the authors are extremely forthright in describing what went wrong during the creation. My raising the point is based on a fundamental understanding of human nature and how we tend to discover what we are looking for.
If you are in the position where you are building a distributed team using people who all have full time jobs doing other things, then this book is perfect for you. For everyone else, you can learn things from their experiences, but it will be necessary for you to be very selective in your education.
Rating:
Summary: Good Buy
Review: 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.
Rating:
Summary: Good Buy
Review: 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.
<< 1 >>
| 
