One Piece Flow

Wir wünschen für die agile Softwareentwicklung One-Piece-Flow. Idealerweise soll immer nur eine Story oder ein MMF in Arbeit sein. Dass One-Piece-Flow dem klassischen Modell (Batchen von Aktivitäten) überlegen ist, zeigt dieses Video sehr schön.

Post bewerten

XP and Frameworks

At the XP2000 conference I had a talk about eXtreme Programming and frameworks. Some people archive things for a really long time. One of them reread my article and asked me a few days ago if I did further research on it. I didn't really do research but I collected some experiences which lead me to some simple conclusions (which didn't changed too between 2000 and now):

• Use before reuse. First you have to use some code successfully and than you can think about generalizing it for reuse. That means that you have to invest effort to refactor application code to framework code. A lot of teams try to avoid this "rework" but in most cases the effect is that the framework becomes bloated and hard to use.
• Running application: You always have to have a running application on top of your framework that proves that the framework is useful. This application may be a demo application but that would restrict the "prove". A real application is much better.
• Supporting framework team: This is the really hard one. When your framework grows larger and supports more than one application team you normally need an own framework team. That is easy part, here is the hard part: The framework team has to have a perspective that the application teams are their customers and that they have to listen to the application teams and support them. Most frameworks teams I met had another attitude. They thought that they understand much better how to implement applications than the application developers know and that the application developers are dumb and foolish to a certain degree. That results in the attempt to prescribe how to develop with the framework. And that doesn't work, especially not if you try to support agile teams that should be self organized and empowered.
  

Post bewerten

Ivar Jacobson über die Zukunft der Softwareentwicklung

The future of software development practices.

Post bewerten

Priorisierung von Features

mal eine neue nette Idee zum Thema von David Anderson

Post bewerten

Aufgaben schätzen oder Aufgaben schneiden?

Viele agile Projekte arbeiten mit Stories, um die Anforderungen zu definieren. Die Komplexität von Stories wird mit abstrakten Story Points geschätzt. Bei der Sprint-/Iterationsplanung findet der sogenannte Task Breakdown statt: Die Stories werden in Aufgaben (Tasks) für die Entwickler zerlegt und diese Tasks werden dann in Personenstunden oder -tagen geschätzt (Commitment Driven Planning). Die Tasks sollten dabei möglichst klein sein. Häufig wird ein Tag als Obergrenze genannt. Dann hat man beim Daily Standup im Durchschnitt jedes mal mind. einen Tasks als erledigt zu vermelden.

Wir haben gute Erfahrungen damit gemacht, die Tasks nicht nur möglichst klein sondern auch möglichst gleich groß zu halten. Wenn alle Tasks gleich groß sind, muss man Aufwände nicht mehr zusammenrechnen, sondern muss nur noch Tasks zählen. Und wenn man irgendwo mal umplanen muss, ist das auch ganz einfach: Einen Task weghängen und einen neuen dafür dazu hängen. Die Vorteile sind in der Praxis deutlich spürbar.

Allerdings kommt man jetzt in eine Zwickmühle. Tatsächlich sind die Tasks konkret nicht alle gleich groß, sondern nur im Durchschnitt. Das kann dazu führen, dass das Team in einem Sprint/Iteration 20 Tasks schafft und in einem anderen 22 Tasks. Für Commitment Driven Planning reicht das Durchzählen der Tasks also nicht aus. Wenn man beim Sprint-/Iterationsreview feststellt, dass man ein paar Tasks mehr oder weniger geschafft hat als geplant, sagt das erstmal wenig aus. Die Abweichung könnte durch die natürlichen Schwankungen bedingt sein.
Das Problem ließe sich durch das Schätzen von Tasks in Stunden beheben, dann ist aber der Vorteil der gleichen Größe wieder futsch.

Daher hat eins meiner Teams mit "halben" Tasks experimentiert. Die meisten Tasks hatte die Normgröße. Einige wenige Tasks waren kleiner und wurden daher mit 1/2 annotiert. Das hat aber nicht so richtig gut funktioniert. Die bereits vorher sehr guten Commitments wurden dadurch nicht besser. Dafür wurde Sprint-/Iterationsplanung umständlicher und beim Review gab es immer wieder Verwirrung um das Tracking ("Zählen wir die halben Tasks für das Tracking jetzt voll oder nur halb?"). Folgerichtig hat das Team die halben Tasks wieder abgeschafft und arbeitet jetzt wieder unter der Annahme, dass alle Tasks gleich groß sind.

