Gantt og Jira: slik holder du planen og arbeidet i samsvar

I mange selskaper finnes prosjektet to ganger. Planen, med faser, avhengigheter og leveringsdatoer, ligger i et Gantt-diagram laget av prosjektlederen. Arbeidet, med saker, sprinter og tildelinger, ligger i Jira. Så lenge de to holdes adskilt, må noen kopiere fremdrift fra den ene til den andre for hånd, og planens datoer blir fort utdaterte.

Denne artikkelen forklarer hvorfor Jira alene ikke er nok til planlegging, hvordan toveis synkronisering mellom Planitude og Jira Cloud fungerer, og hvilke begrensninger det er lurt å kjenne til før du slår den på.

To verktøy, to ulike spørsmål#

Jira svarer på spørsmålet hva jobber teamet med akkurat nå? Backlogger, tavler og sprinter er laget for det. En plan svarer på et annet spørsmål: når blir vi ferdige, og hvilke oppgaver tåler ikke forsinkelse?

Å svare på det andre krever varigheter, avhengigheter med ledetid og forsinkelse, kalendere med helligdager, begrensninger og en beregning som skyver hver endring nedover. Hvis installasjonen av den nye serveren sklir tre dager, må testing, opplæring og go-live flytte seg av seg selv, og prosjektlederen må straks vite om leveringsdatoen fortsatt holder.

Hva Jira mangler for planlegging#

Jira er ikke uten planleggingsverktøy. Tidslinjen viser avhengigheter mellom koblede elementer med koblingstypen «Blocks», og når datoene til to koblede elementer overlapper, blir avhengighetslinjen rød for å signalisere en mulig forsinkelse^[1]. Ifølge Atlassians prisside håndteres avhengigheter innenfor ett enkelt prosjekt i planene Free og Standard og på tvers av prosjekter i Premium^[2].

En advarsel er imidlertid ikke en omberegning: datoene forblir som de ble lagt inn, og kritisk linje er ikke blant de beskrevne funksjonene. Resultatet er at planen lever et annet sted, i en fil eller et annet verktøy, og kommer ut av synk. For en fullstendig sammenligning av de to verktøyene, se Planitude vs Jira.

Slik fungerer toveis synkronisering#

Integrasjonen kobler ett Planitude-prosjekt til ett Jira Cloud-prosjekt. Pålogging bruker Atlassian OAuth 2.0: Planitude ser aldri passordet ditt, lagrer tokenene kryptert og fornyer dem med de roterende refresh-tokenene Atlassian tilbyr, som utløper etter 90 dagers inaktivitet^[3].

Første gang du kobler til, velger du førstegangsavstemmingen:

1. Send planen til Jira: en sak opprettes for hver oppgave og en «Blocks»-kobling for hver avhengighet;
2. Importer fra Jira: hver eksisterende sak blir en oppgave nederst i planen, med startdato, varighet, fremdrift og ansvarlig;
3. Begge deler: først importen, deretter sendes oppgavene som ennå ikke finnes i Jira.

Fra da av går endringer begge veier. Fra Planitude til Jira oppdages og sendes hver endring i planen i løpet av sekunder, uansett hvor den kommer fra: tabellen, Gantt-diagrammet, en import eller KI-assistenten. Fra Jira til Planitude kommer endringer via webhookene integrasjonen registrerer, som Planitude fornyer før Atlassians utløp etter 30 dager^[4], og en kontroll hvert femte minutt fanger opp eventuelle hendelser som er gått glipp av.

Sammendragsoppgaver kan bli i Planitude eller bli Epics, med oppgavene under som underordnede saker.

Hvem som eier hva: feltregelen#

En pålitelig synkronisering trenger en enkel regel for hvert felt. I Planitude er den slik:

Logikken speiler det virkelige arbeidet: planen bestemmer når, teamet bestemmer hvor langt en oppgave har kommet og hvem som gjør den. Status oversettes til en prosent med et redigerbart kart: etter kategori er å gjøre 0 %, pågår 50 %, ferdig 100 %. Hvis en oppgave allerede står på 30 % og saken flyttes til «In Progress», overskrives ikke fremdriften med en flat 50 %.

Personer kobles automatisk via e-post når Jira-brukeren gjør den synlig; ellers velger du koblingen for hånd på integrasjonssiden.

Avhengigheter, konflikter og slettinger#

Avhengigheter. Slutt-til-start-koblinger blir «Blocks»-koblinger: forgjengeren blokkerer etterfølgeren. Start-til-start-, slutt-til-slutt- og start-til-slutt-koblinger har ingen tilsvarighet i Jira og blir bare i Planitude. «Blocks»-koblinger lagt til for hånd i Jira importeres ikke og slettes ikke.

Datoer endret i Jira. Fordi datoer beregnes av planen, settes en dato endret i Jira tilbake til planens verdi, og den avviste endringen vises i integrasjonsloggen. For å flytte en oppgave flytter du den i planen: motoren beregner også på nytt hver oppgave som avhenger av den.

Konflikter. For hvert felt sammenligner Planitude tre verdier: den sist avtalte verdien, den nåværende verdien i planen og den nåværende verdien i Jira. Hvis bare én side er endret, går endringen til den andre. Hvis begge er endret til ulike verdier, vinner feltets eier, og konflikten logges med begge verdiene. Regelen avhenger bare av dataene, ikke av klokkene til de to serverne.

Slettinger. Ingen av sidene sletter noe på den andre. En oppgave slettet i Planitude lar saken bli igjen i Jira med etiketten planitude-unlinked; en sak slettet i Jira lar oppgaven bli igjen i planen, og siden tilbyr to handlinger: opprett den på nytt i Jira eller slutt å synkronisere den.

Koble til Jira steg for steg#

1. Åpne prosjektet i Planitude og velg ⋯ › Integrasjoner › Jira.
2. Klikk Koble til Jira og gi tilgang på Atlassians samtykkeskjerm.
3. Hvis kontoen din kan se flere nettsteder, velger du riktig, deretter Jira-prosjektet.
4. Gå gjennom alternativene: standard sakstype, sammendragsoppgaver som Epics eller ikke, felt for startdato, etikett for saker opprettet av Planitude.
5. Velg førstegangsavstemmingen: send, importer eller begge deler.
6. Sjekk delen Personer og fullfør eventuelle koblinger som ikke ble funnet via e-post.

Planitude skriver til Jira som personen som koblet til prosjektet, så vedkommende trenger Jira-tillatelsene til å bla i prosjektet, opprette, redigere, tildele og koble saker, og sette dem gjennom overganger. Eiere og redaktører av Planitude-prosjektet kan konfigurere integrasjonen; personer med skrivebeskyttet tilgang ser bare statusen. De andre tilgjengelige integrasjonene er beskrevet på siden Integrasjoner.

Kjente begrensninger#

• Bare Jira Cloud: Jira Data Center og Server støttes ikke.
• Bare slutt-til-start-avhengigheter; én ansvarlig per sak (personen med flest enheter på oppgaven).
• Datoer med dagsoppløsning: klokkeslett blir i Planitude.
• Atlassian tillater en OAuth-app 5 webhooks per bruker per nettsted^[4]: utover det femte prosjektet koblet til av samme person på samme nettsted, kommer endringer fra Jira via femminuttskontrollen.
• Med alternativet «bare bunnoppgaver» behandles en oppgave som blir et sammendrag som fjernet, og saken får etiketten planitude-unlinked.

Vanlige spørsmål#