Agile Methoden, Scrum & Test-getriebene Entwicklung
Thomas Eisenbarth
makandra GmbH
Agenda
- makandra
- Agile Methoden
- Unterschiede zu Scrum
- Tests & testgetriebene Entwicklung
makandra
- Gründung Anfang 2009
- 6 feste Entwickler, 4 freie, 2 Werkstudenten, 1 Diplomand
- 2 Vertrieb
- eigenständige Unit in Berlin (BitCrowd)
- ausschließlich Web-Anwendungen mit Ruby on Rails
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 Softwareentwicklung
Weil Softwareprojekte scheitern
Agile Softwareentwicklung
Weil BB-Releases scheitern
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?
- kleine Arbeitspakete (Stories)
- kurze Iterationen, häufiges Abliefern von Stories
- ständige Abstimmung mit Kunden
- Pair programming
- Testgetriebene Entwicklung
- ständiges Refactoring
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
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 sollte 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 meist durch 1 oder 2 Entwickler
- Entwicklung, Test, Deployment der Stories
- Projektabschluss
Typischer Projektablauf
- Definition der Anforderungen (Stories) 25%
- Projektsetup & Start meist durch 1 oder 2 Entwickler 5%
- Entwicklung der Stories (Test+Code) 65%
- Deployments auf Staging & Produktiv-Systeme 5%
1: Anforderungen / Stories
- Erfassen: Kurze textuelle Beschreibung was gewünscht ist
- Schätzen (in Punkten, meistens Fibonacci-Skala)
2: Projektsetup & Start
- Mehr als 2 Techniker erreichen in dieser Phase nicht nennenswert mehr Geschwindigkeit
- Rollen klären, Repository aufsetzen, staging-Umgebung einrichten, Basis-Anwendung aufsetzen
3: Entwicklung
- Die oberste Story nehmen
- Verstehen was & warum der Kunde das Feature möchte
- Tests & Story implementieren
- Deployment
- Abnahme oder Änderungswunsch zur Story durch Kunden
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
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