Interessant sind noch zwei Diskussionen, die wir geführt haben:
1) Boris Gloger hat vorgeschlagen, bei Sprint-/Iterationsplanung gar nicht mehr zu schätzen. Stattdessen fragt man das Team nach dem Task Breakdown einfach Story für Story "Würdet Ihr Euch darauf committen?" Tatsächlich reicht das vollkommen aus. Es geht darum, ein Commitment auf die Planung zu bekommen. Wie man das erreicht ist sekundär. Allerdings mochte das Team Boris' Ansatz nicht folgen. Sie meinten, sie könnten auf dieser groben Ebene nicht einschätzen, ob die Planung funktioniert.
2) Man könnte die Tasks auf eine einheitliche Größe zwingen. Dann würde man nicht Tasks auf ToDo-Zettel schreiben, sondern auf Slot-Zettel. Ein Slot hätte eine feste Größe (z.B. 1/2 Personentag) und man müsste die Tasks so formulieren, dass sie auf diese Größe passen. Bei sehr kleinen Aufgaben müsste man mehrere Tasks auf einen Slot-Zettel schreiben. Diese Herangehensweise hat das Team kontrovers diskutiert, letztlich aber abgelehnt. Es schien den Entwicklern zu unnatürlichen Tasks zu führen.

Im Ergebnis ist das Team als bei einer Sprint-/Iterationsplanung verblieben, die mit etwas unscharfen Werten hantiert - alle Tasks werden als gleich groß angesehen, obwohl sie das nicht sind. Das ist solange unproblematisch, wie das Team trotzdem ein Commitment auf die Planung abgibt und das tut es. Jetzt muss man mal beobachten, wie es sich mit der tatsächlichen Qualität der Planungen verhält.

BTW: Ich persönlich mag den Ansatz von Boris und ich tendiere zu dem Slot-Zettel-Ansatz, um alle Tasks gleich groß zu bekommen. Dass ggf. mehrere Tasks auf einem Slot-Zettel stehen, halte ich für unproblematisch, weil sie so klein sind. Man wird die Aufgaben eines Slot-Zettels ohnehin nicht aufspalten und parallel abarbeiten lassen wollen.

P.S.: Tasks gleicher Größe zu haben, reduziert Variabilität und reduzierte Variabilität führt laut Lean Development/Production zu einer höheren Produktivität. Siehe auch bei David Anderson.

Post bewerten

Einladung zu den XP-Days Germany 2008 in Hamburg

Das Programm für die XP-Days Germany 2008 in Hamburg steht jetzt fest (siehe Programm). Vorträge gibt es am 27.11.08 (Donnerstag) nachmittags und am 28.11.08 (Freitag) den ganzen Tag. Wir haben ein vielfältiges Programm, dass sowohl den Interessen von Neueinsteigern wie auch alter Hasen im Bereich der agilen Methoden gerecht wird.

Wie der Untertitel der Konferenz bereits deutlich macht: Die XP-Days bieten allen agilen Methoden ein Forum, nicht zur eXtreme Programming. Das zeigt sich auch dieses Jahr wieder am Programm. Die meisten Vorträge bieten Wissenswertes, dass sich mit jeder agilen Methode kombinieren lässt.

Der Samstag richtet sich an all diejenigen, die aktiv mitdiskutieren wollen. Dazu muss man kein Experte mit jahrelanger Erfahrung sein. "Nur" das Engagement ist wichtig. Folgerichtig gibt es für den Samstag kein vorab festgelegtes Programm. Stattdessen wird eine "Unconference" im Open-Space-Stil stattfinden.

Jetzt bleibt eigentlich nur noch eines zu tun: Anmelden und den Frühbucherrabatt sichern!

Post bewerten

Sind Aufwandsschätzungen Verschwendung?

