Kesäketterän ohjelmistotuotantoprojektin prosessikuvaus 2009

Johdanto Ohtuketterään prosessimalliin

Kesän 2009 ohjelmistotuotantoprojekteissa kokeiltiin ketterää kehitystä sovelletulla Scrum-variantilla. Oppilailta ei edellytetty esitietoa kyseistä mallista, vaan ohjaaja auttoi opiskelijat alkuun. Niksit tulivat tutuiksi kurssin aikana, ja ohjaajan vastuulla oli valvoa, että ryhmä toimii prosessin mukaisesti.

Tämän dokumentin tarkoituksena on kuvailla kesällä 2009 sovellettu prosessi siten, että se olisi toistettavissa myöhemmillä ohtuprojektin kursseilla. Prosessimalli pohjautuu Scrum-malliin, mutta erinäisten mukautusten johdosta mallia ei pidä kutsua Scrumiksi. Prosessimallin "työnimi" on Ohtuketterä.

Alkutoimet ennen kurssin käynnistymistä

Ohjaaja ottaa yhteyttä ryhmänsä jäseniin 2-3 viikkoa ennen kurssin alkamista ja alustaa esim. Doodle-kyselyn ensimmäistä ryhmätapaamista varten. Ensimmäinen noin kaksi tuntia kestävä ryhmätapaaminen kannattaa sijoittaa kurssin ensimmäisen viikon maanantaille tai tiistaille. Ensimmäisen ryhmätapaamisen sisällöstä on jäljempänä.

Opiskelijoille kannattaa välittää linkki esimerkiksi tähän prosessikuvaukseen jo ennen ensimmäistä tapaamista. Myös jokin lyhyt Scrum-johdanto voi tarjota näppärää taustatietoa, esimerkiksi "Scrum in 10 Minutes"-video. Ohtuketterää prosessimallia ei kuitenkaan pidä kutsua Scrumiksi.

Muistilista kurssin alkuun liittyvistä tehtävistä:

• Ohjaajan muistilista
• Kurssivastuuhenkilön muistilista

Sovellettu aikataulu

Kurssi kestää 16 kalenteriviikkoa, joista vähintään 14 on käytettävä työskentelyyn prosessia noudattaen. Kahden viikon pyrähdyksinä kurssille mahtuu siten yhteensä kuusi pyrähdystä (sprinttiä). Kurssi alkaa niin kutsutulla alkupyrähdyksellä (sprint 0), jonka tarkoituksena on saada lentävä lähtö ensimmäisen varsinaisen pyrähdyksen suunnitteluun. Sekä alkupyrähdyksen että ensimmäisen varsinaisen pyrähdyksen pituudet ovat kaksi viikkoa. Ryhmä saa itse päättää pyrähdyksensä pituuden toisesta pyrähdyksestä alkaen.

Jokaisen pyrähdyksen jälkeen on ohjaajien ja prosessisihteereiden yhteinen ohjaajapalveri. Tästä hieman lisää jäljempänä.

Esimerkki aikataulusta:

vko 1 - vko 2:	Alkupyrähdys	Tutustuminen ja ensimmäisen pyrähdyksen suunnittelu
vko 3 - vko 4:	Pyrähdys 1
vko 5 - vko 6:	Pyrähdys 2
vko 7	Pyrähdys 3	Tenttiviikko
vko 8	Loma	Väliviikko
vko 9 - vko 10:	Pyrähdys 4
vko 11 - vko 12:	Pyrähdys 5
vko 13 - vko 14:	Pyrähdys 6
vko 15 - vko 16:	Pyrähdys 7

Prosessiin kuuluvat palaverit

Aloituspalaveri (2 tuntia)

Esivalmistelut:

• Kaikki opiskelijat lukevat Ohtuketterän prosessikuvauksen läpi
• Linkkivinkkejä tähän

Ensimmäisen ryhmäpalaverin agenda (esimerkki):

