�ݺ�ߣ

Tommi Laitila ja Mikko Mustakallio  
05.12.2012"
Pragmatic Agile

Pragmatic Agile"
•  Mikä se on?"
•  Miten se toimii käytännössä?"
•  Mitä asiakas siitä hyötyy?"

Miksi ketterä kehitys? "
•  Perinteinen vesiputousmalli ja sen variantit eivät enää
kyenneet vastaamaan vaatimuksiin"
–  Järjestelmien koko ja monimutkaisuus teki etukäteen
konseptoinnin (Big Design Up Front) haastavaksi"
–  Isoissa hankkeissa ennustettavuus perinteisillä
malleilla oli epätarkkaa"
–  Aikatauluvaatimukset (Time-to-market) pakotti
aikaistamaan toteutusta hankkeissa"
–  Työntekoa piti tehostaa, johon ratkaisun toi
itseohjautuvat tiimit ja jatkuva priorisointi"

Miksi Pragmatic Agile?"
•  Työkalupakki liiketoimintajärjestelmien ketterään
kehittämiseen"

Mitä Pragmatic Agile tuo lisää ketterään
kehitykseen "
•  Hyvä takaisinmaksuaika (ROI) "
•  Ilman elinkaarikustannusten (TCO) nousua"

Laadukas syöte kehityssykliin"
•  Kehityssykli on kone, joka tuottaa ICT-järjestelmän"
–  Ulos tulevan lopputuotteen laatu korreloi syötteen
laadun kanssa"

Tuote-backlog pitää valmistella ennen
kuin sprint commitment voi tapahtua"

Tarkoituksenmukaisen arkkitehtuurin
varmistaminen (lean)"

Toteutuksesta pienkehitykseen ja ��ä�辱�ٴǴǲ�&��ܴǳ�;

Miten se toimii
käytännössä?"

CASE"
Responsiivinen
kuluttajaverkkopalvelu"

Asiakkaalle aivan uudenlainen sopimus"
•  Lähdettiin rakentamaan uudenlaista luottamussuhdetta
välille tilaaja-toimittaja"
•  Puitesopimus pienen, ketterän toimijan kanssa, joka
tarjoaa osaamisen liiketoimintakonseptista toteutukseen"
•  Ainoastaan laadullisia mittareita sopimuksessa"
•  Asiakkaan ja toimittajan tekijät nivoutuvat yhdeksi tiimiksi"
•  Kvartaaleittain hankintatilaus, jonka pohjana tiimien
tarvitsema optimaalinen roolitus tekemisen luonteeseen
nähden"

Mitä luvattiin?"
•  Oikea ketterän kehityksen malli, jota liiketoiminta voi
ohjata omien prioriteettiensa mukaan"
•  Itseohjautuvat Hero-tiimit"
•  Aivan uudenlaista näkyvyyttä ja ennustettavuutta
hankkeen etenemiseen"
•  Automatisoida kaikki, mikä on järkevästi
automatisoitavissa"
•  Laatu aivan uudelle tasolle"
•  Kova asenne ja vahva vastuuntunto paikalle"
•  Elinkaarikustannusten hallittavuus"

Resources
��
Infrastructure
��
Technology
��
Solu%on
��
design
��
Architecture
��
Scrum
��
Quality
��&
��
deployment
��
Needs
��&
��
��
Requirements
��
Business
��
Produc;on
��
IT
��
Enterprise
��
Architecture
��
Architecture
��
Releases
��
Pragmaattinen malli"

KAPO = Konseptointi, Arkkitehtuuri,
Prototyypitys, Operatiivinen malli"
BUSINESS" Design" UI" Concept"
Architecture"
Web dev"
Operational Process"
Proto" CMS dev"
Content"
Testing"
BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"

Hero Team –periaatteet"
I.  Arkkitehtuuri ja ratkaisukonseptointi yhdessä:  
Vahva arkkitehtuuri- ja ratkaisukonseptointiosaaminen tiimissä keskenään
samassa tilassa. Liiketoimintatarpeet selkeytetään ja prosessoidaan tekniseksi
ratkaisuksi ja tuotetaan Product backlog -itemit toteutustiimille. Operatiivinen
optimointi suoritetaan osana ratkaisukonseptia."
II.  Prototyyppi: HTML5-ulkoasu, CSS-tyylitiedostot, Javascript, graﬁikat"
III.  Toteutettu ominaisuus: Hero Team tuottaa ratkaisukonsepteista suoraan
tuotantokelpoisia ominaisuuksia (Java-toteutus + CMS-integraatio) "
–  Yhteinen vastuu, yhteiset työkalut"
  Saumaton sykli: "