Bei InfoQ findet sich ein interessanter Artikel, in dem die Frage diskutiert wird, ob Aufwandsschätzungen Verschwendung sind. Im Sinne des Lean Thinking sind Aufwandsschätzungen auf jeden Fall Verschwendung. Sie gehen schließlich nicht in die entwickelte Software ein.
Allerdings: Leider kann man nicht jede Verschwendung sofort beseitigen. Mitunter benötigt man die Verschwendung als Zwischenergebnis oder zur Kontrolle seines Projektes. Viele agile Projekte können daher bisher nicht auf die Verwendung "Aufwandsschätzung" verzichten. Das Unternehmen allokiert beispielsweise auf klassische Weise Budgets und muss daher Projektkosten prognostizieren. Oder man hat mit unsäglichen Festpreisverträgen zu tun. Oder man weiß nicht, wie man sonst vernünftig Projektfortschritt messen - also Release Burndown Charts zeichnen - kann. In diesem Sinne wäre es gefährlich, jetzt einfach auf Aufwandsschätzungen zu verzichten.
Allerdings zum Allerdings: Das Ziel bleibt trotzdem bestehen. Nur, weil wir im Moment nicht wissen, wie wir Verschwendung loswerden können, bedeutet es nicht, dass wir die Verschwendung für alle Zeit akzeptieren müssen. Wir müssen stattdessen kontinuierlich an dem Problem arbeiten und uns (häufig schrittweise) einer Lösung nähern.
Ein erster Schritt könnte darin liegen, alle Stories auf dieselbe Größe zu normieren. Das wird im InfoQ-Artikel auch vorgeschlagen, ist bei FDD schon länger gängige Praxis und hat sich auch in unseren Projekten bereits bewährt. Dann muss man nicht mehr schätzen und zusammenrechnen, sondern nur noch zählen.
Und dann kann man sich überlegen, wie man auch noch das Zählen einspart. Diese Einsparung liegt zunächst wahrscheinlich im Bereich von max. 1 Stunde / Woche je Team. Das ist nicht wirklich berauschend. Aber die Einsparung hätte erhebliche - postitive - Seiteneffekte, bzw. Voraussetzungen. Damit man nicht mehr schätzen und zählen muss, muss sich das Unternehmen wandeln weg von Kostenorientierung hin zur Nutzenorientierung. Bei nutzenorientierter Perspektive interessieren mich erstmal die Kosten nicht. Ich priorisiere - möglichst gleich große - Stories nach ihrem Geschäftswert. Wenn mein Bauchgefühl mir sagt, dass die noch übrig gebliebenen Stories weniger Geschäftswert schaffen als mein Team kontinuierlich kostet, ist das Projekt eben zuende. Fertig. So einfach könnte Softwareentwicklung sein und wenn man dem InfoQ-Artikel glauben schenken darf, ist sie das bei einigen Unternehmen auch.

Post bewerten

Übersichtsartikel zu eXtreme Programming

Ich habe in der Zeitschrift dotnetpro einen Übersichtsartikel zu eXtreme Programming veröffentlicht (dotnetpro 02/2008 auf Seite 28). In der Ausgabe finden sich außerdem Artikel zu anderen agilen Methoden wie Scrum.

Post bewerten

Grails-Anwendung: Team-Radar ist Live

In einem früheren Post habe ich von den positiven Erfahrungen geschrieben, die Sebastian und ich zusammen mit Grails gemacht haben. Jetzt ist die zugehörige Anwendung online: Das it-agile Team-Radar führt ein Mini-Assessment für die Einführung agiler Vorgehensweisen durch. Bisher unterstützt Team-Radar Scrum. Andere agile Methoden wie eXtreme Programming und Feature Driven Development sind in Planung.

Post bewerten

Lastenheft vs. User Stories

Im Lastenheft beschreibt der Kunde, welche Aufgaben ein zu erstellendes Softwaresystem unterstützen muss. Anscheinend gewinnt es zur Zeit eine stärkere Bedeutung, insbesondere im Verhältnis zum Pflichtenheft - im Pflichtenheft beschreibt der Softwarehersteller, wie er die Software gestalten wird.

Diese höhere Bedeutung des Lastenheftes liegt vor allem an Kommunikationsproblemen zwischen Fachabteilungen und Softwareentwicklern. Die von den Softwareentwicklern geschriebenen Pflichtenhefte sind für Fachabteilungen größtenteils unverständlich und daher keine geeignete Basis für die Vereinbarung des zu entwickelnden Systems.

