Donnerstag, 29. März 2007

Best Practise: Daily Scrum mit Excel

Während ich sehr gute Erfahrungen mit TargetProcess als Management -Tool für agile Softwareprojekte gemacht habe, verwende ich neben TP noch Excel für den Daily Scrum.

Hier werden von jedem Team-Mitglied folgende Fragen beantwortet:
  • Was hast Du gestern gemacht?
  • Was machst Du heute?
  • Was hindert Dich Deine Arbeit zu machen?
Daily Scrum ist ein formloses, 15-minütiges Stand-up Meeting.

Das Protokoll (Excel) wird anschliessend aufs Team-Wiki hochgeladen und per plug-in der Reiter "Today" ausgelesen. So kann jedes Teammitglied im Wiki schnell das Tagesgeschehen einsehen.

Als Vorlage hier ein Beispiel: sprint-6-daily-scrum.xls

Mittwoch, 28. März 2007

Braucht es eine Rolle - Tester ?

Nach Scrum gibt es folgende Rollen:
  • Scrum Master
  • Product Owner
  • Scrum Team
Diese Rollen werden vor dem Projektbeginn definiert und personifiziert. Eine Rollenaufteilung innerhalb des Scrum Teams ist nicht vorgesehen. Nach Scrum ist das Team selbstorganisierent. Eine Aufgabenverteilung ausserhalb des Scrum Teams ist nicht vorgesehen.

Klar ist, dass getestet werden muss, da sonst die Definition von DONE nicht erreicht wird und somit eine User Story nicht im Sprint zum Abschluss gebracht werden kann.

Wer macht das Testing? Gibt es einen Tester?
Entgegen vieler Annahmen gibt es im Scrum Team keinen dedizierten Tester! Warum?

Das Team löst eine Aufgabe, nicht einzelne Personen bzw. Rollen. Scrum ist Teamarbeit und fördert das "Wir"-Gefühl. "Wir" haben eine Aufgabe, nicht "Ich" habe ein Aufgabe. Gemeinsam wird eine Aufgabe in den Zustand DONE gebracht:
  • Dokumentiert
  • Implementiert
  • Reviewed
  • Getestet
Geht man davon aus, dass man automatisierte Test mit einer Abdeckung von 99% hat, was in einem agilen Software Entwicklungsprojekt unbedingt angestrebt werden sollte, so stellt sich nicht die Frage: "Wer testet?", sondern "Wer schreibt die Tests und wann?".

Test werden zum Zeitpunkt der Erfassung der User Stories "geschrieben", sagen wir dokumentiert. Sie stellen User Acceptance Test(UAT) dar. Der User kann als Kunde (Product Owner) bzw. Benutzer des Systems ausgelegt werden. Wie auch immer, der User definiert ob und wie ein User Story brauchbar (valuable) ist. UAT kann man als Abnahme Tests verstehen.
Vor dem Review einer User Story werden die Tests automatisiert. Nur wenn der Review im Team und der automatisierte Test erfolgreich waren, ist DONE erreicht.

Montag, 26. März 2007

iSBB - SBB Fahrplan auf dem iPod


Nervig, oder? Immer den iPod dabei, aber nie den SBB Fahrplan ... Hier die Lösung!

Man benötigt einen iPod Video, sonst funktionierts nicht! So gehts:

Bei der SBB einen persönlichen Fahrplan erstellen und per Email zusenden lassen.
Mit einem Tool der Wahl den iSBB Fahrplan erstellen, z.B. Excel. Ich persönlich habe den SBB Fahrplan aus von PDF direkt in Excel übernommen, dann muss man nix abtippen ;-).

Dann Screenshot von den Fahrplänen machen (320x240px) und auf den iPod synchronisieren - DONE!

Ich hab das am Beispiel von Kreuzlingen - St. Gallen zusammengestellt:
  1. Runterladen
  2. Entzippen
  3. Mit iTunes auf als Photos auf den iPod synchronisieren.

