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

Older Posts