Robust smidig systemutvikling nr resultater er viktigere enn

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

Hvem er Totto? Metode • Sjefskonsulent i Objectware, Java Champion, ex. java. Bin/Java. Zone ansvarlig • 10 år som applikasjonsutvikler • 20 år som systemutvikler • alle roller i prosjekter • bakgrunn (OOram, UML, RUP standariseringen) • CMM, PSP • Smidig • SCRUM hovedsaklig • P 1: 40 pers, 12 mnd • P 2: 10 pers, 40 mnd • P 3: 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

På hvilken bakgrunn er det egentlig at han Totto driver og uttaler seg i denne debatten? EXPERIENCES 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 Score: 65% 6

Project 2 • Beslutning har konsekvenser var essentielt • Ekstremt høy produktivitet (5 x) igjennom 35+ sprinter • Stor utskifting av ressurser uten produktivitetstap • Arkitektur release sentralt • Både prosjekt og forvaltning Score: 85% 7

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

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

Men dette virker jo for godt til å være sant – og det er det også… THE DARK HORIZON 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 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

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 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/smidigtonull /Agile+2. 0+Community+Home • Undertegnende: • totto@totto. org 21