Zweimal jährlich macht CNN bei der Business 2.0 Initiative ein Umfrage zu Persönlichkeiten, neuen Ideen, Trends und Produkten, die die Geschäftswelt beinflussen und verändern.
Agile Softwareentwicklung als "neuer" Ansatz für web-basiertes Softwareentwicklung belegt Platz 18!
CNNMoney.com
Samstag, 30. Juni 2007
Donnerstag, 28. Juni 2007
TheServerSide: Test Driven Development
Bei TDD, oder auch Test Driven Development genannt, geht es nicht primär ums Testen, sondern es geht um gute Programmierung! Genauer, wie schreibt man Code, der sich testen lässt.
Es gibt da mehrere Ansätze, ein Beispiel-Dependency Injection:
Schlecht!
public class MyServiceImpl implements ServiceInterface {
private final TheOtherService theOtherService;
public MyService() {
this.theOtherService = new TheOtherServiceImpl();
}
public int doIt(String a) {
return this.theOtherService.doSomething(a);
}
...
}
Besser!
public class MyServiceImpl implements ServiceInterface {
private final TheOtherService theOtherService;
public MyService(TheOtherService theOtherService) {
this.theOtherService = theOtherService;
}
...
}
Nur um dass nochmal deutlich klarzustellen: TheOtherService ist ein Interface! Die eigentliche Implementierung wird durch den Konfigrationskontext "incjected", z.B. Spring der JUnit in Verbindung mit JMock.
Warum? loose coupling! Im zweiten Beipiel kann man zum Bespiel ein Mock Object per Dependency Injection im Unit Test übergeben und prüfen, ob und wie Methoden von der injected Klasse aufgerufen werden. So kann sichergestellt werden, dass die Implementierung von ServiceInterface den(die) Aufrufe von einem Dao, einer Message Queue, einem SOA Endpoint etc. durchführt.
Unit Test:
public class MyServiceTestCase extends MockObjectTestCase {
public void testSomething() {
Mock mock = new Mock(TheOtherService.class);
...
ServiceInterface objectUnderTest = new MyServiceImpl(mock );
objectUnderTest.doIt("foo.bar");
mock.expects(once()).method("doSomething").with(eq(a))
.will(returnValue(result1));
...
}
...
}
Grundsätzlich gilt bei TDD der "red-green-refactor-mantra".Erst schreibt man einen Test, der wird zunächst mal failen (red). Dann schreibt man die Implementierung und lässt den Test erneut laufen. Jetzt sollte er passen (green). Bei jedem folgendem Refactoring sollten die Tests ohne Modifikation immer "green" sein!
Ein ständiger red-green-red-green Lifecylce ist nicht die Idee!
Es gibt da mehrere Ansätze, ein Beispiel-Dependency Injection:
Schlecht!
public class MyServiceImpl implements ServiceInterface {
private final TheOtherService theOtherService;
public MyService() {
this.theOtherService = new TheOtherServiceImpl();
}
public int doIt(String a) {
return this.theOtherService.doSomething(a);
}
...
}
Besser!
public class MyServiceImpl implements ServiceInterface {
private final TheOtherService theOtherService;
public MyService(TheOtherService theOtherService) {
this.theOtherService = theOtherService;
}
...
}
Nur um dass nochmal deutlich klarzustellen: TheOtherService ist ein Interface! Die eigentliche Implementierung wird durch den Konfigrationskontext "incjected", z.B. Spring der JUnit in Verbindung mit JMock.
Warum? loose coupling! Im zweiten Beipiel kann man zum Bespiel ein Mock Object per Dependency Injection im Unit Test übergeben und prüfen, ob und wie Methoden von der injected Klasse aufgerufen werden. So kann sichergestellt werden, dass die Implementierung von ServiceInterface den(die) Aufrufe von einem Dao, einer Message Queue, einem SOA Endpoint etc. durchführt.
Unit Test:
public class MyServiceTestCase extends MockObjectTestCase {
public void testSomething() {
Mock mock = new Mock(TheOtherService.class);
...
ServiceInterface objectUnderTest = new MyServiceImpl(mock );
objectUnderTest.doIt("foo.bar");
mock.expects(once()).method("doSomething").with(eq(a))
.will(returnValue(result1));
...
}
...
}
Grundsätzlich gilt bei TDD der "red-green-refactor-mantra".Erst schreibt man einen Test, der wird zunächst mal failen (red). Dann schreibt man die Implementierung und lässt den Test erneut laufen. Jetzt sollte er passen (green). Bei jedem folgendem Refactoring sollten die Tests ohne Modifikation immer "green" sein!
Ein ständiger red-green-red-green Lifecylce ist nicht die Idee!
TheServerSide: WIFI ist teuer und funktioniert nicht!
Der System Engineer ist sichtlich überrascht, als ich mit meiner Maschine vor ihm stehe und er einen Blick auf die Meldung "Es besteht ein IP Adressenkonflikt mit einem anderen System im Netzwerk" wirft. Er erklärt mir auch noch nett und freundlich, dass es 2 DHCP Server gebe und er nun in den Keller geht, um einen davon zu re-booten. Ich soll dann in ein paar Minuten noch mal einen Versuch starten....
Das war von ca. 1.5 Stunden - nothing happend! Es hat sich rumgesprochen und es gibt noch ein paar andere Kursteilnehmen mit ähnlichen Leiden ...Ok, wer führt nach die Verhandlungen über ein "Geld-Zurück" Deal, denn WIFI ist ja teuer ...
Das war von ca. 1.5 Stunden - nothing happend! Es hat sich rumgesprochen und es gibt noch ein paar andere Kursteilnehmen mit ähnlichen Leiden ...Ok, wer führt nach die Verhandlungen über ein "Geld-Zurück" Deal, denn WIFI ist ja teuer ...
Mittwoch, 27. Juni 2007
TheServerSide: Agile Software Development in the Large
Jutta Eckstein (www.jeckstein.com) berichtet zunächst über die Geschichte der agilen Software Enwicklung, geht aufs agile Manifest ein, schildert das agile Wertesystem und deren Prinzipien.
Wie sieht jetzt aber Software Development in grossen Projekten aus (Gross heisst hier mehr als 12 Members)?
Neben dem allgemeinenen Erläuterungen zum agilen Vorgehen im Allgemeinen habe ich folgende Punkte herausgenommen, die neu für mich sind:
1. Feature-Teams
Wenn mehrere Teams an einem Feature arbeiten, z.B. Datenbank Team, Business Analyst Team und Sofware Developer Team, so ist es wichtig, dass jedes Team einen Teil der Verantwortung für ein Feature übernimmt. Wenn nicht, kommt es leicht zu Situationen, wo ein Team am Ende argumentiert:
"Ja, wir waren ja fertig, aber die anderen nicht, weil ...".
Um das zu vermeiden gibt es pro Feature aus jedem Team einen Verantwortlichen - in der Summe dann das Feature Team.
2. Done-Done
Bei einem Multi-Team Projekt kommt es schnell vor, das ein Team ein Feature auf Done setzt, teamübergreifend das aber nicht der Fall ist. Dafür verwendet man einen neuen Zustand für ein Feature: Done-Done, was soviel bedeutet, wie dass ein Feature vom Feature Team auf Done gesetzt wurde und definitiv done ist.
3. Resourcen-Sharing
Um die Kommunikation zu beschleunigen werden die Resourcen der Teams in einem rotierendem Modus ausgetauscht. Damit sind alle Team Members auch teamübergreifend immer syncronisiert.
4. Communication faciliator
Um sicherzustellen, das alle Informationen fliessen und das gesamte Team fokussiert an den Kundenwünsch arbeitet, sollte ein Chief Architect eingesetzt werden. Er ist zentrale Anlaufstelle für neue Ideen, technische Fragen und für generelle Problemstellungen.
5. Common Development Culture
Es ist wichtig, dass es eine gemeinsame "Entwicklungs-Kultur" gibt. Dazu zählen Code-Guidelines, Code Reviews, extreme Programming, Unit Testing und so weiter. Um das gesamte Team auf dem laufenden zu halten bietet sich eine Projektplattform an, z.B. ein Wiki.
6. Staged Retrospective
Jedes Team macht ein eigenes Review Meeting und bringt die Top 3 Verbesserungsvorschläge bei einem Gesamt-Review-Meeting ein, bei dem von jedem Team nur eine Delegation gesandt anwesend ist.
Ok, hat jemand damit schon Erfahrungen gesammelt? Ich persönlich habe bisher nur in Teams < 8 Mitgliedern gearbeitet.
Wie sieht jetzt aber Software Development in grossen Projekten aus (Gross heisst hier mehr als 12 Members)?
Neben dem allgemeinenen Erläuterungen zum agilen Vorgehen im Allgemeinen habe ich folgende Punkte herausgenommen, die neu für mich sind:
1. Feature-Teams
Wenn mehrere Teams an einem Feature arbeiten, z.B. Datenbank Team, Business Analyst Team und Sofware Developer Team, so ist es wichtig, dass jedes Team einen Teil der Verantwortung für ein Feature übernimmt. Wenn nicht, kommt es leicht zu Situationen, wo ein Team am Ende argumentiert:
"Ja, wir waren ja fertig, aber die anderen nicht, weil ...".
Um das zu vermeiden gibt es pro Feature aus jedem Team einen Verantwortlichen - in der Summe dann das Feature Team.
2. Done-Done
Bei einem Multi-Team Projekt kommt es schnell vor, das ein Team ein Feature auf Done setzt, teamübergreifend das aber nicht der Fall ist. Dafür verwendet man einen neuen Zustand für ein Feature: Done-Done, was soviel bedeutet, wie dass ein Feature vom Feature Team auf Done gesetzt wurde und definitiv done ist.
3. Resourcen-Sharing
Um die Kommunikation zu beschleunigen werden die Resourcen der Teams in einem rotierendem Modus ausgetauscht. Damit sind alle Team Members auch teamübergreifend immer syncronisiert.
4. Communication faciliator
Um sicherzustellen, das alle Informationen fliessen und das gesamte Team fokussiert an den Kundenwünsch arbeitet, sollte ein Chief Architect eingesetzt werden. Er ist zentrale Anlaufstelle für neue Ideen, technische Fragen und für generelle Problemstellungen.
5. Common Development Culture
Es ist wichtig, dass es eine gemeinsame "Entwicklungs-Kultur" gibt. Dazu zählen Code-Guidelines, Code Reviews, extreme Programming, Unit Testing und so weiter. Um das gesamte Team auf dem laufenden zu halten bietet sich eine Projektplattform an, z.B. ein Wiki.
6. Staged Retrospective
Jedes Team macht ein eigenes Review Meeting und bringt die Top 3 Verbesserungsvorschläge bei einem Gesamt-Review-Meeting ein, bei dem von jedem Team nur eine Delegation gesandt anwesend ist.
Ok, hat jemand damit schon Erfahrungen gesammelt? Ich persönlich habe bisher nur in Teams < 8 Mitgliedern gearbeitet.
TheServerSide: Language-oriented Programming - DSL
Das TheServerSide Java Symposium, Barcelona hat soeben begonnen und er der erste Slot zum Thema 'Language-oriented Programming' wurde von Martin Fowler und Neal Ford gehalten (ThoughtWorks).
DSL - Domain Specific Language, das zentrale Thema in diesem Vortrag. Was ist DSL? DSL kann man am Beispiel einer menschlichen Sprache gut beschreiben. Wir verwenden Vokabeln, quasi API's. Vokabeln werden durch eine Grammatik, der Domain Specific Language, mit einer Semantik versehen. Je nach Sprache und Inhalt ergibt sich die Semantik.
DSL vs. API
Bei Domain Specific Language gibt es einen impliziten Kontext, beim API nicht, der muss explizit gemacht werden.
Bespiel: Kaffebestelllung bei Starbucks (DSL): "Ein Kaffe bitte, gross, mit Milch, kein Zucker, wenig Fett, zum Mitnehmen".
Beim API würde das in etwa so aussehen (Java API):
Coffee starbucksCoffee = new Coffee();
starbucksCoffee.setSize(Size.HUGE);
starbucksCoffee.setFatness(Fat.LOW);
starbucksCoffee.setSweetness(false);
etc.
Grundsätzlch unterscheidet man interne/embedded und externe DSL. JMock ist eine interne DSL (auch Fluent Interface genannt), externe DSL sind meistens XML basierte Beschreibungen und Konfigurationen, z.B. eine Konfiguration des Apache Webservers.
Warum DSL?
Ziel ist es, dass ein Business Analyst den Code lesen kann, um diesen zu verifizieren.
DSL - Domain Specific Language, das zentrale Thema in diesem Vortrag. Was ist DSL? DSL kann man am Beispiel einer menschlichen Sprache gut beschreiben. Wir verwenden Vokabeln, quasi API's. Vokabeln werden durch eine Grammatik, der Domain Specific Language, mit einer Semantik versehen. Je nach Sprache und Inhalt ergibt sich die Semantik.
DSL vs. API
Bei Domain Specific Language gibt es einen impliziten Kontext, beim API nicht, der muss explizit gemacht werden.
Bespiel: Kaffebestelllung bei Starbucks (DSL): "Ein Kaffe bitte, gross, mit Milch, kein Zucker, wenig Fett, zum Mitnehmen".
Beim API würde das in etwa so aussehen (Java API):
Coffee starbucksCoffee = new Coffee();
starbucksCoffee.setSize(Size.HUGE);
starbucksCoffee.setFatness(Fat.LOW);
starbucksCoffee.setSweetness(false);
etc.
Grundsätzlch unterscheidet man interne/embedded und externe DSL. JMock ist eine interne DSL (auch Fluent Interface genannt), externe DSL sind meistens XML basierte Beschreibungen und Konfigurationen, z.B. eine Konfiguration des Apache Webservers.
Warum DSL?
Ziel ist es, dass ein Business Analyst den Code lesen kann, um diesen zu verifizieren.
TheServerSide: WIFI ist teuer
Angekommen im Princesa Sofia Conference Hotel stellt sich natürlich die Frage, wie kommt man ins Internet? Hm, wohl nicht so ganz naheliegend, denn die Service Crew
ist sichtlich überrascht über mein Anliegen ;-)
Man bekommt einen WIFI Gutschein, einzulösen bei der Reception gegen eine kleine Gebühr von 45 Euro + 7% Steuer ...
Mal schnell rechnen: ca. 300 Teilnehmer à 45 Euro macht schlappe 13.500 Euro - da sind ja die Auslagen für die Veranstaltung schon fast refinanziert....
ist sichtlich überrascht über mein Anliegen ;-)
Man bekommt einen WIFI Gutschein, einzulösen bei der Reception gegen eine kleine Gebühr von 45 Euro + 7% Steuer ...
Mal schnell rechnen: ca. 300 Teilnehmer à 45 Euro macht schlappe 13.500 Euro - da sind ja die Auslagen für die Veranstaltung schon fast refinanziert....
Montag, 25. Juni 2007
Scrum trifft RUP
RUP - Rational Unified Process®
RUP ist ein strukturiertes Vorgehens- modell, Scrum ein agiles Vorgehens- modell - lässt sich das miteinander vereinbaren, kann man RUP "agilisieren"?
Joe Krebs, Senior IT Specialist , IBM Rational, schreibt in einem Artikel "RUP in the dialogue with Scrum" über RUP, Scrum, die wesentlichen unterschiede und wie man RUP mit agilem Ansatz erweitern kann.
Freitag, 22. Juni 2007
Scrum Projekt Abschluss
Wir schreiben die 10. Woche im aktuellen Scrum-Projekt und nach der Auslieferung von Release 4.0. am 18.Juni geht das Projekt dem Ende zu.
Momentan gibt es noch ein paar Abnahmen mit dem Kunden und die Inbetriebnahme beim Provider. Dannach ist das Projekt abgeschlossen. Zeit, mal ein paar Zahlen zu generieren:
Zeitraum: 13. April bis 18. Juni, 47 Arbeitstage
Team: 4 Developer, 1 Product Owner, 1 Scrum Master
# Story Points: 80 PT
Gesamtaufwand: 188 MT (47 Tage x 4 Developer)
# Sprints: 5, davon 1x 3 Wochen, 2x 1 Woche, 2x 2 Wochen
User Stories/Sprint: 9PT/1, 1PT/2, 26PT/3, 23PT/4, 21PT/5
Durschnitt/Sprint: 16 PT pro Sprint
# Releases: insgesamt 4
User Stories/Release: 9PT/1, 27PT/2, 23PT/3, 21PT/4
Durchschnitt/Release: 20 PT pro Release
# Bugs: 24
Ok, der Blick zurück - jetzt wird's interessant. Wie wurde denn das gesamte Projekt vor Beginn vom Team geschätzt?
Die Aufwandschätzung lag also im realistischen Bereich oberhalb der +40% Grenze!!! Mehr als doppelt so teuer! Die berichtigte Aufwandschätzung sieht wie folgt aus:
Bleibt die Frag offen, wieso 50 SP geschätzt und doch 80 realisert worden..... Das genau ist der Vorteil von agiler Entwicklung. Ein mal mehr war der Kunde "moving target" - d.h. er hat seine Prioritäten im Projekt verlangert, neue Ideen eingebracht und andere verworfen.
Momentan gibt es noch ein paar Abnahmen mit dem Kunden und die Inbetriebnahme beim Provider. Dannach ist das Projekt abgeschlossen. Zeit, mal ein paar Zahlen zu generieren:
Zeitraum: 13. April bis 18. Juni, 47 Arbeitstage
Team: 4 Developer, 1 Product Owner, 1 Scrum Master
# Story Points: 80 PT
Gesamtaufwand: 188 MT (47 Tage x 4 Developer)
# Sprints: 5, davon 1x 3 Wochen, 2x 1 Woche, 2x 2 Wochen
User Stories/Sprint: 9PT/1, 1PT/2, 26PT/3, 23PT/4, 21PT/5
Durschnitt/Sprint: 16 PT pro Sprint
# Releases: insgesamt 4
User Stories/Release: 9PT/1, 27PT/2, 23PT/3, 21PT/4
Durchschnitt/Release: 20 PT pro Release
# Bugs: 24
Ok, der Blick zurück - jetzt wird's interessant. Wie wurde denn das gesamte Projekt vor Beginn vom Team geschätzt?
Insgesamt wurden 50 Story Points für die gesamte Realisierung VOR Projektbeginn geschätzt. Aus Erfahrung aus anderen Scrum Projekten ist man von 2.5 MT pro 1 SP ausgegangen. Das ist die Basis für die Schätzung. Mit einer pessimistischen und optimistischen Abweichung kann man den Know-How Gap vom neuen Projekt ein bischen ausbalancieren. Mit einer Abweichung von -25% und + 40% kommt man dan bei optimisticher, realistischer und pessimistischer Schätzung auf:
Mit heutigem Wissen kann man dass richtige Verhältniss MT pro User Story leicht errechnen:
Die Aufwandschätzung lag also im realistischen Bereich oberhalb der +40% Grenze!!! Mehr als doppelt so teuer! Die berichtigte Aufwandschätzung sieht wie folgt aus:
Bleibt die Frag offen, wieso 50 SP geschätzt und doch 80 realisert worden..... Das genau ist der Vorteil von agiler Entwicklung. Ein mal mehr war der Kunde "moving target" - d.h. er hat seine Prioritäten im Projekt verlangert, neue Ideen eingebracht und andere verworfen.
Donnerstag, 21. Juni 2007
Eigenschaften einer User Story
Gestern habe ich in einem Post ein paar Beispiele gezeigt, wie User Stories nicht aussehen sollten. Nur um sicherzugehen, hier noch mal die Eigenschaften, die eine User Story ausmachen:
- Estimatable
- Valuable
- Negotiable
- Small
- Testable
- Independent
TheServerSide Java Symposium - Europe
Kommende Woche werde ich am Java Sympodium in Barcelona teilnehmen. Worauf ich mich besonders freue: GWT und JRuby ...Berichte folgen - stay tuned!
Mittwoch, 20. Juni 2007
Was sind KEINE User Stories
Nach ein paar Scrum Projekten habe ich so einige User Stories gesehen, die definitiv keine sind!
Ein paar Beispiele:
"Ein cooler mash-up mit Google Maps wird erwünscht"
"Navasys durch Google Maps ersetzen (Prototype)"
"Datenbank auf 3.0 migrieren"
"Funktion "Drucken" verwendet eine optimierte Darstellung"
"Anpassung "Schnellzugriff" im eingelogten Zustand"
Ok, was lernen wir? Wie man eine gute User Story schreibt ist nicht so einfach.
Man sollte sich immer wieder vor Augen führen, dass der User im Zentrum steht!
"Wer macht was um welches Ziel zu erreichen" - das ist Basisregel für eine User Story...
Ein paar Beispiele:
"Ein cooler mash-up mit Google Maps wird erwünscht"
"Navasys durch Google Maps ersetzen (Prototype)"
"Datenbank auf 3.0 migrieren"
"Funktion "Drucken" verwendet eine optimierte Darstellung"
"Anpassung "Schnellzugriff" im eingelogten Zustand"
Ok, was lernen wir? Wie man eine gute User Story schreibt ist nicht so einfach.
Man sollte sich immer wieder vor Augen führen, dass der User im Zentrum steht!
"Wer macht was um welches Ziel zu erreichen" - das ist Basisregel für eine User Story...
Dienstag, 19. Juni 2007
10 Gründe für Agile Development
- Wertschöpfung (Revenue)
Iterative Softwareentwicklung bedeutet in erster Linie inkrementelles Entwicklen von Features, um diese bereits früher bereitzustellen, während das Produkt noch (weiter)entwickelt wird. - Marktnähe (Time to market)
Es ist bekannt, dass 80 % der Marktführer mit ihrem Produkt/Service jeweils die ersten am Markt sind(waren). Neben der hohen Wertschöpfung trägt die Philosophie von frühen und regelmässigen Releases bei agiler Projekten nicht zuletzt auch dazu bei. - Qualität (Quality)
Ein wesentlicher Aspekt bei agilen Softwareentwicklungsprojekten ist, dass Testing ein integrativer Bestandteil des Produkt-Lebenszylus während der Entwicklung ist. Somit hat der Produkt Owner die Möglichkeit früh Abweichungen zu erkennen und im Rahmen der Sprint Planungen gegenzulenken. - Transparenz (Visibility)
Ein wesentlicher Grundsatz für agiles Arbeiten ist die Beteiligung von "aktiven" Personen während der gesamten Produktentwicklung - das Team. Jeder Stakeholder kann somit den Projekt- und Produktfortschritt verfolgen und somit sicherstellen, dass die geleistete Investition den gewünschten Ertrag bringt. - Risiko Management (Risk Management)
Kleine, regelmässige Releases ermöglichem dem Produkt Owner und dem Team schnell Probleme zu erkennen und frühzeitig darauf zu reagieren. Die Transparenz trägt dazu bei, dass alle nötigen Entscheidungen zu frühest möglichen Zeitpunkt getroffen werden können, um Probleme zu lösen. - Flexibilität (Flexibility / Agility)
Bei klassischen Softwareentwicklungsprojekten wird vor Projektbeginn eine Spezifikation geschrieben. Obendrein wird darauf hingewiesen, dass es teuer wird, wenn sich an der Spezifikation etwas ändern sollte, insbesondere wenn das Projekt bereits begonnen hat. Oftmals werden Changes hinausgezögert und ein Kontroll Organ eingesetzt, um sich vor never-ending Projekten und Verlagerungen des Scops zu schützen. Der agile Ansatz ist anders - Changes sind willkommen, genauer gesagt: werden erwartet! - Kostenkontrolle (Cost Control)
Der Zeitplan ist fix, der Umfang wage bekannt und natürlich gibt es auch ein fixes Budget. Der Projektscope und die Product Features sind variabel, die Kosten nicht. Der Produkt Owner hat alle Steuerungselemente in der Hand, um seine anfallenden Kosten zu kontrollieren und zu steuern, pro Sprint. - Business Engagement und Kundenzufriedenheit (Business Engagement/Customer Satisfaction)
Die aktive Beteiligung aller Mitglieder inklusive dem Product Owner, die hohe Transparenz des Projektverlaufs und die Flexibilität von Änderungen, wenn Änderungen notwendig sind erhöhen die die Kundenzufriedenheit und das Business Engagement. Dies sind wichtige Vorteile, die nicht zu letzt eine positive und nachhaltige Kundenbeziehung sicherstellen. - Das richtige Produkt
Aufgrund der gegebenen Flexibilität und regelmässigen Releases kann auf Marksituationen schnell und zielgenau reagiert werden. Mit agilen Entwicklungsprojekten steht der User im Zentrum der Aktiviäten. Man nennt das auch User Centered Design (UCD). - Spass an der Arbeit
Eine aktive Beteiligung, die Mit- und Zusammenarbeit von jedem einzelnen machen agile Entwicklungsteams für viele zu einem attraktivem Arbeitsumfeld.
Sonntag, 17. Juni 2007
Use Case, User Story und Szenario
Use Case, User Story und Szenarien - irgendwie ja alles das Gleiche, oder doch nicht?Ich meine, es ist sehr wichtig die einzelnen Begriffe doch deutlich voneinander abzugrenzen.
Ein Use Case ist eine graphische Modellierung eines Anwendungsfalls mittels UML.
Eine User Story ist eine formale Bescheibung einer Aktivität eines Benutzers mit einem System für agile Softwareentwicklung. Im Vordergrund steht die Frag: Wer macht Was, um welches Ziel zu erreichen.
Ein Szenario ist der User Story ähnlich, nur das zusätzlich zur Aktivität noch Rahmenbedinungen, Stimmungen, Gefühle und vieles mehr addressiert werden. Szenarien werden häufig bei der Modellierung von Personas verwendet.
Dienstag, 12. Juni 2007
Agile Development: Back to the future!
Kelly Waters schreibt gestern auf seinem Blog, wie man mit Features umgeht, die nach Ablauf eines Sprints nicht fertig gestellt wurden. Er beschreibt, wie man den Code für eine releasefähige Version verwalten und zurückrollen kann - daher der Name: "Back to the future!"
Er beschreibt, warum das nur theoretisch funktioniert, und warum das in der Praxis nicht so einfach ist.
agile-development-back-to-future
Er beschreibt, warum das nur theoretisch funktioniert, und warum das in der Praxis nicht so einfach ist.
agile-development-back-to-future
Montag, 11. Juni 2007
Wie führt man Scrum ein
Man hat sich mit agiler Vorgehensweise nach Scrum beschäftigt, befürwortet dieses Arbeitsweise, fragt sich, warum ma nicht schon immer so gearbeitet, hat ein paar Sympathisanten an seiner Seite und möchtes Scrum mal selbst "ausprobieren".
Die Frage lautet: Wie führt man Scrum ein?
Iterativ, alles auf einmal, mit oder ohne Kunden, etc? Viele Fragen, hier ein paar Antworten.
Aus meiner Erfahrung kann ich nur empfehlen, Scrum nur gesamthaft, d.h. mit allen Rollen und Ritualen einzuführen. Das bedeutet, Einführung von agiler Vorgehensweise von heute auf morgen, zur Stunde 0.
Wie kann man das vorbereiten? Schulen, Schulen, Schulen! Zunächst ist es wichtig, dass das zukünftige Scrum Team der Idee folgen kann/will. Dazu braucht es auch unmittelbar die Zustimmung der operativen Ebene in einem Unternehmen.
Ein paar "early adaptives" sind sehr wichtig. Es bietet sich an, dass man bestimmte Themen auf verschiedene Personen verteilt und ein paar Rollenspiele vor der Einführung organisiert. Es ist wichtig, dass das Team die Arbeitweise anerkennt und "lebt"....
Was macht man mit dem Kunden? ....coming soon.
Die Frage lautet: Wie führt man Scrum ein?
Iterativ, alles auf einmal, mit oder ohne Kunden, etc? Viele Fragen, hier ein paar Antworten.
Aus meiner Erfahrung kann ich nur empfehlen, Scrum nur gesamthaft, d.h. mit allen Rollen und Ritualen einzuführen. Das bedeutet, Einführung von agiler Vorgehensweise von heute auf morgen, zur Stunde 0.
Wie kann man das vorbereiten? Schulen, Schulen, Schulen! Zunächst ist es wichtig, dass das zukünftige Scrum Team der Idee folgen kann/will. Dazu braucht es auch unmittelbar die Zustimmung der operativen Ebene in einem Unternehmen.
Ein paar "early adaptives" sind sehr wichtig. Es bietet sich an, dass man bestimmte Themen auf verschiedene Personen verteilt und ein paar Rollenspiele vor der Einführung organisiert. Es ist wichtig, dass das Team die Arbeitweise anerkennt und "lebt"....
Was macht man mit dem Kunden? ....coming soon.
Release 3 ausgeliefert
Nach nur einem Sprint von 2 Wochen haben wir am Freitag den Release 3.0 ausgeliefert.Das Team hat insgesamt 23 Story Points, verteilt auf 8 User Stories, angenommen und zu 100% fertiggestellt. Zusätzlich wurde ein Bug bearbeitet.
Die Velocity in diesem Sprint betrug 23- damit ergibt sich ein Durchschnitt bisher von 19 Story Points pro Release.
Seit Projektbeginn Anfang April 07 hat das Team 59 Story Points abgearbeitet.
Das Projekt wird am 15. Juni mit einen weiteren Release abgeschlossen. Es sind noch 13 Story Points geplant.
Freitag, 8. Juni 2007
Daily Scrum mit TargetProcess, Teil III
Nach gut 4 Wochen mit der neuesten TargetProcess Version haben wir das Tool TaskBoard vielfach verwenden können, und - nicht mehr wegzudenken!
TaskBoard ist für die Auslegung des Daily Scrum optimal. Das Team hat dieses neue Werkzeug gut angenommen, jeder arbeitet damit und der Scrum Master, sowie Product Owner haben eine aussagekräftige Übersicht. Sehr gut.
Einzig ein neues Feature fehlt noch: automatisiertes Hinzufügen von Task, wenn eine User Story angelegt wird, z.B. Write a UAT, Write a Unit Test, etc.
Wer ist der Product Owner?
Scrum definiert eine Reihe von Ritualen und Rollen. Eine sehr wichtige Rolle ist der Product Owner, ich würde sogar sagen, dass dies die wichtigste Rolle eines Scrum Projekts ist.
Was, oder besser Wer genau ist der Product Owner?
Bei jedem Projekt gibt es einen Geldgeber, der Investor. Er verfügt über eine Budget zur Lösung diverser "Probleme" innerhalb des budgetierten Zeitraums. Er entscheidet, welche Projekte wieviel Budget in einer solchen Periode zugesprochen bekommen.
Wird einem Projekt Budget zugesprochen, gibt es einen Projekt Manager, der dieses Projekt leitet. Nach Scrum ist diese Person der Product Owner. Er steuert das Projekt. Er balanciert Investment und ROI. Darüber hinaus ist er der Interessenvertreter aller Stakeholder.
Das Scrum Team wird vom Product Owner gesteuert.
Was, oder besser Wer genau ist der Product Owner?
Bei jedem Projekt gibt es einen Geldgeber, der Investor. Er verfügt über eine Budget zur Lösung diverser "Probleme" innerhalb des budgetierten Zeitraums. Er entscheidet, welche Projekte wieviel Budget in einer solchen Periode zugesprochen bekommen.
Wird einem Projekt Budget zugesprochen, gibt es einen Projekt Manager, der dieses Projekt leitet. Nach Scrum ist diese Person der Product Owner. Er steuert das Projekt. Er balanciert Investment und ROI. Darüber hinaus ist er der Interessenvertreter aller Stakeholder.
Das Scrum Team wird vom Product Owner gesteuert.
Abonnieren
Posts (Atom)