Viele Spass!

Wer noch weiter gehen möchte, es gibt auch schon U-Bahn Pläne für den iPod - iSubwayMaps.com.

Sonntag, 25. März 2007

Scrum Einführung

Peter Stevens, Scrum Master bei der namics ag, hält einen Vortrag zum Thema Scrum. Er veranschaulicht am Beispiel eines Transportunternehmens auf dem Weg von Neapel nach Amsterdam, wie und warum klassisches Projektmanagement bei Software Projekten scheitert und wie man mit agiler Managementmethode gegensteuern kann.

Sehr interessant .... was ist, wenn der Gotthard geschlossen ist?
Zum Anschauen: http://www.simplex.tv/xbend/simplex/34/266 - Enjoy!

Dienstag, 13. März 2007

2-tier Continuous Integration

Wie stellt man eine Umgebung für dauerhafte Test bereit? Die Frage ist nicht leicht zu beantworten. Zunächst ist es wichtig zu unterscheiden, was getestet werden soll. Bei der Entwicklung von Software sind das meistens Modul- und Integrationstests. Diese werden oft mit Hilfe eines entsprechendes Framework von den Entwicklern programmiert (z.B. JUnit/NUnit) und nach dem nightly build automatisiert angestossen (z.B. mit CruiseControl).

Bei der agilen Softwareentwicklung kommen kontinuierliche GUI Test hinzu. Aufgrund der Tatsache, dass man iterativ an einer Software entwickelt und stets brauchbare Funktionalität abliefern soll, ist es unerlässlich, dass man bereits implementierte Funktionen re-testet. Aber was soll getestet werden? Entgegen Modul- und Integrationstest, die meist diverse Worst-Case Szenarien abdecken, wird beim GUI Testing ein White-List Verfahren auf Ebene der Funktionen durchgeführt. Unter White-Test versteht man in diesem Zusammenhang das Vorhandensein und "korrekt arbeiten" von Funktionen, nicht jedoch Test, bei denen alle möglichen (fehlerhaften) Eingaben von Benutzer getestet werden (Black-List Testing). Im Vordergrund dieser Test steht die Sicherstlellung der kontinuierlichen Kundenakzeptanz.

Wie stellt man das sicher? Es gibt einen Ansatz - 2tier Continuous Integration. Darunter versteht man einerseits Modul- und Integrationstest (first tier) und GUI Akzeptanztests (second tier). Die folgenden Graphiken soll die Prozess veranschaulichen:





Idealerweise führt jeder Entwickler vor dem Checkin die Akzeptanztests auf seiner Entwicklermaschine aus. Je nach der Done Definition des Teams ist es sogar erforderlich, das alle Test erfolgreich waren, bevor man eincheckt.

Gibt es dafür Tools? Ja, Buildix. Dazu gibt es bereits einen Blog-Eintrag...

Buildix

Oft stellt beim Thema "continuous integration" die Frage, gibt ein Tool, was viel bietet ohne viel Aufwand zubetreiben? Ja, Buildix!

Buildix ist ein auf Debian basierende Knoppix Distribution, die ein Set von Tools für agile Softwarentwicklung mitbringt.



Auf einfache Weise vereint Buildix User Verwaltung (htaccess files per Apache), automatisierte Builds (CruiseControl), Projektmanagement (Trac), Reporting (nightly builds & tests) und Suversion Repository Browsing mit Kommentaren der letzen Modifkationen am Source Code.

Durch einen integrierten Apache können sämtliche Konfigruationen am Buildix System per Browser via Http vorgenommen werden. Da das System auf Knoppix baisert ist Buildix "ohne" grosse Konfiguration aufgesetzt - image runterladen, CD Brennen, booten - Fertig!

Man kann Buildix aus Sicht eines Entwicklers als Video ansehen, so bekommt man einen kurzen Überblick über das Produkt.

