Agile Methoden & Test-getriebene Entwicklung
Thomas Eisenbarth
makandra GmbH
Agenda
- makandra
- Agile Methoden
- Tests & testgetriebene Entwicklung
makandra
- Gründung Anfang 2009
- 8 feste Entwickler/Admins, [3..6] freie Entwickler, 2 Werkstudenten, 1 Diplomand
- 2 Overhead (Vertrieb/Marketing)
- eigenständige Unit in Berlin (BitCrowd)
- ausschließlich Web-Anwendungen mit Ruby on Rails
Wer ist heute da?
Ruby on Rails
- Ruby: Objektorientierte Programmiersprache
- Rails: Web-Framework nach MVC-Pattern
Ruby on Rails
- Ruby: Objektorientierte Programmiersprache
- Rails: Web-Framework nach MVC-Pattern
- M odel → Active Record
- V iew → Action Pack
- C ontroller → Action Pack
makandra (2)
- Unternehmensinterne CRM-, Warenwirtschaft-, Projektmanagement-Systeme, ...
- öffentliche Web-Platformen/Portale, ...
- Viele parallel laufende Projekte
- Selten mehr als 3 Entwickler auf einem Projekt
- Wechselnde Köpfe auf den Projekten
Agile Softwareentwicklung
Warum?
Agile SE: Warum?
Weil Softwareprojekte scheitern
Agile SE: Warum?
Weil Softwareprojekte scheitern
Weil BB-Releases scheitern
Agile SE: Weil...
- ... Softwareprojekte scheitern.
- ... BB-Releases scheitern.
- ... Time-to-Market zu hoch ist.
- ... sich Anforderungen zu häufig ändern.
- ... die Code-Qualität nicht stimmt.
- ... der Aufwand für Maintenance explodiert.
Agile SE: Prinzipien
Agiles Manifest: Prinzipien
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Close, daily co-operation between business people and developers
Agiles Manifest: Prinzipien (2)
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
Agile Softwareentwicklung setzt einiges voraus
- Vertrauen: Kunde ↔ Entwickler ↔ Management
- Eigenständige, kommunikationsstarke, teamfähige, flexible Entwickler
- ständig greifbarer Kunde
Agile Softwareentwicklung: Wie?
Choose as many as possible...
- kleine Arbeitspakete (Stories)
- kurze Iterationen, häufiges Abliefern von Stories
- ständige Abstimmung mit Kunden
- Pair programming
- ständiges Refactoring
- Testgetriebene Entwicklung
Agile Softwareentwicklung: Wie?
Choose as many as possible...
- kleine Arbeitspakete (Stories)
- kurze Iterationen, häufiges Abliefern von Stories
- ständige Abstimmung mit Kunden
- Pair programming
- ständiges Refactoring
- Testgetriebene Entwicklung
Agile Softwareentwicklung: Arbeitspakete / "Stories"
Eine Story...
- ... beschreibt: Wer möchte was warum?
- ... ist atomar
- ... hat eine Schätzung
- ... liefert einen Wert für den Kunden
- ... durchläuft einen klaren, einfachen Workflow
- ... ist eingeplant in eine Liste
Agile Softwareentwicklung: Schätzungen
- Schätzungen in Punkten (1,2,3,5,8)
- Vergleiche fallen Menschen leichter als diskrete Stunden-Schätzungen
- x dauert länger als y und y dauert länger als z
Agile SE bei makandra
Agile Entwicklung bei makandra
Herausforderungen
- Overhead bei Projektübergaben muss klein sein
- Einarbeitungszeiten müssen überschaubar sein
- neue Teammitglieder auf Projekten müssen schnell produktiv sein
- Wissen muss projektübergreifend im Team verteilt werden
Agile Entwicklung bei makandra
- Kein Scrum/XP/Kanban
- Kein Pair-Programming oder Daily Scrum
Agile Entwicklung bei makandra
"Das beste aus allem"
- Testgetriebene Entwicklung
- Sehr kurze Iterationen
- häufige Deployments, meist täglich oder wöchentlich
- Viel und direkte Abstimmung mit Kunden
- Automatisiertes Deployment
- keine Projektfestpreise
Typischer Projektablauf
- Definition der Anforderungen (Stories)
- Projektsetup & Start
- Entwicklung, Test, Deployment der Stories
- Projektabschluss
Typischer Projektablauf
- Definition der Anforderungen (Stories) 25%
- Projektsetup & Start 5%
- Entwicklung der Stories (Test+Code) 65%
- Deployments auf Staging & Produktiv-Systeme 5%
Tools
- Pivotal Tracker: Story-Management
- makandra notes: Wissensdatenbank
- ProjectHero: Planung, Zeiterfassung, Abrechnung
Testgetriebene Entwicklung
Warum?
Testgetriebene Entwicklung
Weil Software kaputt geht
Warum geht Software kaputt?
- Technische Schulden im Projektverlauf
- Einzelne Entwickler überblicken gesamtes System nicht mehr
- Big-Bang-Releases
- Händische Tests ("Durchklicken") fehleranfällig
Automatisierte Tests bieten wirtschaftliche Vorteile
- Bessere Planbarkeit
- Händische Tests ("Durchklicken") aufwändig
- Kürzere Time to Market
Testgetriebene Entwicklung
Tests sind Beispiele, wie sich eine Anwendung verhalten soll.
„Auf der Homepage sollen die beliebtesten Produkte erscheinen.“
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
Unknown class "Article"
1 scenario (1 failed)
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
Error retrieving page (404 not found)
1 scenario (1 failed)
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
No such link "Nintendo Wii"
1 scenario (1 failed)
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
No such button "Add to cart"
1 scenario (1 failed)
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
Excepted to see "Item was added to cart"
1 scenario (1 failed)
Scenario: add an item to the shopping cart
Given an article with the name "Nintendo Wii"
When I am on the homepage
And I follow "Nintendo Wii"
And I press "Add to cart"
Then I should see "Item was added to cart"
1 scenario (1 passed)
Praxis
Weiterführende Links
- Cucumber: http://cukes.info/
- Video-Crashkurs Einführung in TDD: http://www.makandra.de/malennachzahlen
- Workshop Ruby on Rails: http://railsworkshop.makandra.de
Vielen Dank!
Technische Schuld
„Man soll auch ohne Anmeldung und Login bestellen können“
„Man soll auch ohne Anmeldung und Login bestellen können“
Technische Schuld steigt im Laufe von Projekten
- Der Code wird komplizierter
- Die Fehlerrate steigt
- Regressionen: Ein neues Feature bricht ein altes
- Aufräumarbeiten im Code sind risikoreich für die Entwickler
- Steigende Kosten für Änderungen
Technischer Schuldenabbau
Technischer Schuldenabbau
- Tests machen Verbesserungen am Code einfach und gefahrlos für die Entwickler
- Man zahlt seine technische Schuld in kleinen Raten über den Projektverlauf verteilt zurück
- Probleme werden beseitigt, bevor Sie unwartbar werden
Releasezyklen
Time to market: Releaseszyklen
Manuelle Test-Phasen funktionieren nicht
„If your team is not able to test everything as soon as it is ready, they soon will ask you to introduce one or two week long test cycles. They tell you that in that time they can do all the testing and that you’ll have a stable release afterwards.
Unfortunately, nothing could be further from the truth. The later you test, the more effort you’ve got to spend fixing bugs introduced weeks ago. And as the code is changing during the testing weeks, every test cycle you do has to be repeated. In the end, your software is no more stable then it was before the test cycle.“
Matthias Marschall
Agile Softwareentwicklung: Scrum
- Scrum ist eine mögliche Vorgehensweise zur agilen Softwareentwicklung
- Scrum ist nicht zwingend auf Softwareentwicklung beschränkt
Scrum bietet institutionalisierte Rollen, Abläufe, Zyklen
- Product Owner
- Scrum-Master
- Sprint-Planungstreffen
- Daily Scrum
- Retrospektive
Scrum
- festgelegte Terminologie
- kommerzielle Zertifizierung
- → "fertig abgepacktes" Vorgehensmodell
Weitere Alternativen
makandra best practises
- Ausschließlich nach Stunden anbieten, keine Festpreise
- Initiale Angebots-Schätzung in Stunden mit unterer und oberer Schranke für jede einzelne Story
- Ehrlich sein bei der initialen Schätzung
makandra best practises
- Ausschließlich nach Stunden anbieten, keine Festpreise
- Initiale Angebots-Schätzung in Stunden mit unterer und oberer Schranke für jede einzelne Story
- Ehrlich sein bei der initialen Schätzung
makandra best practises (2)
- Pivotal Tracker als Tool für verteilte Entwicklung
- Kunde benennt eine fachlich versierte Person, die jederzeit angerufen werden darf (und wird!)
- Bei *-shoring: Ist- und Ziel-Zustand genau beschreiben
