Posts tagged ‘it-agile-blog-planet’

Test-Mnenomics und Testing-Dojos

Von meinem Kollegen Markus Gärtner habe ich das Konzept der Testing-Dojos für exploratives Testen kennengelernt. Inzwischen habe ich bei Kunden ein paar Testing-Dojos durchgeführt. Dabei hat sich das Vorgehen anhand von Test-Mnemomics sehr bewährt. Sie geben eine Struktur vor, entlang derer man das explorative Testen durchführen kann. So wird ganz gut verhindert, dass das Dojo zu einem beliebigen Rumgeclicke in der Anwendung wird.

Nützliche Test-Mnemomics finden sich hier: http://www.qualityperspectives.ca/mnemonics.html

Ich komme eher aus der Programmier- als der Testecke und fand die Testing-Dojos vor diesem Hintergrund sehr spannend. Ich konnte dort sehr effektiv mitkriegen, wie die Tester arbeiten. Ich empfehle damit explizit auch allen Entwicklern, Testing-Dojos zu besuchen. Es kann wirklich sehr wertvoll sein, die Arbeit der Tester besser zu verstehen. Und es ist natürlich sehr wertvoll, selbst besser testen zu lernen.

January 17, 2011 at 11:35 am 1 comment

Online Scrum-Konferenz

Die FH Vorarlberg arbeitet derzeit an einer Online Scrum-Konferenz, an der namhafte deutsche Vertreter der agilen Szene teilnehmen: Boris Gloger, Roman Pichler, Jutta Eckstein, Krishan Mathis und weitere. Weitere Informationen finden sich hier.

November 23, 2010 at 8:17 pm Leave a comment

Prezi “Inkrementeller Entwurf” als PDF

Letztes Jahr habe ich auf dem Scrum-Gathering in München einen Vortrag über inkrementellen Entwurf gehalten. Ich habe damals Prezi benutzt, was einen Nachteil hatte: Man konnte die “Folien” nicht als PDF bereitstellen. Das hat sich jetzt geändert. Hier ist die Präsentation als PDF (dann natürlich ohne die animierten Übergänge): InkrementellerEntwurf_Roock_Okt2010

November 22, 2010 at 6:59 pm Leave a comment

The Liskov Substitution Principle (LSP) in duck typed programming languages

This article is the follow up to a Twitter conversation in which at least @johanneslink, @jasongorman, @leiderleider and @berndschiffer were involved. The question was if the Liskov Substitution Principle would apply if you don’t use inheritance. I had to stop participating in the Twitter conversation since 140 character messages are just too short to explain my point of view. Here is the longer version:

The Liskov Substitution Principle
The Liskov Substitution Principle (LSP): “[…] states that, if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.).” (Source: Wikipedia).
The more formal definition of the LSP is: “Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.” (Source: Wikipedia).
And to be complete, here is the definition of subtype: “In programming language theory, subtyping or subtype polymorphism is a form of type polymorphism in which a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program constructs, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype.” (Source: Wikipedia).

While subtype and LSP sound similar, there is a difference: The subtype relation normally is interpreted as a syntactical property. If the required methods are available on an object, everything is valid. The Liskov Substitution Principle goes beyond that and adds a requirement on the semantics of the methods.

Example (in pseudo code)

class A {

    public void m() { ... do something ... }

}

class B extends A {

    public void m() { 
        throw new Exception();
    }

}

In this case B is a subtype of A. B has the same methods as A. But the LSP may be violated. If the clients of A expect m to not throw an exception, B’s implementation of m breaks the LSP. Regarding the formal definition of the LSP (“Let q(x) be a property provable about objects x of type T.”). The property q would be that the execution of m won’t throw an exception. This property is true for A’s implementation of m but not for B’s implementation of m. Therefore you shouldn’t use objects of class B where a client expects objects of class A. While that would be syntactically correct it isn’t semantically valid.

