ZA012 - Zehn Tipps zum Troubleshooting
07.05.2012 
38 Minuten
Zusammenfassung
Diese Episode habe ich dem Thema Troubleshooting gewidmet. In den letzten 12 Jahren bin ich in diversen Projekten als Feuerwehrmännchen eingesprungen und habe geholfen, den Karren aus dem Dreck zu ziehen. Zusammen mit den Entwicklerteams habe ich es immer geschafft zu liefern. Das Wissen, wie Sie es auch schaffen können, geben ich Ihnen heute weiter.
Danke an dieser Stelle noch an die fleißigen Hörer für ihr Interesse und das Feedback.
Der Podcast wurde allein im April über 1500 mal angehört. Darüber bin ich sehr glücklich und freue mich schon die nächsten Episoden zu produzieren.
Wer mich persönlich treffen möchte, am 20.06.2012 bin ich als Referent bei der ASQF Fachgruppe Automotive NRW im Technologiepark Köln-Braunsfeld eingeladen und halte einen Vortag über den System Footprint, den ich in Episode ZA004 ja auch schon mal als Thema hatte. Gerne anmelden, die Veranstaltung ist kostenlos!
Die Themen dieser Episode:
- Woran erkenne ich, dass ich im Troubleshooting unterwegs bin?
- Den Kernnutzen des Systems herausfinden
- Wie nutze ich Triage in einem Projekt?
- Negotiation
- Abschirmen des Teams
- System Design vereinfachen
- Sprints und Weekly builds
- Planung und Überwachung
- Konflikte, Führung & Kommunikation
- Stress und Leistungsfähigkeit
Stellen Sie mir Fragen oder geben Sie mir Feedback
- Als Kommentar in den Shownotes
- Wählen Sie 02203 / 988 97 20 und hinterlassen Sie mir eine Nachricht
- Mailen sie mir unter feedback@zukunftsarchitekten-podcast.de (auch gerne Audiofiles)
Ich freue mich über eine Vernetzung und Weiterempfehlung
- Subscribe, bewerten und kommentieren in iTunes
- Auf Twitter folgen @mpfingsten
- Vernetzen auf Xing
Das Problem der Fehler bei der späten Integration lässt sich ganz gut auch durch nightly builds oder sogar durch continous integration in den Griff kriegen.
Bei nightly build: Am nächsten Morgen hat das gesamte Team eine Email, ob die Integration funktioniert hat oder nicht. Wenn nicht, ist das das erste, was am Morgen geregelt werden muss.
Bei continuous build: es gibt einen dedizierten build host, der nicht anderes tut als sich dauernd den neusten Stand auszuchecken, zu compilieren und alle Tests durchlaufen zu lassen. Sobald das fehlschlägt. schickt er eine Email an alle und verriegelt den Versionsmanagement-Server. Wieder Email an alle.
In der Email steht oben übrigens immer die Liste der Files, die seit der letzten erfolgreichen Integration eingecheckt worden sind.