1. Ohaaja esittelee kurssin järjestelyt.
2. Ohjaaja antaa lyhyen johdannon sovellettavaan prosessimalliin.
3. Ryhmän järjestäytyminen:

   Kokousten puheenjohtajan valinta.

   Puheenjohtajan rooli saa vaihtua henkilöltä toiselle esim. kerran per pyrähdys, mutta kokoukset tarvitsevat puheenjohtajan)

   Prosessisihteerin toimienkuvan esittely (huom: valinta vasta alkupyrähdyksen lopuksi!).

   Prosessisihteeri on välttämätöntä nimetä ennen ensimmäisen varsinaisen pyrähdyksen suunnittelupalaveria, mutta valintaa ei saa tehdä ensimmäisessä projektitapaamisessa.

4. Alkupyrähdyksen (ensimmäiset 2 vkoa) suunnittelu, jonka aikana ainakin:
1. Initial-backlog:
   Tehtävät liittyen yhteydenpidosta asiakkaaseen ja ryhmän sisäiseen organisointiin. Ryhmä ei tiedä itse ohjelmistosta vielä mitään!
2. Käytettävissä olevat resurssit, erityisesti ihmisten omat tavoitteet kurssilta, kuriositeettina esimerkiksi kunkin opiskelijan oma tavoitearvosana

Viikkopalaveri, Follow-up (max. 1,5 tuntia)

Viikkopalaveri on lyhyehkö, nopea ja tehokas tilannekatsauspalaveri.

Followupissa käydään läpi:

• Projektin backlog, ja erityisesti katsotaan onko sinne tullut lisää materiaalia seuraaviin pyrähdyksiin.
• Luetaan edellisen kokouksen (review, followup tai muu) muistiinpanot, varmistetaan, että kaikki tulee tehtyä.

Ensimmäisen viikon follow-up korvautuu aloituspalaverilla. Toisesta viikosta alkaen jokaisella viikolla pidetään n. 1h-1,5h ryhmätapaaminen, jossa käsitellään juoksevat asiat ja hoidetaan projektiryhmän sosiaalinen puoli.

Alkupyrähdyksen ja ensimmäisen pyrähdyksen aikana ryhmällä on kaksi säännöllistä viikkotapaamista ohjaajan kanssa. Toisen pyrähdyksen aikana ohjaaja ei osallistu enää toiseen viikkopalaveriin, jolloin ryhmältä vaaditaan vain yksi säännöllinen viikkotapaaminen, jossa ohjaaja on läsnä. Ryhmällä on kuitenkin syytä olla koko projektin ajan myös toinen viikkopalaveri, joka toimii ryhmän sisäisenä motivaattorina ilman ohjaajan läsnäolon mahdollisesti tuomaa auktoriteettipainetta.

Päivittäinen Daily-palaveri (max. 15 minuuttia)

Päivittäinen sykli ei vaadi fyysistä läsnäoloa. Tavoitteena on välittää ryhmäläisille tieto siitä, miten ja milloin pyrähdyksen backlogin tehtävät etenevät. Tai että ne eivät etene. Ryhmä saa järjestää asian niin kuin itse parhaaksi kokee (sähköpostilista, google docs, wiki,....), mutta päivittäinen raportointi täytyy saada jollain tavalla mukaan ryhmätyöhön.

Ryhmän täytyy ylläpitää burndown-käppyrää pyrähdyksen etenemisestä. Projektin todellista etenemisnopeutta kuvaaavan burndown-käppyrän ylläpitäminen ilman päivittäinen sykliä ei ole mahdollista. Palaverin (live tai virtuaalinen) tavoitteena on kunkin jäsenen sosiaalinen lupaus siitä, milloin hänen vastuullaansa olevat asiat etenevät.

HUOM: On erittäin ok arvioida, ettei tee jonain päivänä yhtään mitään! Tärkeää on asiasta kertominen etukäteen.

Pyrähdyksen katselmointi, Sprint Review (max. 2 tuntia)

