Ketterät käytännöt
Ketterät käytännöt - ketteryys käytännössä
HY:n tavoitteena on, että yhteistyö toimittajien kanssa ja tiimien välillä kehittyy asteittain Modern Agilen mukaisesti: otamme turvallisuuden lähtökohdaksi (mm. tämän dokumentin tarjoaman selkänojan turvin) – ja lähdemme yhdessä kokeilemaan ja oppimaan, tuottaen samalla arvoa alusta asti. Jatkuva parantaminen on hyväksi!
Kokeilukulttuuri
Kokeilukulttuuriksi määrittelemme toimittajan ja asiakkaan yhdessä tekemän, kyseenalaistavan ja kokeilevan työn asiakkaan saaman arvon maksimoinniksi. Toimimme kokeiluissa jatkuvan parantamisen (kaizen) hengessä ja oppimissyklejä hyödyntäen (esim. Lean Startupin mukainen Build-Measure-Learn -sykli). Tärkeää on ohjaaminen nopeasti oikeaan suuntaan projektin tarpeista riippuen.
Fail Fast vs Definition of Done
Kokeiluille on paikkansa vaiheessa, jossa epäonnistuminen on mahdollisimman halpaa (ns. Fail Fast -periaate). Näin voi olla esim. projektin alkuvaiheessa, kun teknologiavalintoja ei ole lyöty lukkoon tai integraatioita toteutettu, tai kun projektin myöhemmässä vaiheessa erilliseen teknologiakokeiluun (tech spike) on erikseen budjetoitu resursseja.
Kun kokeiluilla on haettu hyvä ratkaisu, lopullisen toteutuksen tulee kuitenkin täyttää kaikki laatuvaatimukset. Valmiin määritelmä (Definition of Done, DoD) voi olla eri tilanteissa eritasoinen: tuoteomistajan tulee tietää toteutustyötä tilatessaan, onko tilaamassa kokeilulaatua vai priimaa – tai joissain tilanteissa jopa hätäpaikkausta.
Turvallisen kokeiluympäristön mahdollistamiseksi työskentelemme oletuksella, että kukin työntekijä on tehnyt parhaansa senhetkisen tietämyksensä, osaamisensa ja kykyjensä mukaan. Odotamme jokaisen myös kertovan avoimesti niin onnistumisista kuin epäonnistumisista. Pidämme kokeiluissa epäonnistumista neutraalina asiana, sillä se mahdollistaa oppimisen.
Sääntöjä tarpeen mukaan: ”Minimum Viable Governance”
Sovelluskehitys on kompleksinen toimintaympäristö, jossa ratkaisut hahmottuvat usein tapauskohtaisesti ja vasta konkreettisessa tilanteessa mukana olevien osaamisella ja kontekstin tuntemuksella. Yleensä ei ole mahdollista tukeutua yksiselitteisiin ja staattisiin “parhaisiin käytäntöihin”. Tiimien on varauduttava toimimaan yllättävissä tilanteissa, jolloin ongelmanratkaisukeinona on sopeumien löytäminen, ts. olemassa olevien ratkaisujen soveltaminen uusiin tarpeisiin.
Ennalta laadittu malli tai viitekehys voi tarjota vain yleisluontoiset, oletusarvoiset pelisäännöt ketterälle sovelluskehitykselle, eräänlaisen ”pysäytyskuvan” HY:n toimintakulttuurista kirjoittamishetkellä. Malli ei siis yritäkään ennakoida kaikkia tulevia haasteita, vaan jokaisen ketterän projektin / tiimin tulee tarkentaa ja ajoittain myös tarkistaa omat käytäntönsä tässä esitettyjen oletusarvojen pohjalta.
Omat käytännöt ja "paikallisväri"
Omat käytännöt ja paikalliset variaatiot on sovittava yhdessä, tietoisesti ja muulle kehittäjäyhteisölle läpinäkyvästi:
- Tietoisia valintoja, ei ad hoc -päätöksiä
Aloittaessanne uutta projektia (tai parantaessanne vanhaa) pohtikaa ainakin sisäisesti, noudatatteko vakiintuneita käytäntöjä vai poikkeatteko niistä. Syy poikkeamaan voi olla arkijärjellä ilmeinenkin; esim. resurssipula tai kiire voi olla perusteltu syy jättää jokin asia tekemättä, mutta se on juuri siksi tärkeää tehdä näkyväksi. Pelkkä toteamus ”ei katsottu tarpeelliseksi” ei itsessään riitä perusteluksi.
- ”Minimum Viable Documentation”
Kirjatkaa valinnat projektin / tiimin valitsemalla tavalla. Maininta tiimin pikaviestikanavalla, tiimitilan huoneentaululla tai projektin wikisivulla voi olla joillekin asioille aivan riittävä dokumentaatiotaso. On aina parempi saada edes jotain jälkeä poikkeamista kuin karkoittaa osalliset raskailla dokumentaatiovaatimuksilla.
- Tiedon jakaminen on tärkeää
Kuvatkaa ja perustelkaa muuttuvat ja kehittyvät käytännöt muidenkin omaksuttavaksi (kirjaamalla ne HY:n Sovelluskehittäjien ohjeet -wikisivustolle, esittelemällä niitä verkostotapaamisissa ja HY:n arkkitehtuuriratkaisuista vastaaville tahoille jne.)
Etä- ja lähityö
Ketterien periaatteiden julistuksen mukaisesti ”Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan”. Painotus on tässä sanoilla yhdessä ja päivittäin – se miten kukin tiimi tämän toteuttaa itselleen hedelmällisimmällä tavalla, voi vaihdella.
Etä- ja hybridityön osuus työnteosta on merkittävä, mutta myös kasvokkain tapaamisella on arvoa tiimien yhteen hitsautumisessa, tiimien sisäisen kommunikaation kehittämisessä ja hiljaisen tiedon siirtämisessä tiimien välillä.
Puhdas offshoring-malli ei mahdollista näitä hyötyjä, joten kulttuuriimme kuuluu, että tekijät ovat tavanneet toisensa kasvokkain edes joskus. Lähityön osuutta on siksi painotettava projektien alussa. Erityisesti jos tiimin jäsenet eivät ole toisilleen ennestään tuttuja ja/tai kehittäjät eivät ole aiemmin työskennelleet HY:n projekteissa, on tiimiytymiselle ja asiakasymmärryksen luomiselle järjestettävä hyvät olosuhteet. Projektien alkuvaiheisiin liittyvät rituaalit, kuten kick-off-tilaisuudet, design sprintit yms. palvelevat tätä tarvetta hyvin ja tulee järjestää ensisijaisesti lähityönä.
HY pyrkii järjestämään tiimeille työpisteet asiakkaan tiloista, siten että kehitystiimi ja tuoteomistaja voivat työskennellä osan ajasta kasvokkain. Projektit pyrkivät tyypillisesti tekemään lähityötä 1–3 pv/vko. Kehitystiimi saa mahdollisuuksien mukaan ja tilojen asettamien rajoitusten puitteissa muokata työskentelytilaa tukemaan ketterää kehitysprosessiaan.
Mittarit ja seuranta
Ketterän kehityksen kulmakiviä on toiminnan läpinäkyvyys ja rehellisyys. Dokumentaatio ei ole itseisarvo, vaan Lean-periaatteiden mukaisesti vältetään hukkatyötä esim. erillisen raportoinnin muodossa, jos tieto on muuten saatavilla päivittäisen toiminnan tuloksena.
Jatkuva seuranta
Kun projekti toimii aidosti ketterästi, jatkuvan seurannan vaatimukset täyttyvät Scrum-tiimin työskentelyn kautta. Seurannan muodostavat silloin etenemisen visualisointi, kehitystiimin reaaliaikainen yhteistyö tuoteomistajan kanssa sekä Scrumin tilaisuudet (katselmukset yms).
Erillistä formaalia raportointia edellytetään vain poikkeustapauksissa, esim. jos projektilla on erityisiä juridisia tai hallinnollisia dokumentointivaatimuksia.
Sprintin työlistan eteneminen: Scrum Guiden mukaisesti tai muulla projektissa yhteisesti sovitulla tavalla. Kehitystiimi välittää tuoteomistajalle tiedon etenemisestä säännöllisesti, yleensä päivittäisellä palautesyklillä.
Hankkeen tai projektin eteneminen: Kehitystiimi ja tuoteomistaja tuottavat ja välittävät tietoa HY:n projektimallin mukaisesti (mm. päivittämällä projektikortin tietoja projektisalkussa) tai muulla projektissa sovitulla tavalla.
Työmäärien seuranta
Toteutuneiden työmäärien seuranta voi tapahtua osana päivittäistä sprinttityöskentelyä esim. tikettijärjestelmässä yksittäisten stoorien tms. tuntilaskureilla, tai jos tällainen ei ole luontevaa, erillisinä tuntikirjauksina. Tuoteomistajan pitää pystyä selvittämään työmäärät työntekijä- ja tiketti/työkohdekohtaisesti.
Olennaista on että tuoteomistajalla on reaaliaikainen näkyvyys työn etenemiseen myös työmäärien osalta. Tarkoituksena on tehdä budjetin seurannasta yhtä ketterää kuin toteutuksesta: poikkeamiin pitää voida reagoida heti eikä vasta n. 2 kk viiveellä laskun saapuessa.
Jos tuoteomistajalle ei ole mahdollista luoda reaaliaikaista näkymää työmäärien toteumaan, on tiimin raportoitava vastaavat tiedot muulla tavoin. Tällöin projektipäällikkö, Scrum master, account manager tms. raportoi toimittajan tekemät työtunnit tilaajan projektipäällikölle/tuoteomistajalle riittävän tiheällä syklillä. Kunkin työkohteen osalta kirjataan selitteeksi muutaman sanan kuvaus (esim. “sprintin review”, “kommunikointia tahon X kanssa”, ”login-sivun korjaus”, ”käyttöliittymäsuunnittelua virkailijan näkymään”, ”tiketti FOO-475”).