You are here

Daniel Zappold's blog

I often hear "we have to get 80% test coverage!“ or „our coverage is too low“. Does this sound familiar? Many teams or developers strive for high test coverage. But why? In most cases what they want to build a safety net through high test coverage. This safety net allows us to trust our system and enables us to change the system. Yes, uncovered code means there is a blind spot. I totally agree.

In vielen Softwareteams wird Testgetriebene Entwicklung (TDD, Test Driven Development) als gute Praxis angesehen um Code zu schreiben, der testbar, wartbar, änderbar, erweiterbar und im besten Falle auch noch gut designed ist. Der Zyklus zur Testgetriebenen Entwicklung (TDD) ist leicht zu erklären, doch schon kleine Übungen sind für Anfänger nicht immer einfach. 

Whenever somebody says that the team is responsible for product quality most of the time they only refer to the development team. But this is only one side of the coin. What about the rest of the Scrum team? And, in particular, what about the Product Owner?

For sure, the development team is responsible for both internal (maintainability, code quality, code testability, ...) and external quality (stability, usability, performance, ...). Yet I would like to point out how much influence the product owner has on quality as well.

Meine Retrospektiven durchlaufen überwiegend die fünf Phasen wie sie von Esther Derby und Diana Larsen in ihrem Buch "Agile Retrospectives: Making Good Teams Great" beschrieben werden. Als eine für mich interessante Variante für den Einstieg in eine Retrospektive verwende ich "Amazon Rezensionen" in meinen Teams.
 

Leider wird eine Retrospektive oft nur als Kaffeekränzchen angesehen. Kein Wunder, da unerfahrene Teams und Scrum Master darüber oft nicht Wissen, wie man eine Retrospektive gestaltet. Dies fängt dabei an, wer alles an der Retrospektive teilnehmen soll und geht bis hin zur Gestaltung um einen echten Nutzen daraus zu ziehen.

Immer wieder stolpert man beim Lesen von Sourcecode über Namensgebungen. Dies wird insbesondere durch TDD und Clean Code stärker forciert, so dass man sich oft fragen muss, was macht die Variable, die Methode oder die Klasse wirklich?

At the Scrum Gathering Barcelona I had the opportunity to join some very interesting and inspiring sessions. It was a good place for discussions with a lot of great people from all over the world. In Barcelona there were about 330 people from over 30 countries. We had a wonderful open space facilitated by Alan Cyment who spread such a lot of energy to all participating people. Before creating the market place we did some exercises for activation to become more creative. One of the best open space sessions I've joined was about story cubes provided by Björn Jensen. He showed us how to bring you into a creative state by telling stories using nine dices with symbols printed on.

The two session I liked most were:

Bei der Agile World 2012 haben wir für den Workshop "Continuous Delivery mit Lego". einen kleinen Lego Mindstorms Roboter namens “Wall-e” gebaut.

Zurzeit steigt das Bewusstsein für die Bedeutung von Continuous Integration immer stärker, hier mit eingerechnet sind auch Continuous Deployment und Continuous Delivery. Insbesondere letzteres ist für viele Projekte ein hehres Ziel.

Pages