Applied Software Project Management Book Review

Es passiert nicht oft, dass ein Software-Projektmanagement Buch zusammen, das ist praktisch, leicht zu lesen und gestapelt voller bereit, Prozess-Skripte verwenden kommt. Andrew Stellmann und Jennifer Greene haben genau das getan mit den jüngsten Buch Applied Software Project Management.

Es gibt zu viele Bücher über Projektmanagement-Software oder Software-Engineering, die trocken, übermäßig komplex und langweilig sind, aber dieses Buch ist nicht einer von ihnen. Es war eine Freude zu lesen, weil ihre Art des Schreibens ist klar, ohne dabei simpel und beschreiben die Autoren die Dinge in der richtigen Menge an Details. Es scheint, sie verstehen, ihr Publikum und machte sich auf in eine äußerst hilfreiche und praktische Art und Weise zu schreiben. Sie haben sicherlich das erreicht.

Der erste Teil des Buches umfasst Werkzeuge und Techniken, die auf Projekte angewendet werden können. Projektplanung, Kalkulation, Disposition, Testberichte, Anforderungen, Gestaltung und Programmierung und Testen haben jeweils ein eigenes Kapitel. Der zweite Teil wird über die Verwendung von Projektmanagement effektiv und enthält Kapitel über das Verständnis Wandel, Management und Führung, die Verwaltung eines Outsourcing-Projektes und Prozessverbesserung.

Ein klarer roter Faden durch das Buch ist eine Beschreibung der typischen Probleme, Software-Projekt-Teams Gesicht - unzureichende Anforderungen, Verwaltung von Änderungen, mangelnde Qualitätssicherung in jeder Phase eines Projekts, endlose Tests und Bug-Fixing-Zyklen, Spannungen und Missverständnisse zwischen den Software-Ingenieuren und Business-Anwender. Keines dieser Probleme sind technischer Natur, sondern sind Organisations-und Führungsaufgaben. Stellman Greene und bieten praktische Ratschläge, um diese Probleme auf ihre Erfahrung bei ähnlichen Projekten zu lösen.

Stellman Greene und sicher erscheinen, viel über Probleme, die Software-Teams vor Ort kennen. Bereits in der Einleitung beschreiben sie die Notwendigkeit, chronische Probleme zu überwinden und dieses Thema wird im ganzen Buch fort. Für jedes Problem gibt es immer mindestens eine vorgeschlagene Lösung. Zum Beispiel beschreiben sie ein gemeinsames Szenario, wonach Führungskräfte kein Vertrauen in die Schätzungen des technischen Teams, irgendwie zu glauben, dass das technische Team bewusst Überschätzung, um etwas Spielraum geben sich Zeit. Ihre vorgeschlagene Lösung ist es, diese Manager in der Schätzung mit einzubeziehen, damit sie sehen können, die Schätzungen in einer transparenten und systematischen Art und Weise gemacht. Sie dann weiter im Detail zu beschreiben, wie man eine Breitband-Delphi-Schätzung Sitzung ausgeführt und liefern Beispiele für Vorlagen und Dokumente, die während solcher Sitzungen verwendet werden kann. Sie bieten auch eine wertvolle Prozess-Skript für die Teams zu folgen.

Spätere Kapitel behandeln Planung, Disposition, Testberichte, Anforderungen, Gestaltung und Prüfung. Während die meisten dieser Kapitel jedes Thema abdecken in angemessenem Detail, wird der Bereich auf Design nicht detailliert genug und bietet keine Beschreibung, welche Art von Design-Leistungen erzeugt werden könnten, noch keine detaillierte Beschreibung, was diese Konstruktion zu erbringenden Leistungen enthalten könnte. Dies steht im Gegensatz zu den Anforderungen an die Prozess-Skripte Kapitel enthält für Anforderungserhebung und-analyse sowie eine detaillierte Beschreibung der Use Cases und Software-Anforderungen Spezifikationen Dokumente.

Ein weiterer netter Aspekt des Buches ist die Checklisten, die nach dem Umgang mit einem der wichtigsten Projekt-Management oder Software-Engineering-Themen erscheinen. Checklisten sind wichtige Qualitätssicherungstechniken, dass die Autoren zu Recht darauf hinweisen, sollte in der gesamten Software-Projekte als eine Möglichkeit, den Fang Fehler frühzeitig eingesetzt werden. Zum Beispiel, wenn eine Checkliste, die auf die Software-Anforderungen Spezifikationen fängt die Tatsache, dass eine kritische Anforderung fehlen oder nicht eindeutig ist, dann kann der Fehler bei der Analyse Phase korrigiert werden. Die Autoren erklären, dass durch den Fang und das Beheben von Fehlern früh, die Kosten klein ist im Vergleich mit den Kosten für das Beheben von Fehlern später in einem Projekt gefunden. Deren Schwerpunkt auf Qualitätssicherung Techniken werden während des gesamten Projekts mit Beispielen von Checklisten zur Anwendung aufgetragen ist deshalb sehr praktisch und nützlich.