Genau dieses Kommunikationsproblem adressieren auch die agilen Methoden, aber mit anderen Mitteln als dem Lastenheft. Bei den agilen Methoden wird das statische Lastenheft quasi durch
einen Lastenheft-Generator ersetzt. Dieser Lastenhaft-Generator ist ein Mitarbeiter des Kundenund heißt ja nach gewählter Nomenklatur mal Kunde (XP) und mal Produktverantwortlicher (Scrum).
Dieser Produktverantwortliche hat die Aufgabe, jeweils soviele Anforderungen zu generieren, wie zur Zeit realisiert werden können. Er generiert das Lastenheft quasi während der Projektarbeit. Dabei wird auf persönliche Kommunikation zwischen Produktverantwortlichem und Entwicklern gesetzt, um Kommunikationsprobleme zu vermeiden.

Damit übertragen agile Vorgehensweisen die Prinzipien der Just-In-Time-Production auf die
Softwareentwicklung: Die Anforderungen sind genau in dem Moment definiert, in dem sie benötigt werden.

Die Vorteile dieser Vorgehensweise liegen auf der Hand: Es wird keine lange Vorlaufphase für
die Definition des Lastenhaftes benötigt. Man kann sofort mit der Softwareentwicklung beginnen, sobald der Bedarf entdeckt wurde. Der Produktverantwortliche kann auf veränderte Rahmenbedingungen sofort reagieren - er muss ja nicht massenhaft bereits definierte Anforderungen ändern. Die Kosten auf Kundenseite sinken, weil der Produktverantwortliche immer nur genau die Anforderungen definiert, die auch realisiert werden. Es wird kein Aufwand in die Definition von Anforderungen gesteckt, die dann doch nicht realisiert werden. Erste Versionen der Software kann der Produktverantwortliche begutachten, daraus lernen und die Generierung weiterer Anforderungen mit dem Gelernten abgleichen.

Allerdings ist diese agile Vorgehenweise nicht für alle Kunden sofort umsetzbar - genau so wenig, wie es der westlichen Industrie gelungen ist, Just-In-Time-Production vom einen Tag auf den nächsten umzusetzen. Die Problematik bei der agilen Softwareentwicklung liegt in der Rolle des Produktverantwortlichen. Es ist durchaus eine Herausforderung, die Anforderungen genau zeitgerecht (eben Just-In-Time) zu definieren. Generiert der Produktverantwortliche die Anforderungen zu langsam, hat das Entwicklerteam kostenpflichtigen Leerlauf oder muss mit undurchdachten Anforderungen arbeiten. Generiert der Produktverantwortliche die Anforderungen zu schnell, liegen sie auf Halde.
Je mehr Anforderungen auf Halde liegen, desto größer die Gefahr, dass ein Teil der Anforderungen gar nicht realisiert wird. In diesem Fall hat der Produktverantwortliche seine wertvolle Arbeitszeit umsonst investiert. Anforderungen auf Halde wären in der Nomenklatur der Just-In-Time-Production Verschwendung.

Die Definition und die Realisierung von Anforderungen im Fluss zu halten entspricht genau dem Flow-Gedanken aus dem Just-In-Time-Production. Die einzelnen Produktionseinheiten in eine Fabrik entsprechend einzustellen, heißt Production Leveling. Und genau diese Herausforderung besteht auch bei agilen Softwareprojekten.

Eine große Hürde ist dabei häufig die Organisationsstruktur des Kunden. Muss der Produktverantwortliche sehr viele Parteien einbeziehen, ohne dass es sehr klare Strukturen gibt, gleicht seine Aufgabe dem sprichwörtlichen Hüten von Flöhen. Es besteht ein hohes Risiko, dass ein ziemlich inkonsistentes System entsteht.

Tatsächlich mag in solchen Fällen das Lastenheft doch die bessere Variante sein. Das gilt
allerdings nur, wenn der Lastenheft-Autor auch ausreichend Zeit für all die Abstimmungen
zur Verfügung hat. Unter Zeitdruck erstellte Lastenhefte neigen zu undurchdachten Anforderungen. Da sie statisch festgeschrieben sind, ist der Kunde dann mit dem Lastenheft wiederum schlechter bedient als mit dem agilen Produktverantwortlichen.

Zwischen dem Produktverantwortlichen im Sinne von Scrum oder XP und dem klassischen Lastenheft gibt es aber auch Zwischenstufen. FDD liefert mit der vorgeschalteten gemeinsamen Modellierungsphase einen guten Ansatzpunkt. Das Projekt wird dabei in Abschnitte von maximal 6 Monaten unterteilt. Für jeweils einen solchen Abschnitt findet eine Upfront-Analyse/-Modellierung statt. Dadurch wird die Gefahr von Inkonsistenzen reduziert. Natürlich bezahlt man das, indem man nicht mehr so schnell auf neue Erkenntnisse reagieren kann, wie mit XP oder Scrum. Man ist aber immer noch schneller und leichtgewichtiger unterwegs als mit dem klassischen Lastenheft.