–  Ratkaisukonseptoinnista prototyypin kautta operatiivisesti optimoituun
tuotantovalmiiseen järjestelmään"
 Saumaton toiminnallinen laatu:"
–  Konseptisuunnittelija vastaa lopputuotteen toiminnallisesta laadusta
yhdessä kehittäjän kanssa (sign-off ennen hyväksyntätestausta)"
–  Hero Team vastaa testiautomaatiosta ja koodikatselmoinneista"

Vähemmän tekijöitä mutta laajemmissa
rooleissa"
•  Pieni, tehokas tiimi tarkoittaa, ettei tarvita dedikoituja
henkilöitä kapeisiin “laput silmillä” -rooleihin"
•  Laajemmat roolit tukevat kokonaisuuden ymmärtämistä
ja vähentävät vastuurajojen epäselvyyttä"
•  Vähemmän rajapintoja ihmisten/roolien välillä varmistaa
saumattoman kommunikaation"

Pragmatic Agile - Aamiaistilaisuus

Miten lupaus pidettiin?"
•  Asiakas vahvasti integroitu prosessiin"
•  Konseptointi, arkkitehtuurin ohjaus ja protoilu
esisprintissä, joka syötteenä toteutussprinttiin"
•  Itseohjautuvat moniosaajatiimit (Hero Team)"
•  Testilähtöinen kehitys konseptista ylempiin ympäristöihin"
•  Automatisointi kehitykseen, asennuksiin ja testaukseen"
BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"

Mitkä ovat asiakkaan
hyödyt?"

Projektin tila nyt"
I.  Pienemmällä porukalla tehdään isompia asioita
nopeammin ja laadukkaammin"
II.  Lopputuotos on täysin testaantuvaa ja design-velka
minimoitu (vrt. perinteinen käsitys agile-malleista)"
III.  Velocity on tasaantunut ja ennustettavuus parantunut"
IV.  Liiketoiminnan ketterä ohjaus toimii:  
liiketoimintavaatimus sisään, toimiva ominaisuus ulos "

Hard Facts* 1/4 – tiimin koko,  
lähtötilanne vs. Nitor-TB haltuunotto"
0"
10"
20"
30"
40"
50"
60"
70"
Ennen" Nitor-TB"
Projektin pääluku
yhteensä"
Backlog-itemeita
toteutettu"
•  Vaikka projektin pääluku
(ml. konseptoijat,
arkkitehdit, kehittäjät) on
laskenut 1/3-osaan,
ominaisuuksia
toteutetaan jopa
enemmän"
*Vertailun pohjana olevat luvut katsottu yhdessä asiakkaan kanssa kahdesta verrokkisprintistä. Ominaisuus tai backlog item
pysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaan pikemminkin suuntaa-antava yksikkö.

Hard Facts 2/4 - kehittäjän panos per sprintti"
•  Aika, jonka kehittäjät
nyt pystyvät
dedikoimaan itse
kehitystyöhön, on
kasvanut 15%"
4,0"
4,5"
5,0"
5,5"
6,0"
6,5"
7,0"
7,5"
8,0"
Ennen" Nitor-TB"
Kehittäjän kontribuutio
sprinttiin (htp)"

Hard Facts 3/4 - kehittäjän käyttämä aika vs.
toteutettu ominaisuus"
0,0"
1,0"
2,0"
3,0"
4,0"
5,0"
6,0"
7,0"
8,0"
Ennen" Nitor-TB"
HTP:tä / Backlog Item"
•  Hero-tiimin osana
toimivilta kehittäjiltä
menee nyt n. 60%
vähemmän aikaa
yhden liiketoiminnan
tarvetta vastaavan
ominaisuuden*
toteuttamiseen"
*Ominaisuus tai backlog item pysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaan
pikemminkin suuntaa-antava yksikkö.

Hard Facts 4/4 - Tekniset parannukset
(esimerkkejä)"
•  Käännös ja automaattinen
testaus 1/10-osaan "
•  Järjestelmän rakennus ja
asennus (kehitysympäristö)
1/20-osaan"
•  Mahdollistettiin “build on commit”"
•  Muut ympäristöt olivat
manuaalisia ja nyt
automatisoitu"
0"
5"
10"
15"
20"
25"
30"
35"
40"
Ennen" Nitor-TB"
Minuuttia"
0"
20"
40"
60"
80"
100"
120"
140"
160"
180"
Ennen" Nitor-TB"
Minuuttia"