Jokaisen pyrähdyksen lopussa ryhmä käy asiakkaan kanssa läpi pyrähdyksen aikana tehdyn työn näyttämällä pyrähdyksen aikana toteutettua ohjelmistoa. Asiakasdemossa korostuu, että jokaisen pyrähdyksen lopputuloksena pitää olla "toimiva" tuote - oli sen hetkinen implementaatio kuinka pieni tahansa (esim. pelkkä käyttöliittymäprototyyppi).

Demon jälkeen asiakkaalta pyydetään palaute ja tavoitteet seuraavalle pyrähdykselle. Tavoitteet määritellään demolähtöisesti, eli ryhmän täytyy tässä yhteydessä sopia asiakkaan kanssa, mitä seuraavan pyrähdyksen demossa esitetään. Tämän pohjalta muodostetaan kuvaukset käyttötapauksista ("user stories") ja suunnitellaan niihin liittyvät tehtävät (ks. pyrähdyksen suunnittelu).

Ryhmän on oltava heti projektin alussa yhteydessä asiakkaaseen ja sovittava review-tapaamiset pitkälle etukäteen! Pyrähdyksen pituus on määritetty etukäteen, joten kaikki sprint-reviewin päivämäärät voidaan sopia etukäteen jo ensimmäisellä projektiviikolla.

Pyrähdyksen suunnittelu, Sprint Planning (max 6 tuntia)

Seuraavan pyrähdyksen suunnittelupalaveri pidetään mahdollisimman pian Sprint Reviewin jälkeen. Asiakas ei saa osallistua suunnittelupalaveriin. Tapaamisen voi pitää joko heti reviewin jälkeen tai esimerkiksi seuraavana päivänä. Ryhmä suunnittelee (ilman asiakasta) alkavan pyrähdyksen tehtävät ja käsittelee asiakkaalta saadun palautteen.

Ideaalitilanteessa suunnittleupalaverissa valitaan seuraavan pyrähdyksen tehtävät projektin backlogista eikä varsinaisesti mietitä uusia tehtäviä. Projektin backlogia täytyy päivittää koko ajan.

Jokaiselle pyrähdyksen tehtävälistaan tulevalle tehtävälle arvioidaan työmäärä. Työmääräarviot eivät varsinkaan projektin aluksi korreloi tehtäviin käytetyn todellisen työtuntimäärän kanssa, koska ryhmä ei vielä tiedä todellista kehitysnopeuttansa. Arviot kuitenkin tarkentuvat projektin aikana. Työmäärän yksikkönä voi olla kätevää käyttää esimerkiksi kuvitteellista "Zörgön" (zg) -yksikköä, joka kuvaa neljän tunnin eli yhden ohtu-työpäivän keskeyttämätöntä työaikaa.

Työmääräarvion ja todellisen työtuntimäärän suhde on Scrum-noviiseille hankala asia. Ohjaajan täytyy varsinkin kurssin alkupuolella kiinnittää erityistä huomiota siihen, että ryhmäläiset eivät piirrä burndownia todellisten työtuntien vaan työmääräarvioiden mukaan.

Huomioita palaveriin:

Pyrähdyksen backlogin tehtäväkoko

Mikään atominen tehtävä ei saa olla työmääräältään yli kahden projektityöpäivän suuruinen.

Pyrähdyksen teeman päättäminen

Pyrähdyksellä pitää olla teema, joka kertoo noin yhdellä lauseella, mikä on koko pyrähdyksen lopputulos. Esimerkiksi: "Pyrähdys 2: Paperiproto tehty ja tiedonsiirto toimii!"

Pyrähdyksen demon suunnittelu

Demo pitää olla määritelty, jotta tiedetään mitä kohti mennään. Huomioitava asiakkaan vaatimukset.

Suunnittelupalaverin lopputuloksena on seuraavan pyrähdyksen backlog.

Ohjaajien ja prosessisihteereiden palaverit

Jokaisen syklin jälkeen ohjaajat ja prosessisihteerit tapaavat toisensa. Palaverissa käydään "manageritasolla" läpi tilanne kussakin ryhmässä ja pyritään projektien seurannan lisäksi tuomaan esiin erityisesti ryhmissä keksityt hyvät ideat (positiivinen vertaistieto).

