Tonabnehmer
Der Tonabnehmer ist mein Podcast zur agilen Softwareentwicklung.
Episoden können als MP3 heruntergeladen oder als Podcast empfangen werden.
Wenn Sie über neue Ausgaben informiert werden möchten, abonnieren Sie bitte meinen Newsfeed, den Podcast oder tragen Sie sich einfach rechts im Newsletter ein.
Kudos für's Logo gehen an Benjamin Rabe.
25.9.2008
Endlich habe ich mich mal dazu bringen können, meinen webinale-Vortrag abzumixen. Die Aufnahmequalität war leider nur durchwachsen, so dass ich erstmals den Levelator ausprobieren konnte. Duftes Tool!
Getting Real ist der "Weg" der 37signals. Das frei erhältliche Buch beschreibt ihre Erfolgsstrategien, Geschäftsphilosophie und Designprinzipien. Die geplante zweite Auflage soll noch stärkeren Business-Fokus bekommen. Sehr spannend …
29.3.2008
Im Februar 2001 war das Agile Manifest geboren. In dieser Roundtable-Diskussion machen wir eine Bestandsaufnahme, Reflektion, Analyse: Was haben sieben Jahre Agile Entwicklung gebracht?
Mit dabei: Jutta Eckstein (Blog, Profil), Johannes Link (Blog, Profil), Jens Coldewey (Blog, Profil), Henning Wolf (Blog, Profil)
17.3.2008
Im Januar/Februar haben Tammo und ich zwei Ruby-on-Rails-Vorträge in der lokalen ACM/GI-Gruppe gehalten. Unser Ziel war es, die Leichtigkeit vorzustellen, mit der wir dank Rails ab Stunde 1 wirklich Geschäftswert schaffen können. Dazu haben wir nach einer kurzen Vorstellung der Prinzipien von Ruby und Rails in einer guten Stunde live eine kleine, aber substanzielle Web-2.0-App entwickelt: mit Kommentaren, Atom-Feed, REST-API, Tags, Google Map, Widget und allem, was dazugehört.
Sie können den Screencast als iPod/iPhone-Video (H.264-Codec) herunterladen und mit beispielsweise iTunes oder QuickTime ansehen. Aufgrund des hohen Demo-Anteils erscheint diese Episode nicht als Audio-Podcast.
Verwendete Plugins
Buchempfehlungen
16.2.2008
Dieses Interview hatten wir schon so lang vor, daher freut es mich umso mehr: Dierk König (Firma, Profil) spricht über Groovy, dynamische Sprachen auf der Java-Plattform allgemein und das Grails-Framework.
Von Herzen empfohlen sei hiermit auch sein Buch Groovy in Action (deutsche Ausgabe).
Dierk: Die Sprache muss passend sein zu dem, was man tut. In den typischen Java-Programmen gibt es überall Teile, wo man gerne ein bisschen dynamischer sein möchte … wenn man mal weiß, was es überhaupt heißt, dynamisch zu sein. Sonst, wenn man's gar nicht weiß und nie gesehen hat, dann entwickelt man auch den Bedarf nicht. Wenn man ihn kennt und die typischen Einsatzpatterns für dynamische Sprachen auf der Virtual Machine, dann sieht man's natürlich überall.
Obwohl man eine Grails-Applikation typischerweise in Groovy schreibt (man kann so viel man will auch in Java schreiben), hat der Stack, auf dem man arbeitet, einen relativ großen Teil von unten hoch Java: Java Enterprise Edition, mit allem, was dazu gehört. Dann darüber: Spring. Dann darüber: Hibernate. Damit hat man schon mal einen relativ hohen Kuchen. Und dann: Grails, zum großen Teil in Java geschrieben, muss man sich als obersten Layer vorstellen, der auch noch fast in Java ist. Und dann: Der eigentliche Applikationscode – ist ja nur noch unglaublich wenig, wenn man das vergleicht – ist nur noch so wie ein Zuckerguss, ganz oben auf dem Kuchen drauf. Und trotzdem hat man das Gefühl, dass man sehr leicht und dynamisch arbeitet. Man hat sozusagen die volle Power von Java ausgenutzt.
29.12.2007
Zum Jahresabschluss habe ich ein Gespräch mit Christian Setzwein (Firma, Blog, Profil) geführt – über seine Erfahrungen im Turnaround-Management von IT-Projekten (Buch), über das Managen von Atmosphären in Projekten u.v.m.
Die Episode kann als MP3 heruntergeladen oder auch direkt als Podcast abonniert werden.
Christian: Turnaround Management ist eigentlich ein Begriff, der aus der BWL kommt und bei dem es im Grunde um die Sanierung von großen Unternehmen geht. Meistens handelt es sich dabei um Liquiditätskrisen oder Absatzkrisen – irgendwelche Probleme, die diese Unternehmen haben und die das Unternehmen in seinem Bestand gefährden.
Wir haben nun diesen Begriff für große Projekte genommen, die in Schieflage und in Krisen sind, und bieten eine Dienstleistung an, die diese Projekte wieder in vernünftiges Fahrwasser bringt – also Krisenprojekte wieder in einen Zustand zu versetzen, dass das Projekt entweder vernünftig abgeschlossen werden kann oder vernünftig weitergeführt werden kann von dem Unternehmen selbst.
3.11.2007
Auftakt der neuen Tonabnehmer-Staffel ist ein Gespräch mit Rolf F. Katzenberger (Profil) über die Vier-Stunden-Arbeitswoche von Tim Ferriss.
Die Episode kann als MP3 heruntergeladen oder auch direkt als Podcast abonniert werden.
Lifestyle-Design. Wenn Du jemanden fragst: Was willst Du erreichen? Was sind Deine Ziele? Was macht Dich glücklich?
[...] dann hörst Du oft Sachen, die sich um das Haben von Dingen drehen, also was man sich leisten können will.
Wenn man sich darauf fokussiert, dann ist es klar, dass man möglichst viel Geld anhäufen muss, um seine Träume zu verwirklichen.
Aber es gibt neben dem Haben auch noch das Tun oder das Sein. [...]
Wenn man die Träume ein bisschen verschiebt vom Haben weg zum Tun und zum Sein, dann kann man eigentlich mit dem Geld, das man bisher fürs Haben ausgegeben hat, schon viel von seinen Träumen im Bereich Tun und Sein verwirklichen.
Das, was man sich so als Einkommen ausrechnen kann, was man monatlich bräuchte – so eine Art monatliches Zieleinkommen –, das ist dann vielleicht gar nicht mal so hoch, muss sich also gar nicht so sehr unterscheiden von dem, was man bisher für das Kaufen (oder Finanzieren) von Sachen ausgegeben hat.
Dreamlining. Man sollte eigentlich Träume nicht auf den Ruhestand verschieben, sondern immer so einen kleinen Miniruhestand einschieben und sich vielleicht vier oder fünf seiner Träume vornehmen, für das nächste halbe Jahr einplanen, Wie erreiche ich die? Wie kann ich das realisieren?
und dann das Ganze auch finanziell so entsprechend durchplanen.
28.5.2006
Diese Episode erscheint erstmalig als Audio- und Video-Podcast.
Mit freundlicher Genehmigung vom Software & Support Verlag konnte ich meine JAX-Session vom 10.5.2006 mitschneiden.
Das Ergebnis ist ein Vortrag im Stil von Lawrence Lessig (500 Folien in 70 Minuten), weshalb sich ein audiovisuelles Medium anbot.
Sie können den Vortrag als MP3 und iPod Video herunterladen.
Zum Abspielen des Videos benötigen Sie entweder ein aktuelles QuickTime 7 (kostenloser Download) auf Ihrem Rechner oder einen iPod der 5. Generation.
Buzzword-Bingo für das Jahr 2006:
"Web 2.0" und "Social Software" - was verbirgt sich hinter den aktuellen Schlagwörtern wirklich?
Was sind die heißesten Schlüsseltechnologien, welche Startups sind am erfolgreichsten und was sind ihre Erfolgsgeheimnisse?
Ein Exkurs für Entscheider, Entwickler und Entrepreneure.
Web2.0pedia
15.5.2006
Stress? Keine Zeit? Zu viel zu tun?
Tonabnehmer #9 dreht sich um die schon Kultstatus erreichende Selbst- und Zeitmanagementmethode Getting Things Done von David Allen und andere Life-Hacks zur persönlichen Produktivitätssteigerung.
Empfohlen für alle Projektleiter, alle Entwickler, eigentlich jedermann.
Ein Mitschnitt meiner JAX-Session vom 9.5.2006 (leider nur in durchwachsener Qualität).
Mit freundlicher Genehmigung vom Software & Support Verlag.
Sie können die Episode als MP3 herunterladen oder direkt als Podcast abonnieren.
(Was ist Podcasting?)
Die Idee von Getting Things Done ist, dass wir alle Verpflichtungen, die wir haben, alle Ideen, die wir im Kopf mit uns herumtragen, wirklich alles, aus dem Kopf und aus unseren Gedanken auf ein externes Medium bringen.
Das kann ein Palm sein, das kann ein Karteikartenstapel sein, ein vertrauenswürdiges System, dem wir alle diese Erinnerungen anvertrauen.
Die Maxime von Getting Things Done ist, dass wir uns umso mehr entspannen können, je weniger wir über irgendwelche Dinge nachdenken, die wir im Moment sowieso nicht tun können.
Wer heute morgen an irgendetwas gedacht hat und es nicht erledigen konnte ... das war ein verschwendeter Gedanke.
Das ist die Grundidee.
Wenn man sich von diesen Gedanken befreit, hat man die Möglichkeit, sich um die wirklich wichtigen Dinge zu kümmern.
Man kann kreative Energie schöpfen oder sich um die Sache mit absolutem Fokus kümmern, die jetzt gerade am wichtigsten ist.
"Open Loops" werden all die Sachen in Getting Things Done (GTD) Lingo genannt, die wir angefangen, aber nicht fertig gemacht haben, oder wo wir noch nicht entschieden haben, was wir damit überhaupt anfangen wollen.
GTD will, dass wir uns dieser Sachen überhaupt erstmal bewußt werden, dann das Ziel definieren, also das erwartete Ergebnis und dann - eine Grundidee von GTD - die nächste physikalische Aktion (aka Next Action), um es in die Realtät umzusetzen. [...]
Das Problem, das wir Wissensarbeiter haben, ist, dass wir Aufgaben haben und Probleme wälzen, die nicht klar definiert, sondern amorph sind und keine Grenzen haben.
Ein Teil unserer Arbeit ist eben genau, erst einmal zu definieren, was die Aufgabe überhaupt ist.
GTD geht davon aus, dass man ganz, ganz viele Listen schreibt.
Das ist eigentlich das Krisenprinzip dauerhaft angewendet: Wenn man ganz, ganz viel zu tun hat, dann schreiben die meisten Menschen sowieso Listen. [...]
Viele räumen auf, wenn sie in Urlaub gehen, damit sie entspannt in Urlaub gehen können und im Urlaub nicht über die Arbeit nachdenken müssen.
Das ist eigentlich genau die Idee von GTD: Warum machen wir das nicht jeden Tag?
Warum nur, wenn wir in Urlaub gehen?
Getting Links Done
3.2.2006
Nach längerer Sendepause geht's weiter:
Heute mit Thomas Baustert und Ralf Wirdemann (zusammen: b-simple) über Ruby on Rails und ihr Buch Rapid Web Development mit Ruby on Rails.
Sie können die Episode als MP3 herunterladen oder direkt als Podcast abonnieren.
(Was ist Podcasting?)
Was begeistert euch an Ruby?
Ralf: Mich begeistert an Ruby die Dynamik, die ich jetzt in statisch getypten Sprachen richtig vermisse, seitdem ich täglich Ruby programmiere.
Die Eigenschaft, eine Sprache selber zu erweitern um domänenspezifische Funktionen, wie ich sie brauche, finde ich einfach großartig.
Thomas: Geht mir genauso.
Man muss erst mal viel weniger Code schreiben, um das gleiche zu erreichen.
Und bei Ruby sind die Klassen offen, man kann sie erweitern, also eigene Methoden dazufügen, auch zu bestehenden Bibliotheksfunktionen von Ruby.
Was ist Rails?
Ralf: Rails ist ein Webapplication-Framework mit einem zugehörigen Persistenz-Layer, das uns ermöglicht, geschäftskritische Webanwendungen in Ruby zu programmieren. [...]
Wichtig finde ich einige zentrale Prinzipien, die Rails zugrunde liegen.
Ganz oben auf der Liste steht Konvention statt Konfiguration.
Das heißt, bei Rails versucht man, sehr viel über Konventionen zu lösen und dadurch möglichst wenig Konfiguration zu haben. [...]
Ein weiteres wichtiges Prinzip ist die Einhaltung des DRY-Prinzips: Don't repeat yourself.
Das heißt, Rails versucht Wissen möglichst konsequent an einer einzigen Stelle im System zu repräsentieren und schafft dadurch die Voraussetzung, um möglichst wartbare und langlebige Systeme zu bauen.
Wichtig finde ich unmittelbares Feedback.
Man hat in Rails die Möglichkeit, durch einen einfachen Reload im Browser seine Änderungen sofort sichtbar zu machen, ohne dass ich meine Anwendung umständlich deployen muss.
Man merkt wirklich in der Praxis, wie viel Zeit das doch tatsächlich spart.
15.8.2005
Nach kurzer Sommerpause melde ich mich mit einem neuen Tonabnehmer zurück.
Dieses Mal mit Markus Völter und den Themen Softwarearchitektur und Modellgetriebene Entwicklung.
Unseren Skype-Schwatz können Sie als MP3 herunterladen oder direkt als Podcast abonnieren.
(Was ist Podcasting?)
Markus zum Thema Architektur: "Eine gute Softwarearchitektur ist leicht verständlich. [...]
Man sollte in der Lage sein, mit einem kleinen Dokument oder Wikiseite von fünf bis zehn DIN A4-Seiten die wesentlichen Punkte einer Softwarearchitektur zu beschreiben oder zu kommunizieren.
Das macht die Architektur leichter verständlich, es macht sie leichter umsetzbar.
Je weniger Konzepte sie hat, desto leichter wird sie auch wartbar, weil man nicht so viele Details hat.
Letztendlich muss sie natürlich auch testbar sein - das ist ganz, ganz essenziell.
Eine Architektur, die die verschiedenen Aspekte des Gesamtsystems so miteinander verschränkt, dass sie nicht einzeln testbar ist, wird es nicht lange durchhalten.
Was ich auch denke, ist, dass eine Architektur nur in zweiter Linie mit Technologien zu tun hat.
Ich habe da auch selbst einen gewissen Lernprozess durchgemacht.
Als ich früher angefangen hab so mit Architekturthemen, war das ganz, ganz stark technologiegetrieben.
Also: Wenn eine Anforderung kam, mit welcher Technologie setzt man das am dümmsten um.
Jetzt sehe ich's ein bisschen anders und denke bisschen mehr konzeptioneller Art.
Sprich man sollte erst einmal versuchen, eine Architektur zu definieren, indem man die wichtigsten Konzepte [identifiziert] - quasi die Bausteine, aus denen ich nachher meine Software baue, erst einmal konzeptionell zu beschreiben und dann erst im weiteren Schritt zu überlegen, wie ist die Technologieabbildung von dem Ganzen, weil man sonst natürlich viel zu stark von Technologie bei der Arbeit gestört wird."
Bei Modellgetriebener Entwicklung geht es darum, "Softwareentwicklung effizienter zu gestalten, indem man den Entwicklern erlaubt, Dinge mit Sprachen auszudrücken, die sich besser für das entsprechende Problem eignen als die 3GL-Programmiersprache.
Das Problem ist ja, wenn ich in einer bestimmten Domäne arbeite, gibt's immer eine Menge von Worten, Begriffen, Konzepten, Vorgehensweisen, die für diese Domäne spezifisch sind.
Und wenn ich's schaffe meine Werkzeuge - in dem Fall: Programmiersprachen - für diese Domäne anzupassen, dann kann ich natürlich die Sachverhalte, die ich in der Domäne ausdrücken will, auch effizienter gestalten.
Das heißt, im Endeffekt geht's bei Modellgetriebener Entwicklung darum, dass man sich domänenspezifische Sprachen "ausdenkt", definiert, erarbeitet, um mit ihnen nachher effizienter entwickeln zu können."
21.6.2005
Unser heutiges Thema ist die Eclipse Rich Client Platform - eine Skype Konferenz mit Frank Gerhardt, Bernd Kolb und Martin Lippert.
Den Mitschnitt können Sie als MP3 herunterladen oder direkt als Podcast empfangen.
(Was ist Podcasting?)
Frank: Die Eclipse Rich Client Plattform ist ein Teil der Eclipse Java-Entwicklungsumgebung.
Irgendwann haben die Leute gedacht: Jetzt haben wir eine so schöne Entwicklungsumgebung, wir wollen eigentlich, was wir da benutzen, also diese Perspektiven und Views, auch in allgemeinen Anwendungen verwenden.
Und dann wurde - ich glaube, es war 2003 - ein Bug eingestellt in Bugzilla von Eclipse, wo jemand geschrieben hat: Ich möchte RCP verwenden.
Das kam gar nicht von IBM, sondern wurde aus der Community getrieben und bei diesem Bug-Report hat die Community über 20 DIN A4-Seiten Anforderungen gesammelt, was die Rich Client Plattform alles können soll.
Im Eclipse3-Release hat das Eclipse-Team dann die Plattform soweit refactort, dass man sie jetzt auch stand-alone verwenden kann.
Bernd: Und dadurch, dass das Ganze eben Plugin-basiert ist, war das relativ einfach, aus der IDE-spezifischen Anwendung die RCP-Plattform herauszulösen. [...]
Standardmäßig bekommt man mit RCP, was man sieht, wenn man die Eclipse-Entwicklungsumgebung startet.
Also: Ich habe verschiedene Perspektiven, die ich mir definieren kann, ich habe verschiedene Views und Editoren, die ich definieren und erstellen kann.
Dann kann ich mir ein Menü zusammenbauen.
Ich kann mehrere Fenster öffnen gleichzeitig.
Also: Alle die Funktionalitäten, die ich aus der Entwicklungsumgebung für Java kenne, kann ich jetzt herauslösen und mir für meine Funktionalität selber implementieren.
Martin: Technisch darunter besteht das Ganze aus der Runtime: dem eigentlichen OSGi-Kernel und der Eclipse-Runtime, wo letztendlich die Plugins definiert werden, die ich benutzen kann, um zu sagen: Mein System kann aus Plugins zusammengesetzt werden.
Dann kommt SWT Widget Toolkit dazu und das JFace und als letztes die Generic Workbench.
Frank: Das Schöne an der Eclipse Rich Client Plattform ist, dass sie aus einem lauffähigen Produkt entstanden ist und nicht wie viele andere Dinge als Spezifikation das Licht der Welt erblickt hat.
Die RCP hat sozusagen schon den Beweis ihrer Benutzbarkeit oder Brauchbarkeit, Nützlichkeit in der Java-Entwicklungsumgebung erbracht.
25.5.2005
Frühling!
Was liegt da näher, als sich über das hochaktuelle Spring-Framework zu unterhalten.
Mit Eberhard Wolff.
Sie können den Beitrag als MP3 herunterladen oder direkt als Podcast empfangen.
(Was ist Podcasting?)
Was ist Spring?
Eberhard: "Die beste Analogie zu Spring ist für mich J2EE.
Ich habe in J2EE eine Ansammlung von APIs - das habe ich in Spring auch.
In Spring habe ich eine deutliche Vereinfachung bei der Benutzung dieser APIs und kann damit serverbasierte Anwendungen entwickeln.
Das ist für mich der Fokus!
Oft wird Spring primär gesehen als ein Dependency Injection Container.
Dependency Injection ist eben dieses Prinzip, dass ich sage, ich habe Java-Objekte und statt dass sie aktiv irgendwo hingehen und sich Ressourcen holen, ist es so, dass die Ressourcen ihnen zugewiesen werden.
Das ist eine Geschichte, die relativ fundamental ist und ich habe inzwischen das Gefühl, dass das extrem fundamental etwas über objektorientierte Programmierung sagt."
Spring - Das neue J2EE?
"Das kann gut sein, dass es tatsächlich so passiert.
Wobei man das abwarten muss.
Und das ist auch eine Geschichte, die auf J2EE natürlich aufbaut.
Es ist also nicht so, dass es das ersetzt, sondern es erleichtert es halt primär."
21.4.2005
Heute sprach ich mit Bernd Oestereich über die soziale Dynamik in IT-Projekten, agiles Projektmanagement und den Maschinenbau des 21. Jahrhunderts.
Das Interview können Sie als MP3 herunterladen oder direkt als Podcast empfangen.
(Was ist Podcasting?)
Erfahren Sie von Bernd, warum fachliche oder technische Probleme versteckte Kommunikationsprobleme sein können:
"Das Problem liegt vielleicht ganz woanders.
Vielleicht ist das überhaupt kein Problem, was auf der technischen Ebene liegt.
Vielleicht liegt das so mehr auf der Geschäftsordnungsebene.
Vielleicht sind die Verantwortlichkeiten falsch verteilt.
Vielleicht sind die schlecht organisiert.
Vielleicht ist der Prozess schlecht oder so etwas. [...]
Dann macht man auf der Ebene vielleicht Vorschläge.
Dann ist man schon bei Organisationsberatung letztendlich.
Wenn auch das wieder nicht funktioniert nach zwei, drei Versuchen, dann kann man sagen, vielleicht liegt das Problem noch eine Ebene tiefer.
Dann landen wir häufig auf einer sozialen Ebene.
Das heißt, wir merken dann, es gibt dort Spannungen.
Bestimmte Leute mögen nicht miteinander reden, haben Vorbehalte gegeneinander.
Der eine sabotiert den anderen, spricht das aber gar nicht offen aus oder so etwas.
Oder es gibt eine Besitzstandswahrung in Wirklichkeit und diese Geschäftsordnungsebene und die Prozedere, die es so in Unternehmen gibt, werden nur vorgeschoben.
Dann muss man halt auf der Ebene arbeiten.
Das Problem ist aber, da kann man den Kunden in der Regel nicht mehr offen drauf ansprechen.
Man darf diese Themen nicht so einfach adressieren.
Man greift dann in ein Wespennest."
"Unsere Welt ist ja durchdrungen von Software mittlerweile. [...]
Es wird immer vernetzter, immer kleiner.
Und da kommt eine ganz neue Komplexität auf uns zu: diese ganz vielen, kleinen vernetzten Systeme, wo unheimlich viele verschiedene Leute dran beteiligt sind, viele verschiedene Firmen.
Und wer kann eigentlich die Gesamtheit dieser Systeme noch überblicken, auch was wir da so als Gesellschaft oder Zivilisation aufbauen.
Das Internet ist ja auch eine Sache, die so ja niemandem gehört und die irgendwie eine ganz interessante Dynamik und Komplexität hat.
Und ich glaube, da kommen noch Probleme auf uns zu, die erahnen wir noch nicht mal.
Das heißt, ich sehe im Moment den Schwenk vom Software Engineering zum Systems Engineering."
1.4.2005
Heute hatte ich das Glück, Greg Woydnilek am Hörer zu haben.
Passend zum gegenwärtigen Entschleunigungstrend verspricht Contemplative Programming, den Blick zurück auf's Wesentliche zu lenken:
"Relax, there's more to life than work!" erklärt Greg die Grundmauern der Kontemplation.
Sie können unser Telefongespräch (hoffentlich verständlich genug, da Greg gebrochenes Deutsch spricht) als MP3-Datei herunterladen oder als Podcast empfangen.
(Was ist und wie funktioniert Podcasting?)
Bringen Sie von Greg z.B. in Erfahrung, warum Kontemplative Programmierung an die berühmte Rodin-Statue erinnert:
"Was wir herausheben wollen, das ist der Wert von Nachdenken ... und Vordenken - eigentlich Denken überhaupt.
Was habe ich gerade angestellt?
Was haben wir in der letzten Zeit im Projekt gemacht?
War das erfolgreich?
Können wir es verbessern?
Wir unterscheiden uns von anderen Approachen, dass wir solche Retrospektiven nicht erst post mortem durchführen, wenn schon alles tot ist.
Stattdessen betreiben wir kontinuierliche Retrospektive.
Das geht soweit, dass wir auch Prospektive machen.
Allerdings nur kurzfristig, denn auch Kontemplation ist keine Glaskugel."
Greg und ich waren uns dann auch einig, was Burn-Out und Work/Life-Balance betrifft:
"Hand auf's Herz, wenn man mal älter ist als 25, dann findet man es nicht mehr wirklich cool, bis zur Besinnungslosigkeit an einer Sache zu arbeiten.
Begeisterung und Commitment sind natürlich großartig.
Allerdings nicht mehr dann, wenn sie einen zerstören.
Es muss anders gehen, denn so geht es jedenfalls nicht."
16.3.2005
Für den zweiten Tonabnehmer habe ich Jutta Eckstein in Braunschweig besucht.
Bei leckerem Husten- und Bronchialtee haben wir über agile Softwareentwicklung in großen Projekten geschwätzt.
Das Interview können Sie als MP3 herunterladen oder direkt als Podcast empfangen.
(Was ist Podcasting?)
Hören Sie u.a., warum Feedback im Zentrum von Agilität steht:
"Wenn man sich überlegt, agile Entwicklung zu verfolgen, dann ist es nicht damit getan, dass man sich einen Prozess ausschaut wie Extreme Programming oder Scrum oder Feature-Driven Development oder was auch immer und dann diesen umsetzt, sondern was eben das Wichtigste ist:
Dass man immer wieder Feedback einholen muss, inwiefern der Prozess dem Team und dem Projekt auch wirklich gerade nützt.
Oder ob es vielleicht irgendwelche Ecken gibt, wo der Prozess mehr hindert oder vielleicht auch das Team Probleme hat, genau diesen Prozess umzusetzen.
Man muss dann eben gemeinsam herausfinden, was man stattdessen tun kann, um zum Erfolg zu kommen."
Ohne Retrospektiven ist ein agiler Prozess dann auch kein agiler Prozess, erklärt Jutta:
"Weil ich nur durch die Retrospektiven in der Lage bin, den Prozess wirklich anzupassen: an die Bedürfnisse des Projekts, an die Bedürfnisse des gesamten Teams, des Kunden usw."
Zu ihrer Rolle als Kommunikationsmanagerin:
"Manche Dinge, die [in kleinen Projekten] automatisch laufen, wie dass man sich an der Kaffeetheke trifft, dass man nebenbei mitkriegt, wie jemand ein Problem hat, oder grundsätzlich was Kommunikation angeht:
Das funktioniert [in größeren Projekten] einfach nicht mehr automatisch, sondern man muss es institutionalisieren.
Also: Man muss sicherstellen/gewährleisten, dass die Kommunikation existiert."
9.2.2005
Zum Auftakt des Tonabnehmers, meiner neuen Audiokolumne zur agilen Softwareentwicklung, sprach ich mit Johannes Link über sein neuestes Buch Softwaretests mit JUnit.
Das Telefoninterview können Sie als MP3 herunterladen oder direkt als Podcast empfangen.
(Was ist Podcasting?)
Aus dem Interview erfahren Sie alles Wissenswerte rundum die Testgetriebene Softwareentwicklung.
Auf meine Frage, welche Herausforderungen auf uns zukommen, antwortete Johannes:
"Das Entscheidende, was wir in den letzten Jahren erlebt haben, ist ein großer Kostendruck auf die Softwareindustrie. [...]
Wir müssen herausstellen, dass Testgetriebene Entwicklung nur zu einem kleinen Teil mit Testen und Programmierung zu tun hat, sondern große Auswirkungen auf den Prozess und das Management hat.
Denn im Prozess und im Management liegen eben die größten Optimierungspotenziale der Softwareentwicklung.
Und dann können wir, wenn wir das rüberbringen, auch vielen, die völlig auf Outsourcing und Offshoring schwören, den Wind aus den Segeln nehmen."
"Wenn ich als Kunde mir einen Dienstleister aussuche, würde ich einen auswählen, der von sich aus automatisierte Testfälle erstellt und die Anforderungen mit mir zusammen in automatisierten Akzeptanztests festhalten will."
Über Feedback zum Podcast auf Podster.de freue ich mich …
