Robust smidig systemutvikling

Presentasjon om: "Robust smidig systemutvikling"— Utskrift av presentasjonen:

1 Robust smidig systemutvikling
når resultater er viktigere enn religion Totto

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 Metode - metodebakgrunn (OOram, UML, RUP standariseringen) - CMM, - Smidig (SCRUM hovedsaklig) siden 2001 SCRUM - 3 prosjekter: -- 40pers, 12 mnd -- 10 per, 40 mnd -- 6 pers, 6 mnd

3 Agenda Experiences The dark horizon How to act References

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

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

6 Bra effektivitet og prosjektresultat
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 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 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 Score: 95%

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

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

11 Men dette virker jo for godt til å være sant – og det er det også…
The dark horizon

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)

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.

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

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

16 OK, så var det ikke så lett alikevel, men hva skal vi gjøre for å få høstet litt av verdibudskapet til smidig? How to act

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

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

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

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?

21 Agile 2.0 Undertegnende: References totto@totto.org
Undertegnende: