Rapid Development zeigte uns, wie wir die Geschwindigkeit der Softwareentwicklung erh\u00f6hen k\u00f6nnen, und beschrieb die Grenzen der Entwicklungsgeschwindigkeit, damit wir eine solide Grundlage haben, um zwischen realistischen Verbesserungsprogrammen und Wunschtr\u00e4umen zu unterscheiden.<\/p>\n\n
DAS BUCH ERKL\u00c4RT IN 60 SEKUNDEN<\/strong><\/p>\n\n Der in diesem Buch beschriebene Weg ist der weniger befahrene Weg in der heutigen Industrie. In diesem Buch wird er\u00f6rtert, wie Softwareentwicklungsteams die Geschwindigkeit der Softwareentwicklung erh\u00f6hen k\u00f6nnen, so dass Sie Software schneller liefern k\u00f6nnen. Rapid Development hebt auch Praktiken hervor, die den Fortschritt sichtbar machen, so dass Sie den Anschein einer langsamen Entwicklung zerstreuen k\u00f6nnen. <\/p>\n\n DIE DREI BESTEN ZITATE<\/strong><\/p>\n\n „W\u00e4hlen Sie Ihre Schlachten. Wenn eine schnelle Entwicklung oberste Priorit\u00e4t hat, sollten Sie Ihre Entwickler nicht fesseln, indem Sie auf zu vielen Priorit\u00e4ten gleichzeitig bestehen.“<\/p>\n\n „Selbst wenn Sie ein paar Dinge richtig machen, z.B. moderne Programmierpraktiken in hohem Ma\u00dfe nutzen, kann es sein, dass Sie einen Fehler machen, der Ihre Produktivit\u00e4tsgewinne zunichte macht.“<\/p>\n\n „Eine Studie nach der anderen hat gezeigt, dass Motivation wahrscheinlich einen gr\u00f6\u00dferen Einfluss auf Produktivit\u00e4t und Qualit\u00e4t hat als jeder andere Faktor.“<\/p>\n\n BUCHZUSAMMENFASSUNGEN UND HIGHLIGHTS<\/strong><\/p>\n\n TEIL I: EFFIZIENTE ENTWICKLUNG<\/strong><\/p>\n\n Erstes Kapitel: Willkommen bei Rapid Development<\/strong><\/p>\n\n Was ist schnelle Entwicklung?<\/strong><\/p>\n\n F\u00fcr manche bedeutet schnelle Entwicklung die Anwendung eines einzigen Lieblingswerkzeugs oder einer einzigen Methode. Hacker bezeichnen dies als das Schreiben von Code f\u00fcr 36 Stunden am St\u00fcck. F\u00fcr 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\u00f6nnen in vollem Umfang zu einer h\u00f6heren Entwicklungsgeschwindigkeit beitragen. Laut dem Buch ist Rapid Development ein beschreibender Ausdruck, der bedeutet, dass Software schneller als mit den \u00fcblichen 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. <\/p>\n\n Eine schnelle Entwicklung erreichen<\/strong><\/p>\n\n Um eine schnelle Entwicklung zu erreichen, m\u00fcssen Sie diese beiden Aspekte ber\u00fccksichtigen: die Auswahl wirksamer Praktiken gegen\u00fcber unwirksamen Praktiken und die Auswahl zielgerichteter Techniken. Die Entwicklungsgeschwindigkeit h\u00e4ngt in der Regel von den festgelegten Entwicklungspraktiken ab. Wie schnell Sie ein bestimmtes Produkt entwickeln, h\u00e4ngt davon ab, inwieweit Sie effektive und zeitplanorientierte Techniken ausw\u00e4hlen. Es gibt drei zeitplanorientierte Praktiken: Geschwindigkeitsorientierte Praktiken, Zeitplan-Risikoorientierte Praktiken und Sichtbarkeitsorientierte Praktiken. Ihre Bedenken bez\u00fcglich der Entwicklungsgeschwindigkeit bestimmen die Art der zeitplanorientierten Praktiken, die Sie w\u00e4hlen. Wenn Sie glauben, dass Sie Ihre Entwicklungsgeschwindigkeit erh\u00f6hen m\u00fcssen, 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. <\/p>\n\n Kapitel zwei: Strategie der schnellen Entwicklung<\/strong><\/p>\n\n Allgemeine Strategie f\u00fcr schnelle Entwicklung<\/strong><\/p>\n\n Eine schnelle Entwicklung l\u00e4sst sich mit einer vierteiligen Strategie erreichen. Zu den vier Teilen geh\u00f6ren: Vermeidung klassischer Fehler, Implementierung von Entwicklungsgrundlagen, Risikomanagement zur Vermeidung katastrophaler R\u00fcckschl\u00e4ge und Implementierung zeitplanorientierter Praktiken. Sorgen Sie daf\u00fcr, dass alle S\u00e4ulen vorhanden sind und machen Sie sie so stark wie m\u00f6glich. Die ersten drei S\u00e4ulen bestimmen in hohem Ma\u00dfe Ihr Potenzial, den besten Zeitplan zu erreichen. Die ersten drei S\u00e4ulen bieten die notwendige Unterst\u00fctzung f\u00fcr den bestm\u00f6glichen Zeitplan. Vielleicht nicht die ideale Unterst\u00fctzung, aber das meiste, was erforderlich ist. M\u00f6glicherweise k\u00f6nnen Sie einen optimalen Zeitplan auch ohne zeitplanorientierte Praktiken erreichen. <\/p>\n\n Vier Dimensionen der Entwicklungsgeschwindigkeit<\/strong><\/p>\n\n 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\u00f6\u00dften Einfluss auf die Softwareentwicklung, Produktivit\u00e4t und Qualit\u00e4t als jeder andere Faktor. Es liegt auf der Hand, dass jedes Unternehmen, das seine Produktivit\u00e4t verbessern m\u00f6chte, 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\u00f6ht die Qualit\u00e4tssicherung, hilft beim Risikomanagement und erm\u00f6glicht es Ihnen, Nacharbeit zu vermeiden. Produkt: Dies ist die am meisten greifbare Dimension. Wenn Sie sich auf die Gr\u00f6\u00dfe und die Eigenschaften des Produkts konzentrieren, k\u00f6nnen Sie den Zeitplan enorm verk\u00fcrzen. Wenn Sie den Funktionsumfang eines Produkts reduzieren k\u00f6nnen, k\u00f6nnen Sie auch den Zeitplan f\u00fcr das Produkt verk\u00fcrzen. Und schlie\u00dflich die Technologie: Wenn Sie Ihre technischen Hilfsmittel wechseln, besteht die Chance, dass Sie Ihre Entwicklungsgeschwindigkeit erh\u00f6hen. Sie k\u00f6nnen von weniger effektiven Mitteln zu produktiveren Tools wechseln. <\/p>\n\n Kapitel drei: Welche Dimension ist am wichtigsten?<\/strong><\/p>\n\n Analysieren Sie Ihr Projekt, um festzustellen, welche der vier Dimensionen begrenzt sind und welche Sie maximal ausnutzen k\u00f6nnen. Sch\u00f6pfen Sie dann jede Dimension bis zum \u00c4u\u00dfersten aus. Das ist, kurz gesagt, der Schl\u00fcssel zu einer erfolgreichen schnellen Entwicklung. <\/p>\n\n Mein Lieblingszitat aus diesem Teil: „Die erste Schlussfolgerung ist, dass wir jetzt mit Sicherheit wissen, dass Peopleware-Probleme mehr Einfluss auf die Produktivit\u00e4t und Qualit\u00e4t von Software haben als jeder andere Faktor.“<\/em><\/strong><\/p>\n\n TEIL II: SCHNELLE ENTWICKLUNG<\/strong><\/p>\n\n Kapitel eins: Passt eine Gr\u00f6\u00dfe allen<\/strong><\/p>\n\n Verschiedene Projekte haben unterschiedliche Anforderungen an die schnelle Entwicklung, auch wenn sie alle „so schnell wie m\u00f6glich“ entwickelt werden m\u00fcssen. Im Allgemeinen m\u00fcssen Produkte, die weit verbreitet sind, sorgf\u00e4ltiger entwickelt werden als Produkte, die nur wenig verbreitet sind. Produkte, deren Zuverl\u00e4ssigkeit entscheidend ist, m\u00fcssen sorgf\u00e4ltiger entwickelt werden als Produkte, deren Zuverl\u00e4ssigkeit zweitrangig ist. Das bedeutet, dass Sie eine L\u00f6sung ma\u00dfschneidern m\u00fcssen, die zu Ihrer Situation passt. <\/p>\n\n Welche Art von schneller Entwicklung ben\u00f6tigen Sie?<\/strong><\/p>\n\n Bei der schnellen Entwicklung geht es vor allem darum, herauszufinden, welche Art von schnellem Entwicklungsansatz Sie w\u00fcnschen. Ist es ein leichter Geschwindigkeitsvorteil, eine bessere Sichtbarkeit des Fortschritts, niedrigere Kosten oder mehr Vorhersehbarkeit? Viele Menschen glauben, sie br\u00e4uchten 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; <\/p>\n\n 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\u00e4hlich ab. Bei Produkten mit festen Zeitvorgaben gibt es jedoch einen Punkt, an dem der Wert sprunghaft sinkt. <\/p>\n\n Bevor Sie Ihr Projekt auf den k\u00fcrzesten Zeitplan und nicht auf die geringsten Kosten, das geringste Risiko oder die beste Leistung ausrichten, sollten Sie herausfinden, was ben\u00f6tigt wird. Rapid-Development-\u00e4hnliche Projekte verlangen nach einem hohen Entwicklungstempo, aber sie verlangen nach etwas anderem. <\/p>\n\n Kapitel zwei: Lebenszyklus-Planung<\/strong><\/p>\n\n Ein Lebenszyklusmodell ist ein pr\u00e4skriptives Modell dessen, was zwischen dem ersten Schimmer und dem letzten Atemzug passiert. Jede Softwareentwicklung durchl\u00e4uft einen Lebenszyklus, der alle Aktivit\u00e4ten zwischen dem Anfang und dem Ende umfasst. Das bekannteste Lebenszyklusmodell ist das bekannte Wasserfallmodell, das einige <\/p>\n\n ebenso bemerkenswerte Schw\u00e4chen. Es gibt andere Lebenszyklusmodelle, und in vielen F\u00e4llen sind sie f\u00fcr eine schnelle Entwicklung besser geeignet als das Wasserfallmodell. <\/p>\n\n Reiner Wasserfall<\/strong><\/p>\n\n Das Wasserfallmodell ist die Grundlage f\u00fcr 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 \u00fcberpr\u00fcft, um festzustellen, ob es in der Lage ist, zum n\u00e4chsten Schritt \u00fcberzugehen – von der Anforderungsanalyse bis zum Architekturentwurf. Wenn die \u00dcberpr\u00fcfung ergibt, dass das Projekt nicht bereit ist, in die n\u00e4chste Phase \u00fcberzugehen, verbleibt es in der aktuellen Phase, bis es bereit ist. <\/p>\n\n Code-and-Fix<\/strong><\/p>\n\n Das Code-und-Fix-Modell ist Standard, k\u00f6nnte aber hilfreicher sein. Wenn Sie kein anderes Lebenszyklusmodell ausgew\u00e4hlt haben, m\u00fcssen Sie standardm\u00e4\u00dfig Code-and-Fix verwenden. Die Verwendung des Code-and-Fix-Modells bedeutet, dass Sie mit einer allgemeinen Vorstellung davon beginnen, was Sie erstellen m\u00f6chten. Sie k\u00f6nnen eine formale Spezifikation haben oder auch nicht. Dann verwenden Sie eine beliebige Kombination von informellen Design-, Code-, Debugging- und Testmethoden, bis Sie ein releasef\u00e4higes Produkt haben. Bei diesem Modell gibt es keinen Overhead, d.h. Sie verbringen au\u00dfer mit der Programmierung keine Zeit mit Planung, Qualit\u00e4tssicherung oder Dokumentation. Es erfordert auch wenig Fachwissen. Jeder, der mit Computerprogrammen vertraut ist, kann das Code-and-Fix-Modell anwenden. <\/p>\n\n Spirale<\/strong><\/p>\n\n 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\u00e4ltigen gibt. Risiken sind in diesem Zusammenhang inkompetente Anforderungen, Leistungsprobleme, eine schlecht verstandene Architektur und vieles mehr. Sobald die Risiken bew\u00e4ltigt sind, wird das Spiralmodell wie das Wasserfallmodell beendet. Beim Spiralmodell beginnen Sie in einem kleinen Ma\u00dfstab in der Mitte der Wirbels\u00e4ule, identifizieren und pr\u00fcfen alle Risiken, formulieren einen Plan zur Kontrolle der Risiken und legen sich schlie\u00dflich auf einen Ansatz f\u00fcr die n\u00e4chste 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\u00fchzeitig Hinweise auf un\u00fcberwindbare Risiken. <\/p>\n\n Kapitel drei: Sch\u00e4tzung<\/strong><\/p>\n\n Die Sch\u00e4tzung von Software ist ziemlich komplex. Das obere und untere Management, Kunden und einige Entwickler verstehen nicht, warum die Sch\u00e4tzung so schwierig ist. Die grundlegende Geschichte der Software-Sch\u00e4tzung 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\u00e4ren. Da das Bild der Software, die Sie entwickeln wollen, unscharf ist, ist auch die Sch\u00e4tzung des Zeit- und Arbeitsaufwands f\u00fcr die Entwicklung unklar. Die Vorhersage kann erst zusammen mit der Software selbst in den Fokus r\u00fccken, was bedeutet, dass auch die Sch\u00e4tzung von Softwareprojekten ein Prozess der schrittweisen Verfeinerung ist. <\/p>\n\n Kapitel vier: Terminplanung<\/strong><\/p>\n\n \u00dcberm\u00e4\u00dfig optimistische Terminplanung<\/strong><\/p>\n\n \u00dcberm\u00e4\u00dfig optimistische Zeitpl\u00e4ne sind eine verblasste Tradition in der Softwareentwicklung. Alle wesentlichen Programmierungsfragen sind Notf\u00e4lle, und viele Softwareprojekte brauchen mehr Zeit im Kalender. \u00dcberm\u00e4\u00dfiger Termindruck ist der destruktivste Einfluss in der Softwareentwicklung. Die meisten Projekte legen ihre Zeitpl\u00e4ne fest, bevor die Anforderungen feststehen, und legen sie nicht fest, ohne Zeit zu gewinnen. Die Ursachen f\u00fcr zu optimistische Zeitpl\u00e4ne sind tiefgreifend und umfassen u.a.: Manager oder Kunden weigern sich, eine Bandbreite von Sch\u00e4tzungen zu akzeptieren und machen <\/p>\n\n Pl\u00e4ne, die auf einer einzigen „Best-Case“-Sch\u00e4tzung basieren. Manager und Entwickler untersch\u00e4tzen das Projekt absichtlich, weil sie eine Herausforderung suchen oder gerne unter Druck arbeiten. Das Projekt wird von der Gesch\u00e4ftsleitung oder dem Vertrieb absichtlich untersch\u00e4tzt, um ein g\u00fcnstiges Angebot abgeben zu k\u00f6nnen. <\/p>\n\n Termindruck besiegen<\/strong><\/p>\n\n Der Termindruck ist in der Softwareentwicklung endemisch und hat ein negatives kurzfristiges Denken hervorgerufen. Erstens hat er dazu gef\u00fchrt, dass bei bestimmten Projekten Abk\u00fcrzungen genommen wurden, was zu einer schlechten Lieferung f\u00fchrte. Zweitens hat er zu einer Feuerl\u00f6schmentalit\u00e4t in Bezug auf den Termindruck selbst gef\u00fchrt. Wir k\u00f6nnen das Problem der schnellen Entwicklung nicht l\u00f6sen, bevor wir nicht das Problem des Termindrucks gel\u00f6st haben. <\/p>\n\n Lieblingszitat des Kapitels: „Jede Softwareentwicklung durchl\u00e4uft einen „Lebenszyklus“, der aus allen Aktivit\u00e4ten 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\u00dflich auf dem Rechner des letzten Kunden ihren letzten Atemzug tut, liegen.“<\/em><\/strong><\/p>\n\n TEIL DREI: BESTE PRAKTIKEN<\/strong><\/p>\n\n Kapitel eins: Change Board<\/strong><\/p>\n\n Dieser Ansatz kontrolliert die \u00c4nderungen an einem Softwareprojekt. In einem \u00c4nderungsausschuss sind Vertreter der Entwicklung, der Benutzerdokumentation, der Qualit\u00e4tssicherung, des Kundensupports, des Managements und des Marketings vertreten, die \u00fcber die Annahme oder Ablehnung von \u00c4nderungsvorschl\u00e4gen entscheiden k\u00f6nnen. Dieser Ansatz tr\u00e4gt zu einer schnellen Entwicklung bei, indem er die Anzahl der unkontrollierten \u00c4nderungen am Produkt minimiert und die Sichtbarkeit der schleichenden Entwicklung von Funktionen erh\u00f6ht. Change Boards k\u00f6nnen in jeder Art von Umgebung zum Einsatz kommen. <\/p>\n\n Kapitel zwei: T\u00e4glicher Build und Smoke-Test<\/strong><\/p>\n\n Im Rahmen des Daily Build and Smoke Test-Prozesses wird ein Softwareprodukt jeden Tag erstellt und mehrmals getestet, um seine prim\u00e4ren Funktionen zu \u00fcberpr\u00fcfen. Dieser Prozess kann eingeleitet werden, w\u00e4hrend das Projekt bereits begonnen hat. Dieser Prozess minimiert \u00fcberf\u00e4llige Risiken, eine schlechte Sichtbarkeit des Fortschritts und eine fehlgeschlagene Integration. Der Prozess bietet eine kritische Kontrolle f\u00fcr Projekte im Recovery-Modus. Sein Erfolg h\u00e4ngt 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\u00f6\u00dfe und Komplexit\u00e4t effektiv eingesetzt werden. Die Idee hinter dem t\u00e4glichen Build- und Smoke-Test-Prozess ist einfach: Bauen Sie das Produkt und testen Sie es t\u00e4glich. <\/p>\n\n Kapitel drei: F\u00fcr den Wandel entwerfen<\/strong><\/p>\n\n Designing for Change ist eine umfassende Implementierung, die viele ver\u00e4nderungsorientierte Designpraktiken umfasst. Damit diese Praktiken wirksam sind, m\u00fcssen sie bereits in den fr\u00fchen Phasen des Software-Lebenszyklus umgesetzt werden. Der Erfolg dieses Ansatzes h\u00e4ngt von der Identifizierung geeigneter \u00c4nderungen, der Entwicklung eines \u00c4nderungsplans und dem Verbergen von Designentscheidungen ab, damit sich die \u00c4nderungen nicht auf das Programm auswirken. Einige der \u00e4nderungsorientierten Designpraktiken sind komplexer, als man annimmt. Wenn diese Praktiken richtig umgesetzt werden, legen sie den Grundstein f\u00fcr langlebige Programme und eine Flexibilit\u00e4t, die die Auswirkungen von sp\u00e4ten \u00c4nderungsw\u00fcnschen 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. <\/p>\n\n Kapitel vier: Evolution\u00e4re Lieferung<\/strong><\/p>\n\n Evolutionary Delivery ist ein Lebenszyklusmodell, das ein Gleichgewicht zwischen der Kontrolle von Staged Delivery und der Flexibilit\u00e4t von Evolutionary Prototyping herstellt. Es bietet den Vorteil der schnellen Entwicklung, indem es ausgew\u00e4hlte Teile der Software fr\u00fcher als m\u00f6glich ausliefert, aber es liefert das Endprodukt nicht unbedingt schneller. Sie bietet eine gewisse M\u00f6glichkeit, die Richtung des Produkts in der Mitte des Kurses zu \u00e4ndern, um auf Kundenw\u00fcnsche zu reagieren. Evolutionary Delivery wurde bereits erfolgreich bei firmeninterner Unternehmenssoftware und Shrink-Wrap-Software eingesetzt. Mit Bedacht eingesetzt, kann es zu einer besseren Produktqualit\u00e4t, einer geringeren Codegr\u00f6\u00dfe und einer gleichm\u00e4\u00dfigeren Verteilung der Entwicklungs- und Testressourcen f\u00fchren. Wie bei anderen Lebenszyklusmodellen ist Evolutionary Delivery eine Praxis f\u00fcr das gesamte Projekt: Wenn Sie es einsetzen m\u00f6chten, m\u00fcssen Sie schon fr\u00fch im Projekt damit beginnen, es zu planen. <\/p>\n\n Lieblingszitat des Kapitels: „Zu viele \u00dcberstunden und Termindruck k\u00f6nnen einer Entwicklung schaden<\/em><\/strong><\/p>\n\n Aber ein paar \u00dcberstunden k\u00f6nnen das w\u00f6chentliche Arbeitspensum erh\u00f6hen und die Motivation steigern.“<\/em><\/strong><\/p>\n\n WIE DIESES BUCH SOFTWAREENTWICKLERN HELFEN KANN<\/strong><\/p>\n\n „Rapid Development“ von Steve McConnell ist ein umfassender Leitfaden f\u00fcr Softwareentwickler, der praktische Ratschl\u00e4ge 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\u00e4hrte Verfahren und Strategien f\u00fcr das Risikomanagement, die Reduzierung von Fehlern, die Verbesserung der Kommunikation und die Steigerung der Gesamtqualit\u00e4t von Softwareentwicklungsprojekten. McConnell sch\u00f6pft aus seiner umfangreichen Erfahrung in diesem Bereich und veranschaulicht seine Ausf\u00fchrungen mit zahlreichen Beispielen aus der Praxis. Insgesamt ist „Rapid Development“ eine wertvolle Ressource f\u00fcr Entwickler, die ihre Produktivit\u00e4t und die Qualit\u00e4t ihrer Arbeit verbessern wollen. Das Buch bietet praktische, umsetzbare Ratschl\u00e4ge, die Entwicklern aller Ebenen helfen, effektiver und effizienter zu werden. <\/p>\n","protected":false},"excerpt":{"rendered":" Eine langsame Entwicklung betrifft alle am Softwareentwicklungsprozess Beteiligten, einschlie\u00dflich Kunden, Entwickler, Endbenutzer und Manager. Alle Software-Entwicklungsteams wollen dieses eine gro\u00dfe Problem l\u00f6sen – wie kann man die Entwicklungsgeschwindigkeit erh\u00f6hen und gleichzeitig die unter hohem Druck stehenden Entwicklungszeitpl\u00e4ne unter Kontrolle haben. In Rapid Development von Steve McConnell stellt der Autor Ideen f\u00fcr eine effiziente Entwicklung in […]<\/p>\n","protected":false},"author":1,"featured_media":21597,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[83],"tags":[],"writer":[],"class_list":["post-19999","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-buchclub"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19999","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/comments?post=19999"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19999\/revisions"}],"predecessor-version":[{"id":20001,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/posts\/19999\/revisions\/20001"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media\/21597"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/media?parent=19999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/categories?post=19999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/tags?post=19999"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/de\/wp-json\/wp\/v2\/writer?post=19999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/james-harrison-UVMPVIRCF5w-unsplash-1024x576.jpg\")
<\/figure>\n\n![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/saffu-E4kKGI4oGaU-unsplash-edited.jpg\")
<\/figure>\n\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/brett-jordan-XAX8vCM5G6o-unsplash-edited-scaled.jpg\")
<\/figure>\n\n