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

1. 1
Robust smidig systemutvikling
når resultater er viktigere
enn religion
Totto
Totto@objectware.no

2. 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

3. Agenda
•Experiences
•The dark horizon
•How to act
•References
3

4. Religion
Tro kan flytte fjell
- kan tro skape god
software?
4

5. EXPERIENCES
På hvilken bakgrunn er det egentlig at han Totto driver og uttaler
seg i denne debatten?
5

6. 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%

7. 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%

8. 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%

9. SCRUM hotlist
•beslutninger har konsekvenser -
læringssirkel
•fokus på resultat, ikke veien
•man finner tidlig ut at man er ”på
tur”
9

10. SCRUM shortlist
•Manglende/feil kompetanse er det
samme som katastrofe
•overforenkling og hardkoding (not
invented here)
•Utmattelse etter 9-14 sprinter
10

11. THE DARK HORIZON
Men dette virker jo for godt til å være sant – og det er det også…
11

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. References
•Agile 2.0
• http://wiki.community.objectware.no/display/smidigtonul
l/Agile+2.0+Community+Home
•Undertegnende:
•totto@totto.org
21