Väle tarkvaraarendus - kodu.ut.eekodu.ut.ee/~kiho/TVTkonspekt/VOtsasonAgile/VOtsasonXP.pdf · – Ei oma liigseid klasse ja meetodeid • Täna tuleb lahendada tänaseid probleeme

1

Väle tarkvaraarendusEkstreemprogrammeerimine

Veljo Otsason

Loengute kava

1. Sissejuhatus teemasse– Mis on väle arendus ja miks see hea on?

2. Väledad metoodikad– RUP, XP, DSDM, Scrum jne. Nende

sarnasused ja erinevused.3. Ekstreemprogrammeerimine

– Põhimõtted, arendusprotsess, praktikad jne.

2

Mis on väle arendus?

• Väle (agile) lähenemine tähendab:– Kergekaalulist arendusprotsessi– Muutustega kohandumist– Inimestele orienteeritust

• Üks võimalik viis, kuidas tarkvara luua. Sobib paremini teatud projektide korral

• Olemas mitmed erinevad väledad metoodikad

• License to hack?

Väleda arenduse manifest

• Eelistatakse:– isikuid ja suhtlust

protsessile ja vahenditele– töötavat tarkvara

kõikehaaravale dokumentatsioonile– kliendiga suhtlust

lepinguläbirääkimistele– muutustele vastamist

plaani järgimisele

- agilemanifesto.org

3

Väle vs. plaan-juhitud

Täielik“häkkerlus” XP

Täielikult etteplaneeritud

tegevus

Väledad metoodikad

CMMI

- Barry Boehm, USC

Cutter Consortium’i uuring

51%

38%

23% 22%19%

8% 7%3%

0%

10%

20%

30%

40%

50%

60%

osak

aal v

asta

nute

st

RUP XPFDD

ASDDSDM

Crystal

Clea

r LDScru

m

Lisaks:54% oli kasutanud omaleiutatud väledat metoodikat9% oli kasutanud mõnda muud väledat metoodikat

4

Võrdlus• Ulatus

– RUP, DSDM vs. Scrum, FDD• Detailsus

– XP, RUP vs. ASD, CrystalClear

• Rakendatavus– RUP ei piira, Crystal Clear

piirab• Iteratsioonid

– Igal pool olemas, kuid eri pikkustega (FDD, XP vs. RUP, Crystal Clear)

• Kliendi seotus– Eriti oluline XP ja DSDM korral

• Nõuded– kliendile mõistetavad osad

• Tiimi dünaamika– FDD muutuvad meeskonnad,

XP paarisprogrammeerimise partnerite vahetus

• Koodi omand– XP – kollektiivne, FDD -

individuaalne• Visuaalne modelleerimine

– RUP, FDD eeldavad UML-i• Metoodika arendus ja

haldamine– DSDM-i ja RUP-i arendavad

organisatsioonid• Mida on uuritud?

– XP ja RUP eelkõige

Kuidas metoodikat rakendada?

• Kasutamisele peab eelnema analüüs• Vajadus kombineerida eri metoodikaid• Rakendamine samm-sammult

olemasolevat metoodikat muutes• Eesmärk pole metoodikat kasutada vaid

edukalt tarkvara arendada

5

Tänased teemad

• Ekstreemprogrammeerimisest detailsemalt• Väärtused• Printsiibid• Arendusprotsess• Praktikad• Millal XP ei sobi

Ekstreemprogrammeerimine• eXtreme Programming (XP)• XP on kergekaaluline, kohanduv, inimese- ja

suhtluskeskne ning probleemilahendamisele orienteeritud arendusprotsess väikestele meeskondadele olukordadeks, kus kergesti muudetava lahenduse loomine on tulevikuennustamisest odavam

• Üks tuntumaid väledaid metoodikaid• Detailsed praktikad• Metafoor: tarkvara kui autosõit

6

Neli muutujat

• Arendusprotsessi kontrollivad neli muutujat– Maksumus– Aeg– Kvaliteet– Ulatus

• Neljast muutujast kolme väärtused võib lastamäärata välistel jõududel, arendusmeeskondmäärab neljanda muutuja väärtuse

Tarkvara kolmnurk?

Tavaline

Funktsionaalsus

Aeg Ressursid

DSDM

Funktsionaalsus

RessursidAegfikseeritud

muutuv

7

Põhiväärtused• Suhtlemine

– arendusprotsessi efektiivsuse aluseks on suhtluskõigi osapoolte vahel