Gibts schon jemand, der Buildix verwendet? Erfahrungsberichte?

Selenium: The in-browser acceptance testing tool



http://video.google.com/videoplay?docid=-594153467742593805&q=selenium

Montag, 12. März 2007

Continuous Testing

Oft wird im Zusammenhang mit Scrum von ein automatisiertem Testing gesprochen. Abgeleitet ist der Ansatz vom eXtreme Programming - Test Driven Development (TDD).
Während TDD die Strategie verfolgt, dass man einen Test "schreibt" bevor man die Entwicklung beginnt geht automatisiertes Testing noch einen Schritt weiter- man automatisiert die Tests auf täglicher Basis, ähnlich einem nigthly build.

Wie kommt man zu den Tests und was wird getestet?
Entgegen einem Modul-Test mit JUnit werden beim Testing in Verbindung mit Scrum die Akzetpanz getestet. Voraussetzung ist eine User Story. An der User Story werden Notes und Contraints vermerkt. Daraus lassen sich Akzeptanztests ableiten.
Beispiel-User Story:
Man kann mit Kreditkarte bezahlen
Note: MasterCard, Visa
Contraint: Betrag > 0, Karte nicht abgelaufen oder gesperrt

Daraus ergeben sich folgende Tests, die vor der Implementierung "geschrieben" werden.
Kartezahlung mit MasterCard und Visa.
Kartenzahlung mit Betrag <>
Kartenzahlung mit abgelaufener Karte.
Kartenzahlung mit gesperrter Karte.

Die Definition von "geschrieben" wird vom Team bestimmt. Oft ist es so, dass man dabei lediglich von einer Notiz in Papierform ausgeht, nicht von JUnit Test Implementierungen. Die Idee ist, dass man zusammen mit dem Product Owner die Aufgabe hinterfragt und somit die Abnahmekriterien definiert. Man spricht dann von User Acceptance Tests, wobei unter User in diesem Zusammenhang der Product Owner verstanden wird.
Ziel ist es, dass jeder im Team versteht, was der Kunde möchte.

Diese Tests werden dann nach der Realisieriung mit einem FIT (Framework for Integrated Tests) Tool aufgezeichnet und automatisiert.

Warum soll man automatisiert Testen?
Durch die interative Arbeitsweise hat der Kunde stets die Möglichkeit seine Prioritäten zu verlagern bzw. neue Wünsche ins Produkt aufzunehmen. Das Team in einem Sprint-Arbeitstakt an den Wünschen des Kunden. Damit kann von Sprint zu Sprint die Code-Basis bis zu 50% ändern, da man Synergien nutzen kann, die es vorher nicht gabt oder Vereinfachungen und Widerverwendung zum Tragen kommen.
Oft ist wird eine User Story erst nach mehreren Sprints vollständig abgeschlossen. Mit Akzeptanztests kann sichergestellt werden, dass alle bisher entwickelten Funktionen noch immer den Wünschen des Kunden entsprechen.

Wann sollte man Testen?
Gemäss der "Done" Definition sollen alle Funktionen lauffähig sein. Dazu gehört aber auch, dass alle bereits vorgeführten Funktionen auch noch laufen. Demnach kann man eine User Story erst als Done markieren, wenn alle Tests erfolgreich waren, d.h. vor dem Check-In müssen alle Akzeptanztest erfolgreich sein.

Wieviel sollte man Testen?
Es ist unmöglich, 100% zu testen. Im Vordergrund stehen die Tests, deren Akzeptanz vom Kunden erforderlich ist. Wenn man 60% des gesamten Produkts mit Akzeptanztest testen kann, hat man schon sehr viel erreicht!

Scrum Regeln