Die Autoren Vielleicht möchten Sie einige der Beispiele, die sie verwenden zu überdenken. Sie beschreiben den Prozess der Umgestaltung Code, um ihn besser wartbar zu machen und verwenden Sie ein Beispiel für eine Java-Code, die sie allmählich Refactoring über mehrere Iterationen. Am Ende dieses Prozesses sagen, warum sie Refactoring anwendbar wäre, in Situationen, in denen Code ist wie Spaghetti. Das ist in Ordnung, außer dass sie ein Beispiel für die sehr un-Spaghetti-ähnlichen Java-Code, Refactoring verwenden. Dadurch sieht es für mich, dass sie in eine gemeinsame Programmierer Falle von Code-Verschönerung, wo verbringen Sie Zeit Programmierer aus dem Zeitplan iterativ verbessern Code, der ganz gut funktioniert, um das "perfekte" Code, Klasse oder ein Objekt zu schreiben fallen. Ich habe das bei Projekten, wo es war einfach nicht die Zeit, in der Anlage zu ermöglichen dies geschehen, und es ist sicherlich brachte keine zusätzlichen geschäftlichen Nutzen für die Beteiligten. Dies ist jedoch eine geringfügige meckern.

Ich würde mir mehr Seiten gewidmet Risikomanagement hätte. Immer wieder, nicht das Management von Risiken wird als ein Grund, warum Projekte scheitern zitiert. Die Autoren beschreiben, tun das Risikomanagement in einer oberflächlichen Art und Weise, aber das Buch würde von einer besseren Beschreibung, wie und warum das Risikomanagement sollte während des gesamten Projekts durchgeführt werden, nicht nur in den frühen Phasen der Projektplanung profitieren.

Eine Sache, dachte ich, das Buch fehlte, war ein detaillierter Blick auf iterative Verfahren. Die implizite Annahme ist, dass die gesamten Software-Projekt sollte der Wasserfall-Methode folgen. Ich würde nicht zustimmen. Es hat einige wichtige Alternativen zur Wasserfall-Methode, die in den letzten 20 Jahren haben vor allem diejenigen, basierend auf iterativen Ansätzen entwickelt. Die wichtigsten Sturz mit dem Wasserfall-Ansatz ist es die Annahme, dass alles, was über die Anforderungen zu Beginn eines Projekts bekannt ist.

Iterative Ansätze auf der anderen Seite davon ausgehen, dass Anforderungen werden im Rahmen des Projekts nichts ändern, weil die Benutzer ein besseres Verständnis von dem, was sie brauchen, oder aufgrund von Änderungen der Rahmenbedingungen für Unternehmen. Basierend auf dieser Annahme, iterative Methoden entwickelt, um besser zu managen dieses sich wandelnde Umfeld. Mit Wasserfall Ansätze, veränderte Anforderungen erfordern oft das Projekt auf früheren Stadien mit einer entsprechenden Zunahme der Kosten und Aufwand zu überdenken. Die Autoren verbringen kaum eine Seite auf dem Rational Unified Process (RUP) und die Autoren sollten genauer anzusehen, wie ihre praktische Ratschläge und Prozesse könnte über alternative Ansätze verwendet werden iterativen Ansatz zum Wasserfall.

Schließlich glaube ich, das Buch versucht, zu breit unter Berufung auf drei verschiedene Gruppen von Menschen. Zunächst wird ein Teil an den in einem Software-Team (Projektleiter, Analytiker, Programmierer und Tester) tätig sind. Der zweite Teil richtet sich an Berater angeheuert, um Projektmanagement-Praktiken und Projektleiter, die Software-Outsourcing-Projekte verwalten müssen verbessert werden soll. Das Buch wäre besser gewesen, hatte es ausschließlich auf den in der Software-Team beteiligt konzentriert.

Das vorletzte Kapitel über die Verwaltung eines Outsourcing-Projekts wird in einer oberflächlichen Art und Weise fast, als ob die Autoren haben den Wunsch, es zu erwähnen, denn Outsourcing ist ein solches Geschäft Priorität in diesen Tagen behandelt. Das letzte Kapitel den Umgang mit Prozessverbesserung ist auch zu kurz, um effektiv mit einem so großen Thema. Getrennte Bücher, die sich ausschließlich mit diesen Fragen wäre angemessener gewesen.

Ungeachtet dieser Punkte, ist dieses Buch eine hervorragende Anleitung für jene Leute in Software-Projekten, beide Projektleiter und technische Teammitglieder gleichermaßen beteiligt. Sie werden vieles finden, sie können sich direkt an ihren eigenen Projekten.

Ich würde dieses Buch jedem, der auf einem Software-Entwicklungsteam arbeitet empfehlen, weil das Buch hat so viel praktische Tipps, um den Menschen helfen, ihre Fähigkeit verbessern, hochwertige Software zu liefern. Kommen Sie, daran zu denken, würde ich empfehlen es auch an leitende Mitarbeiter von Unternehmen, die eine negative Sicht der eigenen Software-Entwicklungsteams haben. Vielleicht könnte dann Führungskräfte verstehen, warum begehen Ressourcen zur Prozessverbesserung ist eine der besten Investitionen, die sie machen können.