Pecha Kucha Session
Raum Fidelitas
Anti-Pattern
... und wer rasiert den Barbier?
Prozessqualität in der IT ist eine Größe, die aus mehreren Blickwinkeln beurteilt werden kann. Je nachdem, ob (zum Beispiel) die Entwicklung, das Management oder der Kunde sie beurteilen, soll ein Prozess vielleicht effektiv, verlässlich oder schnell sein. Je besser ein Prozess die Ansprüche an ihn erfüllt, desto besser ist seine Qualität - dominiert dabei eine Sichtweise zu sehr, so kann dies zu einer einseitigen Prozessqualität führen.
Dieser Kurzvortrag nimmt den Blickwinkel einer prozessverantwortlichen Person ein und nennt Beispiele dafür, wie Prozessqualität in der IT je nach Sichtweise variieren kann. Anhand der sechs Praktiken von Kanban will er einfache und praktische Impulse dafür geben, wie neue Aspekte in die Beurteilung von Prozessqualität eingebracht werden können. Dies eröffnet die Möglichkeit, bewusst zwischen verschiedenen Ansprüchen abzuwägen und damit die Qualität der Prozessqualität zu erhöhen.
Mit Java entwickeln und liefern: besser ohne Build & Deploy
Als Antwort auf die Herausforderungen zunehmend komplexerer Softwarelösungen stehen der Java Community leistungsfähige Werkzeuge von Build Tools über Artefact Repositories bis zu CI Lösungen zur Verfügung.
Sind diese Werkzeuge aber Teil der Lösung oder Teil des Problems?
Die Open-Source Umgebung z2-Environment implementiert einen systemzentrischen Ansatz, der keine Build-Infrastruktur benötigt, Entwicklersetup minimiert und gleichzeitig Deployment-Updates dramatisch vereinfacht und beschleunigt.
Unter Beibehaltung der Standard-Java-Programmiermodelle, stellen sich für den Eingeweihten durchaus Analogien zur Entwicklung mit klassischen SAP Werkzeugen dar.
Der Vortrag zeigt wie sich die Entwicklung von Java Lösungen mit einem solchen Werkzeug anfühlt und wie damit Anpassungs- und Erweiterungsprobleme gelöst werden.
Nieder mit dem Zaun
Manuelles Testen ist bei kurzen Sprints schon schwierig und bei Continuous Delivery einfach nicht mehr möglich. Automatisierte Tests, die getrennt oder nachgelagert zur Entwicklung entstehen, sind wenigstens eine kurze Zeit veraltet und eignen sich daher auch nicht für Continuous Integration oder eine Deploymentpipeline. Automatisierte Tests sollten zudem ein Stück eines jeden Softwaresystems sein und auch mit ihm verwaltet und ausgeliefert werden.
Dies ist ein Appell für eine Zusammenarbeit von Test und Entwicklung mit einem gemeinsamen Ziel, einem gemeinsamen Werkzeugkasten und in einem gemeinsamen Repository.
Folien:
http://consulting.hildebrandt.tk/vortraege/nieder-mit-dem-zaun/vortrag/index.html