Scrum ist ein sehr restriktives Projektmanagement. Scrum definiert die Zusammenarbeit des Kunden mit dem Projektteam sowie die Entwicklung eines Produktes mittels agiler Methodik. Scrum ist die Projektmanagement Methode zum bekannten XP Entwicklngsprozess, bei dem sich die Begrifflichkeiten und Grundideen stark überschneiden. So gibt es bei XP Interationen, Pair Programming, Test Driven Develoment und viele andere Ansätze, die so oder so ähnlich bei Scrum wiedergefunden werden. Scrum legt ein strenge organisatorische Sicht über den agilen Entwicklungsprozess. Dazu zählen:

  • Sprint Planning Meeting
    Das Planning Meeting ist in zwei Teile unterteilt: Planning und Estimation, je ca. 4 Stunden. Der Kunde, vertreten durch den Product Owner stellt im Teil 1 - Planning - seine Wünsche und Prioritäten vor. Das Team hat die Möglichkeit Fragen zu stellen. Anschliessend schätzt das Team den Aufwand für die Wünsche - Estimation. Der Product Onwer ist in dieser Phase nicht anwesend. Der Aufwand wird in Story Points oder Ideal Days geschätzt. Sowohl beim Planning und bei der Estimation ist das gesamte Team anwesend.
  • Sprint
    Ein Sprint entspricht einer Interation nach XP. Ein Sprint dauert idealerweise zwischen 1 und 4 Wochen und representiert den Arbeitstakt des Teams. Nach jedem Sprint liefert das Team brauchbare Funktionalität und bekommt dafür alle Story Points. Ziel ist es, so viel Story Points wie möglich pro Sprint zu "verdienen".
  • Sprint Demo
    Am Ende eines Sprints werden die Funktionen präsentiert. Dabei kann der Product Owner den Entwicklungsstand selbst prüfen und gegebenenfalls für den kommenden Sprint seine Prioriäten verschieben bzw. neue Wünsche äussern. Die Sprint Demo dauert ca. 4h. Das gesamte Team ist anwesend.
  • Sprint Retrospecitve
    Im Anschluss an den vergangenen Sprint gibt es eine 4 stündige Retrospecive, wo das gesamte Team anwesend ist und man hinterfragt was besonders gut war, bzw. wo es Optimierungspotenzial gibt. Es werden Massnahmen zur Verbesserung vom Team definiert. Der Scrum Master moderiert.
  • Daily Scrum
    Der Daily Scrum wird vom Scrum Master moderiert. Er findet täglich statt und dauert 15 min. Es werden folgende Fragen von jedem Teammitglied beantwortet: "Was hab ich gestern gemacht", "Was mache ich heute" und "Was sind meine Hindernisse". Idealerweise sollte pro Aktivität Ziele definiert werden, die an einem Tag erreicht werden. Der Daily Scrum soll die Kommunikation und Transparenz im Team steigern - jeder weiss, woran gerade im Team gearbeitet wird. Unentschuldigtes Fehlen ist nicht erlaubt. Man kann telefonisch oder vertreten durch ein Teammitglied teilnehmen. Physische Anwesenheit ist nicht Pflicht.

Da es zu Beginn meistens ungewohnt ist, täglich zu einem Daily Scrum zu erscheinen, kommt es häuft vor, das von den 15min schnell 5min für Warten auf andere Teammitglieder verschwendet wird. Hierfür haben wir ein Team-Sparschwein angeschafft und es gelten folgende Regeln:
  • Wer bei Meetings zu spät kommt, zahlt einen Beitrag X ans Sparschwein.
  • Wer bei Meetings unentschuldigt fehlt, zahlt einen Betrag X ans Sparschwein.
  • Überzieht der Scrum Master das 15 minütige Daily Scrum, zahlt er ebenfalls.
  • Wird in Meetings das Handy abgenommen, zahlt man einen Betrag X ans Sparschein.
Das Team-Sparschwein wird regelmässig nach der Sprint Demo geschlachtet ;-)

Simon Roberts - Einführung in Scrum

Simon Roberts gibt eine Einführung in Scrum in deutsch. Unter anderem gibt es auch eine Übersetzung in portugiesisch (Cesar Brod) und französisch (Claude Aubry)...