Post bewerten

Scrum ist nicht Agil?

Es ist ein interessanter Blog-Artikel mit dem Titel "Scrum is not Agile" aufgetaucht. In dem Artikel wird nicht argumentiert, dass Scrum unagil sein. Es wird stattdessen argumentiert, dass die Gleichsetzung Scrum==Agil nicht stimmt, weil agil eben mehr ist als Scrum.
Scrum biete agiles Management. Man bräuchte aber auch aktive Kundeneinbindung, iteratives Vorgehen (inkl. Incremental Design) und selbstorganisierende Teams. Das ist alles auch mit Scrum möglich, aber Scrum gibt keine konkreten Hinweise, was jeweils zu tun ist.
XP deckt immerhin noch das iterative Vorgehen / inkrementelles Design ab.
Für die aktive Kundeneinbindung und die selbstorganisierenden Teams scheint aber noch was zu fehlen.

Post bewerten

Veröffentlichungen

Siehe auch meine frühere Publikationsliste sowie meine Vorträge.

• Stefan Roock: "eXtreme Programming", in dotnetpro 02/2008 , Seite 28-33, Februar 2008
• Stefan Roock, Henning Wolf, "Feature Driven Development (FDD)", 4-teilige Artikelserie im Java-Magazin, 2007-2008
  
• Stefan Roock, Henning Wolf: "Berufsethos, Qualität, Rollenverständnis", in Java-Magazin, Juli 2006
  
• Johannes Link, Stefan Roock: "Je abstrakter, desto besser, oder?", in Java-Magazin, S. 65-69, Juni 2006
  
• Eberhard Wolff, Henning Wolf, Stefan Roock: "Ist die Java-Plattform zu komplex geworden?", in Java-Magazin, Mai 2006
  
• Achin Bangert, Dierk König, Eberhard Wolff, Henning Wolf, Johannes Link, Martin Lippert, Stefan Roock: "Technology First", in Java-Magazin, April 2006
  
• Martin Lippert, Stefan Roock, Henning Wolf: "Ist die Technologie das geringere Problem?", in Java-Magazin, Oktober 2005
  
• Martin Lippert, Stefan Roock: "Large Refactorings". Englische Übersetzung von "Refactorings in großen Softwareprojekten", Wiley, 2006
  
• Robert Beeger, Arno Haase, Stefan Roock, Sebastian Sanitz: "Hibernate", dpunkt-Verlag, 2006.
  
• Henning Wolf, Stefan Roock, Martin Lippert: „eXtreme Programming – Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis“, 2. überarbeitete und erweiterte Auflage, dpunkt-Verlag, 2005
  
• Stefan Roock, Martin Lippert: "Refactorings in großen Softwareprojekten", dpunkt-Verlag, 2004
  
• Roock, S., Wolf, H.:, Agile Project Controlling, XP 2004, Juni 2004, Garmisch-Patenkirchen, 2004
  
• Becker-Pechau, P., Roock, S., Sauer, J.:, Open Source für die Softwareentwicklung, In: HMD Praxis der Wirtschaftsinformatik, 238, August 2004, dpunkt.verlag, Heidelberg, S. 19-25, 2004
  
• Roock, S., Lippert, M.:, Refactorings in großen Softwareprojekten, (Hrsg.): dpunkt.verlag, Heidelberg, 2004
  
• Lippert, M., Becker-Pechau, P., Breitling, H., Koch, J., Kornstädt, A., Roock, S., Schmolitzky, A., Wolf, H., Züllighoven, H.:, Developing Complex Projects Using XP with Extensions, In: IEEE Computer Magazine, June 2003, Vol. 36, No. 6, 2003
  
• Roock, S.:, RE bei agilen Methoden, 2003
  
• Martin Lippert, Stefan Roock, Henning Wolf, "eXtreme Programming in Action". Englische Übersetzung des XP-Buchs „eXtreme Programming in Action“, Wiley, 2003.
  
• „Software entwickeln mit eXtreme Programming – Erfahrungen aus der Praxis“, Martin Lippert, Stefan Roock, Henning Wolf, 2002 erschienen im dpunkt-Verlag
  
