HY:n tapa toimia — elävä dokumentaatio tässä wikissä

Tässä wikissä pyritään pitämään yllä elävää dokumentaatiota HY:n omista vakiintuneista ketteristä käytännöistä, siltä osin kuin esim. Scrum Guide tai Modern Agile ei ota kantaa menettelytapoihin tai HY:ssä poiketaan niistä. Erityisesti Kanban-mallista, jolle ei ole olemassa mitään kanonista määritelmää, on tänne dokumentoitu HY:ssä tyypillisimmin noudatettuja tulkintoja.

Projekteissa ja kehitystiimeissä on syytä ottaa oletusarvoksi Scrum Guidessa ja tässä wikissä esitetyt käytännöt, koska ne ovat muiden tiimien kokemuksen myötä osoittautuneet Helsingin yliopiston ympäristössä toimiviksi. Jos jokin täällä esitetty oletusarvoinen tapa ei sovellu projektisi/tiimisi tarpeisiin tai on muuten vain liian epämääräistä, asiakasarvoa vähentävää tms, on poikkeaminen tietenkin paikallaan. Tee silloin poikkeama ja sen syyt näkyväksi sekä projektin sisäisesti (mm. PO:lle) että ulkoisesti (muille tiimeille): keskustelkaa sisäisesti miksi muutatte käytäntöä ja dokumentoikaa oma käytäntönne myös tähän wikiin, jotta muutkin voivat ymmärtää ja ottaa oppia.

• Modern Agile
• Ketteryyden skaalaus
• Scrum
  • Pohjana Scrum Guide
  • Paikalliset variaatiot tässä wikissä
• Kanban
• Sopivan toimintamallin valinta

Modern Agile

Helsingin yliopiston sovelluskehityksen toimintatapaa kuvaa yleisellä tasolla hyvin Modern Agile ja sen neljä perusperiaatetta:

• Auta ihmisiä loistamaan
• Toimita arvoa jatkuvasti
• Tee turvallisuudesta lähtökohta
• Kokeile ja opi nopeasti

Näiden taustalla vaikuttavat lisäksi edelleen alkuperäinen ketterän ohjelmistokehityksen julistus (Agile Manifesto) vuodelta 2001 ja sen takana olevat 12 periaatetta.

HY:n sovelluskehityksen piirissä on tehty ketteriä IT-projekteja Agile-maailman alkuhämäristä lähtien, vuodesta 2005 eli jo ennen kuin useimmat toimijat olivat agilesta kuulleetkaan. Kaikki HY:n tilaama ja tekemä sovelluskehitys on ollut ketterää vuodesta 2013 alkaen.

HY:n ketterän kehityksen ytimessä ovat tyypillisemmin olleet kevyet ja minimalistiset rakenteet kuin laajat, enterprise-tasoiset menetelmäkehikot.

Ketteryyden skaalaus

HY:ssä ei ole (tällä hetkellä) yhtä yhteistä, koko yliopiston kattavaa ketterän kehityksen johtamismallia. Tämä on tunnistettu puutteeksi.

Sovelluskehitystä aktiivisesti tekevistä toimialoista Yliopistopalvelut (YPA) on ottanut 2021 käyttöön suomalaisen Business Technology Forum -yhteisön kehittämän BT-mallin (engl. BT standard). Sen ajattelutapa ja käsitteistö on käyttökelpoinen HY:n toimintaympäristössä laajemminkin.

Meille ovat tuttuja myös muut ketterän skaalausmallit, esim. Kokonaisketterä, SAFe, Nexus ja LeSS, ja joitain niiden piirteitä on käytössä eri toimijoilla, muttei keskitetysti tai kattavasti.  Yleisradion Lean Culture Toolkit on meille ajattelutapana läheinen, muttei sekään virallisessa asemassa.

Scrum

Sovelluskehityksen menetelmänä projekti- ja tiimitasolla on Scrum.

Pohjana Scrum Guide

HY:ssä käytetään Scrumia oletusarvoisesti siten kuin Scrum.org-yhteisön Scrum Guide sen määrittelee. HY:ssä on käytössä Scrum Guiden suomennettu versio (Schwaber & Sutherland, 2020 / käännös Lekman et al 2021): https://www.lekman.fi/scrumguide

Paikalliset variaatiot tässä wikissä

Harva organisaatio kuitenkaan noudattaa Scrum Guidea 100%:sesti, eikä Scrum Guide ota kantaa kaikkiin sovelluskehityksessä tarvittaviin menettelytapohin.