C.Aubry arbeitet übrigens auch am Eclipse Process Framework Project (EPF) an einem Scrum Plug-in: http://www.eclipse.org/epf/downloads/scrum/scrum_downloads.php

Scrum Glossary

Auf ScrumAlliance.org gibts eine komplettes Glossar der Scrum Begifflichkeiten ...
[Quelle: http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms]

Samstag, 10. März 2007

ScrumWiki

Heute habe ich bei Scrum Allince eine Link auf ScrumWiki gefunden - generell ein gewöhnliches Wiki, ähnlich Confluence oder Wikipedia, aber...

Neben üblichen Wiki-Funktionen bietet ScrumWiki ein paar sehr einfache, aber gute Templates für
  • Teamverwaltung
  • Product Backlog- Verwaltung
  • Sprintverwaltung inkl. Burndown Charts!!
  • Taskverwaltung
  • Estimation & Planning
ScrumWiki ist Open Source. Es läuft auf Linux und Windows.

Gibts schon Erfahrungen damit? Wie gut ist ScrumWiki?

http://www.scrumwiki.org/

Freitag, 9. März 2007

Scrum Master: Leader of the Band

Mike Cohn schreibt diese Woche in seinem Artikel bei ScrumAlliance "Leader of the Band" über die Eigenschaften, die ein Scrum Master haben sollte und begründet, warum er das so sieht. Es empfiehlt sich, sofern man gerade in einem agilen Projekt arbeitet und einen Scrum Master hat, diese Punkte kritisch hinterfragen.

Verantwortlichkeit: Der Scrum Master übernimmt nicht die Verantwortung für den Erfolg des Projekts. Diese Verantwortung wird vom Team übernommen. Der Scrum Master ist verantwortlich, dass das Team "Scrum" als Projek-Mangement Methode annimmt und nach deren Regeln arbeitet.

Menschlichkeit: Ein guter Scrum Master übernimmt die Aufgabe nicht des Egos wegen - "Schau, was wir alles erreicht haben!" - statt "Schau, was ich erreicht habe!" Er tut was auch immer getan werden muss um gemeinsam zum Erfolg zu kommen, d.h. er stellt auch mal seine Bedürnisse zurück, wenn es der Sache dient. Er wertschätzt jeden einzelnen im Team und sorgt dafür, dass alle diese Sichtweise haben.

Gemeinschaftlichkeit: Ein guter Scrum Master sorgt dafür, dass der Gemeinschaftgedanke im Team "lebt" und "gelebt wird". Er sorgt dafür, dass jeder einzelne im Team das Gefühl hat, er können jederzeit seine Meinung kundtun. Er unterstützt und stärkt die Gemeinschaft indem er selbst so handelt und damit das Wir-Gefühl unterstreicht.

Verfügbarkeit: Die Scrum Master Rolle ist keine Vollzeitstelle, trotzdem braucht es einen Scrum Master, der jederzeit verfügbar ist. Er ist zur Verfügbarkeit verpflichtet, wie jedes einzelne Teammitglied sich verpflichtet hat, innerhalb des Sprints die angenommen Aufgaben zu lösen. Er sollte die Hindernisse des Teams nicht verschleppen, sondern jedem einzelnem Nachgehen. Hindernisse vom Team sollten nach dem Daily Scrum nicht gelöscht werden, da es Hindernisse geben kann, die eine längere Zeit zur Behebung brauchen. Obwohl der Scrum Master keine Vollzeitstelle ist, sollte er sich für die gesamte Projektdauer verpflichtet fühlen. Es gibt nichts unangenehmeres für das Team als ein Scrum Master Wechsel während des Projekts.