• Mitarbeit am Buch „Object-Oriented Software Construction“, Heinz Züllighoven
  
• Mitarbeit am Buch „Das objektorientierte Konstruktionshandbuch“, Heinz Züllighoven
  
• Lippert, M., Roock, S., Wolf, H., Züllighoven, H.:, XP in Complex Project Settings: Some Extensions, In: Extreme Programming Perspectives, Addison-Wesley XP Series, 2002
  
• Lippert, M., Roock, S., Tunkel, R., Wolf, H.:, Stabilizing the XP Process Using Specialized Tools, In: Extreme Programming Perspectives, Addison-Wesley XP Series, 2002
  
• Lippert, M., Roock, S., Wolf, H.:, Extreme Programming in Action - Practical Experiences from Real-World Projects, In: Wiley & Sons, UK, 2002
  
• Roock, Stefan, Frameworks and Testing, In: Proceedings of Extreme Programming Conference 2002, Villasimius, Cagliari, Italy, 2002
  
• Roock, Stefan; Havenstein, Andreas, Refactoring Tags for automatic refactoring of framework, In: Proceedings of Extreme Programming Conference 2002, Villasimius, Cagliari, Italy, 2002
  
• Lippert, M., Roock, S., Wolf, H., Züllighoven, H.:, XP en proyectos complejos: algunas extensiones., In: Novatica, ATI, Spain, Nr. 156, March - April, 2002
  
• Lippert, M., Roock, S., Wolf, H., Züllighoven, H.:, XP in Complex Project Settings: Some Extensions, In: Informatik/Informatique. Schweizerischer Verband der Informatikorganisationen. Nr. 2, April, 2002
  
• Lippert, M., Roock, S., Wolf, H.:, Software entwickeln mit eXtreme programming: Erfahrungen aus der Praxis, In: dpunkt Verlag, Heidelberg, 2002
  
• Lippert, Martin; Roock, Stefan; Tunkel, Robert; Wolf, Henning, Stabilizing the XP Process Using Specialized Tools, Proceedings of Extreme Programming Conference 2001, Villasimius, Cagliari, Italy, 2001
  
• Lippert, Martin; Roock, Stefan; Wolf, Henning; Züllighoven, Heinz, XP in Complex Project Settings: Some Extensions, Proceedings of Extreme Programming Conference 2001, Villasimius, Cagliari, Italy, 2001
  
• Gryczan, G.; Kornstädt, A.; Roock, S.; Wolf, H.; Züllighoven, H., Das JWAM-Framework und Komponenten. Eine konzeptionelle Bestandsaufnahme, in: Tagungsband des 3. Workshops zu komponentenorientierter betrieblicher Anwendungsentwicklung (Frankfurt: April 2001), S. 15-21, 2001
  
• Lippert, Martin; Roock, Stefan; Züllighoven, Heinz, From Documents to Applications via Frameworks: The Tools and Materials Approach, in OOPSLA 2000 Companion, Minneapolis, ACM press, 2000
  
• Roock, S., eXtreme Frameworking - How to aim applications at evolving frameworks, Proceedings of the XP2000 conference. Cagliari, Sardinia, Italy, 2000
  
• Lippert, Martin; Roock, Stefan; Wolf, Henning; Züllighoven, Heinz, JWAM and XP - Using XP for framework development, Proceedings of the XP2000 conference. Cagliari, Sardinia, Italy, 2000
  
• Gryczan, G., Roock, S., Wolf, H., Züllighoven, H., Frameworkbasierte Anwendungsentwicklung (6. und letzter Teil): Frameworkentwicklung und -einsatz organisieren, OBJEKTspektrum 2/2000, März/April 2000, S. 88-93, 2000
  
• Gryczan, G., Havenstein, A., Roock, S., Wetzel, I., Züllighoven, H., Frameworkbasierte Anwendungsentwicklung (Teil 5): Unterstützung von Kooperation mit persistenten fachlichen Behältern, In: OBJEKTspektrum 1/ 2000, Januar/Februar , 2000
  
• Gryczan, G.; Roock, S.; Wolf, H.; Züllighoven, H., Management kundenorientierter Softwareentwicklungsprojekte mit Objektorientierung, In: Informatik Software Project Management, Zeitschrift der schweizerischen Informatikorganisation, Nr. 5, Oktober 1999, S. 22-29, 1999
  
