Amazon.co.uk
The first part of the book concentrates on the common myths of object-oriented development. (For example, Cockburn clearly prefers Smalltalk and Java to C++ as a development language and he is not enthusiastic about today's computer-aided software engineering [CASE] tools.) He also cuts through the mire of software-engineering methodologies for development by stressing an incremental approach to creating software and gives many useful and practical suggestions for setting up and managing projects of varying sizes.
Throughout this lively and well-written text, the author mixes in anecdotes from actual managers and developers. He also presents actual project case histories (both small and large) and analyses what was done correctly and what went wrong. The author develops 12 strategies for creating successful, on-time software using objects, which are collated in a handy appendix--there is even a detachable "crib sheet".
With its mix of common sense and real-world savvy, Surviving Object-Oriented Projects offers a refreshing take on the realities of developing object-oriented software. This concise and engaging title can improve the odds of success for your next programming project. --Richard Dragan
Amazon.com
The first part of the book concentrates on the common myths of object-oriented development. (For example, he clearly prefers Smalltalk and Java to C++ as a development language and he is not enthusiastic about today's computer-aided software engineering [CASE] tools.) He also cuts through the mire of software-engineering methodologies for development by stressing an incremental approach to creating software and gives many useful and practical suggestions for setting up and managing projects of varying sizes.
Throughout this lively and well-written text, the author mixes in anecdotes from actual managers and developers. He also presents actual case histories for projects (both small and large) and analyzes what was done correctly and what went wrong. The author develops 12 strategies for creating successful, on-time software using objects, which are collated in a handy appendix--there is even a detachable "crib sheet."
With its mix of common sense and real-world savvy, Surviving Object-Oriented Projects offers a refreshing take on the realities of developing object-oriented software. This concise and engaging title can improve the odds of success for your next programming project. --Richard Dragan
Kurzbeschreibung
Synopsis
Buchrückseite
Today, many organizations claim competitive market advantages resulting from the application of object-oriented technology and approaches in their software development efforts. As the use of object technology has become increasingly widespread and mainstream, a growing number of project managers are faced with a daunting task: keeping the object technology project on track and within budget. These project managers are burdened by the weight of knowing that the survival and ultimate success of the project hinges on their insight when planning the project and their responses to events that lie ahead. Unfortunately, hidden costs, unpleasant surprises and unrealistic expectations lie in wait for the unprepared manager.
Although much has been written about object technology and the benefits of this paradigm, there is still a shortage of compiled knowledge about what to expect and to plan for during project implementation. This book provides information that managers need to combat the unforeseen challenges that await them, allowing them to survive and ultimately succeed with an object-oriented project.
To provide practical advice and guidelines for successfully managing an object-oriented project, the author borrows from the seasoned wisdom of numerous experts and successful consultants while also drawing on his personal experience and extensive knowledge. Surviving Object-Oriented Projects: A Manageris Guide points out potential hazards and names workable solutions by addressing the important issues of scheduling, budgeting, staffing, and cost justification. Key points are supported and illustrated through short case studies taken from real object-oriented projects, and an appendix collects these workable guidelines and solutions into brief icrib sheetsio ideal for handy reference.
0201498340B06012001
Über den Autor
Prolog. Abdruck erfolgt mit freundlicher Genehmigung der Rechteinhaber. Alle Rechte vorbehalten.
If you are thinking of starting, or have already started, an object-oriented (OO) project, and want to know what you are up against, this book will be of use to you. Organizations that have successfully made the transition to object technology claim significant time-to-market reduction. Developers say object orientation is a fun way to develop software.
There is no shortage of literature on the subject; however, the press has made so much of object technology that it is hard to sort out exaggerations and selective reporting from the actual experience one can expect. Speakers rarely seem to want to name the actual costs of making the move to objects, perhaps to avoid scaring away future newcomers.
There is, therefore, a lack of information on what sorts of unpleasant surprises await one when starting an OO project, and what to do about them. It is this lack of information that Surviving Object-Oriented Projects: A Manager's Guide addresses.
Scope
This book covers issues I have found in several dozen organizations that are doing object-oriented projects. From failed efforts, we learned specific difficulties; from successful projects, we learned how to get around the difficulties.
The early reviewers of this book unanimously said that it takes several projects to apply the lessons. They said that people on their first OO project are not sufficiently aware of the issues to detect them, are not yet open to suggestions, and cannot set aside old habits and thinking patterns. It is my hope that you can prove them wrong, that you will succeed on your first, or your second, project by paying attention to the lessons from other people's experiences.
This book is not a primer on object technology, nor is it a primer on object-oriented design techniques or of macro- or micromanagement. It is not a technical review of the literature, nor a cataloging of project types. Despite all that has been written about object orientation, there is still a shortage of compiled knowledge of what happens on a project. The information in this book is based on personal project experiences--my own, those of people I have interviewed, and interviews I have read. The project leader will come up against numerous, specific topics for which an answer cannot easily found in the literature, or the obvious answer does not work.
In this book, I identify topics, point out hazards and name a workable strategy taken from a project that successfully cleared the hazard. The hazards and strategies are collected at the back of the book in Appendix B, Crib Sheets.
For readers interested in companion texts to this book, I recommend David Taylor's Object Technology: A Manager's Guide (Reading, MA: Addison Wesley, 1990), Grady Booch's Object-Oriented Analysis and Design (Reading, MA: Addison Wesley, 1994) and his Object Solutions (Reading, MA: Addison Wesley, 1996).
Audience
Surviving Object-Oriented Projects: A Manager's Guide is intended for the busy professional. Here is a reading strategy four types of possible readers:
- The executive scanning for impact to the organization. Read the Preface and the first two chapters. These take you through concepts, project histories, expectations, and costs. If you are interested in the next level of depth, skim the setup issues involving project selection and staffing, and the chapters on large projects. At that point, you may wish to give the book to the project manager.
- The manager before starting on a project. Read Chapters 1, 2, 3, and 5 of the book. These cover expectations, project setup, and incremental and iterative development. Then look through the list of strategies (Appendix A) and hazards (Appendix B) at the back of the book to get a sense of the total set of issues.
- The manager on a project. The primary audience for this book is the manager on a project, working with the technical lead. Some issues are technical enough to require terms of object technology. You, the project manager, may find that the technical lead will bring these problems to your attention or will help you work through them. Skim the entire book to get the nature and location of topics. When working on the project, look up particular topics as they occur. The chapters are organized in roughly the order topics usually show up and need to be dealt with. Reread Chapter 5 about making corrections before each increment.
- The project's technical leader. Use the book to help your manager understand certain issues, such as organizing teams, developing iteratively, and resisting unproductive tools and activities. I have added technical depth in a few areas where a project hazard lurks and there is no simpler way to carry through on the discussion.
Among these are: simplistic modeling of the business (sometimes passing under the name of "analysis"), overstaffing at the beginning of a project, and false productivity measures. For some issues, it is up to you, the technical leader, to work with the arguments in the book to convince other developers and the management team to adopt a sensible direction.
I have included an extended section on C++ because it is my carefully considered opinion that C++ represents an additional hazard to the survival of the project. If you favor using C++, read through this section and deal with the issues to ensure your project's success.
Organization
The book has eight chapters and two appendices, roughly matching the chronology of encounter with the issues.
- Chapter 1 summarizes and introduces sucess and failure factors, and defines terms you will have to become familiar with.
- Chapter 2 is a reality check. What expectations do you have about object technology, and how should you adjust those expectations? The chapter contains stories about a dozen projects, which are referred to throughout the book
- Chapter 3 deals with selecting and setting up a project. This is the best place to work on survival, even if survival means walking away from the project. It covers all the standard issues of staffing, training, tool selection, methodology, legacy systems, and the like.
- Chapter 4 covers some basic issues you will encounter when running the project: estimates, plans, milestones, measurements--and design.
- Chapter 5 deals with the inevitable corrections you will have to make. I start by citing my favorite project, which started dismally and then was turned around. From this project, we can learn a great deal about tuning. You will have much tuning to do; do not feel bad about making changes during the project.
- Chapter 6 is written as a reflection on the first five chapters. You can pretend that you have just finished your project and are giving advice to another person who is about to start a project. What would you highlight for him or her? Here is where you can get hindsight in advance.
- Chapter 7 addresses organizations that have safely made it to the point (or declared themselves at the point) of committing large numbers of their staff to using object technology. There are new costs and new dangers lying in wait for those who move on to larger projects.
- Chapter 8 is another reality check in which I compare the contents of the book to a real project. It opens the topic of organizational culture in overall software success.
- Appendix A is a collection of 12 success strategies presented in a medical diagnosis metaphor.
- Appendix B is a summary, a "crib sheet," to copy and tape to the wall as your daily reminder about the basics of an object-oriented project.
Throughout the book, the topics cross-reference each other extensively. To keep the reading uncluttered, the links to other pages are noted in the margin with a page number, as shown here. Your project's survival depends on developing your insights and reflexes. To help you...