Einflussreich: Der Scrum Master sollte die "Macht" haben, auf Teammitglieder und Personen ausserhalb des Teams genügend Einfluss ausüben zu können. Zu Beginn muss der Scrum Master das Team sicher beinflussen, so dass man Scrum überhaupt eine Chance gibt. Später in einem agilen Projekt sollte der Scrum Master das Team mit Innovationen beinflussen, z.B. neue Technologien einzusetzen. Er sollte das richtige Mass an Einfluss finden, um nicht "command-and-control" Mentalität an den Tag zu legen. Das ist nicht förderlich. Oft ist des der Wunsch und das Bedürniss des Teams von äusseren Einflüssen ferngehalten zu werden - eine sehr wichtige Aufgabe, die der Scrum Master hat.

Sachkenntnisse: Der perfekte Scrum Master hat sowohl technische, betriebswirtschaftliche, Markt- und sonstige Kenntnisse, die er dem Team zu Erfüllung der Aufgabe zur Verfügung stellt. Ein Mindestmass an Detailwissen, wie etwas funktionieren kann oder nicht, muss der Scum Master haben, damit er dem Team auf einem Meta-Level die Richtung weisen und führen kann. Die Sachkenntniss sollte eher breit als tief sein, aber sollte mit den technischen Feinheiten des Projekts vertraut sein.

Also, was meint Ihr?

Selenium IDE - Recording a Test



http://wiki.openqa.org/display/SIDE/Recording+a+Test

Dienstag, 6. März 2007

User Acceptance Testing

Nach Extreme Progromming (XP) ein wichtiger Ansatz, dass man erst einen Test schreibt, bevor man die Implementierung beginnt, auch bekannt als Test Driven Development (TDD).


Für die Durchführung von Tests gibt es diverse Frameworks, z.B. JUnit (Erich Gamma and Kent Beck, http://junit.org). Sie dienen in erster Linie für Integrationstest. Diese werden meistens nächtlich (nightly build) automatisiert durchlaufen und charakterisieren "Modul-" bzw. "Integrationstest". Sie sind technischer Natur und prüfen technische Belange, z.B. DB Connection, korrekte Berechnungen, CRUD Operationen auf Objekten, etc.

Zusätzlich gibt es (User) Acceptance Tests (UAT): Die Idee ist, dass man die entwickelten Features einer Applikation, die iterativ entwickelt wird, stetig einem Akzpeptanztest unterzieht. Geprüft wird, ob das entwickelte Feature das tut, was erwartet wird, was es tun soll. Dies kann der Product Owner oder ein (fremder) Benutzer des Systems verfizieren. Man spricht bei UAT von einem System-under-test (SUT).

Ward Cunningham hat dafür ein einfaches Framework entwickelt: FIT, Framework for Integrated Test: "Fit is a tool for enhancing communication and collaboration. Fit creates a feedback loop between customers and programmers. Fit allows customers and testers to use tools like Microsoft Office to give examples of how a program should behave--without being programmers themselves. Fit automatically checks those examples against the actual program, thus building a simple and powerful bridge between the business and software engineering worlds."[Quelle: http://fit.c2.com/wiki.cgi?IntroductionToFit]

Es ist sehr einfach die Acceptance Test zu definieren, gemeinsam mit dem Kunden/Product Owner, z.B. mit Excel.

FIT selbst basieren auf HTML, was sich leicht aus dem Excel Sheet generieren lässt. Fit Tools parsen einen speziellen HTML Syntax und verarbeiten diesen als Tests. Dafür muss pro Excel Tabelle ein "fixture" codiert werden.
Das ist sehr mühsam und bedeutet, dass man Development-Skills benötigt, um einen Test zu schreiben.

Selenium ist ein Tool, dass auf dem FIT HTML Syntax basiert, aber zunächst keine codierung von "fixture" benötigt. Es wurde ThoughtWorks entwickelt. Man kann mit der Selenium IDE als Browser plug-in Test einfach aufzeichnen.

Mit Selenium Remote Control besteht auch die Möglichkeit Test in einer beliebigen Sprache zu implementieren.