“Ihr seid doch agil, benutzt ihr auch den Hudson?”
Das ist eine gute Frage, die man – so oder so ähnlich – immer wieder von Leuten hört, die durchaus an agilen Themen interessiert sind, sich aber noch nicht wirklich weiter damit beschäftigt haben.
Aber was ist jetzt eine gute Antwort auf diese Frage? Ein einfaches “Ja!” entspricht zwar den Tatsachen, würde der Sache aber nicht wirklich gerecht werden. Die tool-orientierte Antwort könnte auch lauten: “Ja, wir benutzen Hudson, aber wir könnten auch Bamboo oder Cruise Control nutzen.” Verbunden mit einer länglichen technischen Begründung, warum wir uns letzten Endes für Hudson als Werkzeug entschieden haben. Hilfreich? Vermutlich eher nicht! Also nehmen wir noch einen Anlauf für eine Antwort: “Ja, wir benutzen Hudson als einen Teil unserer Umgebung für kontinuierliche Integration (Continuous Integration). Dieses wird komplementiert durch ein passendes SCM-Konzept und automatisierte Tests.” Soweit so gut, aber zu kontinuierlicher Integration gibt es doch noch eine Menge mehr zu sagen und damit sind wir am eigentlichen Start dieser kleinen Artikelserie über Continuous Integration.
(weiterlesen …)
Dieser Eintrag muss noch übersetzt werden, bis dahin ist er leider nur auf englisch verfügbar.
In dieser Session geht es also um TPI, die Abkürzung wurde jetzt schon ein paar mal erwähnt und offensichtlich sollte ich die kennen. Tue ich aber nicht. Gestern hab ich noch behauptet, dass ich erwarte, dass auf dieser Konferenz jeder weiß, was BDD ist, und jetzt bin ich einer derjenigen, der unwissend ist (eine schnelle Abstimmung hat das bestätigt. Also, mal sehen, was das ist.
Dieser Eintrag muss noch übersetzt werden, bis dahin ist er leider nur auf englisch verfügbar.
The One Thing You Need to Know … About Software Development
“Korrektheit kann zu jedem Zeitpunkt bestätigt werden” ist der Untertitel von Marys Keynote und er startete mit einem klaren Statement, dass “Wasserfall” einfach nicht funktioniert. Also, dann mal hören, was funktioniert 
Die Frage ist, wie man mit der Komplexität umgeht, und die Antwort ist zu einem gewissen Grad “Teile und Herrsche”. Es folgten ein paar geschichtliche Hinweise, wie das zu erreichen sei. In den 70er-Jahren war alles “Strukturiert” (Strukturiertes Design, Strukturierte Maintenance, etc), aber das hat das Problem nicht wirklich lösen können, wie wir heute wissen. Was wir wirklich wollen, ist das man gar nicht erst anfängt, die Probleme zu injezieren. Eine frühe Antwort darauf kam von Edsger Disjkstra in der Form einer mehrschichtigen Architektur, jede Schicht ist eine virtuelle Maschine zu der darüberliegenden Schicht.
(weiterlesen …)
Key Note Lisa Crispin – Are Agile Testers Different?
Besucht und geschrieben von: Andreas & Thomas
Die Antwort auf die Fage aus dem Titel der Keynote lautet: Ja! Dabei hat Lisa auch wieder besonderen Fokus darauf gelegt, dass es in agilen Teams keine Silos gibt, sondern es darum geht gemeinsam die gestellte Aufgabe zu lösen. Hierzu sind (agile) Tester genauso wichtig wie (agile) Entwickler und alle anderen Mitglieder des Teams.
(weiterlesen …)
Der erste Tag der agilen Testtage in Berlin ist vorüber. Vor Wochen hatte ich die Konferenz noch als kleindeutsch abgeschrieben. Nachdem ich auf der Agile 2009 in Chicago aber von vielen gehört hatte, dass sie hier sein würden, hatte ich schon die Vermutung, dass sie größer und internationaler wird, als ich zuerst annahm. Diese Vermutungen haben sich heute bestätigt. Es haben sich viele interessante Gespräche und Kontakte ergeben. Zu der angenehmen Atmosphäre trägt mit Sicherheit auch das gut ausgestattete und architektonisch interessant gebaute Konferenzhotel bei.
Kleiner Wehrmutstropfen am Abend: die ganzen Sprecher haben sich zum “Speaker Dinner” verabschiedet. Die normalen Leute bleiben also unter sich, und Thomas und ich werden gleich mal sehen, wo wir noch andere Agile Tester zum Abendessen auftreiben.
Designing a Lean Software Development Process, von Mary und Tom Poppendieck
Besucht und geschrieben von: Andreas
Laut dem Abstract des Tutorials sollten Möglichkeiten aufgezeigt werden, die (stagnierenden) Produktivitätssteigerungen, die sich allein durch agile Softwareentwicklung ergeben, zu analysieren und Möglichkeiten zur Verbesserung aufzuzeigen.
(weiterlesen …)
Kategorie: 