• Gryczan, G., Roock, S., Wolf, H., Züllighoven, H., Frameworks von der Stange reichen nicht aus - Auswahl eines Rahmenwerks für die Software-Entwicklung, In: Computerwoche Nr. 5, 17.9.99, S. 6-8., 1999
  
• Bleek, W.-G., Görtz, T., Lilienthal, C., Lippert, M., Roock, S., Strunk, W., Weiss, U., Wolf, H., Interaktionsformen zur flexiblen Anbindung von Fenstersystemen., Universität Hamburg. Fachbereich Informatik. Fachbereichsmitteilung FBI-HH-M-285/99. April., 1999
  
• Bleek, W.-G., Lippert, M., Roock, S., Züllighoven, H., Strunk, W., Frameworkbasierte Anwendungsentwicklung (Teil 3): Die Anbindung von Benutzungsoberflächen und Entwick- lungsumgebungen an Frameworks, OBJEKTspektrum 3/99, Mai/Juni, S. 90-95, 1999
  
• Bleek, W.-G., Lilienthal, C., Lippert, M., Roock, S., Strunk, W., Wolf, H., Züllighoven, H., Frameworkbasierte Anwendungsentwicklung (Teil 2): Die Konstruktion interaktiver Anwendungen, OBJEKTspektrum 2/99, März/April, S. 78-83, 1999
  
• Bleek, W.-G., Gryczan, G., Lilienthal, C., Lippert, M., Roock, S., Wolf, H., Züllighoven, H., Von anwendungsorientierter Softwareentwicklung zu anwendungsorientierten Lehrveranstaltungen - der Werkzeug & Material-Ansatz in der Lehre, Software Engineering im Unterricht der Hochschulen (SEUH) 99, Berichte 52, B. Dreher/Ch. Schulz/D. Weber-Wulff (Hrsg.), Workshop des German Chapter of the ACM und der Gesellschaft für Information (GI) am 25. und 26. Februar 1999 in Wiesbaden, pp. 9-20, 1999
  
• Gryczan, G., Lilienthal, C., Lippert, M., Roock, S., Wolf, H., Züllighoven, H., Framework-basierte Anwendungsentwicklung (Teil 1), OBJEKTspektrum Nr. 1, Jan./Feb., S. 90-98, 1999
  
• Roock, S., Wolf, H., Züllighoven, H., Frameworking, In: Niels Jakob Buch, Jan Damsgaard, Lars Bo Eriksen, Jakob H. Iversen, Peter Axel Nielsen (Eds.): IRIS 21 "Information Systems Research in Collaboration with Industry“, Proceedings of the 21st Information Systems Research Seminar in Scandinavia, 8-11 August 1998 at Saeby Soebad, Denmark, pp. 743-758, 1998
  
• Fricke, N., Lilienthal, C., Lippert, M., Roock, S., Wolf, H., Operating and Window Systems will never strike back or Independence day for Java developers, In: R. Nigel Horspool (Ed.): Systems Implementation 2000, Chapman & Hall, London, New York 1998, Proceedings of SI2000 (IFIP Working Group 2.4), Berlin 23-26 February 1998, pp. 86-99., 1998
  
• Roock, S., Wetzel, I., Wolf, H., Züllighoven, H., Location as an Analysis and Design Metaphor in Work Settings with Complex Cooperations, In: Kristin Braa & Eric Monteiro (eds.): Proceedings of IRIS 20 "Social Informatics", Oslo, June 1997. S. 431-448, 1997
  

Post bewerten

Vorträge

siehe auch meine Artikel und Bücher

• Bernd Schiffer, Stefan Roock: Agile Entwicklung mit Grails, XP-User-Group-Hamburg und Java-User-Group-Hamburg, Dezember 2007
  
• Stefan Roock: Einfachheit in Softwareprojekten, XP-Days Germany 2007, Karlsruhe, November 2007
• Stefan Roock (Organisation): Agile Lightning Talks, XP-Days Germany 2007, Karlsruhe, November 2007
  
• Stefan Roock, Bernd Schiffer, Henning Wolf: Agile Lego Hour, W-JAX 2007, München, November 2007
• Stefan Roock, Henning Wolf: Festpreisvertrag und agil nützt nicht viel?, Agility Day auf der W-JAX 2007, München, November 2007, Folien
  
