Seeing the Whole: Mapping the Extended Value Stream
Author: Dan Jones
Winner of the 2003 Shingo Prize!
By identifying all the steps and time required to move a typical product from raw materials to finished goods, the authors show that nearly 90 percent of the actions and 99.99 percent of the time required for the value chain's Current State create no value. In addition, the mapping method clearly shows demand amplification of orders as they travel up the value stream, steadily growing quality problems, and steadily deteriorating shipping performance at every point up stream from the customer.
The mapping methodology takes managers step-by-step through an improvement process that converts the traditional value stream of isolated operations into an ideal future-state value stream in which value flows from raw materials to customer in just 6 percent of the time previously needed. The dramatically improved value stream also eliminates unnecessary transport links, inventories, and handoffs, the key drivers of hidden connectivity co sts.
Applying the method to a realistic example, the authors show how four firms sharing a value stream can create a win-win-win-win-win future in which everyone, including the end consumer, can be better off.
The Mythical Man-Month: Essays on Software Engineering
Author: Frederick P Brooks Jr
Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.
The added chapters contain (1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is ther efore critical; and that it is difficult but possible to achieve this unity; (2) Brooks' view of these propositions a generation later; (3) a reprint of his classic 1986 paper "No Silver Bullet"; and (4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."
0201835959B04262002
Booknews
The 20th anniversary edition of this classic collection of essays on software engineering and managing complex projects includes revised material, and new chapters condensing the author's original propositions and his views 20 years later, plus a reprint of his 1986 paper "No Silver Bullet," and his recent comments on that essay. Brooks' central argument is that large programming projects suffer different management problems from small ones due to the division of labor, and that conceptual integrity of the product is critical. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Ray Duncan
Tar Pits and Silver Bullets
Whenever a product's development schedule is slipping badly and there is a crisis meeting of the programming team, the term "mythical man-month" is likely to be bandied about. There will be many sighs and exchanges of knowing looks and pointing of fingers and tasks assigned and subsequent exchanges of memoranda and Highly Significant Position Papers. But it's a safe bet that hardly anyone at the meeting will have actually read "The Mythical Man-Month" by Frederick P. Brooks Jr. or know exactly what it talks about -- the book, and its author, have acquired a certain mythic status of their own.
So what is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?"
Alas, time cannot be warped so easily. Dr. Brooks observed, while he was managing the development of Operating System/360 (OS/360) in the early 1960's, that man-months are not -- so to speak -- factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.
When you stop to think about it, this phenomenon is easy to understand. There is an inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be dedicated to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there will be at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger.
The Mythical Man-Month is, of course, about substantially more than, well, man-months. Many other concepts and chapter titles found in the book have also made their way into computing jargon and folklore, such as "the second-system effect" and "ten pounds in a five-pound sack" and "plan to throw one away." Brooks also addresses design issues, interfaces, specifications, tool-building, and debugging techniques. He was an early proponent of cross-compiling and simulation (when the OS/360 project started, there were as yet no fully-functional implementations of the hardware).
Interestingly (and I suspect characteristically), Brooks did not exploit 20 years of hindsight to revamp the body of The Mythical Man-Month for the Anniversary Edition reviewed here. He chose, instead, to let the original text stand on its own merits and to add four chapters containing his influential 1986 essay "No Silver Bullet," a summary of the debate over the latter essay by other computer scientists and Deep Thinkers, his own annotations of the chapters in the first edition of The Mythical Man-Month, and some general musings on the evolution of computer science and programming.
I first stumbled across The Mythical Man-Month shortly after it was released in 1975. At that time, I was your prototypical self-taught code mangler, working in almost complete isolation from other programmers, learning everything the hard way, reinventing wheels by the dozen, and with minimal exposure to the computing literature. Although I recognized Brooks's work as both important and very well written, I was too naive to fully appreciate its significance. Revisiting the book twenty years later, having in the meantime plowed through some hundreds of other computer books and spent a fair amount of time writing and editing computer books myself, I find myself somewhat in awe of The Mythical Man-Month.
Although there are definitely passages that feel dated (such as Brook's recommendations from the 1960's for a "surgical" team structure), very few computing books have stood the test of time as well as this one. The book is beautifully written, edited, typeset, and illustrated. It has few peers in the elegance of its presentation and its insights into the human side of software development. And although Brooks comes across as a direct and rather unpretentious fellow, I can imagine that he must have been inspiring and challenging to work for -- his powers of observation, willingness to learn from mistakes, and ability to see through to the deeper issues are remarkable.--Dr. Dobb's Electronic Review of Computer Books
Table of Contents:
1. The Tar Pit.2. The Mythical Man-Month.
3. The Surgical Team.
4. Aristocracy, Democracy, and System Design.
5. The Second-System Effect.
6. Passing the Word.
7. Why Did the Tower of Babel Fail?
8. Calling the Shot.
9. Ten Pounds in a Five-Pound Sack.
10. The Documentary Hypothesis.
11. Plan to Throw One Away.
12. Sharp Tools.
13. The Whole and the Parts.
14. Hatching a Castrophe.
15. The Other Face.
16. No Silver Bullet -- Essence and Accident.
17. "No Silver Bullet" ReFired.
18. Propositions of The Mythical Man-Month: True or False?
19. The Mythical Man-Month After 20 Years.
Epilogue.
Notes and references.
Index. 0201835959T04062001
No comments:
Post a Comment