Palaverin sihteeri (kurssin vastuuhenkilö) kirjoittaa muistiinpanot. Puhtaaksikirjoitetut muistiinpanot välitetään kurssin opiskelijoile, jotta vertaistieto leviäisi mahdollisimman laajalle.

Kurssilla edellytettävä kokoustekniikka

Palaverin valmistelusta

Jokaisen kokouksen tavoitekesto sekä esityslista täytyy määritellä etukäteen. Poikkeus voidaan tehdä hyvästä syystä esim. pyrähdyksen suunnittelupalaverissa: jos kaikilla osanottajilla on aikaa, palaveria voi jatkaa kunnes kokouksen tavoitteet on saavutettu. Ryhmän täytyy kuitenkin päättää menettelytavasta etukäteen.

Kokouksen etenemisestä

Jokaisella yli 15 minuuttia kestävällä kokouksella on oltava puheenjohtaja ja esityslista. Puheenjohtajuus voi olla kiertävä tai pysyä samana kaikissa kokouksissa. Puheenjohtajan ei kokousteknisistä syistä kannata toimia kokouksen sihteerinä.

Puheenjohtajan tehtävänä on:

• laatia ja jakaa kokouksen esityslista etukäteen, jotta osanottajat pystyvät valmistautumaan ennen kokouksen alkua. Jos jollekin kokoukselle ei osata laatia esityslistaa (työjärjestystä), kokous kannattaa perua ja käyttää osanottajien aika johonkin hyödyllisempään.
• pitää keskustelu esityslistan kulloisessakin kohdassa, jottei palaveri veny keskustelun rönsyilemisen vuoksi.
• päättää keskustelu ja siirtyä esityslistan seuraavaan kohtaan viimeistään siinä vaiheessa, kun puheenvuoroissa ei ole tullut enää uutta asiaa, puheenvuorot kiertävät kehää tai jos keskustelu ei pysy esityslistan mukaisessa kohdassa.
• varmistaa, että kaikille osanottajille (erityisesti kokoussihteerille) on selvää, mitä päätettiin, ennen kuin työjärjestyksessä siirrytään seuraavaan kohtaan.
• varmistaa kokouksen sujuvuus, jotta palaverin kesto ei veny ennalta sovittua aikaa pidemmäksi

Palaverin sujuvuus edellyttää etukäteen jaettua esityslistaa. Esityslistan ei tarvitse olla monimutkainen tai pitkä, mutta tavoitteena on oltava esityslistan noudattaminen.

Kokouksen dokumentoinnista

Jokaisella kokouksella on oltava sihteeri, joka kirjoittaa kokousmuistiinpanot kokouksen edellyttämässä laajuudessa. Esimerkiksi päivittäisen daily scrum -palaverin muistiinpanoina toimii backlogiin päivitetty työmääräarvion eteneminen.

Huom: Erityisesti asiakastapaamisten muistiinpanot on laadittava huolellisesti! Kärjistetysti sanoen kaikki, mitä asiakas sanoo, on dokumentoitava.

Kullekin palaverityypille (daily-palaveri, followup, sprint review, sprint planning) varten kannattaa laatia esityslistapohja, jotta palavereissa toistuvat asiat eivät unohdu käsittelystä. Pohjaan kannattaa ottaa kussakin kokoustyypissä toistuvat asiat, esim. lyhyt tarkistus tuntiseurantaan, lyhyt katsaus burndowniin tms.

Huom: Esimerkiksi daily-palaverin esityslista voi olla kaikissa kokouksissa täysin identtinen, mutta se on silti laadittava vähintään kerran.

Dokumentaation laajuus

Ohtuprojektin kurssisivulla on periteiden painama raskaan dokumentoinnin listaus. Tällä kurssilla ei ole tarkoitus dokumentoida raskaasti. Kurssin dokumentaaiovaatimukset ovat seuraavat:

Arkkitehtuurikuvaus [esimerkki: pohjatiedosto]