• Stefan Roock (Organisation): Agile Lightning Talks, Agility Day auf W-JAX 2007, München, November 2007
• Stefan Roock: Anforderungen, Usability und Agilität, Universität Konstanz, 2007, Folien
  
• Stefan Roock, Henning Wolf: Scrum und Lean-Management in IT-Projekten, Arbeitskreis Projektmanagement, Nordakademie, 2007
  
• Jürgen Ahting, Stefan Roock: Warum sind die Kunden in Softwareprojekten so schwierig?, JAX 2007, Wiesbaden, 26.04.2007
• Robert Beeger, Matthias Lübken, Stefan Roock, Sebastian Sanitz: XP-Live-Demo, JAX 2007, Wiesbaden, April 2007
• Stefan Roock, Henning Wolf: IT-Kaizen: Kontinuierliche Verbesserung in der Softwareentwicklung, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  
• Bernd Schiffer, Stefan Roock: Beispiel Grails - Brauchen wir neue Technologien für agile Entwicklung?, XP-Days Germany 2006, Hamburg, 24.11.2006, Folien
  
• Arno Haase, Stefan Roock, Sebastian Sanitz: Hibernate 3 (ganztägiger Power-Workshop). JAX 2006, Wiesbaden, 08.05.2006
  
• Stefan Roock, Henning Wolf: Aufwandsschätzung in agilen Projekten. Lehmanns Buchhandlung, Hamburg, Januar 2006.
  
• Robert Beeger, Arno Haase, Stefan Roock: Hibernate 3. (ganztägiger Power-Workshop). W-JAX 2005, München, November 2005.
  
• Bernd Schiffer, Stefan Roock: eXtreme Programming (Tutorial). ix-Konferenz, Köln, November 2005.
  
• Jürgen Ahting, Stefan Roock: Der Kunde in agilen Projekten. ix-Konferenz, Köln, November 2005
  
• Stefan Roock: Aufwandsschätzung in großen agilen Projekten. ix-Konferenz, Köln, November 2005.
  
• Stefan Roock: Refactorings in großen Softwareprojekten, XP-Days 2004, Karlsruhe
  
• Martin Lippert, Stefan Roock: Refactorings in großen Softwareprojekten, Java Forum Stuttgart 2004, 01.07.2004, Stuttgart.
  
• Stefan Roock, Martin Lippert, Frank Westphal: Testing in the Extreme Programming World. (Full-Day Tutorial). ICS Test, Köln, http://www.icstest.com, 01.04.2003
  
• Stefan Roock, Martin Lippert: Large Refactorings (Workshop). OT 2003, Cambridge, UK, http://www.ot2003.org, 2003
  
• Stefan Roock: Requirements Engineering bei agilen Methoden. GI-Workshop "Requirements Engineering", Ulm, http://www-lufgi3.informatik.rwth-aachen.de/GI/GI-FG2.1.6.html. 28.09.2002
  
• Holger Breitling, Axel Schmolitzky, Stefan Roock: Extreme
  Programming (Half-Day Tutorial). Software Management Tagung, Hamburg, 06.11.2002
  
• Holger Breitling, Petra Becker-Pechau, Stefan Roock: Agile Requirements Engineering (Full-Day Tutorial). RE 2002, Essen. 10.09.2002
  
• Martin Lippert, Stefan Roock: Using and Adapting Extreme Programming (Full-Day Tutorial). ECOOP 2002, Malaga, Spanien, 11.06.2002
  
• Martin Lippert, Stefan Roock: Extreme Programming in komplexen Projektsituatuionen (Full-Day Tutorial). OOP 2002, München. Januar 2002.
  
• Stefan Roock: eXtreme Programming integrativ? GI-Workshop "Vorgehensmodelle". 2001
  
• Martin Lippert, Stefan Roock: Extreme Programming in Complex Project Settings (Half-Day Tutorial). ECOOP 2001, Budapest, Ungarn, Juni 2001
  
• Stefan Roock: Anforderungsermittlung mit eXtreme Programming. GI-Workshop
  "Requirements Engineering", 2001.
  
• Stefan Roock, Henning Wolf: Framework-Entwicklung (Full-Day Tutorial). OOP
  2001, München, Januar 2001.
  
• Stefan Roock: Object Oriented Design (3-Day Workshop). University
  of Roenneby, Schweden, März 2000.
  

Post bewerten