Desarrollo y Gestion de Proyectos Informáticos

by Steve McConnell, McConnell

I can hear some of you exclaiming, "How can you possibly recommend a book about software scheduling published by Microsoft Press and written by a consultant to Microsoft?!" Well, put aside any preconceived biases. This is a tremendous book on effective scheduling software development, and it drinks deeply from the wisdom of all the classics in the field such as Brook's Mythical Man Month -- and is likely well-informed by McConnell's experiences, good and bad, in Redmond.

The nine page section entitled "Classic Mistakes Enumerated" is alone worth the price of admission and should be required reading for all developers, leads, and managers. Here are some types of the 36 classic mistakes that McConnell describes in detail:

People Related Mistakes Heroics Adding people to a late project Politics placed over substance (etc.)
Process Related Mistakes Abandonment of planning under pressure Planning to catch up later "Code-like-hell" programming (etc.)
Technology Related Mistakes Silver-Bullet syndrome Overestimating savings from new tools or methods Switching tools in the middle of a project (etc.)

I suspect that if you've ever been involved in software development, you winced after reading each of these nine points. And you will learn a great deal from the remaining 640 pages about concrete solutions.

My only substantive gripe: cheesy Powerpoint graphics. Nonetheless, this book is Very Highly Recommended.

Genres: Programming, Software, Technology, Management, Computer Science, Nonfiction, Technical

691 pages, Paperback

First published January 1, 1996

Reviews

[Jim Butler · Rating 5 out of 5]

How can I add any value to the multitude of reviews that obviously say "You must buy this"?
When I was working 80 hours a week - this was the only book I read cover-to-cover.

When I lent my book to one of my staff and he left the firm, I bought another copy off the shelf within 24 hours (I couldn't wait for Amazon's delivery time). This was after having read the book twice.

This is the only book I have bought 3 copies: one for work, one for home, and one to share. It's the only book which caused me to specifically make a trip to the bookstore to get a signature and hear a writer speak.

This is the 2nd of McConnell's books I've read. Code Complete was great. I couldn't believe anything could be better but this book is it. It repeated a few facts and figures but it's worthwhile to have it reorganized and re-presented for a different view. This book has led me to be a confirmed McConnell reader. His other books are good, but this is his best. Unfortunately, my expectation is so high now that his subsequent books are not impressing me as much.

Because of this book, I will attend my second course from his company - even if it means flying into Seattle's rain. One book and he's hooked me for literally a thousand dollars - that's an effective writer!

[Matt · Rating 2 out of 5]

I think this book is really showing it's age. McConnell's advice feels genuine, but the data is based on experiences from the early 90s. A lot has happened in the software world between then and now so there are many things that don't fit with some of the best practices that modern development embraces. Unless you're staying on top of how companies do development today, it's hard to filter out what is outdated advice versus what is still relevant. Therefore, in spite of the book having some good information, I can't recommend it strongly because uninformed readers might be lead astray by practices that have proven themselves to be fads (I'm looking at you, JAD) or are just mediocre advice.

[kar-kar · Rating 5 out of 5]

Эта книга посвящена организации процесса разработки программ. Она написана для людей, цель которых создать программный продукт максимально быстро. Автор рассматривает общие, философские идеи быстрой разработки, классические организационные ошибки и эффективные методы повышения скорости разработки.

В книге нет советов по написанию кода. Несмотря на это, мне, как простому программисту, который в основном пишет код, правит баги и лишь изредка может повлиять на процесс разработки, она очень понравилась. Идеи, изложенные в книге, придают смысл происходящему вокруг, помогают лучше понять коллег и заказчиков, объясняют важность планирования и формирования правильных ожиданий у всех заинтересованных сторон.

Автор приводит множество ссылок на источники утверждений и фактов, описанных в книге, чем дает понять, что данная книга это не очередное очень важное мнение одного человека, а скорее исследовательская работа, на основе сотен книг и личного опыта. Читается легко, во многом благодаря умению автора подобрать простые слова, продуманной структуре книги, а так же наличию учебных примеров - вымышленных историй о проектах.

[Toby Reiter]

This book is as much about psychology as it is about specific IT techniques for rapidly developing applications. Many of the books lessons focus on managing expectations, avoiding common political and personal pitfalls during the development process, and anticipating and controlling change.

For developers, this pairs very well with Code Complete.

[Ben · Rating 3 out of 5]

Two stars for readability and concise writing, three and a half stars for content. The content is quite good, but in attempting to be comprehensive, the book ends up being excessively verbose. A more well-organized and edited version of this book might be a third the length and cover all the material more effectively. The "case studies" were the most painful part as they felt artificial and contrived and rarely provided insight the text had not already clarified.

[Emily · Rating 4 out of 5]

I probably wouldn't have read this book if I hadn't been assigned to read it. It is written for software developers, but I believe that any project manager could learn a lot. This book has really opened my eyes.

[Nathan · Rating 4 out of 5]

Great book on Project Management. This book was required as in college and I was fortunate this book was assigned as a read. Great concepts on managing expectations, dealing with business politics, and delivering projects.

Worth the read.

[Dax · Rating 5 out of 5]

I thought this was a lot better than (the more famous) Code Complete by the same author, and perhaps the best software engineering best-practices book there is.

[Robert Kennedy · Rating 4 out of 5]

I don't think this has aged as well as Code Complete, but still has a ton of great insights. I would love to see an updated version written in the age of iterative delivery.

[Summa Smiff · Rating 5 out of 5]

Probably the best software development guide I've ever read. The main focus is on how to develop software quickly, although, unlike many manuals on the Agile methodology, et al, sometimes focuses on other goals (and how to identify which goal is right for your project). Some of those goals being: increased project status visibility, less defects /bugs, or higher overall quality. The concept of increasing project visibility being what stakeholders actually want in many cases was a lightbulb moment for me.

Hard to believe this book is over 20 years old - some of the techniques were brand-new to me, and identify common errors made by developers and management alike. Don't let the size of this book dissuade you from reading it - the book is well organized into small chapters that demonstrate the efficiency you would expect from a subject matter expert.

[Mingyang Li · Rating 5 out of 5]

How does the book relate to me myself?
“Beware of adopting new tools.” Yes, I’ve experienced strong curiosity, painful ramping-up, and sudden disappointment chasing the craze of many Markdown editors.
“Beware of adopting a 4GL.” Yes, I’ve tried VB, and still feel that Python is more productive.
“Changes in plans and designs should be made carefully and rarely.” I can’t tell you how many times in my research work I have found that I needed to re-clean the datasets in the analysis stage.
“Tap into developers’ inner motivation.” My manager has been very supportive for my personal growth, which indeed makes me feel appreciated and voluntarily wanted to work overtime.

[Diego Pacheco · Rating 3 out of 5]

For the 1996 book - there are some still relevant things such as the Team models, classical mistakes such as (2) Weak Personal, (4) Heroics, (6) Noisy, Crowded offices (60% people hate offices - De Marco 1987) - this one resonates a lot with me :-), (8) Unrealistic Expectations - Still happens a LOT !!!! (29) Feature Creap. There are some things that are not problems anymore like lack of Source Control. Some of the Waterfall comparisons or tradeoffs, I'm not sure I agree but the author is not pro-waterfall for sure.