Projektin jatkokehityksen kannalta tärkein dokumentti. Arkkitehtuurikuvauksen tarkoituksena on kuvailla tehdyt suunnittelupäätökset ja laajan perspektiivin tekniset ratkaisut. Ilman ajantasaista arkkitehtuurikuvausta uuden projektiryhmän on hankala saada kosketuspintaa ryhmän tuottamaan ohjelmistoon.

Päivitettävä ajantasaiseksi jokaisen pyrähdyksen päätteeksi!

Testauskuvaus

Testauksen dokumentoinniksi riittää kevyt selvitys siitä, mitä/miksi/miten järjestelmää on testattu.

Automatisoidut testitapaukset täydentävät dokumentaatiota omalta osaltansa.

Jatkoprojektin kannalta mielenkiintoisinta voi olla rajatestaus/benchmark siitä, kuinka suuresta kuormasta tai kuinka nopeasti järjestelmä selviytyy. HUOM: benchmark-tulokset "lorem ipsum" -testidatalla eivät kuitenkaan todennäköisesti vastaa todellisuutta!

Ohjelmiston asennuksen erityispiirteet

voi olla osana muuta dokumentaatiota

esimerkiksi Apachen asennusta ei pidä dokumentoida, mutta esim. ohjelmiston edellyttämä Apachen konfiguraatio pitää dokumentoida

Sprinttien aikana tuotettu oheisdokumentaatio (burndownit, projektin backlog, sprinttien backlog jne) tulee jättää logiksi jatkoprojektille. Niitä ei tarvitse kirjoittaa erityisesti "puhtaaksi" tai erilliseksi dokumentiksi, mutta ne on liitettävä osaksi palautusta (esim. exporttaamalla Google Docsista), koska ne kompensoivat perinteisiä dokumentointivaatimuksia.

Kesän 2009 kurssilta ilmaan jäänyt kysymys: kuinka ketterässä ohtuprojektissa pitäisi dokumentoida vaatimukset? Vaatimusten dokumentoiminen reverse engineering -tyyppisesti jälkikäteen ei ole mielekästä, kuten ei myöskään vaatimusten dokumentoiminen "etukäteen", jolloin muutosten päivittäminen tuottaa harmia. Olisiko ratkaisu riittävän kattavassa automatisoidussa testijoukossa (test suite)?

Automatisoitu testaus

AUTOMATISOITU TESTAUS
  Vaatimuksesti aluasta alkaen (dokumentaation kompensointi)
  Backlogin tehtäviin huomioitava sisäänrakennetusti testaus

  Testauksesta:
	- ajettava test-suite
	- yksikkötestauksen harjoittelua
	- "huonokin testi on parempi kuin ei testiä"
	- php: integraatiotestaus, selenium
	- palm: miten? c-unit?
	- junit

	Linkki: the way of testivus
		

Ohtuketterässä sovellettavat termit

Pyrähdyksen tehtävälista, sprint backlog

• Määrittelee kunkin pyrähdyksen aikana kehitettävinä olevat käyttäjätarinat (user stories), joiden alle lajitellaan pyrähdyksen tehtävät.
• Päätetään pyrähdyksen suunnittelupalaverissa.
• Tavoitteena taata kehitystiimille työrauha pyrähdyksen ajaksi. Asiakas ei saa vaatia pyrähdyksen aikana tehtäviä, jotka eivät ole pyrähdyksen tehtävälistassa. Uudet tai muuttuneet vaatimukset kirjataan tuotteen tehtävälistaan. Jos on Hätätapaus ja Aivan Pakko vaihtaa kurssia kesken pyrähdyksen, niin pyrähdyksen backlogista on tiputettava samassa suhteessa tehtäviä pois.
• Yhdenkään atomisen tehtävän työmääräarvio ei saa olla yli kahden ohtu-työpäivän suuruinen. Tällaiset tehtävät on pilkottava pienempiin osiin.

Kaikki pyrähdykseen liittyvät vaatimukset on ehdottavasti saatava asiakkaalta pyrähdyksen katselmointitilaisuudessa (sprint review), jotta ryhmä pystyy huomioimaan ne pyrähdyksen suunnittelutilaisuudessa (sprint planning).

HUOM! Ero projektin tehtävälistaan (product backlog) ja suhde pikkutehtävälistaan (action points).

Esimerkki: "Kaikki kolmossprintin backlogin tehtävät ovat korkeintaan 2 työpäivän (2 zg, 8h, whatever) kokoisia, mieluiten 0,5 - 1 työpäivää.
Ideaalimaailmassa keskiarvoksi tulisi: (sprintin päivät) x tekijät, eli jokaiselle päivälle n. 1 tehtävä, joka pitäisi tehdä, jotta pysytään burndownin tavoiteviivalla."

Projektin tehtävälista, product backlog

• Sisältää kaikki tulevat projektiin liittyvät vaatimukset ja tehtävät.
• Päivitetään jatkuvasti pitkin pyrähdystä sitä mukaa kun uusia asioita ilmaantuu tai vaatimukset muuttuvat (ei kertarysäyksenä).

Prosessisihteeri (Process Secretary)

• Prosessin sihteeri; Master of Ceremony.
• Vastuussa backlogista: kaikkien tehtävien tulee olla kirjattuna selkeästi ja priorisoidussa järjestykssä.
• Vastaa siitä, että backlogia ylläpidetään koko ajan. Backlog ei ole koskaan "valmis"!
• Oltava tiimin tasa-arvoinen koodaava jäsen: muussa tapauksessa prosessisihteeri ei pysty ymmärtämään työmääräarvioita.
• Ei ole esimiesasemassa.
• Prosessisihteeri vähentää raskautta kaikilta muilta ryhmän jäseniltä, koska hän hoitaa "paperityön" heidän puolestansa. Prosessisihteerin oma työmäärä on kuitenkin yhtä suuri kuin muillakin: hän tekee paperityön viemän määrän vähemmän muita tehtäviä.

Sprintin retrospektiivi

Jokaisen sprintin päätteeksi sprintin katselmointitilaisuuden jälkeen pidetään retrospektiivi. Tilaisuudessa käydään päättyneen sprintin kokemukset läpi. Tavoitteena on, että jokainen ryhmän jäsen vuorollaan kertoo menneestä sprintistä:

• mikä hyvää
• missä kehitettävää
• mikä huonoa

Asiat kannattaa käydä läpi iteratiivisesti siten, että ensin listataan kaikki sprintissä koetut hyvät asiat, sen jälkeen kehitettävät ja lopuksi kiukuttavat ja pieleen menneet jutut. Ohjaaja voi käyttää esimerkiksi metodia "sprintin suunnittelua ei aloiteta ennen kuin jokainen sanonut väh. 3 asiaa". Tavoitteena on ryhmän oman prosessin parannus ja tehdyistä virheistä oppiminen.

Pikkutehtävät (Action Points)

Lista tehtävistä asioista, jotka ovat pyrähdyksen ulkopuolella (erityisesti pieniä tai yllättäviä). Listan kanssa pikkutehtävät pysyvät edes jotenkin hallinnassa. (rivitykset saattaa mennä vituiks, sori) Lista voidaan käydä läpi aina kun nähdään.

Erään ohjaajan kommentti: "Ihan mielettömän enterprisey kun voi huutaa paltsussa 'AP sulle tosta!' tai "mä otan AAPEEN tosta!"

Lista voidaan taulukoida esimerkiksi seuraavasti: aihe, kenelle delegoitu, deadline, status.

Projektipäälliköttömyys

Peke: "Projektipäällikkö/johtajuus on melko perinteinen ongelma ohtuprojekteissa. Viime keväällä kokeiltiin mallia, jossa ei ollut mitään ennalta määrättyä johtajuutta. Siitä ei tullut mielestäni erityisen hyviä kokemuksia (ohjaajien puheiden perusteella), eli nyt kokeillaan tällaista kevyen johtajuuden mallia joka ei kuitenkaan ole yhtä auktorisoitunut kuin perinteinen projektipäällikkömalli."

Ongelma ehkä ratkesi kun oli nimetty prosessin sihteeri?

Demot

Kurssilla on kaksi yhteistä demoa: välidemo ja loppudemo. Välidemon ideana on luoda kaikille ryhmille yhteinen väli-deadline, joka kannustaa saamaan jotain aikaiseksi jo ennen kurssin viimeisiä hetkiä. Toinen yhteinen demo on joko projektin toiseksi viimeisellä tai viimeisellä viikolla.

Yhteisten demojen kohderyhmänä ovat ensisijaisesti kaikki ohtuprojektikurssin opiskelijat. Demotilaisuus kestää yhteensä korkeintaan kaksi tuntia, ja kaikkien kurssin opiskelijoiden tulee osallistua siihen. Yhteinen demotilaisuus ei saa kilpailla asiakkaan ajankäytöstä pyrähdyksen demon kanssa, eli asiakas osallistuu yhteisen demon sijasta ryhmän sisäiseen pyrähdysdemoon.

Riskit

Riskit kannattaa käydä läpi pyrähdyksen asiakasdemossa, koska silloin myös asiakas tietää mahdollisista ongelmista. Asiakas saattaa jopa kysyä, "voidaanko tiputtaa jotain ominaisuuksia pois", koska hän saa myös tiedon mahdollista ongelmista. Riskienhallinta on pidettävä mukana tehtävien suunnittelussa, jotta riskejä ylläpidetään jokaisen pyrähdyksen aikana.

Geneerinen riskilista ei auta, pitää löytää projektikohtaiset riskit. Riskien listaaminen ja ennakoiminen auttaa välttämään riskejä. Riskienhallinan suola on proaktiivisuus, riskienhallinan ei tarvitse ainoastaan olla reagoiva. Asiakkaan ei tarvitse ymmärtää teknisiä riskejä, mutta asiakas tulee lähemmäs kehitystyön ongelmia, kun hän ymmärtää riskin tuomat ongelmat.

Ongelmia ohtuprojekteissa

Seuraavia pulmia voi tulla vastaan projektin aikana

- osittain yhteinen ongelmakenttä:
-- kaikki suorittaa kurssia, ei rahapalkkaa
-- motivaatio-ongelmat
-- osaamisongelmat
-- yhteisen työtilan puute
- auttaako ryhmän sisäiset demot aikataulussa pysymiseen
- miten muut ryhmät ovat suunnitelleet
- auttaako, että ryhmä tietää, miten muut arvioi, suunnittelee ja hoitaa daily scurminsa ja muut rutiinit
---> erityisesti vinkkejä siitä, miten muut ryhmät ovat järjestäytyneet.
     Tiimi ei oletusarvoisesti ole ollut ennen töissä.
-- ohjaajien ja prosessisihteereiden palaveri == järjestelmällinen tapa välittää tietoa ryhmien välillä

Projektiväsymys?
 - kesän lomaviikko vasta puolivälin jälkeen
 Oireita:
		- myöhässä saapuminen paltsuun
		- asioiden unohtuminen
		- asioiden ennakoimaton viivästyminen

		3) Laitoksen maililista bugasi ryhmäläisillä ajoittain siten, että vasta
		esim. päivän jälkeen tuli ilmoitus, ettei viestiä pystytty lähettämään.
		Ryhmä käytti kommunikointiin nimenomaan postilistaa, jolloin on aika
		ikävää kun oma viesti ei mene perille eikä saa virheilmoitusta ajoissa.

asiakastapaaminen:
		"Asioita ei koskaan voi sopia tarpeeksi tarkasti asiakkaan kanssa, aina on implisiittisiä vaatimuksia ja yllätyksiä. Toki tiimiltä odotetaan "kokemuksen tuomaa oikeiden vaatimusten selvitystaitoa", mutta lopulta katsotaan, mitä lukee asiakastapaamisen pöytäkirja/logissa, josta toivottavasti löytyy KAIKKI asiakkaan kanssa yksityiskohtaisesti, ohimennen ja implisiittesti sovitut asiat."