The Liskov Substitution Principle in class typed languages
In most statically typed object-oriented languages (like C++, Java, C#) the subtype relation is defined by inheritance between classes. When a class B inherits from a class A the defined type B is a subtype of A. The example above showed that the LSP may be violated due to specific method implementations provided by B.
Some languages (like Java) provide an interface concept. Interfaces only define the signature of methods but don’t provide method implementations. Classes implement interfaces and provide the method implementations. With interfaces the LSP is still a useful concept. The clients of an Interface C rely on a certain behaviour of the objects implementing the interface. Again the clients of C may assume that m won’t throw exceptions.

interface C {

    public void m();

}

class A implements C {

    public void m() {
        throw new Exception();
    }

}

In the example code A’s implementation of m will break the LSP.

These situations are clear and well understood. But what happens in programming languages with duck typing (like Ruby)?

The Liskov Substitution Principle in duck typed languages
In programming languages with duck typing (e.g. Ruby, Python, Smalltalk) classes don’t really define types. There is no type checking when assigning objects to variables or passing objects as method arguments. There is a kind of type checking when a method is called. It is checked that the method exists with a matching number of parameters.
Since classes don’t define types, inheritance in duck typed languages has nothing to do with the subtype relation or the LSP.
In a way clients define interfaces in an implicit way. Let’s look at an example:

def my_method1(a) do
    a.m1()
    a.m2()
    my_method2(a)
end

def my_method2(a) do
  a.m3()
end

Calling my_method1 with an object a will succeed if the object a provides the three methods m1, m2 and m3. This is the implicit interface the object a needs to implement. And with this implicit interface comes the clients expectation about the behaviour of m1, m2 and m3. That’s just the same as with the Java interface. If an object b provides m1, m2 and m3 but doesn’t fit the expected behaviour, the LSP is violated.

Conclusion
The LSP isn’t tied to inheritance or class based typing. It applies to duck types languages as well as to systems without inheritance. LSP is a concept that applies to all kinds of polymorphism. Only if you don’t use polymorphism of all you don’t need to care about the LSP.

November 8, 2010 at 10:16 am 2 comments

ScrumBut auf den XP-Days Germany

Am 25. bis 27.11.2010 finden in Hamburg die XP-Days Germany statt.

Ich werde dort über ScrumBut vortragen und würde mich freuen, Euch zahlreich auf den XP-Days zu treffen.

Abstract meines Vortrags

Es gibt immer wieder die Frage nach Anpassungen an Scrum. Für Anpassungen, die man nur macht, um Probleme nicht lösen zu müssen, hat Ken Schwaber den Begriff ScrumBut geprägt. Im diesem Vortrag geht es um die Frage, welche Anpassungen an Scrum gerechtfertigt sind und von welchen man lieber die Finger lassen sollte.

October 25, 2010 at 6:54 am 1 comment

Buchtipp: “Inspired – How to create products customers love” von Marty Cagan

Das Buch richtet sich an Produktmanager/Product Owner und ist aufgeteilt in drei Teile: People, Process, Product. Das Buch hat seinen Schwerpunkt auf Internet-Anwendungen. Viele der dargestellten Konzepte sind auf andere Anwendungstyper aber problemlos übertragbar.

Der People-Teil hat mir nicht so viel gegeben. Was dort steht, ist alles richtig, aber vieles davon schien mir selbstverständlich. Das ist vielleicht meinem agilen Hintergrund geschuldet. Anderes erschien mir zu unkonkret.

Die Teile über Prozess und Produkt fand ich viel besser. Hier stehen absolut richtige und wichtige Dinge für Produktmanager / Product Owner. Vor einem Scrum-Hintergrund liefert das Buch unter anderem konkrete und nützliche Hinweise dazu, was der Product Owner vor dem ersten Sprint zu tun hat. Besonders gut hat mir gefallen (weil es in der Praxis leider häufig anders gehandhabt wird):

  • Cagan macht deutlich, dass es einen Unterschied zwischen Anwenderanforderungen und Produktfeatures gibt. Nicht alles, was sich Anwender wünschen, muss oder sollte umgesetzt werden.
  • Das bedeutet aber nicht, dass der Produktmanager keinen Kontakt zu Anwendern haben muss. Das Gegenteil ist der Fall; er muss von Beginn an sehr engen Kontakt mit den Anwendern pflegen und kann diese Aufgabe auch nicht delegieren.
  • Produktideen müssen validiert werden. Das kann bis zu einem gewissen Maße bereits vor Beginn der eigentlichen Entwicklung (erster Sprint) geschehen. Dazu sind Prototypen notwendig, die man direkt Anwendern zeigt und Feedback einholt. Auch das muss der Produktmanager persönlich tun und kann es nicht delegieren.

Es gab nur einen Punkt, wo ich eine andere Meinung vertrete als Cagan: Er erweckte bei mir mehrfach den Eindruck, als schwebe ihm eine sehr strikte Trennung zwischen Produktmanagement und Entwicklung vor. Ich glaube, dass man sich damit viele Chancen vertut und stattdessen eine sehr enge Zusammenarbeit zwischen beiden Parteien anstreben sollte, in der die Entwickler nicht einfach nur das liefern, was der Produktmanager bei ihnen bestellt, sondern zusammen mit dem Produktmanager konzipieren.

Fazit: Ein äußerst wertvolles Buch für jeden Produktmanager/Product Owner (auch wenn nach Wasserfall entwickelt wird).


October 22, 2010 at 7:11 pm 1 comment

Poll about code katas

We have created a poll about code katas to better understand the current use of code katas and the needs of programmers doing code katas. Please help us to gather the data and participate in the anonymuous poll (only eats 5 minutes of your time): Participate in Poll and please spread the link to the poll.

We will puplish the results after the poll ended.

October 7, 2010 at 2:02 pm Leave a comment

Vortrag auf dem Objekt-Forum-Nord: “Auf der Suche nach dem Qualitäter”

Am 14.09.2010 haben Roman Pichler und ich auf dem Objekt-Forum Nord in Hamburg über Qualität vorgetragen. Roman hatte sich die Product-Owner-Sicher vorgenommen und ich die Entwicklersicht unter dem Titel: “Auf der Suche nach dem Qualitäter”.

Die PDFs der Folien finden sich hier zum Download.

Ich hatte meinem Vortrag begonnen mit einem Beispiel für wirklich schlecht strukturierten Code (siehe Folien) und habe ein paar Fragen ans Publikum gestellt. Die Antworten finde ich ganz interessant (die Zahlen stimmen im Detail wohl nicht, weil ich sie aus der Erinnerung rekonstruiert habe – die Größenordung passt aber).

  • Wer ist sich sicher, dass es so schlecht strukturierten Code bei ihm im Projekt/Unternehmen gibt? Meldungen: 40
  • Wer ist sich sicher, dass es solchen Code bei ihm nicht gibt? Meldungen: 1
  • Wer ist sich unsicher? Meldungen: 5
  • Wer kennt TDD? Meldungen: 30
  • Wer nutzt TDD? Meldungen: 20
  • Wer kennt SOLID? Meldungen: 20
  • Wer nutzt SOLID? Meldungen: 10

Das Ergebnis passte auf jeden Fall gut zur Argumentationslinie meines Vortrags. Obwohl zumindest ein Teil der Teilnehmer TDD und SOLID kennen und nutzen, scheint es nur geringe Auswirkungen auf die Code-Qualität zu haben. Nach meiner These nützt das beste Handwerkszeug nichts, wenn man es unter Druck nicht anwendet.

Daher mein Argument, wir müssten Berufsehre für unsere Branche etablieren: Wir sind stolz auf unseren Code und schreiben nichts, was unter diesem (subjektiven) Qualitätsstandard liegt. Nichts. Niemals. Und wenn wir dort angekommen sind, werden uns Vorgehensweisen wie TDD und Entwurfsprinzipien wie SOLID wirklich wichtige Dienste leisten.

Warum man das Manifesto for Software Craftsmanship unterzeichnen und sich ein Clean-Code-Armband besorgen sollte, steht in den Folien.

September 21, 2010 at 11:43 am 1 comment

Wasteful Scrum Meetings

Sometimes the Scrum meetings (planning, review, retrospective, daily scrum) are considered to be wasteful overhead.

Sorry, but that is bullshit. If the Scrum meetings feel like wasteful overhead, it is almost always your own failure.

Focus is one of the Scrum values. If your Scrum meetings feel wasteful, they need better focus. Stop doing the things that don’t provide value.

Let’s look at the meetings one by one.

Estimation Meeting

During the estimation meeting two things should happen:

  1. The product backlog items are estimated by the team.
  2. More important: Knowledge is shared between Product Owner and Team and the Team participates in definition, splitting and refining product backlog items.

If the Product Owner doesn’t have to forecast a release date or development effort, he could simply skip point 1. An alternative could be to use a very rough estimate and simply use an estimation of 1 story point for every backlog item.

If the product backlog items are simple and clear point 2 may not be neccessary. In that case you could simply skip it.

If both points aren’t neccessary you can skip the whole meeting. There is a reason that the estimation meeting is not an official part of Scrum.

Sprint Planning

The goal of the sprint planning is of course to plan the Sprint. It is dependent on the team how it is done best and how much effort the team has to invest. I have seen teams doing a Sprint Planning in a few minutes.

Doing a task breakdown is a proven practice during the Sprint Planning but it is not a must. If the team can generate value with only considering the stories, the team doesn’t need to do a task breakdown during the Sprint Planning. The team could do an ad-hoc task breakdown when it begins working on the story. If the stories are really tiny the team may need no task breakdown at all.

Sprint Review

If the Product Owner is colocated with the development team he should have seen the implemented stories before the Sprint Review. Therefore there may be no need to present the stories again to the Product Owner during the Sprint Review. But there is much more to the Sprint Review. The Product Owner should invite the stakeholders to the Sprint Review meeting so that they can get a first-hand impression about status and progress of the development.

Sprint Retrospective

The Sprint Retrospective is the focus point where the teams tries to improve. If the retrospectives feel like waste, the facilitator is probably not doing his job effectivly.

Daily Scrum

The 15 minutes of the Daily Scrum should help the development team to focus on the next step within the Sprint. The team finds out where it stands and defines the plan for the day. A team may or may not use the full 15 minutes. But if there is a team the members simply have to coordinate. Within very small teams (e.g. 2 persons) there may be no need for a Daily Scrum. But even in these cases I have seen Daily Scrums to be very useful.

Similar to the retrospectives: If the Daily Scrum feels like waste, probably the ScrumMaster isn’t facilitating effectivly.

Assumptions

There are two assumptions underlying this blog post:

  • You want to work with a team and not just a group of people.
  • You want to work with timeboxed Sprints.

If one of these assumptions doesn’t hold true, one may come to other conclusions.

July 12, 2010 at 12:28 pm 2 comments

Retrospektiven-Training am 25.08.2010 in Hamburg

Retrospektiven sind das Mittel in agilen Projekten, um die Entwicklung kontinuierlich zu verbessern. Mit der Qualität der Retrospektiven steigt und fällt das Potenzial zu Verbesserung. Es ist also extrem wichtig, dass Retrospektiven qualifiziert vorbereitet und moderiert werden.

it-agile bietet am 25.08.2010 ein eintägiges Training zur Vorbereitung und Durchführung bon Retrospektiven an. Es eignet sich für alle, die Retrospektiven durchführen wollen, z.B. für ScrumMaster.

Ich werde das Training mit Josef Scherer durchführen, der wie ich langjährige Erfahrungen in agilen Projekten mitbringt.

Die Anmeldung und mehr Infos zum Retrospektiven Training findet Ihr hier:http://www.it-agile.de/retrospektiven-schulung.html

July 5, 2010 at 7:48 pm Leave a comment

Older Posts