Tekniset parannukset (näkyvyys)"
•  Mitä mitataan näkyy kaikille"

Yhteenveto"
•  Kehityssyklin lopputuote on syötteestä riippuvainen,
saumaton yhteistyö varmistaa tehokkuuden ja laadun "
•  Selkeät vastuut (DoD) ja saumattomat hand-overit
varmistavat, että kehittäjät tekevät oikeita asioita eikä
heidän työnsä keskeydy kesken sprintin "
•  Asiakkaiden ei enää tarvitse ostaa isoja projekteja ja
useita erilaisia mutta kapeita rooleja, vaan keskittyä
moniosaajiin, jotka tehokkaasti tuottavat
liiketoimintavaatimuksista toimivan järjestelmän"

Asiakkaamme kertovat"
”Oikeasti, hyvät tyypit ja rutkasti asiantuntemusta”
“They have good working moral
and always look for the best
interest of the customer.”
“Talent Base and NitorCreations’ people
stand out especially with subject matter
expertise and mastering of their
responsibility areas”“I personally would prefer a small
service provider like NitorCreations to
a large service vendor with
complicated hierarchy and processes”
“They stand out with their brilliant down-to-
earth, humble and always helpful attitude”
“If something isn’t clear to myself or others in the
business, your guys patiently take the time to
explain or bring in others who can help”
“Easy to approach with any
questions at any time, no matter
what the issue”

THIS IS WHAT COUNTS:
☐
Team delivers working, tested software after each iteration
☐
Team delivers what the business needs most
☐
Team is continuously improving its practices
☐ Clearly defined product owner (PO)
☐
PO is dedicated to the project and easily available to the team
☐
PO is empowered and has knowledge to prioritize
☐
PO has direct contact with team
☐
PO has direct contact with stakeholders
☐
PO maintains a product backlog (PBL)
☐
PBL is prioritized by business value
☐
PBL is visible to the team
☐
Top PBL items are well understood and ready for development
☐
Grooming takes place before sprint planning
☐
Bizcases have been approved
☐
Architectural implications to other systems have been agreed
☐
UI mockups have been created an verified
☐
Items have been estimated by the team
☐
Items are small enough to fit in a sprint
☐
Team understands architecture and goals of surrounding systems
☐
Team receives architectural guidance when needed
☐
Team can bring up architectural issues and proposals
☐
Issues and proposals are managed transparently
☐
Team has sprint planning meetings
☐
PO brings an up-to-date PBL with well-understood items
☐
Whole team and PO participates
☐
Meeting is not longer than 4 hours
☐
Team decides what fits into the sprint
☐
Team has a visible sprint backlog and a burndown chart
☐
Team has a release burndown chart
☐
Teams estimate in story points rather than hours
☐
Team velocity is measured and used for release planning
POSITIVE INDICATORS:
☐
Team is having fun and is being trusted by stakeholders
☐
Work generally takes place within the limits of normal working hours
☐
The atmosphere is open for discussing, experimenting and criticizing
Pragmatic Agile check list v1.1
☐
Daily scrum (max 15 minutes) takes places daily at the same time
☐
Whole team participates
☐
Impediments surface and are dealt with
☐
Clearly defined scrum master (SCM) who is not PO
☐
Team knows top impediments
☐
SCM works actively to solve impediments
☐
Escalated to mgmt. when team cannot solve
☐
All code is automatically tested
☐
Continuous integration is used
☐
Unit tests are written and test coverage is followed

☐
Acceptance tests are automated and created based on user stories
☐
Demos are held after each sprint before the next one starts
☐
PO and the required stakeholders participate
☐
Useful feedback is received
☐
Retrospective takes place after each sprint
☐
The entire team including the PO participates
☐
Results in improvement proposals and some get implemented
☐
Sprints of max 4 weeks
☐
Thee sprints always end on time
☐
Team usually finished most items
☐
Team is not disrupted by other tasks
☐
Team possesses all skills required for completing items

�ݺ�ߣ

Pragmatic Agile - Aamiaistilaisuus

Recommended

More Related Content

What's hot (9)

Similar to Pragmatic Agile - Aamiaistilaisuus (20)

Pragmatic Agile - Aamiaistilaisuus