Software in 30 Tagen

Book description

Das Buch wendet sich an IT-Führungskräfte und Manager, die Scrum im Unternehmen einführen möchten, um in der Softwareentwicklung erfolgreicher zu sein. Es zeigt, wie Software in kleinen, sog. Inkrementen von maximal 30 Tagen entwickelt wird, sodass nach jedem Inkrement die Richtung der Entwicklung geändert werden kann. Mit Scrum kann flexibel auf veränderte Marktbedingungen reagiert und das vertiefte Verständnis der benötigten Produkteigenschaften in die weitere Planung integriert werden. Führungskräfte lernen in diesem Buch, wie sie Risiken im Projekt im Griff behalten und das Team dabei unterstützen können, erfolgreich zu sein.

Table of contents

  1. Über diese Übersetzung
  2. Über die Autoren
  3. Danksagungen
  4. Einleitung
  5. Teil I Warum jedes Unternehmen der Welt in 30 Tagen Software herstellen kann
  6. 1 Die Softwarekrise: Die falschen Prozesse erzeugen die falschen Ergebnisse
  7. Fallbeispiel: Das Sentinel-Projekt des FBI
  8. Der falsche Ansatz: vorhersagende Prozesse
  9. Die falschen Ergebnisse: Projektfehlschlag
  10. Fallstudie: Parametric Technology Corporation
  11. Zusammenfassung
  12. 2 Scrum: Der richtige Prozess erzeugt die richtigen Ergebnisse
  13. Empirie in Aktion
  14. Löst Empirie unsere Probleme?
  15. Aus Empirie ergeben sich Praktiken für den Umgang mit Menschen
  16. Auch wenn wir es besser wissen
  17. Agilität
  18. Zusammenfassung
  19. 3 Versuchen Sie es selbst: der Pilot
  20. Empirie wird woanders im Unternehmen verwendet
  21. Ein beispielhaftes Pilotprojekt
  22. Teammitglieder ändern ihre Arbeitsweise
  23. Zusammenfassung
  24. 4 Was kann ich tun?
  25. Die Kunst des Möglichen
  26. Transparenz verlangen und eine Umgebung schaffen, in der sie aufblühen kann
  27. Auf die Menschen verlassen
  28. Menschen dabei unterstützen, ihr Sicherheitsbedürfnis zu reduzieren
  29. Zusammenfassung
  30. Teil II Wie man Software in 30 Tagen herstellt
  31. 5 Mit Scrum starten
  32. Das Scrum-Team zusammenstellen und den Sprint planen
  33. Wertschaffende Sprints
  34. Das Sprint-Review
  35. Die Sprint-Retrospektive
  36. Mit dem nächsten Sprint weitermachen
  37. Zusammenfassung
  38. 6 Scrum auf Projektebene
  39. Bottom-up- und U-Boot-Scrum
  40. Vorteile und Erkenntnisse
  41. Die Arbeit managen: Burndown-Charts
  42. Komplexität nicht ignorieren – immer die Augen offen halten
  43. Sprint-Länge
  44. Gründe gegen kürzere Sprints
  45. Vorsicht bei extremen Sprint-Längen
  46. Stabile Sprint-Länge innerhalb eines Projekts
  47. Ein Beispiel eines Scrum-PRN-Projekts
  48. Das nächste Kapitel
  49. 7 Scrum-Fähigkeiten entwickeln
  50. Das Softwarestudio ist eine lernende Organisationseinheit
  51. Der Studiomanager
  52. Ausbildung und Nutzungsbedingungen
  53. Die Ausstattung des Softwarestudios
  54. Veränderungen und Probleme
  55. Management nach Zahlen
  56. Metriken basieren auf Transparenz
  57. Ein fertiggestelltes, vollständiges Inkrement
  58. Eine Analogie
  59. Technische Schuld vermeiden, um benutzbare Inkremente zu erhalten
  60. Die Quellen der Sünde
  61. Zusammenfassung
  62. 8 Scrum auf Unternehmensebene
  63. Tief greifende, aber kurzlebige Veränderung
  64. Tief greifende und nachhaltige Veränderung
  65. Carbonite verändert sich und bleibt bestehen
  66. Wie Carbonite sich änderte
  67. Ergebnisse
  68. Zwei unverhandelbare Elemente jeder Scrum-Umstellung
  69. 9 Unternehmensumstellung: tief greifende und nachhaltige Veränderung
  70. Das Transitionsprojekt
  71. Startklar machen
  72. Das Transitionsprojekt starten
  73. Ein Transitionsteam bilden
  74. Vision und Strategie definieren
  75. Vision und Strategie kommunizieren
  76. Ausbreitung im Unternehmen
  77. Wirkung erzielen
  78. Nutzen messen, bewerten und konsolidieren
  79. Einbetten, ausweiten und nachhaltig verankern
  80. Zusammenfassung
  81. 10 Scrumming Scrum
  82. Scrum für die Scrum-Einführung bei SeaChange International
  83. Wie SeaChange neue Wege ging
  84. Ergebnisse
  85. Scrum breitet sich bei Iron Mountain aus
  86. Transitionsteams
  87. Zusammenfassung
  88. Anhang
  89. A Terminologie
  90. B Der Scrum Guide
  91. Zielsetzung des Scrum Guide
  92. Scrum-Überblick
  93. Scrum-Theorie
  94. Scrum
  95. Das Scrum-Team
  96. Scrum-Ereignisse
  97. Scrum-Artefakte
  98. Definition of »Done«
  99. Fazit
  100. Danksagungen
  101. Revisionen
  102. C Spielzüge, um Unternehmensagilität zu erreichen
  103. 1.1 Einführung
  104. 1.2 Überblick über Scrum und agile Softwareentwicklung
  105. 1.2.1 Scrum-Prinzipien
  106. 1.2.2 Scrum und agile Softwareentwicklung
  107. 1.3 Auf Scrum vorbereiten
  108. 1.3.1 Den Softwareprozess und das Unternehmen »scrummen«
  109. 1.3.2 Der CxO als Unternehmens-Scrum-Master für kontinuierliche Verbesserung
  110. 1.3.3 Achtung: Veränderungen bedeuten harte Arbeit
  111. 1.4 Spielzüge für die Scrum-Einführung
  112. 1.4.1 Spielzug 0: Überblick, Bewertung und Vorbereitung des Piloten
  113. 1.4.2 Spielzug 1: Pilotprojekt(e)
  114. 1.4.3 Spielzug 2: Ausbreitung im Unternehmen
  115. 1.4.4 Spielzug 3: Veränderung bewirken
  116. 1.4.5 Spielzug 4: Messen, bewerten und anpassen
  117. 1.4.6 Spielzug 5: Ausbreiten und gewinnen
  118. 1.5 Unternehmenshindernisse bei der Scrum-Einführung
  119. 1.5.1 Hindernisse mit Scrum aufdecken
  120. 1.5.2 Hindernisse charakterisieren
  121. 1.6 Scrum skalieren
  122. 1.6.1 Die Organisation skalieren: Scrum-Teams aus Teams
  123. 1.6.2 Teams aus Teams koordinieren
  124. 1.6.3 Infrastruktur für Unternehmensagilität
  125. 1.7 Zusammenfassung
  126. D Literatur
  127. Index

Product information

  • Title: Software in 30 Tagen
  • Author(s): Ken Schwaber, Jeff Sutherland
  • Release date: February 2014
  • Publisher(s): dpunkt
  • ISBN: 97833864900747