• Lihtsus– lahendada tuleb tegelikke probleeme

• Tagasiside– adekvaatne tagasiside aitab tarkvara täiustada

• Julgus– muutustega kaasa minemine nõuab julgust, vigade

tunnistamine nõuab julgust

Printsiibid

• Kiire tagasiside• Lihtsuse eeldamine• Inkrementaalsed muutused• Muutuste aktsepteerimine• Kvaliteet

8

Põhitegevused

• Kodeerimine– Lahenduse koostamine probleemile

• Testimine– Lahenduse kvaliteedi mõõtmine

• Kuulamine– Lahendatava probleemi leidmine,

täpsustamine• Projekteerimine (disain)

– Lahendusele loogilise struktuuri andmine

Arendusprotsess

• Teineteisele järgnevad redaktsioonid (release)

• Iga redaktsiooni lõpus viiakse tarkvara töökeskkonda

• Redaktsioon kestab 1..3 kuud. Esimene redaktsioon kestab kauem (2..6 kuud)

• Redaktsioon koosneb iteratsioonidest• Iga iteratsioon kestab 1..3 nädalat

9

Arendusprotsess

Redaktsiooniplaanimine Iteratsioon Vastuvõetavus

testidVäljastaminekasutajatele

Kasutajalood

Nõuded

Redaktsiooniplaan Tarkvara Kliendi

nõusolek

Järgmineiteratsioon

Testistsenaariumid

Praktikad

• Lihtsad, enamasti ammutuntud ja läbiproovitud

• XP paneb need kokku ja “viib äärmuseni”• Praktikad toetavad üksteist

10

Praktikad

• Plaanimismäng• Väikesed

redaktsioonid• Metafoor• Lihtne disain• Testimine• Rekodeerimine

• Paaris-programmeerimine

• Kollektiivne omand• Pidev integreerimine• 40-tunnised nädalad• Kasutaja tiimis• Ühtne

kodeerimisstandard

Praktikad





kodeerimisstandard

11

Plaanimismäng

• Äriinimeste otsustada:– Projekti ulatus– Alamülesannete

prioriteedid– Redaktsioonide

koostis– Redaktsioonide

väljalaske ajad

• Arendajate otsustada:– Mahuhinnangud– Strateegiliste

äriotsuste tehnilisedtagajärjed

– Arendusprotsess– Detailne ajagraafik

Plaanimismäng

12

Praktikad





kodeerimisstandard

Väikesed redaktsioonid• Arendusmeeskonnale on oluline kliendi

tagasiside• Õigeagne tagasiside aitab projekti

ebaõnnestumist vältida• Klient saab kõige olulisemat juba kasutama

hakata• Redaktsioon

– On nii väike kui võimalik– Sisaldab olulisi ärivajadusi– Omab tervikuna mõtet

13

Praktikad





kodeerimisstandard

Metafoor

• Metafoor on lugu, mis ütleb niiprogrammeerijale, kliendile kui ka juhile, kuidas süsteem töötab– Ühine vaade– Ühine sõnavara– Loomingulisus– Arhitektuur

14

Praktikad





kodeerimisstandard

Lihtne disain

• Korrektselt kirjutatud tarkvara– Läbib kõik testid– Ei sisalda dubleeritud loogikat– Väljendab ilmutatult kõiki programmeerija olulisi

kavatsusi– Ei oma liigseid klasse ja meetodeid

• Täna tuleb lahendada tänaseid probleeme• XP ei tegele ennustamisega vaid valmisolekuga

jätkata ükskõik millise tuleviku korral

15

Praktikad





kodeerimisstandard

Testimine• Erisust ilma automaatse testita ei eksisteeri• Komponenditeste kirjutavad programmeerijad• Funktsionaalsed testid koostatakse koos

kliendiga• Testid on kvaliteedi tagatis ja mõõdupuu

– 100%– Komponenditestid võimaldavad rahulikult katsetada ja

rekodeerida• Test kirjutatakse enne koodi, ehk siis

– Kõigepealt projekteeritakse liides– Pannakse kirja tulemus, mida soovitakse saada

16

Praktikad





kodeerimisstandard

Rekodeerimine• Rekodeerimine (refactoring) on XP viis

projekteerida• Rekodeerimine on programmi struktuuri

teisendamine selliselt, et funktsionaalsus säilib• Enne erisuse lisamist rekodeerida nii, et erisust