[Nathaniel Inman · Rating 2 out of 5]

RD is not a methodology but a set of practices that can coexist alongside agile teams to help deliver product faster while adjusting one of the four dimensions of development speed: people, product, process or technology. While it sheds light on helpful tools it's controversial foundation on antiquated COCOMO practices for estimation or occasionally outdated take on tools and industry best practices limits its credibility. My page tabs are on 8, 11, 22, 58, 84, 126, 222, 284, 329, 376, 403, 481, 503 & 559.

[James · Rating 4 out of 5]

This book could have been one quarter of the size and still convey the same data. A decent read, but missing information on the latest software development fads. Steve Maguire's Debugging the Development Process is better.

[Julio · Rating 4 out of 5]

Although some parts are a little outdated, the book is in general interesting to read. Some examples are too detailed and not really necessary.

It is curious that some of the techniques/processes described are the prelude to the agile methodologies that are nowadays spread among almost every software project.

[Tiger Abrodi · Rating 2 out of 5]

Read it, and cut in the middle. The book isn't outdated but was written at a time when waterfall was extremely common.

You're MUCH better off reading the book "Clean Agile", skip this one, it doesn't provide much value after you've learned about agile.

[Mark]

Did not finish, but I enjoyed the portion I did read.

[Daniel · Rating 3 out of 5]

Agile practices before they were called agile. In some topics the book shows its age, but it is still a good read, if you put in perspective.

[Anish K George · Rating 4 out of 5]

May be Agile books made some parts of this book outdated. But topics like different team models, development strategies and best practices are eye openers even today.

[Darragh · Rating 2 out of 5]

Excessively verbose and fairly dated, some interesting content though.

[Craig Cecil · Rating 5 out of 5]

This book should be read, re-read, memorized, and used by anyone involved in the planning, management, development, or deployment of software. It's that good. Steve McConnell presents a succinct, well organized collection of the lessons learned and best practices in software engineering over the last three decades.

[Hasyimi Bahrudin · Rating 5 out of 5]

Just got the book today. I'm pretty impressed with the book quality. Just a few flipped pages (for bookmarking) here and there. No stains (so far). No missing pages (so far). Pretty good deal for an awesome book!

[Ben Haley]

Another from the Art of Project Management which will be useful for the type of development we do at PERTS.

[Lauri · Rating 4 out of 5]

Taming Wild Software Schedules is no joke....

[Michael Fruergaard · Rating 5 out of 5]

680p- 01-02-2007

[Doug · Rating 3 out of 5]

Seemed a bit obvious to me, but others have told me they really liked.

[Justin · Rating 5 out of 5]

Top notch advice from a giant in the field. Any developer or manager who wishes to elevates their skills to true engineering needs to read this book, cover to cover.

[Lori Grant · Rating 4 out of 5]

A should-read book on product development for knowledge workers and entrepreneurs.

[Lu Wangshan · Rating 4 out of 5]

Comprehensive treatment of software development.

[Sridhar Jammalamadaka · Rating 5 out of 5]

Loved this book. Wonderful content presented well. A must read for IT services providers to improve customer delight and avoid schedule slippages.