HY:n omat vakiintuneet käytännöt on pyritty kuvaamaan tähän wikiin, jos ne poikkeavat Scrum Guidesta tai niitä ei ole Scrum Guidessa kuvattu. Aloittaessanne uutta projektia pohtikaa tiimin sisäisesti, noudatatteko näitä oletusarvoja vai poikkeatteko niistä; kuvatkaa muuttuvat ja kehittyvät käytännöt muidenkin omaksuttavaksi. Evolutiivinen muutos on hyväksi!

Kanban

Kanban on Lean-periaatteisiin ja just-in-time –tuotantostrategiaan perustuva, evolutiivinen menettelytapa, joka tekee näkyväksi prosessin ja sen pullonkaulat. Lean-ajattelun mukaisesti kanban-työskentelyssä pyritään optimoimaan arvoketjua, ts. minimoimaan läpimenoaikaa, jonka lisäarvon tuottaminen kestää.

Ei ole olemassa virallista ”kanban-ohjelmistoprosessia”. Kanban on hyvin minimalistisesti määritelty ja jättää runsaasti liikkumavaraa tiimin omille tulkinnoille ja sovelluksille. Tässä on määritelty vain kanbanin perusmekanismi, jota voidaan – ja kuuluukin! – optimoida projektikohtaisesti. Lähtökohtana on tiimin kulloinenkin prosessi, jota aletaan hienosäätää.

Sopivan toimintamallin valinta

Scrum: Projektin tuotekehitystyön aikana käytetään pääsääntöisesti Scrumia. Kanban-menetelmästä suositellaan otettavaksi mukaan peruselementit (visualisoi, rajoita, mittaa) myös Scrum-projekteihin. Scrumin korvaaminen tapauskohtaisesti jollain muulla ketterällä viitekehyksellä (esim. XP) on mahdollista, jos se kaikille osallisille on luontevaa.

Kanban: Ylläpitovaiheessa sekä projektien suvantovaiheissa (kahden intensiivisen kehitysjakson välillä) sovelletaan pääsääntöisesti Kanban-mallia. Kehitysresurssit ovat tällöin tyypillisesti pieniä ja kehityksen intensiteetti matala.

”ScrumBan”: Kanban-lähestymistapaa voidaan soveltaa myös väliaikaisesti tilanteissa, joissa työtehtäviä ei jostain syystä pystytä sitomaan aikarajatuksi iteraatioksi (sprintiksi) ts. jos jo 1–2 viikon sprintti sisältäisi liiaksi epävarmuutta esim. rajauksen, tietämyksen, riskien, esteiden tai prioriteettien suhteen. Tällaiset olosuhteet voivat tulla vastaan mm. ympäröivän ei-ketterän organisaation reagointia (esim. hallinnollisia päätöksiä tai ulkopuolisia integraatioita) odotellessa. 
Samoin esim. teknisesti haastavan Scrum-projektin aikana on mahdollista siirtyä hetkellisesti ”kanban-moodiin” vaikkapa nopean teknologiakokeilun (technology spike) tekemiseksi, jos sprinttiä ei ole mielekästä suunnitella ja aloittaa ennen tällaisen ymmärryksen saavuttamista.

Vesiputous: Olemassaolevan esim. SaaS-palvelun suoraviivainen käyttöönotto voi tapahtua lineaarisella projektimallilla, jos se ei sisällä räätälöintejä, konfigurointeja tai muuta asiakaskohtaista kehittämistyötä. Sovelluskehitysprojektit tehdään HY:ssä ketterästi, joten vesiputousprojekti ei ole hyväksyttävä toimintamalli hankinnoissa, joissa tehdään minkäänlaista sovelluskehitystyötä. Käytännössä lähes kaikki vesiputousmaiseksikin mielletty projektityö sisältää myös jonkinlaisia ei-lineaarisia piirteitä, esim. tarkistuspisteitä, joista palataan korjaamaan virheitä, joten voidaan kysyä, onko olemassakaan mallia, jossa eteneminen olisi 100% lineaarista.

Mallien ulkopuolella työskentely: Osa työstä voidaan ja kannattaa toki organisoida näiden mallien ulkopuolella, esimerkiksi projektin arkkitehtuuriworkshop tai järjestelmän auditointi.

Cowboy-koodaus: Ad hoc -työskentely (ns. cowboy coding) ketteryyden varjolla ei ole hyväksyttävää missään olosuhteissa.