Eine langsame Entwicklung betrifft alle am Softwareentwicklungsprozess Beteiligten, einschließlich Kunden, Entwickler, Endbenutzer und Manager. Alle Software-Entwicklungsteams wollen dieses eine große Problem lösen – wie kann man die Entwicklungsgeschwindigkeit erhöhen und gleichzeitig die unter hohem Druck stehenden Entwicklungszeitpläne unter Kontrolle haben. In Rapid Development von Steve McConnell stellt der Autor Ideen für eine effiziente Entwicklung in den Vordergrund, indem er Strategien für eine schnelle Entwicklung untersucht und klassische Fehler im Zusammenhang mit den Grundlagen der Softwareentwicklung und dem Risikomanagement analysiert. Er schlüsselt die Kernfragen der schnellen Entwicklung, der Lebenszyklusplanung, der Schätzung und der Terminplanung auf.
WIE DIESES BUCH UNS GEHOLFEN HAT?
Rapid Development zeigte uns, wie wir die Geschwindigkeit der Softwareentwicklung erhöhen können, und beschrieb die Grenzen der Entwicklungsgeschwindigkeit, damit wir eine solide Grundlage haben, um zwischen realistischen Verbesserungsprogrammen und Wunschträumen zu unterscheiden.
DAS BUCH ERKLÄRT IN 60 SEKUNDEN
Der in diesem Buch beschriebene Weg ist der weniger befahrene Weg in der heutigen Industrie. In diesem Buch wird erörtert, wie Softwareentwicklungsteams die Geschwindigkeit der Softwareentwicklung erhöhen können, so dass Sie Software schneller liefern können. Rapid Development hebt auch Praktiken hervor, die den Fortschritt sichtbar machen, so dass Sie den Anschein einer langsamen Entwicklung zerstreuen können.
DIE DREI BESTEN ZITATE
„Wählen Sie Ihre Schlachten. Wenn eine schnelle Entwicklung oberste Priorität hat, sollten Sie Ihre Entwickler nicht fesseln, indem Sie auf zu vielen Prioritäten gleichzeitig bestehen.“
„Selbst wenn Sie ein paar Dinge richtig machen, z.B. moderne Programmierpraktiken in hohem Maße nutzen, kann es sein, dass Sie einen Fehler machen, der Ihre Produktivitätsgewinne zunichte macht.“
„Eine Studie nach der anderen hat gezeigt, dass Motivation wahrscheinlich einen größeren Einfluss auf Produktivität und Qualität hat als jeder andere Faktor.“
BUCHZUSAMMENFASSUNGEN UND HIGHLIGHTS
TEIL I: EFFIZIENTE ENTWICKLUNG
Erstes Kapitel: Willkommen bei Rapid Development
Was ist schnelle Entwicklung?
Für manche bedeutet schnelle Entwicklung die Anwendung eines einzigen Lieblingswerkzeugs oder einer einzigen Methode. Hacker bezeichnen dies als das Schreiben von Code für 36 Stunden am Stück. Für einen Informationstechniker ist RAD eine Kombination aus intensiver Einbeziehung der Benutzer, CASE-Tools und engen Zeitvorgaben. All diese Methoden und Tools sind ideal und können in vollem Umfang zu einer höheren Entwicklungsgeschwindigkeit beitragen. Laut dem Buch ist Rapid Development ein beschreibender Ausdruck, der bedeutet, dass Software schneller als mit den üblichen Methoden entwickelt wird. Ein Rapid Development-Projekt ist jedes Projekt, bei dem der Schwerpunkt auf der Entwicklungsgeschwindigkeit liegt. In der heutigen Zeit fallen viele Projekte unter diese Beschreibung.
Eine schnelle Entwicklung erreichen
Um eine schnelle Entwicklung zu erreichen, müssen Sie diese beiden Aspekte berücksichtigen: die Auswahl wirksamer Praktiken gegenüber unwirksamen Praktiken und die Auswahl zielgerichteter Techniken. Die Entwicklungsgeschwindigkeit hängt in der Regel von den festgelegten Entwicklungspraktiken ab. Wie schnell Sie ein bestimmtes Produkt entwickeln, hängt davon ab, inwieweit Sie effektive und zeitplanorientierte Techniken auswählen. Es gibt drei zeitplanorientierte Praktiken: Geschwindigkeitsorientierte Praktiken, Zeitplan-Risikoorientierte Praktiken und Sichtbarkeitsorientierte Praktiken. Ihre Bedenken bezüglich der Entwicklungsgeschwindigkeit bestimmen die Art der zeitplanorientierten Praktiken, die Sie wählen. Wenn Sie glauben, dass Sie Ihre Entwicklungsgeschwindigkeit erhöhen müssen, dann konzentrieren Sie sich auf geschwindigkeitsorientierte Praktiken. Wenn Sie davon ausgehen, dass Ihre Geschwindigkeit in Ordnung ist, aber die Wahrnehmung Ihrer Geschwindigkeit durch Ihre Kunden das Problem ist, dann richten Sie Ihre Aufmerksamkeit auf sichtbarkeitsorientierte Praktiken.
Kapitel zwei: Strategie der schnellen Entwicklung
Allgemeine Strategie für schnelle Entwicklung
Eine schnelle Entwicklung lässt sich mit einer vierteiligen Strategie erreichen. Zu den vier Teilen gehören: Vermeidung klassischer Fehler, Implementierung von Entwicklungsgrundlagen, Risikomanagement zur Vermeidung katastrophaler Rückschläge und Implementierung zeitplanorientierter Praktiken. Sorgen Sie dafür, dass alle Säulen vorhanden sind und machen Sie sie so stark wie möglich. Die ersten drei Säulen bestimmen in hohem Maße Ihr Potenzial, den besten Zeitplan zu erreichen. Die ersten drei Säulen bieten die notwendige Unterstützung für den bestmöglichen Zeitplan. Vielleicht nicht die ideale Unterstützung, aber das meiste, was erforderlich ist. Möglicherweise können Sie einen optimalen Zeitplan auch ohne zeitplanorientierte Praktiken erreichen.
Vier Dimensionen der Entwicklungsgeschwindigkeit
Ganz gleich, ob Sie langsam arbeiten, um Fehler zu vermeiden, oder sich mit den besten zeitplanorientierten Verfahren mit hoher Geschwindigkeit bewegen. Ihr Softwareprojekt funktioniert mit Hilfe von vier wesentlichen Dimensionen: Prozess, Menschen, Produkt und Technologie. Erstens haben die Menschen den größten Einfluss auf die Softwareentwicklung, Produktivität und Qualität als jeder andere Faktor. Es liegt auf der Hand, dass jedes Unternehmen, das seine Produktivität verbessern möchte, sich zuerst mit dem Thema Peopleware befassen muss. Zweitens umfasst der Prozess der Softwareentwicklung sowohl technische als auch Management-Methoden. Die Konzentration auf Prozesse erhöht die Qualitätssicherung, hilft beim Risikomanagement und ermöglicht es Ihnen, Nacharbeit zu vermeiden. Produkt: Dies ist die am meisten greifbare Dimension. Wenn Sie sich auf die Größe und die Eigenschaften des Produkts konzentrieren, können Sie den Zeitplan enorm verkürzen. Wenn Sie den Funktionsumfang eines Produkts reduzieren können, können Sie auch den Zeitplan für das Produkt verkürzen. Und schließlich die Technologie: Wenn Sie Ihre technischen Hilfsmittel wechseln, besteht die Chance, dass Sie Ihre Entwicklungsgeschwindigkeit erhöhen. Sie können von weniger effektiven Mitteln zu produktiveren Tools wechseln.
Kapitel drei: Welche Dimension ist am wichtigsten?
Analysieren Sie Ihr Projekt, um festzustellen, welche der vier Dimensionen begrenzt sind und welche Sie maximal ausnutzen können. Schöpfen Sie dann jede Dimension bis zum Äußersten aus. Das ist, kurz gesagt, der Schlüssel zu einer erfolgreichen schnellen Entwicklung.
Mein Lieblingszitat aus diesem Teil: „Die erste Schlussfolgerung ist, dass wir jetzt mit Sicherheit wissen, dass Peopleware-Probleme mehr Einfluss auf die Produktivität und Qualität von Software haben als jeder andere Faktor.“
TEIL II: SCHNELLE ENTWICKLUNG
Kapitel eins: Passt eine Größe allen
Verschiedene Projekte haben unterschiedliche Anforderungen an die schnelle Entwicklung, auch wenn sie alle „so schnell wie möglich“ entwickelt werden müssen. Im Allgemeinen müssen Produkte, die weit verbreitet sind, sorgfältiger entwickelt werden als Produkte, die nur wenig verbreitet sind. Produkte, deren Zuverlässigkeit entscheidend ist, müssen sorgfältiger entwickelt werden als Produkte, deren Zuverlässigkeit zweitrangig ist. Das bedeutet, dass Sie eine Lösung maßschneidern müssen, die zu Ihrer Situation passt.
Welche Art von schneller Entwicklung benötigen Sie?
Bei der schnellen Entwicklung geht es vor allem darum, herauszufinden, welche Art von schnellem Entwicklungsansatz Sie wünschen. Ist es ein leichter Geschwindigkeitsvorteil, eine bessere Sichtbarkeit des Fortschritts, niedrigere Kosten oder mehr Vorhersehbarkeit? Viele Menschen glauben, sie bräuchten eine schnelle Entwicklung, aber in Wirklichkeit brauchen sie niedrigere Preise und mehr Vorhersehbarkeit oder einen Ansatz, der ein tragisches Scheitern verhindert. Um festzustellen, welche Art von Rapid Development Sie brauchen, stellen Sie sich diese Fragen;
- Wie stark ist die Zeitvorgabe für das Produkt?
- Liegt der Schwerpunkt des Projekts auf dem Zeitplan, weil es sich um ein ähnliches Projekt wie Rapid Development handelt?
- Ist das Projekt durch Schwachstellen eingeschränkt, die einen schnellen Entwicklungserfolg verhindern?
Produkte, bei denen es mehr auf die Entwicklungsgeschwindigkeit als auf Kosten oder Vorhersagbarkeit ankommt, haben einen anderen Zeitwert als typische Produkte. Im Laufe der Zeit nimmt der Wert bestimmter Produkte in der Regel allmählich ab. Bei Produkten mit festen Zeitvorgaben gibt es jedoch einen Punkt, an dem der Wert sprunghaft sinkt.
Bevor Sie Ihr Projekt auf den kürzesten Zeitplan und nicht auf die geringsten Kosten, das geringste Risiko oder die beste Leistung ausrichten, sollten Sie herausfinden, was benötigt wird. Rapid-Development-ähnliche Projekte verlangen nach einem hohen Entwicklungstempo, aber sie verlangen nach etwas anderem.
Kapitel zwei: Lebenszyklus-Planung
Ein Lebenszyklusmodell ist ein präskriptives Modell dessen, was zwischen dem ersten Schimmer und dem letzten Atemzug passiert. Jede Softwareentwicklung durchläuft einen Lebenszyklus, der alle Aktivitäten zwischen dem Anfang und dem Ende umfasst. Das bekannteste Lebenszyklusmodell ist das bekannte Wasserfallmodell, das einige
ebenso bemerkenswerte Schwächen. Es gibt andere Lebenszyklusmodelle, und in vielen Fällen sind sie für eine schnelle Entwicklung besser geeignet als das Wasserfallmodell.
Reiner Wasserfall
Das Wasserfallmodell ist die Grundlage für andere effektive Lebenszyklusmodelle, da es mit vielen Problemen verbunden ist. Beim Wasserfallmodell schreitet ein Projekt in einer geordneten Abfolge von Schritten vom ersten Softwarekonzept bis zum Systemtest voran. Am Ende jeder Phase wird das Projekt überprüft, um festzustellen, ob es in der Lage ist, zum nächsten Schritt überzugehen – von der Anforderungsanalyse bis zum Architekturentwurf. Wenn die Überprüfung ergibt, dass das Projekt nicht bereit ist, in die nächste Phase überzugehen, verbleibt es in der aktuellen Phase, bis es bereit ist.
Code-and-Fix
Das Code-und-Fix-Modell ist Standard, könnte aber hilfreicher sein. Wenn Sie kein anderes Lebenszyklusmodell ausgewählt haben, müssen Sie standardmäßig Code-and-Fix verwenden. Die Verwendung des Code-and-Fix-Modells bedeutet, dass Sie mit einer allgemeinen Vorstellung davon beginnen, was Sie erstellen möchten. Sie können eine formale Spezifikation haben oder auch nicht. Dann verwenden Sie eine beliebige Kombination von informellen Design-, Code-, Debugging- und Testmethoden, bis Sie ein releasefähiges Produkt haben. Bei diesem Modell gibt es keinen Overhead, d.h. Sie verbringen außer mit der Programmierung keine Zeit mit Planung, Qualitätssicherung oder Dokumentation. Es erfordert auch wenig Fachwissen. Jeder, der mit Computerprogrammen vertraut ist, kann das Code-and-Fix-Modell anwenden.
Spirale
Dieses Modell unterteilt ein Softwareprojekt in Miniprojekte und ist stark risikoorientiert. Jedes Miniprojekt befasst sich mit bedeutenden Risiken, bis es keine Risiken mehr zu bewältigen gibt. Risiken sind in diesem Zusammenhang inkompetente Anforderungen, Leistungsprobleme, eine schlecht verstandene Architektur und vieles mehr. Sobald die Risiken bewältigt sind, wird das Spiralmodell wie das Wasserfallmodell beendet. Beim Spiralmodell beginnen Sie in einem kleinen Maßstab in der Mitte der Wirbelsäule, identifizieren und prüfen alle Risiken, formulieren einen Plan zur Kontrolle der Risiken und legen sich schließlich auf einen Ansatz für die nächste Iteration fest. Das Spiralmodell bietet mindestens so viel Managementkontrolle wie das traditionelle Wasserfallmodell. Sie haben die Kontrollpunkte am Ende jeder Iteration. Da das Modell risikoorientiert ist, liefert es frühzeitig Hinweise auf unüberwindbare Risiken.
Kapitel drei: Schätzung
Die Schätzung von Software ist ziemlich komplex. Das obere und untere Management, Kunden und einige Entwickler verstehen nicht, warum die Schätzung so schwierig ist. Die grundlegende Geschichte der Software-Schätzung ist, dass die Software-Entwicklung ein Prozess der schrittweisen Verfeinerung ist. Sie beginnen mit einem unscharfen Bild von dem, was Sie entwickeln wollen, und verbringen dann den Rest des Projekts damit, dieses Bild zu klären. Da das Bild der Software, die Sie entwickeln wollen, unscharf ist, ist auch die Schätzung des Zeit- und Arbeitsaufwands für die Entwicklung unklar. Die Vorhersage kann erst zusammen mit der Software selbst in den Fokus rücken, was bedeutet, dass auch die Schätzung von Softwareprojekten ein Prozess der schrittweisen Verfeinerung ist.
Kapitel vier: Terminplanung
Übermäßig optimistische Terminplanung
Übermäßig optimistische Zeitpläne sind eine verblasste Tradition in der Softwareentwicklung. Alle wesentlichen Programmierungsfragen sind Notfälle, und viele Softwareprojekte brauchen mehr Zeit im Kalender. Übermäßiger Termindruck ist der destruktivste Einfluss in der Softwareentwicklung. Die meisten Projekte legen ihre Zeitpläne fest, bevor die Anforderungen feststehen, und legen sie nicht fest, ohne Zeit zu gewinnen. Die Ursachen für zu optimistische Zeitpläne sind tiefgreifend und umfassen u.a.: Manager oder Kunden weigern sich, eine Bandbreite von Schätzungen zu akzeptieren und machen
Pläne, die auf einer einzigen „Best-Case“-Schätzung basieren. Manager und Entwickler unterschätzen das Projekt absichtlich, weil sie eine Herausforderung suchen oder gerne unter Druck arbeiten. Das Projekt wird von der Geschäftsleitung oder dem Vertrieb absichtlich unterschätzt, um ein günstiges Angebot abgeben zu können.
Termindruck besiegen
Der Termindruck ist in der Softwareentwicklung endemisch und hat ein negatives kurzfristiges Denken hervorgerufen. Erstens hat er dazu geführt, dass bei bestimmten Projekten Abkürzungen genommen wurden, was zu einer schlechten Lieferung führte. Zweitens hat er zu einer Feuerlöschmentalität in Bezug auf den Termindruck selbst geführt. Wir können das Problem der schnellen Entwicklung nicht lösen, bevor wir nicht das Problem des Termindrucks gelöst haben.
Lieblingszitat des Kapitels: „Jede Softwareentwicklung durchläuft einen „Lebenszyklus“, der aus allen Aktivitäten besteht, die zwischen dem Zeitpunkt, an dem Version 1.0 eines Systems wie ein Schimmer in den Augen eines Menschen beginnt, und dem Zeitpunkt, an dem Version 6.74b schließlich auf dem Rechner des letzten Kunden ihren letzten Atemzug tut, liegen.“
TEIL DREI: BESTE PRAKTIKEN
Kapitel eins: Change Board
Dieser Ansatz kontrolliert die Änderungen an einem Softwareprojekt. In einem Änderungsausschuss sind Vertreter der Entwicklung, der Benutzerdokumentation, der Qualitätssicherung, des Kundensupports, des Managements und des Marketings vertreten, die über die Annahme oder Ablehnung von Änderungsvorschlägen entscheiden können. Dieser Ansatz trägt zu einer schnellen Entwicklung bei, indem er die Anzahl der unkontrollierten Änderungen am Produkt minimiert und die Sichtbarkeit der schleichenden Entwicklung von Funktionen erhöht. Change Boards können in jeder Art von Umgebung zum Einsatz kommen.
Kapitel zwei: Täglicher Build und Smoke-Test
Im Rahmen des Daily Build and Smoke Test-Prozesses wird ein Softwareprodukt jeden Tag erstellt und mehrmals getestet, um seine primären Funktionen zu überprüfen. Dieser Prozess kann eingeleitet werden, während das Projekt bereits begonnen hat. Dieser Prozess minimiert überfällige Risiken, eine schlechte Sichtbarkeit des Fortschritts und eine fehlgeschlagene Integration. Der Prozess bietet eine kritische Kontrolle für Projekte im Recovery-Modus. Sein Erfolg hängt davon ab, dass die Entwickler den Ansatz ernst nehmen und dass die Smoke-Tests gut konzipiert sind. Der Daily Build and Smoke Test kann bei Projekten praktisch jeder Größe und Komplexität effektiv eingesetzt werden. Die Idee hinter dem täglichen Build- und Smoke-Test-Prozess ist einfach: Bauen Sie das Produkt und testen Sie es täglich.
Kapitel drei: Für den Wandel entwerfen
Designing for Change ist eine umfassende Implementierung, die viele veränderungsorientierte Designpraktiken umfasst. Damit diese Praktiken wirksam sind, müssen sie bereits in den frühen Phasen des Software-Lebenszyklus umgesetzt werden. Der Erfolg dieses Ansatzes hängt von der Identifizierung geeigneter Änderungen, der Entwicklung eines Änderungsplans und dem Verbergen von Designentscheidungen ab, damit sich die Änderungen nicht auf das Programm auswirken. Einige der änderungsorientierten Designpraktiken sind komplexer, als man annimmt. Wenn diese Praktiken richtig umgesetzt werden, legen sie den Grundstein für langlebige Programme und eine Flexibilität, die die Auswirkungen von späten Änderungswünschen auf den Zeitplan minimiert. Designing for Change“ bezieht sich nicht auf eine einzelne Designmethode, sondern auf eine ganze Reihe von Designpraktiken, die zu flexiblen Softwaredesigns beitragen.
Kapitel vier: Evolutionäre Lieferung
Evolutionary Delivery ist ein Lebenszyklusmodell, das ein Gleichgewicht zwischen der Kontrolle von Staged Delivery und der Flexibilität von Evolutionary Prototyping herstellt. Es bietet den Vorteil der schnellen Entwicklung, indem es ausgewählte Teile der Software früher als möglich ausliefert, aber es liefert das Endprodukt nicht unbedingt schneller. Sie bietet eine gewisse Möglichkeit, die Richtung des Produkts in der Mitte des Kurses zu ändern, um auf Kundenwünsche zu reagieren. Evolutionary Delivery wurde bereits erfolgreich bei firmeninterner Unternehmenssoftware und Shrink-Wrap-Software eingesetzt. Mit Bedacht eingesetzt, kann es zu einer besseren Produktqualität, einer geringeren Codegröße und einer gleichmäßigeren Verteilung der Entwicklungs- und Testressourcen führen. Wie bei anderen Lebenszyklusmodellen ist Evolutionary Delivery eine Praxis für das gesamte Projekt: Wenn Sie es einsetzen möchten, müssen Sie schon früh im Projekt damit beginnen, es zu planen.
Lieblingszitat des Kapitels: „Zu viele Überstunden und Termindruck können einer Entwicklung schaden
Aber ein paar Überstunden können das wöchentliche Arbeitspensum erhöhen und die Motivation steigern.“
WIE DIESES BUCH SOFTWAREENTWICKLERN HELFEN KANN
„Rapid Development“ von Steve McConnell ist ein umfassender Leitfaden für Softwareentwickler, der praktische Ratschläge und Techniken zur Steigerung der Geschwindigkeit und Effizienz des Softwareentwicklungsprozesses bietet. Das Buch behandelt verschiedene Themen wie Projektplanung, Anforderungserfassung, Design, Codierung, Testen und Projektmanagement. Das Buch behandelt auch bewährte Verfahren und Strategien für das Risikomanagement, die Reduzierung von Fehlern, die Verbesserung der Kommunikation und die Steigerung der Gesamtqualität von Softwareentwicklungsprojekten. McConnell schöpft aus seiner umfangreichen Erfahrung in diesem Bereich und veranschaulicht seine Ausführungen mit zahlreichen Beispielen aus der Praxis. Insgesamt ist „Rapid Development“ eine wertvolle Ressource für Entwickler, die ihre Produktivität und die Qualität ihrer Arbeit verbessern wollen. Das Buch bietet praktische, umsetzbare Ratschläge, die Entwicklern aller Ebenen helfen, effektiver und effizienter zu werden.
