holidaypacklist Hier klicken Sport & Outdoor Unterwegs_mit_Kindern Cloud Drive Photos TomTom-Flyout Learn More madamet saison Hier klicken Fire Shop Kindle PrimeMusic GC FS16

Kundenrezensionen

3,9 von 5 Sternen56
3,9 von 5 Sternen
Format: Taschenbuch|Ändern
Preis:31,60 €+ Kostenfreie Lieferung mit Amazon Prime
Ihre Bewertung(Löschen)Ihre Bewertung


Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.

am 7. September 2003
In seinem Buch "Extreme Programming Explained" führt Kent Beck auf unterhaltsame und leicht verständliche Weise in die Technik des Extreme Programming (XP) ein. Er zeigt auf, auf welchen Prinzipien XP beruht und wie XP üblichen Probleme des traditionellen Software-Projektmanagements begegnet. Weiterhin erläutert Beck, in welchen Projekten XP Sinn macht, in welchen man besser darauf verzichtet und wie man XP auch nur teilweise oder nach und nach einführen kann.
Leider bleibt das Buch bei der XP-Einführung unkonkret - ein paar Beispiele aus der Praxis wären hier hilfreich gewesen. Negativ fällt auch auf, dass der Autor sich sehr oft wiederholt, anstatt das Buch logisch zu gliedern und direkt auf den Punkt zu kommen.
0Kommentar|Eine Person fand diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 8. Januar 2000
Extreme programming really is not what the name suggests. In many ways, it is a throwback to the earlier days of programming. When I was teaching at the college level in the decade of the eighties the first thing that we told the students was the classic principle that goes back to the beginning of civilization. When faced with an extremely difficult task, divide and conquer. Works in war, politics and software development. In extreme programming, this principle is applied to the largest of projects. The iterations are parceled into as small a unit as possible, with the cycle being: design a little, code a little, test a little. Something like the baby step approach to software development. In particular, "Code is integrated and tested after a few hours - a day of development at most." However, this must only be a rule of thumb, as there are times when it takes longer than a day to create the code update. Which is what I see as the problem with extreme programming taken to the stated level. In all the stages of development, there are tasks that simply cannot be broken down into the "baby steps" needed for extreme programming. An even better example is testing. Even with a superb design that is heavily encapsulated, it is possible to make a "simple" change that would require days of testing to verify.
Another throwback is simply, make the programmers talk to each other. Note that the word was talk, not communicate. Electronic messages are fine, but humans still transfer information and resolve differences much better when there is mutual visibility. The core of this point is what the author refers to as pair programming, where the tasks are parceled out into teams of two. Ideally, the two will complement each other, where one can code while the other analyzes. All fine in theory. Like so many other theories, it ignores the reality of human nature. If you create a team of two and place them in a stressful situation, there must be a great deal of mutual respect, tolerance, understanding and they must complement each other. If one possesses a greater skill set or more simply, a dominant personality, then the total will not be greater than the sum of the parts. There is also the problem of breaking ties, which will fall to a manager, who may not be as cognizant of the issues as the members of the pair.
The four principles of extreme programming are: communication, simplicity, feedback and courage. Sound advice for almost anything you wish to undertake. However, not everything is simple, feedback is sometimes difficult, impossible or wrong; communication is both positive and negative and courage can get you fired. I have no doubt that these principles will work, but only of they are used as general guidelines and not as fixed rules. It is worth reading, but there are better books available.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 29. Oktober 1999
Since I partipated in may of the disussions on the Wiki Wiki Web site and had many of the objections in the begining that the first reviewer had, I feel I am very qualified to give this book a review. It DOES turn everything that those so-called Methodologists sprout on their ear but that is what we need. It is a well-defined process to get software done on schedule and done correctly. Here is my review from Wiki: This is an important'' and ''monumental book. I think that this book will have as much of an impact on development pratices as GOF did with Patterns. I can't remember when if ever (maybe UmlDistilled) that I read a technical book all the way through in just two sittings. I've had my share of troubles understanding the essence and even the pratices of XP online here at Wiki. I found some of the topics here too philosophical for me to understand. Not so with this book. What Kent has done so brilliantly is capture XP and explain it in simple terms. It's a small book, it has small chapter, so it is a joy to read. These things really helped but the writing style is so clear and lucid. I found that I couldn't put it down and my excitement growing with each page. The thouhts flashed to convincing everyone I know to read this book as well as Wow! What if I really could work in an XP enviornment! I found particuarly exciting the 40-hour week pratice as I don't think I have seen it discussed anywhere here. "Work no more than 40 hour weeks as a rule. Never work overtime a second week in a row." I just think of all the frenzied places I've worked and their feeling of total loss of control. But even more importantly, this book made me feel excited about being a programmer again.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 2. November 1999
Kent has pulled off quite a feat: He's come up with a theory of software development that is actually unique, exciting, and inspiring - to managers, to programmers, and to end-users.
I first looked into XP around June of this year, on the WikiWikiWeb (c2.com), and was admittedly skeptical. Over the summer I began to look at the problems in my own projects, [I slept at my office 2/3 of the month of July doing overtime] and realized how much practices like unit tests, paired programming, and user stories would help me deliver things on time & without losing as much sleep.
XP is one of the most important things to happen to development in years - it will make you WANT to be a programmer (or even a project manager) again.
Peter Drucker, in 1964, said:
"There are only two things we know about the future: 1) it cannot be known, and 2) it will be different from what exists now and from what we expect. Any attempt to base today's actions and commitments on predictions of future events is futile. But precicely because the future is going to be different and cannot be predicted, it is possible to make the unexpected and unpredicted come to pass. To try to make the future happen is risky; but it is a rational activity. And it is less risky than coasting along on the comfortable assumption that nothing is going to change, less risky than following a prediction as to what "must" happen or what is "most probable". The purpose of the work on making the future is not to decide what should be done tomorrow, but what should be done today to have a tomorrow."
Extreme Programming is a way to make the future happen.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 29. Oktober 1999
This is a great book that promotes a set of disciplines that support the management and development of the software artifact. Be warned - this does not promote hacking. But instead, stresses the adherence to a set of disciplines that are geared towards mitigating risk and improving the quality of your software while improving the productivity of the developers. This book promotes continuous attention to the software that is being developed versus a point and shoot (then magic happens) approach.
Those that make their money off of promoting big process will criticize this book for its lack of attention to the artifacts that their particular methodology promotes. Yet many of these methodologies do not stress the discipline in evolving the actual software artifact that the XP approach does.
This book is very pragmatic in the way it addresses software development. It promotes a shift to cleanup the cobwebs in our current development practices. This shift will cause people to react in different ways (as does any paradigm shift). Many will lash out. Many will find new productivity and enjoyment in their programming. This is a must read regardless of whether you agree or disagree with all of its principles. You owe it to yourself as a developer to understand these ideas.
It is a great complement to Fowler's Refactoring book.
This book is very approachable for all developers. It provides disciplines that you can quickly apply without having to buy any expensive supporting tools.
I am very interested to see how this approach to software development evolves.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 30. Oktober 1999
Some people will attack it as being a return to cowboy coding, which it isn't. It is instead a new methodology that focuses on creating tests before you code, working in pairs to get an instant code review and other innovative ideas.
The methodology seems like it would work with small teams of well motivated people, but it probably wouldn't work in cases where morale is poor (ie: bad management) and it remains to be seen how it will scale up to larger teams.
Another part that seems weak is the transition from a rapidly growing system to a stable system with only maintenance work being done. This part is glossed over largely because the author doesn't seem to have had much experience with this (he mentions never being on such a project).
Lastly, the question of how big the effect of the Smalltalk origins of the methodology are make it hard to judge their applicability to a non-Smalltalk dev team.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 5. November 1999
At one of Kent Beck's talks I went to, he described Xp in terms of "building software like software" instead of like archetectur or craftmanship or mathmatics or anything else.
Reading this book, though, it would seem that programing is actually like raising kids. You have to start small, use the simplist thing that could posibly work, make sure everyone does only their job, that everyone contributes and no one is overworked. In a very real sense, everything you need to do Xp, you learned in kindergarten. Take turns, work together, if you break something, fix it, none of the concepts are that dificult, which makes you wonder why some people hate it so much. If you really want to learn the philosiphy behind Xp, take a look at his bibliography. It is a magnificent document on it's own.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 22. Juni 2000
This is one of the most thought-provoking, interesting software development books I have read. At its heart is the idea that the traditional exponential software lifecycle cost-of-change curve doesn't necessarily have to be, and if we "embrace change" as the book's subtitle suggests, we can roll with the punches, flatten the curve and deliver solid software sooner and in a much more satisfying way. Kent Beck's style is very easy and enjoyable to read, and very practical and realistic. He knows programmer psychology and it shows, with the whole methodology working with the programmer, not against him/her. Even if you don't want to or can't follow the whole extreme programming model, you will certainly be able to pick up pieces of good advice to improve the way you currently development software.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 5. Dezember 1999
I don't recommend this book for someone on a real OO project of any size. While there are parts of the book that might be useful, many of the suggestions are downright wrong IMO from the many OO projects I've been on. CRC cards are all well and good, but they don't scale to significant commercial projects. Open group areas with desks pushed together is a bad thing, not a good thing. As much as the author wants everything to center around programming, it doesn't. Some thought in analysis and design and refactoring @ that level is more powerful. Programmer pairs is an interesting idea to try (though I think it's taken too far in the book). There are much better books out there (e.g. Larman's OOA/D book; Fowler's UML book) - get them and leave this one on the bookstore's shelf!
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 20. April 2000
No doubt the ideas brought forth in Beck's work will generate controversy. He writes as he preaches, simple and courageous. I read the book in 3 hours and am still thinking heavily about its message. Current technological advances may actually allow his approach to work but it will be a tough sell to any customer comfortable with current methodologies. Beck's zeal is contagious but it comes across as rationalization for the lazy way I want to code. Frankly, what he espouses could be downright dangerous (not courageous) if the test bed environment is not extremely robust. I would have loved more facts and figures behind the one-paragraph arguments. I agree with other reviewers, this is just a large article, not a book, but oh does it generate some radical thoughts!
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden