Sisällysluettelo
- Miksi Scrum ja Kanban epäonnistuvat tekoälyprojekteissa
- Kolme perustavanlaatuista eroa ohjelmisto- ja tekoälykehityksen välillä
- AI-first-työskentelytavat: Mitä Scrumin jälkeen tulee
- Käytännön työskentelytavat tekoälyllä vahvistetuille tiimeille
- Työkalupino ja prosessit: Mikä oikeasti toimii
- Tyypilliset virheet siirryttäessä tekoälypohjaisiin työskentelytapoihin
- Usein kysytyt kysymykset
Viime viikolla meinasin menettää hermoni.
Asiakkaani halusi väkisin puristaa tekoälyprojektinsa kahden viikon sprintteihin.
Teimme näin myös sovelluskehityksessä, hän sanoi.
Minun piti selittää hänelle: tekoäly ei ole ohjelmistokehitystä.
Kolmen epäonnistuneen sprintin ja turhautuneen kehitystiimin jälkeen vaihdoimme lähestymistapaa täysin.
Tulos: 6 viikossa enemmän edistystä kuin kolmena edeltävänä kuukautena yhteensä.
Tänään näytän sinulle, miksi perinteiset ketterät menetelmät eivät toimi tekoälyprojekteissa – ja mitkä työskentelytavat oikeasti tuovat tulosta.
Miksi Scrum ja Kanban epäonnistuvat tekoälyprojekteissa
Scrum kehitettiin ohjelmistokehitykseen.
Tekoäly noudattaa täysin eri lainalaisuuksia.
Tämän unohtaminen on yleisin virhe, jonka näen asiakkaillani.
Sprintti-ongelma: Tekoäly ei kehity lineaarisesti
Yksi sprintti kestää kaksi viikkoa.
Koneoppimismallilta voi kestää kolme viikkoa tuottaa ensimmäiset käyttökelpoiset tulokset.
Mitä teet viikolla 1 ja 2? Esitteletkö sprintin tuloksena Koulutamme edelleen?
Olen nähnyt tämän käytännössä.
Yksi kehitystiimi ei neljässä sprintissä saanut aikaan mitään esiteltävää – vaikka työ oli huippuluokkaa.
Ongelma on siinä, että tekoälykehityksellä on omat rytminsä.
Joskus datan valmisteluun menee neljä viikkoa, ja ensimmäinen malli toimii heti.
Joskus joudut kouluttamaan 50 erilaista mallia ennen kuin yksikään toimii.
Tämä ei taivu kahden viikon sykleihin.
Backlogin kaaos: Kun algoritmit muuttavat prioriteetit
Product Backlog toimii ominaisuuksille.
Tekoälyssä prioriteetit muuttuvat kokeiluiden ja löydösten myötä.
Esimerkki omasta arjesta:
Halusimme rakentaa asiakaspalautteiden sentimenttianalyysityökalun.
Suunnitellut 5 ominaisuutta:
- Positiivinen/negatiivinen luokitus
- Tunteiden tunnistus
- Teemojen erottelu
- Trendianalyysi
- Dashboard
Ensimmäisen dataexploraation jälkeen selvisi, että 60% datasta oli käyttökelvotonta.
Yhtäkkiä datan puhdistus nousi ykkösprioriteetiksi.
Tätä ei oltu backlogin listalla ollenkaan.
Tekoälyprojekteissa data määrittää seuraavan askeleen – eikä Product Owner.
Daily Standup muuttuu viikkopalaveriksi (ja se on ihan oikein)
Mitä teit eilen?
Optimoitin hyperparametreja.
Entä tänään?
Optimoitin hyperparametreja.
Onko esteitä?
Mallin koulutus kestää vielä 12 tuntia.
Tältä näyttää tekoälytiimin daily standup.
Turhaa aikaa.
Tekoälykehityksessä palaute tulee hitaammin.
Mallin koulutus kestää joskus päiviä.
A/B-testin arviointi vaatii tilastollista merkitsevyyttä – aikaa kuluu usein viikkoja.
Päivittäinen synkronointi ei ole järkevää, jos arjessa mikään ei merkittävästi muutu joka päivä.
Kolme perustavanlaatuista eroa ohjelmisto- ja tekoälykehityksen välillä
Ohjelmistokehitys: Tiedät mitä rakennat.
Tekoälykehitys: Tiedät mitä kokeilet.
Tässä on koko eron ydin.
Ennustamattomuus perinteisen suunniteltavuuden sijaan
Ohjelmistossa kirjoitat koodia ja se toimii (tai ei toimi).
Tekoälyssä koulutat mallia, joka toimii 73-prosenttisesti – etkä tiedä miksi.
Ei huonon koodin takia.
Vaan yllättävien dataprobleemien tai mallin suorituskyvyn vuoksi.
Et voi suunnitella, milloin malli yltää haluttuun tarkkuuteen.
Voit vain kokeilla ja iteratiivisesti parantaa.
Tämä tekee perinteisestä projektisuunnittelusta mahdotonta.
Kokeellinen vs. lineaarinen kehitysprosessi
Ohjelmistoetenee lineaarisesti:
Vaatimukset → Design → Toteutus → Testaus → Julkaisu
Tekoälykehitys on kokeilujen kehä:
Hypoteesi → Kokeilu → Arviointi → Oppiminen → uusi hypoteesi
80% ajastani tekoälyprojekteissa menee kokeiluihin, jotka eivät toimi.
Se on normaalia.
Se on jopa hyvä asia.
Jokainen epäonnistunut kokeilu vie ratkaisua lähemmäksi.
Ohjelmistossa 80% epäonnistunutta koodia olisi kestämätöntä.
Tekoälyssä se on tie onnistumiseen.
Datan laatu kriittisenä menestystekijänä
Ohjelmisto toimii synteettisellä testidatalla.
Tekoäly kaatuu tai nousee oikean, laadukkaan datan varassa.
Olen nähnyt projekteja, joissa tiimi kirjoitti täydellistä koodia kuusi kuukautta.
Malli oli silti käyttökelvoton.
Siksi että data oli huonoa.
Tekoälyprojekteissa käytät 60–80% ajasta datatyöhön:
- Datan keräys
- Datan puhdistus
- Datan merkintä
- Datan validointi
- Data Pipeline -rakentaminen
Tämä ei näy yhdessäkään ohjelmistoprojektin sprinttisuunnitelmassa.
Mutta ilman näitä tekoäly ei toimi.
AI-first-työskentelytavat: Mitä Scrumin jälkeen tulee
Olen käyttänyt kolme vuotta erilaisia työskentelytapoja tekoälytiimeissä.
Tässä on, mitkä oikeasti toimivat.
Hypoteeseihin perustuva kehitys User Stories -tarinoiden sijaan
Unohda User Storyt.
Käyttäjänä haluan… ei toimi tekoälyssä.
Sen sijaan: hypothesis-driven development.
Jokainen kehitysvaihe alkaa mitattavalla hypoteesilla:
Jos lisäämme ominaisuuden X, mallin tarkkuus paranee vähintään 5 %.
Tai:
Jos käytämme algoritmia Y, koulutusaika lyhenee 50 %.
Jokaiselle hypoteesille määritellään:
- Mitattava metriikka
- Tavoitearvo
- Arvio kokeen kestosta
- Menestyksen/epäonnistumisen kriteerit
Näin optimoimme mallia muuttuu konkreettiseksi kokeeksi selkeällä tuloksella.
Jatkuva kokeilu ydintoimintana
Ohjelmistossa rakennat ominaisuuksia.
Tekoälyssä suoritat kokeita.
Tärkein prosessi ei ole sprinttisuunnittelu, vaan kokeen suunnittelu.
Meidän vakioprosessimme:
- Hypoteesin määrittely (1 päivä)
- Kokeen toteutus (2–3 päivää)
- Suoritus (vaihtelee: 1 päivä – 2 viikkoa)
- Arviointi (1–2 päivää)
- Päätös (Jatka/Hylkää/Käännä suuntaa)
Oleellista: jokainen koe dokumentoidaan.
Myös epäonnistuneet.
Erityisesti epäonnistuneet.
Pidämme Experiment Logia, jossa on:
- Hypoteesi
- Lähestymistapa
- Tulos
- Opit
- Seuraavat askeleet
Tämä muodostuu tiimin arvokkaimmaksi resurssiksi.
Data-keskeiset työnkulut tekoälytiimeille
Ohjelmistotiimit organisoituvat ominaisuuksien ympärille.
Tekoälytiimien täytyy organisoitua datan ympärille.
Meidän työnkulku ei kulje Kanbanlaudan kautta vaan Data Pipelinessa:
| Vaihe | Vastuuhenkilö | Tuotos | Laatukriteeri |
|---|---|---|---|
| Data Collection | Data Engineer | Raaka datasett | Kattavuus, ajantasaisuus |
| Data Cleaning | Data Scientist | Puhdas datasett | <5 % puuttuvia arvoja |
| Feature Engineering | ML Engineer | Ominaisuusjoukko | Korrelaatio tavoitteeseen |
| Model Training | Data Scientist | Koulutettu malli | Tavoitetarkkuus saavutettu |
| Model Deployment | ML Engineer | Tuotantomalli | Viive < 200ms |
Jokaisella vaiheella on selkeät siirtokriteerit.
Ei valmis-leimaa ilman mitattua laatua.
Käytännön työskentelytavat tekoälyllä vahvistetuille tiimeille
Tarpeeksi teoriaa.
Tässä ovat työskentelytavat, joita käytän joka päivä.
Tekoälyprojektin 3-vaiheinen malli
Jaan jokaisen tekoälyprojektin kolmeen vaiheeseen:
Vaihe 1: Discovery (25 % ajasta)
Tavoite: Ymmärtää, mikä on mahdollista.
Toimenpiteet:
- Datan alustava analyysi
- Proof of Concept
- Toteutettavuuden arviointi
- Ensimmäiset baseline-mallit
Menestyksen mittari: Onko ongelmaa mahdollista ratkaista tekoälyllä?
Vaihe 2: Development (60 % ajasta)
Tavoite: Rakentaa paras mahdollinen malli.
Toimenpiteet:
- Iteratiivinen mallin kehitys
- Feature engineering
- Hyperparametrien optimointi
- Ristiinvalidointi
Menestyksen mittari: Tavoitetarkkuus saavutettu.
Vaihe 3: Deployment (15 % ajasta)
Tavoite: Tuoda malli tuotantoon.
Toimenpiteet:
- Mallin paketointi
- API-kehitys
- Monitoroinnin pystytys
- A/B-testaus
Menestyksen mittari: Malli toimii vakaasti tuotannossa.
Tärkeää: Vaiheet eivät ole aina lineaarisia.
Hyppäät välillä takaisin Discoveryyn kehityksen aikana.
Se on täysin normaalia.
Ketterä data science: Sprintit uudelleen ajateltuna
Käytämme silti sprinttejä – mutta uudella tavalla.
Tekoälysprinttimme kestävät 3–4 viikkoa (ei kahta).
Jokaisella sprintillä on kokeeseen perustuva tavoite, ei ominaisuustavoitetta.
Sprinttisuunnittelu menee näin:
- Kokeiden katselmointi: Mitä opimme viime sprintillä?
- Hypoteesien priorisointi: Mitkä kokeet ovat lupaavimpia?
- Resurssien jako: Kuka tekee mitäkin kokeilua?
- Menestyksen kriteerit: Miten mittaamme onnistumisen?
Sprinttikatselussa esitellään ei ominaisuuksia vaan oppeja:
- Mitkä hypoteesit todistettiin/vastustettiin?
- Mitä uusia havaintoja syntyi?
- Miten mallin suorituskyky muuttui?
- Mitä kokeita seuraavaksi?
Poikkifunktionaalisen tekoälytiimin oikea organisointi
Tekoälytiimi tarvitsee eri rooleja kuin ohjelmistotiimi.
Peruskokoonpanomme tekoälyprojektiin:
| Rooli | Päätehtävä | Taidot | % ajasta |
|---|---|---|---|
| Data Scientist | Mallin kehitys | ML, Tilastotiede, Python | 40 % |
| Data Engineer | Data Pipeline | ETL, Tietokannat, Pilvi | 30 % |
| ML Engineer | Mallin tuotanto | DevOps, API:t, Skaalautuvuus | 20 % |
| Product Manager | Liiketoiminnan linjaus | Domainekspertisi, Strategia | 10 % |
Tärkeää: Product Manager EI ole Scrum Master.
Hän määrittelee liiketoiminnan tavoitteet, ei sprinttitavoitteita.
Kokeiden priorisointi tehdään yhdessä tiimin kanssa.
Työkalupino ja prosessit: Mikä oikeasti toimii
Tekoälytiimien työkalut ovat erilaisia kuin ohjelmistotiimeillä.
Tässä meidän hyväksi todettu pinomme.
Projektinhallinnan työkalut tekoälytiimeille
Jira on ok ohjelmistotiimille.
Tekoälyssä käytämme yhdistelmää:
Kokeiden seuranta: MLflow
- Kaikki kokeet kirjataan automaattisesti
- Parametrit, metriikat ja artefaktit yhdessä näkymässä
- Malliversioiden vertailu
Tehtävien hallinta: Notion
- Hypoteesibacklog
- Kokeiden dokumentointi
- Tiimin opit
- Datalaadun dashboardit
Viestintä: Slack + Daily Data Reports
- Automatisoidut malliraportit
- Hälytykset datalaatuongelmista
- Kanava jokaiselle käynnissä olevalle kokeelle
Kuitenkin tärkein työkalu on yhteinen kokeiden loki.
Dokumentoimme JOKAISEN kokeen – lopputuloksesta riippumatta.
Mallien ja datan versiointi
Koodia versioidaan Gitillä.
Mutta mitä tehdään malleille ja datalle?
Meidän ratkaisu:
Data Versioning: DVC (Data Version Control)
- Jokaiselle datasetille oma versiotunnus
- Toistettavat datapipeline-prosessit
- Automaattinen datalinjan seurantaa
Malliversiointi: MLflow Model Registry
- Kaikki mallit versioidaan automaattisesti
- Staging/Production-ympäristöt
- Automaattinen rollback, jos suorituskyky heikkenee
Koodin versionhallinta: Git + Pre-commit Hooks
- Automaattiset koodilaatutestit
- Kokeiden metadata tallentuu commiteihin
- Jupyter-notebookit putsataan ennen committia
Ilman versiointia tekoälykehitys ei ole toistettavaa.
Ja jos ei ole toistettavuutta, ei ole myöskään mahdollista debugata.
Testaus ja käyttöönotto tekoälyympäristössä
Yksikkötestit tekoälyssä eroavat ohjelmistokehityksestä.
Testaat paitsi funktioita, myös datan laatua ja mallin suorituskykyä.
Käytämme seuraavaa testauskehystä:
Datalaatutestit
- Skeeman validointi (ovatko kaikki sarakkeet mukana?)
- Datan ajantasaisuus (onko data tuoretta?)
- Tilastolliset testit (onko jakauma muuttunut?)
- Puuttuvien arvojen tarkistus
Mallin suorituskykytestit
- Tarkkuusrajan testit
- Viivetestit
- Muistin käytön testit
- Biasin tunnistus
Integraatiotestit
- End-to-End pipeline -testit
- API:n vasteaikatestit
- Rasitustestit
Käyttöönotto hoidetaan Blue-Green Deploymentilla ja automaattisella rollbackilla.
Jos mallin suorituskyky heikkenee yli 5 %, palataan automaattisesti aiempaan versioon.
Tyypilliset virheet siirryttäessä tekoälypohjaisiin työskentelytapoihin
Olen nähnyt samat virheet lähes jokaisella asiakkaalla.
Tässä suurimmat – ja miten vältät ne.
Scrum Master siirtyy AI Product Ownerin rooliin
Klassinen virhe:
Yritys haluaa pysyä ketteränä ja tekee Scrum Masterista AI Product Ownerin.
Ongelma: Scrum Master tuntee prosessit, muttei datatiedettä.
Hän ei osaa priorisoida kokeita, koska ei tiedä mikä on realistista.
Ratkaisu: AI Product Ownerilla täytyy olla tekninen tausta.
Hänen täytyy ymmärtää:
- Kuinka koneoppiminen toimii
- Mitä datan laatu tarkoittaa
- Kuinka kauan mallin koulutus vie
- Mitkä metriikat ovat olennaisia
Meillä AI Product Owner on aina data scientist tai ML engineer, jolla on liiketoimintaymmärrystä.
Ei koskaan pelkkä projektipäällikkö.
Miksi perinteinen Definition of Done ei toimi
Ohjelmisto: Ominaisuus toimii kuten määritelty = valmis.
Tekoäly: Malli saavuttaa 85 % tarkkuuden = valmis.
Mutta entä jos malli pääsee vain 84 %:iin?
Onko se sitten kesken?
Perinteinen Definition of Done johtaa tekoälyssä päättymättömiin optimointikierteisiin.
Meidän ratkaisumme: Probabilistinen Definition of Done.
Sen sijaan että Mallin on oltava 85 % tarkka, määrittelemme:
Malli saavuttaa vähintään 80 % tarkkuuden ja on parempi kuin aikaisempi baseline.
Lisäksi aikaraja:
Jos neljän viikon optimoinnin jälkeen ei saavuteta merkittävää parannusta, nykyinen malli voidaan siirtää tuotantoon.
Näin vältetään perfektionismi ja mahdollistetaan iteratiivinen parantaminen tuotannossa.
Change Management perinteisille tiimeille
Vaikeinta ei ole tekniikka.
Haaste on muutosjohtaminen.
Ohjelmistokehittäjät ovat tottuneet deterministiseen maailmaan.
Tekoäly on probabilistista.
Se vaatii ajattelutavan muutoksen.
Miten lähestyn jokaista siirtymää:
1. Odotusten hallinta
- Rehellinen viestintä: 80% kokeista epäonnistuu
- Se on normaalia ja arvokasta
- Onnistumista mitataan eri tavoin kuin ennen
2. Kaksin koodaaminen tekoälyssä
- Kokenut data scientist ja softakehittäjä työskentelevät yhdessä
- Koodikatselmuksilla nopeutetaan tiedonsiirtoa
- Yhteinen kokeiden suunnittelu
3. Jatkuva oppiminen
- Viikoittaiset ML learning sessions
- Koonta onnistuneista kokeiluista
- Post mortem -istunnot epäonnistuneista lähestymistavoista
Siirtymä kestää 3–6 kuukautta.
Suunnittele se mukaan aikatauluun.
Ja juhli pieniäkin onnistumisia – myös epäonnistuneet kokeet tuovat arvokasta oppia.
Usein kysytyt kysymykset
Kuinka kauan kestää siirtyminen Scrumista tekoälypohjaiseen työskentelyyn?
Kokemukseni mukaan muutos kestää 3–6 kuukautta. Tiimin pitää oppia uudet ajattelumallit ja rakentaa uusia prosesseja. Tärkeintä on edetä vaiheittain, ei yrittää muuttaa kaikkea kerralla.
Voiko Scrumia ja tekoälykehitystä yhdistää?
Kyllä, mutta Scrum täytyy mukauttaa. Pidemmät sprintit (3–4 viikkoa), kokeilupohjaiset tavoitteet ominaisuuksien sijaan ja joustavampi aikataulutus. Puhtaalla Scrumilla tekoälyprojekti ei toimi.
Mitä rooleja tekoälytiimi ehdottomasti tarvitsee?
Vähintään: Data Scientist, Data Engineer ja ML Engineer. Pienemmässä tiimissä yksi ihminen voi hoitaa useampaakin roolia – mutta kaikki osa-alueet täytyy kattaa. Product Manager, jolla on tekoälyosaamista, on myös tärkeä.
Miten tekoälykokeiden onnistumista mitataan?
Ennalta määritellyillä, mitattavilla metriikoilla kuten tarkkuus, precision, recall tai liiketoiminnan KPI:t. Olennaista: myös epäonnistuneet kokeet ovat arvokkaita, jos niistä opitaan. Dokumentoimme kaikki kokeet järjestelmällisesti.
Mitkä ovat suurimmat haasteet siirryttäessä?
Muutosjohtaminen on usein vaikeampaa kuin tekniikka. Tiimi joutuu oppimaan sietämään epävarmuutta ja ajattelemaan probabilistisesti determinismin sijaan. Lisäksi tarvitaan uusia työkaluja sekä datan ja mallien versionointistrategioita.
Mitkä työkalut ovat välttämättömiä tekoälytiimille?
MLflow kokeiden seurantaan, DVC datan versionointiin, pilvialusta laskentatehoon ja hyvä dokumentaatiotyökalu kuten Notion. Pelkkä Git ei riitä – tarvitset nimenomaan datatieteeseen rakennetut työkalut.
Kuinka käsitellään tekoälyprojektien epävarmuus?
Asettamalla kokeille aikaraja (timebox), sekä selkeät Go/No-Go-kriteerit. Määritä optimointiin selkeät aikarajat ja vähimmäissuorituskykyrajat. Suunnittele joustoa aikatauluun ja viesti epävarmuudet avoimesti sidosryhmille.
Toimivatko perinteiset projektinhallintatyökalut tekoälytiimeissä?
Vain osittain. Jira käy tehtävien hallintaan, mutta kokeiden dokumentointiin ja datalinjan seurantaan tarvitaan lisätyökaluja. Käytämme yhdistelmää eri erikoistyökaluista.
Miten järjestetään code reviewt tekoälyprojekteissa?
ML-koodikatselmointi eroaa ohjelmistosta. Tarkastellaan koodin lisäksi kokeen suunnittelua, datan laatua ja mallin validointia. Parikoodaus kokeneen data scientistin ja softakehittäjän välillä vauhdittaa osaamisen siirtoa.
Mitä tehdään, jos tekoälyprojekti epäonnistuu täysin?
Näin tapahtuu 15–20 % projekteista – eikä se ole harvinaista. Tärkeää on havaita nopeasti, jos suunta ei toimi, ja vaihtaa. Dokumentoi kaikki opit – niistä on hyötyä tulevaisuudessa. Epäonnistunut projekti voi estää muut toistamasta samoja virheitä.
