Embed Size (px)
Citation preview
Hvem er Totto?
•Sjefskonsulent i Objectware, Java Champion, ex. javaBin/JavaZone ansvarlig
•10 år som applikasjonsutvikler
•20 år som systemutvikler
•alle roller i prosjekter
Metode
•bakgrunn (OOram, UML, RUP standariseringen)
•CMM, PSP
•Smidig • SCRUM hovedsaklig
• P1: 40 pers, 12 mnd
• P2: 10 pers, 40 mnd
• P3: 6 pers, 6 mnd
2
Agenda
•Experiences
•The dark horizon
•How to act
•References
3
Religion
Tro kan flytte fjell
- kan tro skape god software?
4
EXPERIENCES
På hvilken bakgrunn er det egentlig at han Totto driver og uttaler seg i denne debatten?
5
Project 1: 40 pers, 12 mnd
•Bra effektivitet og prosjektresultat
•Arkitekturforvitring og duplisering av foretningsregler, spesielt i klientlaget
•Utfordrende å forvalte etter at prosjektressursene var ute av prosjektet
6
Score: 65%
Project 2
•Beslutning har konsekvenser var essentielt
•Ekstremt høy produktivitet (5x) igjennom 35+ sprinter
•Stor utskifting av ressurser uten produktivitetstap
•Arkitektur release sentralt
•Både prosjekt og forvaltning
7
Score: 85%
Project 3
•Scrum essentielt for suksess/leveranse – hadde ikke råd til en eneste feil..
•Veldig høy spredning i kompetanse og erfaring (les: overvekt av juniorer)
•Prioriteringer og tidlige avklaringer – kundeinvolvering
•Risikostyring
8
Score: 95%
SCRUM hotlist
•beslutninger har konsekvenser - læringssirkel
•fokus på resultat, ikke veien
•man finner tidlig ut at man er ”på tur”
9
SCRUM shortlist
•Manglende/feil kompetanse er det samme som katastrofe
•overforenkling og hardkoding (not invented here)
•Utmattelse etter 9-14 sprinter
10
THE DARK HORIZONMen dette virker jo for godt til å være sant – og det er det også…
11
Smidige prosjekter er et stor suksess
Men vi har noen ’nye’ utfordringer
• En lei tendens til å lage nye 2.5 lags database-sentriske siloapplikasjoner
• ”arkitektur, design er ikke viktig” –les: for vanskelig/tidkrevende • Testing –raske tester, som også skal være aktiv del av
dokumentasjon er selvmotsigelser
• Konfigurasjonsstyring –blir ofte ’glemt’ i smidige prosjekter, siden drift sjelden er aktiv stakeholder.
• Smidig-bevegelsener religiøst selvsentrisk, og lite villige til å se konsekvenser
• (Overvekt av hotshot-grooupies)
12
What the marked sees…
Today, the agile community faces threats from non-agile communities by failing to deliver good solutions with regards to TCO, enterprise requirements and team skill and/or Cargo Cult.
This is by itself not a weakness with the Agile manifesto, but if the community fail to address and solve these challenges, we fear that software development is forced back to non-agile practices.
13
What Gartner demands…
•"The message for IT is clear; business needs and expects greater agility from IT," said Ms. Gomolski. "The current approaches to project prioritization, resourcing, agility and governance are clearly not satisfying customer needs."
• "Moreover, in these troubled economic times, CIOs need to remember that choosing the least-cost approach to solving today's technology needs may become the most expensive, least-effective in the long run."
•Gartner October 14, 2008
14
Som betyr
•Tiden for religion er over..
•Smidige team er aldri perfekte – vi må støtte opp om hullene med gode software engineeringprosesser der det behøves
•Hvis vi ikke har en god “teknisk arkitekt” i teamet eller på tvers av teamene så er vi i risikosonen
•Smidige prosjekter er ikke for alle!
•Tro har flyttet fjell, men hvis vi ikke klarer å levere så er vi like langt
15
HOW TO ACT
OK, så var det ikke så lett alikevel, men hva skal vi gjøre for å få høstet litt av verdibudskapet til smidig?
16
Agile manifest - extended
•evolve ability and maintainability over project heroes
•sustainability and total customer value over features and glass bowl project focus
•facts and knowledge over religion and preaching
17
Som betyr
•... bruk det Agile Manifestet som basis
•… vurder relevansen av de foreslåtte utviddelsene for prosjektet/teamet
•… spe på med posesser og teknikker for å dekke kompetansehull
•... glem ikke å bruke hodet
•... ingen sa at smidig var enkelt eller for alle
18
Startpunkter..
•Gjeninnføre arkitektur og design • Tøffe utfordringer trenger de beste utviklerne!
• Hvor ble det av anti-corruptionlayer?
• Vi kan ikke fortsette å ignorere at modning tar tid
•Opprette/standariseretest-kategorisering • Gjeninnføre et bevist forhold til konfigurasjonsstyring og
versjonering.
•Gjeninnføre sunn fornuft
19
Eksempler på nøkkelutfordringer som man trenger “hodet” til
Arkitektur
• How to ensure a sound architecture when starting a new project?
• How to prevent the architecture from corrupting over time?
• Technical and architectural debt
• How to avoid sub-optimization?
• Which design/architecture decisions can a single programmer (or a pair) make by themselves?
• How to make developers aware of that their decisions might have more far-reaching effects than their single, small component?
20
References
•Agile 2.0• http://wiki.community.objectware.no/display/smidigtonul
l/Agile+2.0+Community+Home
•Undertegnende:
21
