Jira–VSTS-migraatio: työtehtävien siirtäminen

Jiran ja VSTS:n suunnittelutyökalut muistuttavat monin tavoin toisiaan, sillä molemmat on suunniteltu ratkaisemaan samaa ongelmakokonaisuutta. Kuten arvata saattaa, ne lähestyvät näitä ongelmia kuitenkin eri tavoin. Esimerkkejä ovat muun muassa hieman erilainen terminologia ja toteutus. Tämän vuoksi olemassa olevan datan migraatio ei ole aivan niin yksinkertaista kuin toivoisi.

Tässä blogikirjoituksessa tarkastelemme, miten Jirasta VSTS:ään (Visual Studio Team Services) tehtävää migraatiota kannattaa lähestyä. Pohdimme myös, mitä dataa haluamme säilyttää ja mitä mahdollisuuksia siihen on, sekä keskeisiä muutoksia, jotka siirtymässä kannattaa tehdä.

Mitä pitää migroida?

Katsotaan, mitä haluamme migroida siirtyessämme Jirasta VSTS:ään:

• Tiketin ominaisuudet

• Linkit tikettien välillä

• Liitteet

• Yhteydet ulkoisiin artefakteihin (buildit, commitit)

• Rakenteelliset tiedot (backlog/sprintit): milloin sprintit alkavat ja päättyvät? Mitkä kohteet kuuluvat mihinkin sprinttiin? Mikä on backlogin prioriteetti?

• Historiatiedot: kuka loi minkäkin tiketin ja milloin? Kuka sulki sen ja milloin? Milloin se avattiin uudelleen? Lisättiinkö samalla linkki?

Työnkulun ja nimeämisen muutokset

Molemmat työkalut tukevat laajaa mukauttamista: voit tehdä pieniä muutoksia valmiisiin prosessimalleihin tai määritellä täysin yksilöllisiä prosesseja. Käytitpä Jiraa sellaisenaan tai mukautit työnkulkua merkittävästi, ensimmäinen vaihe on tarkastella nykyisiä käytäntöjäsi ja sitä, miten ne vastaavat VSTS:ssä tavoiteltavaa toimintamallia. Tarkastellaan esimerkiksi Jiran ja VSTS:n Scrum-prosessimallien välisiä eroja.

Kun Jiran tiketti muutetaan VSTS-työkohteeksi, ensimmäiseksi on päätettävä, minkä tyyppinen työkohteesta tulee.

Tyyppien ja hierarkioiden erot

Verrataan kahta eri tyyppiä:

Kuva 1. Jiran tikettityyppien hierarkia

Yllä olevista kuvista näemme, että ero ei ole vain nimeämisessä (esimerkiksi Jiran alitehtävät vastaavat VSTS:n tehtäviä), vaan myös semantiikassa, joka liittyy prosessimallin työnkulkuun ja käyttöliittymätukeen. VSTS:n featureille ei ole Jirassa vastaavaa käsitettä, ja sekä Jiran tarinoita että tehtäviä voidaan pitää VSTS:n product backlog itemeina.

Muutama huomioitava kysymys:

Aikooko tiimisi käyttää VSTS:n portfoliohallintatoimintoja? Kuinka monta backlog-tasoa tarvitsette? Pitääkö Jiran Story ja Task erottaa toisistaan?

Tilojen erot

Toteutukset eroavat toisistaan myös tilojen osalta:

VSTS:n tehtävätilat ovat riittävän samankaltaisia kuin Jiran tilat, mutta entä PBI-tilat? To Do voi vastata sekä New- että Approved-tilaa, ja In Progress sekä Approved- että Committed-tilaa. Tätä semanttista eroa ei välttämättä voida ratkaista pelkästään yhdistämällä tilojen nimet. On myös tarkistettava sprintit, joissa tarinat, tehtävät ja alitehtävät ovat In Progress -tilassa.

Lisäksi on selvitettävä, onko Jira-prosessimallia muokattu lisäämällä siihen uusia tiloja. Jos on, mihin niitä käytetään? Löytyykö VSTS:stä vastaava? Jälkimmäiseen kysymykseen vastaus voi olla vastaava tila tai täysin erilainen toimintatapa, kuten VSTS:n test casejen käyttäminen Ready for Testing -tilan sijaan.

Työkalut käsittelevät myös linkityksiä eri tavoin. Jiran Epic Link- ja Parent-kentät korvataan VSTS:ssä Parent- ja Child-linkkityypeillä. Myös muutamia Jirassa tyypillisesti käytettyjä linkkityyppejä puuttuu VSTS:stä oletuksena, kuten Blocked by ja Caused by.

Mukautukset

VSTS:n prosessimalleja voidaan toki mukauttaa laajasti muistuttamaan Jiraa. Jossain vaiheessa on kuitenkin löydettävä tasapaino tutun toimintamallin ja uuden työkalun täysipainoisen hyödyntämisen välillä. Yleensä tämä tarkoittaa joidenkin VSTS:n oletustoimintatapojen hyväksymistä.

