Andreas Becker
Agile-by-HOOD
18.03.2014
RE und Scrum –
auf den zweiten Blick ein geniales Team
Inhalt
• Einleitung
• Refinement
• Vision
• Planung
• Abstimmung
• Erhebung und Feedback
• Weitere Rollen
• Zusammenfassun...
Klassische RE-Aktivitäten
3
Umfang definieren
(Scoping)
Erheben
Spezifizieren
VerwaltenModellieren
Konsolidieren
Konkretis...
Scrum: 3 – 3 – 5
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospekti...
In welchem Umfeld arbeiten Sie?
6
Kunde Product
Owner
ScrumMaster
Entwicklerteam
Kunde
Product
Owner
ScrumMaster
Entwickle...
Refinement
Scrum - Framework
8
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospe...
User Story
9
Als Administrator
möchte ich Nutzer des
Portal sperren
können, um Missbrauch
zu verhindern
Rolle
Funktionalit...
Quelle: http://www.informit.com/articles/article.aspx?p=1928232&seqNum=4
Backlog Refinement
Scrum - Framework
11
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrosp...
Akzeptanzkriterien – es müssen nicht immer Stichworte sein
12
Tabellen
Als Nutzer möchte ich mein Profil löschen können,
u...
Schätzung und Dialog
13
User
Stor
y
Von der Idee zur Umsetzung
14
Epic
User Story
Erste Vorstellung der
User Story +
Akzeptanzkriterien
Vollständig verstanden...
Backlog-Management
Agilität erleben
Portfolio
Backlog
Feature
Backlog
Product Backlogs
Sprint Backlogs
NFA
Architektur-
en...
Status „Ready“ und „Done“
• READY – Qualität der User Story (Anforderungen)
• DONE – Abnahmekriterien für User Story (Anfo...
Vision
Scrum
18
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily...
Quelle: Alice im Wunderland, Film 2010
"Würdest Du mir bitte
sagen, welchen Weg ich
einschlagen muss?"
"Das hängt in
beträchtlichem Maße
davon ab, wohin du gehen...
Vision Board
21
Planung
„Wir können nicht hinter den Horizont
schauen“ (Mike Cohn)
-24-
Scrum
25
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily...
Abhängig vom Planungskontext sind unterschiedliche
Planungshorizonte* notwendig
*: basierend auf Ellen Gottesdiener
PO und...
Ziele der Planungshorizonte
*: basierend auf Ellen Gottesdiener
 Ausblick auf
kommende
Themen /
Epics / Feature
 Gemeins...
Abstimmung
Scrum – ein Blick ins Daily
29
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Revi...
Daily - Scrum
30
„…und ich
mach die
Toten“
…Ich mache den
Task
„DB-Modell“
anpassen …
…Ich mache den
Task „Menueleiste
anp...
Scrum – mit vielen POs
31
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Re...
Product Owner Pre-Planning
-32-
Velocity
Velocity
Velocity
Produktvision
 Abgleich der geplanten
Backlog Items mit
Strate...
Anforderungserhebung
34
Sprint Review – die traurige Realität
ScrumMaster
Entwicklerteam
Product Owner
Sprint Review als Feedback- und Erhebungsworkshop
„Das Ergebnis des Sprint Reviews ist ein potentiell neu organisiertes
Pr...
Umdenken
Funktionale Dekomposition Agiles nutzenorientiertes Umfeld
Epic
User Story 1 User Story 2 User Story 3  

Epi...
Feedback im agil skalierten Umfeld
Hotline
Endanwender
Session-basiertes Testen
….
Beta-Kunden /
Pilotierung
Endanwender E...
Rollen im Business-Team
Der PO – ein Superheld?
40
Product Owner
Terminator
Quelle: http://www.fuenf-filmfreunde.de/2009/04/23/ist-arnold-schwarzenegger-im-neuen-terminator-salvation-doch...
NORMator
Quelle: http://prem666.deviantart.com/art/Terminator-Robot-Face-398031009
NORMator – der Mann / die Frau für das regulierte Umfeld
NORMator
Dokumentation
44
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkreme
ntSprint Planning Review
Retrospekti...
NORMator im Überblick
Agilität erleben 45
NORMator
Validierung der Gebrauchstauglichkeit
- User
- Gebrauchsformen
- Szenar...
Business-Team mit PO und NORMator
46
NORMator
Product Owner
Der Business Analyst – was wird aus ihm?
47
Business Analyst
Story Mapping
Prozess (zeitlicher Ablauf)
… … … ……
Aktivitäten
R
a
n
k
i
n
g
Aufgaben/ Tasks
……..
……..
……..
……..
…….. …….....
Story Mapping – Beispiel „Buchversand“
Prozess (zeitlicher Ablauf)
Buchung
finden
Angebote
sichern
Bestellen-
daten
Bestel...
Business-Team mit PO, BA und NORMator
50
NORMator
Product Owner
Business
Analyst
Prozess (zeitlicher Ablauf)
Aktivitäten
R...
Zusammenfassung
Scrum und mögliche Erweiterungen
52
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning...
Software-Entwicklung ist häufig komplex
Technologie
Anforderungen
bekannt unbekannt
bekanntunbekannt
Merkmale eines agilen Requirements Engineering –
es muss nicht immer Scrum sein
 RE ist eine kontinuierliche Tätigkeit un...
Das Agile Manifest – 12 Prinzipien
-55-
Unsere höchste Priorität ist es, den Kunden durch frühe und
kontinuierliche Auslie...
Fragen und Diskussion
Andreas.Becker@HOOD-Group.com
HOOD GmbH
Büro München
Keltenring 7
82041 Oberhaching
Germany
Tel: 0049 89 4512 53 0
www.Agi...
Upcoming SlideShare
Loading in...5
×

RE und Scrum - auf den zweiten Blick ein geniales Team

1,202

Published on

Ist der häufig in agil arbeitenden Organisationen zu hörende Satz „wir arbeiten agil und benötigen kein RE mehr“ tatsächlich zutreffend? Ist die Zeit des RE durch die Verbreitung von agilen Methoden (z.B. durch das Scrum-Framework) abgelaufen? Der Eindruck könnte auf den ersten Blick entstehen, da die Aktivitäten des Requirements Engineering in der agilen Entwicklung nicht isoliert betrachtet werden.

Auf den zweiten Blick stellt sich heraus, dass Kenntnisse rund um RE-Methoden im agilen Umfeld nötiger sind denn je. Dies ergibt sich aus der Tatsache, dass immer größere Organisationen den Umstieg von ihren an Phasen und Dokumenten orientierten Prozessen zu einer agilen Entwicklung anstreben. Dies hat zur Folge, dass diese Organisationen häufig nicht individuell für genau einen Kunden implementieren, sondern zahlreiche Produkte für eine größere Kundenanzahl entwickeln. In einem agil-skalierten Umfeld.

Ein kleines Beispiel: In einem Review Meeting mit mehreren anwesenden Stakeholdern erhalten die Anwesenden einen Einblick in die bisherige Produktimplementierung und ergänzen die bisherige Implementierung mit neuen Wünschen - also mit weiteren Kundenanforderungen. Diese Anforderungen können sich widersprechen und schon muss der Product Owner die Anforderungen konsolidieren – eine typische RE-Aktivität.

Dieser Vortrag orientiert sich an zahlreichen dieser kleinen Beispiele, die in der alltäglichen Praxis vorkommen, und belegt dadurch die wachsende Bedeutung von RE-Kenntnissen im agil-skalierten Umfeld.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,202
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
22
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Es muss nicht immer agil verwendet werden.Einfache = leicht erkennbar, wiederholbare MusterKompliziert = nicht einfach, aber immer noch erkennbar, das System ist vorhersehbarKomplex = nicht vollständig erkennbar, aber teilweise vorhersehbarChaotisch = weder erkennbar noch vorhersehbar.Bsp.:Mein Autoschlüssel ist einfach.Es dauerte etwa drei Sekunden, um zu verstehen, wie meine Autoschlüssel funktioniert. OK, vielleicht ist das nicht ganz richtig. Meiner hat eine Batterie drin. Wenn ich es auseinander zu nehmen, es könnte mich noch drei Stunden, um die Details zu verstehen. Aber ja, ich bin klug, ich werde zu verwalten.Mein Auto ist kompliziert.Es würde mich Jahre zu verstehen, wie mein Auto funktioniert. Und ich habe nicht die Absicht. Aber wenn ich es täte, dann eines Tages in ferner Zukunft würde ich mit Sicherheit der Zweck jeder Mechanismus und jedem Stromkreis kennen. Ich würde verstehen, wie sie zu kontrollieren, und ich wäre in der Lage, mein Auto auseinander nehmen und wieder zusammenbauen, fahren sie genau so, wie ich früher. In der Theorie, natürlich. In der Praxis tun nur echte Männer solche Dinge.Auto Verkehr ist komplex.Ich kann reisen und auf der gleichen Straße für 20 Jahre, und die Dinge würden jedes Mal anders. Es gibt keinen Weg, um vollständig zu verstehen und wissen, was um mich herum passiert auf der Straße, wenn ich fahre, wie andere Fahrer ihre Fahrzeuge zu betreiben, und wie die Menschen in den Straßen zu interagieren. Ich kann Vermutungen anstellen, und ich kann in Erfahrung Prognosen zu gewinnen. Aber ich werde nie sicher wissen.Auto Verkehr in Lagos (Nigeria) ist chaotisch.Wenn die Dinge zu komplex zu bekommen, sie leicht chaotisch. Verkehr in Lagos ist so schlecht, es ist nicht einmal vorhersehbar. Schlechte Infrastruktur und Planung, Haufen von Abfall, Umweltverschmutzung, mangelnde Sicherheit, Überschwemmungen und viele mehr Probleme machen es zu einem der schlimmsten Orte der Welt zu sein, als eine einfache Autofahrer.
  • RE und Scrum - auf den zweiten Blick ein geniales Team

    1. 1. Andreas Becker Agile-by-HOOD 18.03.2014 RE und Scrum – auf den zweiten Blick ein geniales Team
    2. 2. Inhalt • Einleitung • Refinement • Vision • Planung • Abstimmung • Erhebung und Feedback • Weitere Rollen • Zusammenfassung oder muss es immer Scrum sein?
    3. 3. Klassische RE-Aktivitäten 3 Umfang definieren (Scoping) Erheben Spezifizieren VerwaltenModellieren Konsolidieren Konkretisieren Ableiten Abstimmen / Review Abnehmen Stakeholder- Management
    4. 4. Scrum: 3 – 3 – 5 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Stand: Scrum Guide 2013
    5. 5. In welchem Umfeld arbeiten Sie? 6 Kunde Product Owner ScrumMaster Entwicklerteam Kunde Product Owner ScrumMaster Entwicklerteam Kunde = Kunde Kunde Kunde Kunde Kunde Kunde Kunde Kunde KundeKunde Kunde Kunde Kunde Kunde Kunde Kunde
    6. 6. Refinement
    7. 7. Scrum - Framework 8 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 User Stor y
    8. 8. User Story 9 Als Administrator möchte ich Nutzer des Portal sperren können, um Missbrauch zu verhindern Rolle Funktionalität Nutzen / Grund Kommunikationsgrundlage
    9. 9. Quelle: http://www.informit.com/articles/article.aspx?p=1928232&seqNum=4 Backlog Refinement
    10. 10. Scrum - Framework 11 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 Story Time User Stor y „…10% der Zeit des Entwicklungsteams für die Beschäftigung mit zukünftigen Anforderungen…“
    11. 11. Akzeptanzkriterien – es müssen nicht immer Stichworte sein 12 Tabellen Als Nutzer möchte ich mein Profil löschen können, um keine Daten im Netz zu hinterlassen.  Given - der Nutzer ist eingeloggt  and er hat keine aktuellen Buchungen von Mitfahrgelegenheiten  When - der Löschbutton wird betätigt  die Anfrage wird bestätigt  Then - der Nutzer bekommt eine Bestätigungs- eMail  and die Daten des Nutzers werden aus der Datenbank gelöscht Konkretes Beispiel
    12. 12. Schätzung und Dialog 13 User Stor y
    13. 13. Von der Idee zur Umsetzung 14 Epic User Story Erste Vorstellung der User Story + Akzeptanzkriterien Vollständig verstandene User Story + Akzeptanzkriterien Kommunikative Ergänzungen zur User Story R E F I N E M E N T Sprint Planning Story Time Sprint Product Backlog Schätzung der User Story Story Time
    14. 14. Backlog-Management Agilität erleben Portfolio Backlog Feature Backlog Product Backlogs Sprint Backlogs NFA Architektur- entscheidungen User Story User Story User Story User Story User Story User Story Task Task Task Task Task Task Task Task Task GesetzeGf-Ziele Use Case Feature ….. 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- 1. ----- 2. ----- 3. ----- 4. ----- 5. ----- 6. ----- … … …. Nachverfolgbarkeit z.B. Sicherheits- anforderungen Akzeptanz- kriterienAkzeptanz- kriterienAkzeptanz- kriterien
    15. 15. Status „Ready“ und „Done“ • READY – Qualität der User Story (Anforderungen) • DONE – Abnahmekriterien für User Story (Anforderungen) 16 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkreme ntSprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage R E A D Y D O N E
    16. 16. Vision
    17. 17. Scrum 18 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 Vision
    18. 18. Quelle: Alice im Wunderland, Film 2010
    19. 19. "Würdest Du mir bitte sagen, welchen Weg ich einschlagen muss?" "Das hängt in beträchtlichem Maße davon ab, wohin du gehen willst" "Oh, das ist mir ziemlich gleichgültig" "Dann ist es auch einerlei, welchen Weg du einschlägst" Quelle „Alice im Wunderland“ Lewis Carroll / 26. 11 1865
    20. 20. Vision Board 21
    21. 21. Planung
    22. 22. „Wir können nicht hinter den Horizont schauen“ (Mike Cohn) -24-
    23. 23. Scrum 25 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013
    24. 24. Abhängig vom Planungskontext sind unterschiedliche Planungshorizonte* notwendig *: basierend auf Ellen Gottesdiener PO und ManagementPO-Team Scrum-Team Sprint Release (1-6 Monate) Roadmap (6 Mon. – 2 Jahre)
    25. 25. Ziele der Planungshorizonte *: basierend auf Ellen Gottesdiener  Ausblick auf kommende Themen / Epics / Feature  Gemeinsames Verständnis erzielen  Konkrete Fragen des Teams beantworten  Akzeptanzkriterien ergänzen  User Stories schätzen  Ermittlung von Abhängigkeiten  Epics / Feature  Epics in User Stories splitten  Grobe Varianten erörtern und schätzen Nächste 1-2 Sprints Release- Vorschau Das große Ganze Roadmap
    26. 26. Abstimmung
    27. 27. Scrum – ein Blick ins Daily 29 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013
    28. 28. Daily - Scrum 30 „…und ich mach die Toten“ …Ich mache den Task „DB-Modell“ anpassen … …Ich mache den Task „Menueleiste anpassen„… ? „…die Toten machen wir nicht…“
    29. 29. Scrum – mit vielen POs 31 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done Scrum Guide 2013 PRE Planning
    30. 30. Product Owner Pre-Planning -32- Velocity Velocity Velocity Produktvision  Abgleich der geplanten Backlog Items mit Strategie  Fachliche Abhängigkeiten  Technische Abhängigkeiten  Know How Transfer Sprint oder Release Architektur- Vision Chief Product Owner PO Pre-Planning Product Owner Product Owner Product Owner Abgestimmtes Backlog
    31. 31. Anforderungserhebung
    32. 32. 34
    33. 33. Sprint Review – die traurige Realität ScrumMaster Entwicklerteam Product Owner
    34. 34. Sprint Review als Feedback- und Erhebungsworkshop „Das Ergebnis des Sprint Reviews ist ein potentiell neu organisiertes Product Backlog, bei dem die am höchsten bewerteten Product Backlog-Einträge am wahrscheinlichsten für das nächste Sprint Planning ausgewählt werden.“ Quelle: Scrum Guide 2013 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done
    35. 35. Umdenken Funktionale Dekomposition Agiles nutzenorientiertes Umfeld Epic User Story 1 User Story 2 User Story 3    Epic 1 User Story 1  Epic 2 User Story 1  Feedback Potentiell lieferbares Produkt- inkrement Feedback Potentiell lieferbares Produkt- inkrement User Story 2 User Story 3  
    36. 36. Feedback im agil skalierten Umfeld Hotline Endanwender Session-basiertes Testen …. Beta-Kunden / Pilotierung Endanwender EndanwenderPilotierungskunden Optionale Nutzung Product Owner Review-Event (Feedback- & Erhebungsworkshop) Videoaufzeichung Scouts beim Endkunden Usability Prototyping UX Usability Testing
    37. 37. Rollen im Business-Team
    38. 38. Der PO – ein Superheld? 40 Product Owner
    39. 39. Terminator Quelle: http://www.fuenf-filmfreunde.de/2009/04/23/ist-arnold-schwarzenegger-im-neuen-terminator-salvation-doch-zu-sehen/
    40. 40. NORMator Quelle: http://prem666.deviantart.com/art/Terminator-Robot-Face-398031009
    41. 41. NORMator – der Mann / die Frau für das regulierte Umfeld NORMator
    42. 42. Dokumentation 44 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkreme ntSprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Definiton of Done NORMatorDoR / DoD Sprint Notes Team Charta Architecture Notes Release Notes Test Documentation Prozess
    43. 43. NORMator im Überblick Agilität erleben 45 NORMator Validierung der Gebrauchstauglichkeit - User - Gebrauchsformen - Szenarien - Schnittstellen Risikomanagement - Risikoanalyse - Maßnahmen - Dokumentation Traceability sicherstellen …… Vollständigkeit der Dokumentation - Prozessvorgehen - Sprintnachweis - Architektur - Teamcharta - ….
    44. 44. Business-Team mit PO und NORMator 46 NORMator Product Owner
    45. 45. Der Business Analyst – was wird aus ihm? 47 Business Analyst
    46. 46. Story Mapping Prozess (zeitlicher Ablauf) … … … …… Aktivitäten R a n k i n g Aufgaben/ Tasks …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. …….. ……..
    47. 47. Story Mapping – Beispiel „Buchversand“ Prozess (zeitlicher Ablauf) Buchung finden Angebote sichern Bestellen- daten Bestellinfor- mationen Zahlungs- möglichkeiten Aktivitäten R a n k i n g Aufgaben/ Tasks Warenkorb legen Merkliste speichern Wunschliste speichern Lieferadresse eingeben Rechnungs- adresse eingeben Voraus- überweisung Per PayPal zahlen Bestellstatus- Informationen einsehen Kreditkarte nutzen Suche durch Titel Suche nach Autor Suche nach ISBN-Nr …….. Per Rechnung zahlen
    48. 48. Business-Team mit PO, BA und NORMator 50 NORMator Product Owner Business Analyst Prozess (zeitlicher Ablauf) Aktivitäten R a n k i n g Aufgaben / Tasks
    49. 49. Zusammenfassung
    50. 50. Scrum und mögliche Erweiterungen 52 Product Backlog Sprint Backlog Potentiell lieferbares Produktinkrement Sprint Planning Review Retrospektive Daily Sprint Sprint Max. 30 Tage Scrum Guide 2013 Story Time User Stor y Vision R E A D Y D O N E PRE Planning NORMator
    51. 51. Software-Entwicklung ist häufig komplex Technologie Anforderungen bekannt unbekannt bekanntunbekannt
    52. 52. Merkmale eines agilen Requirements Engineering – es muss nicht immer Scrum sein  RE ist eine kontinuierliche Tätigkeit und endet nicht nach einer Phase  Abkehr von der Vorstellung einer vollständigen Spezifikation / Änderungen sind willkommen  Direkte Kommunikation steht im Mittelpunkt und nicht die Spezifikation  „Wert“ einzelner Funktionen steht im Fokus und beeinflussen Rangfolge  Kontinuierliches Feedback  Teammitglieder und deren Know-how werden involviert  Abkehr einer „in Stein gemeißelten“ Kosten- und Zeitplanung am Anfang eines Projekts  Verschwendung vermeiden
    53. 53. Das Agile Manifest – 12 Prinzipien -55- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
    54. 54. Fragen und Diskussion
    55. 55. Andreas.Becker@HOOD-Group.com HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.Agile-by-HOOD.com Andreas Becker Agile Coach
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×