oleks lihtne lisada• Peale erisuse lisamist lihtsustada koodi

säilitades samal ajal funktsionaalsuse• Rekodeeritakse vaid siis kui süsteem seda palub• Näide – dubleeritud kood

17

Praktikad





kodeerimisstandard

Paarisprogrammeerimine

• Kogu kood kirjutatakse paaris• Kaks inimest töötavad koos ühe arvuti taga

– Juht – kirjutab koodi– Kaardilugeja – jälgib juhi tööd, mõtleb kaasa, leiab

vigu• Rolle ja paarilisi vahetatakse• Toimub suhtlus, informatsiooni vahetamine• Pidev koodi ülevaatus• Peer pressure

18

Paarisprogrammeerimine

Praktikad





kodeerimisstandard

19

Kollektiivne omand

• Kelle oma võib kood olla?– Ei kellegi kood– Viimase, kes muutis– Igal klassil/kihil omanik– Kollektiivne omand

• Kollektiivne omand– Kõigil on ülevaade– Teiste järgi ei pea ootama– Samas, suure koodi korral raske kõigil ülevaadet

omada

Praktikad





kodeerimisstandard

20

Pidev integreerimine

• Millal integreerida?– Vahetult enne väljalaset?

– Iga päev.

–Pidevalt!

• Pidev integreerimine– Iga paari tunni tagant– Eraldi masin

integreerimiseks– Integreerimise käigus

ilmnevad probleemidlahendavadintegreerijad

– 100%!!!

Praktikad





kodeerimisstandard

21

40-tunnised nädalad

• Pidevad ületunnid on tunnistusekstõsisematest probleemidest

• XP korral teist nädalat ületunde ei tehtavaid otsitakse lahendust tegelikuleprobleemile

• Puhkus on oluline eeldus töötahtetekkimiseks ja töövõime säilimiseks

40-tunnised nädalad

22

Praktikad





kodeerimisstandard

Kasutaja tiimis

• Tulevase süsteemi reaalne kasutaja on tiimi liige– Vastab küsimustele– Määrab prioriteete– Koostab lähtematerjale testide tarbeks

• Kui firma leiab, et üks töötaja on talletulusam kui töötav süsteem, siis tulebküsida, kas seda süsteemi üldse vaja on

23

Praktikad





kodeerimisstandard

Ühtne kodeerimisstandard• Kuidas kirjutatakse koodi, sh:

– Kirjutatakse kommentaare– Täistatakse muutujaid– Kirjutatakse meetodeid

• Suhtumine kodeerimistandarditesse– Standard puudub, kirjutan, kuidas juhtub– Igaühele oma, kasutab igal pool– Igaühele oma, aga teise koodi muutes kasutan tema

standardit– Meeskonnal on ühine standard

• Kollektiivne omand eeldab ühtset standardit!

24

Millal XP ei sobi?• Sobimatu ärikultuur

– Dokumentatsiooni ülehindamine, ületunnid, vale ruumikujundus

• Suured tiimid– Üle 10-liikmeline tiim on juba raskendav

• Mitteusaldav klient– Ei nõustu koostööd tegema, tahab fikseeritud lepingut

• Muutused on kallid– Nt. peab arvestama paljude teiste süsteemidega

• Liiga pikk tagasisidetsükkel– Nt. süsteemi kompileerimine võtab 24h, tihti testimine

liiga kallis

Infoallikad

• Raamatud:– K. Beck, “Extreme Programming Explained:

Embrace Change”, 1999– K. Beck et al., “Planning Extreme

Programming”, 2000– R. Jeffries et al., “Extreme Programming

Installed”, 2000• www.extremeprogramming.org• www.xprogramming.com

25

Kokkuvõtteks

• XP on üks levinumaid väledaid metoodikaid

• XP põhiväärtused on:suhtlemine, lihtsus, tagasiside, julgus

• XP on kirjeldatud detailsete praktikatega

Loengumaterjalid

• Loengumaterjalid, kordamisküsimused jm.:www.cs.ut.ee/~veljoo/teach/se/

• Kontakt:[email protected]

26

Kohtumiseni eksamil:)

Documents

Väle tarkvaraarendus - kodu.ut.eekodu.ut.ee/~kiho/TVTkonspekt/VOtsasonAgile/VOtsasonXP.pdf · – Ei oma liigseid klasse ja meetodeid • Täna tuleb lahendada tänaseid probleeme