Anforderungen, Architektur, Projektvertrag – ein Trio von Freunden(?)
Umfragen unter Benutzern von IT-Systemen ergeben: Nur zwanzig Prozent der Funktionen eines IT-Systems werden „immer“ oder „oft“ benutzt, fast zwei Drittel hingegen „selten“ oder „nie“. Diese Zahlen haben den Umgang mit Anforderungen in IT-Projekten verändert: Agilität und Flexibilität sind heute wichtiger geworden als je zuvor. Es muss nicht mehr alles realisiert werden, was geplant wurde. Lernen im Projekt ist ausdrücklich erlaubt, Änderungen sind willkommen. Das neue Vorgehen stellt auch neue „Anforderungen an die Anforderungen“. Der Vortrag zeigt, wie Anforderungen heute aussehen können, um drei Vorteile daraus zu ziehen: Software-Architekten können daraus eine tragfähige Architektur herleiten, Entwicklungsteams können sie gut und zeitnah umsetzen, der Projektfortschritt kann einfach gemessen und vorausgesagt werden. Der Vortrag gibt Ihnen einen Einblick in die neuesten Entwicklungen in der Gestaltung von Projektverträgen. „Money for nothing, changes for free“ sind hier die zunächst unglaublich klingenden Stichworte. Auftraggeber und Entwicklungsorganisation ziehen am selben Strang, Änderungsanforderungen kosten ab jetzt kein zusätzliches Geld mehr und brauchen deshalb nicht mehr verhandelt zu werden. Energie wird frei, damit Sie sich auf die wirklich wichtigen Dinge im Projekt konzentrieren und so einen echten Vorsprung gegenüber dem Wettbewerb erreichen können.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Anforderungen, Architektur, Projektvertrag – ein Trio von Freunden(?)
Ähnlich wie Anforderungen, Architektur, Projektvertrag – ein Trio von Freunden(?) (20)
Mehr von Matthias Bohlen
Mehr von Matthias Bohlen (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Anforderungen, Architektur, Projektvertrag – ein Trio von Freunden(?)
- 1. Anforderungen, Architektur und Projektvertrag – ein Trio von Freunden(?)! Vortrag auf der OOP 2010 Matthias Bohlen <mbohlen@mbohlen.de> Unabhängiger Coach und Berater
- 2. Requirements How should they look like?
- 3. 3 The Ship: A Model for Requirements Online Store Advertise Order Invoice Identify promotion Register user Setup promotion Monitor promotion Place order Create invoice Business Goals User Goals Alistair Cockburn Overall project Functions Identify product Identify customer
- 4. 4 User Stories: The three C's Card Conversation Confirmation Ron Jeffries
- 5. 5 A story template <Story title> <Role> can <do what> so that <why> How to demo: 1. System does this… 2. User does that… 3. System reacts like this… Business value Effort estimate Issue#
- 6. 6 Example Story Review submission Reviewer can review a submission so that the chairman will know how good it is. How to demo: 1. System lists submissions assigned to this reviewer 2. Reviewer selects submission for download 3. System serves document file 4. Reviewer assigns rating: A (strong) to D (poor) 300 3857 5
- 7. 7 INVEST in good stories! Bill Wake Independent Negotiable Valuable Estimatable Small Testable
- 8. Architecture How do we find it?
- 11. 11 Architectural Metamodel Application Module Data Service Entity Value Object à la Eric Evans' DDD
- 12. 12 User ConferenceController user/register.gsp … Conference Submission Submission View Controller Service ConferenceService Domain Tag Example: splendicon.net powered by
- 13. 13 From Story to Architecture noun concept controller name verb action controller method name noun concept entity name noun attribute name
- 14. 14 From Story to Architecture Review submission Reviewer can… How to demo: 1. System lists submissions assigned to this reviewer 2. Reviewer selects submission for download 3. System serves document file 4. Reviewer assigns rating A (strong) to D (poor) 5. Reviewer comments on his rating 6. System assigns rating and comment to submission 300 3857 5 concept / entityaction attribute action
- 16. Project Contract How do we satisfy both customer and developers?
- 17. 17 Contracts are a matter of trust Customer asks: Will they develop what I need? Do they understand me? Do they charge me for every change? Do I have to know everything in advance so that changes are minimal? Do they keep their promised delivery date? Developers ask: Will they pay us? Do they clearly say what they need? Fixed-price project: How about all those changes they want? Fixed-time project: How do we keep the release date facing all those changes? Usual reaction: Customer installs rich, heavy- weight change management process !
- 18. 18 Scrum overview Image available at www.mountaingoatsoftware.com/scrum
- 19. 19 Product Backlog: Sprint #1 Story 1 Goal: Deliver business value in shortest possible time 500 3 Story 2 300 5 Story 3 200 8 1000 16
- 20. 20 Scrum: Changes for free Cancel Gift wrap Return Sprint 2-4 weeks Return Sprint goal Sprint backlog Potentially shippable product increment Product backlog CouponsGift wrap Coupons Cancel 24 hours
- 21. 21 Scrum Change Management Product Backlog: Sorted by descending business valueStories New story with high biz value Story with lowest biz valueEffort estimate for added story must be less or equal to sum of removed stories.
- 22. 22 Money for nothing Business value Rise in business value is non-linear 100% Terminate here! Original plan €€€ saved 80% to customer 20% to developers Time 80%
- 23. 23 Three friends, now! Questions? Call: +49 (170) 7728545 e-mail: mbohlen@mbohlen.de