Jira–VSTS-migraation ensimmäinen vaihe on nykyisten käytäntöjen ja niiden tarkoituksen tarkastelu ja ymmärtäminen. Tätä varten on tärkeää ymmärtää hyvin, mitä VSTS tarjoaa. Sen jälkeen voit muokata käytäntöjäsi niin, että ne sopivat paremmin uuteen työkaluun.

Tämän pohjalta voimme valita sopivan VSTS-mallin ja päättää, räätälöimmekö sitä ja miten. Sen jälkeen määrittelemme tarvittavat vastaavuudet ja muunnokset Jiran ja VSTS:n kohteiden, nimien ja arvojen välillä.

Perusskenaariossa tarkastelemme ensisijaisesti seuraavien asioiden vastaavuuksia:

1. Tyypit

2. Linkkityypit

3. Tilat

4. Mittauskentät (esim. prioriteetti, Story Pointit, työmäärä, jäljellä oleva työ)

5. Backlogin organisointi, kuten sprinttien kohdistaminen ja priorisointi

Jira–VSTS-toteutus

Onneksi sekä Jira että VSTS tarjoavat API-rajapinnat, joiden avulla voimme automatisoida prosessin.

Kokemuksemme mukaan suurin haaste siirryttäessä Jirasta VSTS:ään on historian palauttaminen ja simulointi. Jira mahdollistaa kenttien, linkkien ja liitteiden muutosten tarkastelun. Yhdessä kommenttien hakemiseen tarkoitetun API-päätepisteen kanssa tämä mahdollistaa kohteen historian simuloinnin muutos kerrallaan.

Haasteet

Historian palauttamiseen ja muutosten simulointiin tällä tavalla liittyy muutamia haasteita:

• Muutosten tekemiseksi ja toisen käyttäjänä esiintymiseksi meidän on ohitettava VSTS:n pakottamat säännöt (API-vaihtoehto). Tämä vaikuttaa hienovaraisesti siihen, kuinka hyvin työkalu tunnistaa nämä pienet kiertotavat käyttöliittymässä tai raporteissa. Koska tuetut työnkulkusäännöt eivät aina ole samoja, tästä tulee erityisen tärkeää.

• Liitteet ja muut aiempiin muutoksiin liittyvät artefaktit eivät välttämättä ole enää saatavilla.

• Jira käyttää renderöityjen kenttien hakemiseen eri API-rajapintaa. Voimme siis simuloida näihin kenttiin tehtyjä muutoksia, mutta vain viimeisin tila renderöidään kuten Jirassa.

Muutosten tekemiseksi ja toisen käyttäjänä esiintymiseksi meidän on ohitettava VSTS:n pakottamat säännöt (API-vaihtoehto). Tämä vaikuttaa hienovaraisesti siihen, kuinka hyvin työkalu tunnistaa nämä pienet kiertotavat käyttöliittymässä tai raporteissa. Koska tuetut työnkulkusäännöt eivät aina ole samoja, tästä tulee erityisen tärkeää.

Liitteet ja muut aiempiin muutoksiin liittyvät artefaktit eivät välttämättä ole enää saatavilla.

Jira käyttää renderöityjen kenttien hakemiseen eri API-rajapintaa. Voimme siis simuloida näihin kenttiin tehtyjä muutoksia, mutta vain viimeisin tila renderöidään kuten Jirassa.

Jos käytössä on linkkejä ulkoisiin artefakteihin, niiden on oltava käytettävissä VSTS:stä, jotta käyttöliittymäintegraation taso säilyy samana. Jos linkki viittaa Bitbucketin git-repositorion commitiin, myös repositorio on migroitava VSTS:ään, jos siihen halutaan linkittää migroidusta Work Itemista. Muussa tapauksessa linkki on vain pelkkää tekstiä, mikä voi olla hyväksyttävä kompromissi.

• Varaudu siihen, että joidenkin kenttien muuttaminen käynnistää muutoksia muissa kentissä, kuten State- ja Reason-kentissä. Näiden simuloinnista voi tulla monimutkaista, kun otetaan huomioon mahdolliset muutosyhdistelmät.

Yhteenveto

Haasteista ja joistakin kompromisseista huolimatta Jira–VSTS-migraatiossa voidaan saavuttaa hyvä tarkkuus. Yksi tapa on erottaa migroidut kohteet aluksi projektin muusta sisällöstä käyttämällä Areas-alueita. Tämä mahdollistaa massamuokkauksen manuaalisesti sekä projektidatan osittaisen tai vaiheittaisen migraation. Suurin haaste ei kuitenkaan ole itse datan migraatio, vaan tiimien prosessiseurannan työnkulkuun tehtävät muutokset.

Jos haluat tehdä migraation itse, noudata yllä kuvattua menettelyä. Jos kohtaat ongelmia tai haasteita, ota rohkeasti yhteyttä. Meillä Solidifylla on asiantuntemusta ja kokemusta molemmista järjestelmistä, ja autamme mielellämme.

Minkä järjestelmän kanssa työskentelet? Oletko harkinnut migraatiota järjestelmästä toiseen? Kerro meille kommenteissa!