DevOpsWorkitem Management in GitHub

Workitem Management in GitHub

Op Techorama heb ik een interessante sessie bijgewoond van Brian Randell, GitHub Projects -- Planning for Developers, Teams, and Enterprise. Het belangrijkste punt dat ik uit deze sessie haalde, was dat de Workitem Management in GitHub niet alleen een nabouwde Workitem Management uit Azure DevOps wordt. Ze hebben hier echt een eigen visie op en strategie voor. Maar wat betekent dat? En hoe ziet de toekomst eruit?

Een project aanmaken in GitHub

Het start met het aanmaken van een project in GitHub. Hiervoor zijn er op dit moment een beperkt aantal opties:

Project - Workitem management in github

Start from scratch

Wanneer je kiest voor start from scratch bevat deze een aantal velden zoals: Title, Assignee, Status, Priority, Size, Linked pull-requests en Labels.

  • Table: Een table lijkt op de backlog view in Azure DevOps en is een lijst met kolommen.
  • Board: Een board lijkt op de board view in Azure DevOps, een Kanban Board met standaard To do, Doing en Done.

Selecteer een project template

In de project template is de configuratie uitgebreid met een aantal velden, zoals: Status, Iteration en Estimate. Dit wordt waarschijnlijk de komende maanden uitgebreid.

  • Team backlog:
    • Er wordt een board aangemaakt, met een aantal voor gedefinieerde kolommen: New, Backlog, Ready, In Progress, In review en Done).
    • En er worden 3 views aangemaakt: Backlog, By priority, By size.
  • Feature:
    • Er wordt een table aangemaakt met een aantal custom velden, zoals Iteration, Estimate, Linked pull requests, Labels.

In dit blog starten we vanuit een Feature template, omdat hierin al een aantal velden zijn aangemaakt.

Work item management in GitHub

Belangrijk: Hiërarchie van issues (work items in Azure DevOps) zit nog niet in GitHub

Zoals we in Azure DevOps de hiërarchie hebben (zie afbeelding hieronder) zit dit op dit moment niet in GitHub. Alles is een issue en je kunt het zelf wel een label Epic, Feature, PBI of task geven, maar voor GitHub zijn het allemaal issues op hetzelfde niveau. Houd hier rekening mee als je gaat starten met work item management in GitHub. In dit blog leg ik uit hoe je toch dat inzicht kunt krijgen.

Hierarchie in Azure DevOps - Workitem managment in GitHub

De backlog vullen

We starten met het vullen van de backlog door een aantal Epics, Features en PBI’s in te voeren. Als we dit doen wordt alles aangemaakt als Draft, dit betekent dat het wel zichtbaar is in onze project view, maar niet vanuit de GitHub Repos. Ik kies ervoor om alles naar een issue om te zetten. Als ik alles heb ingevuld, hebben we onderstaande backlog met issues.

Work item management in GitHub

Je ziet dat alle omschrijvingen als laatste het issuenummer toegevoegd krijgen, dit vul je niet zelf in maar dat wordt bij het omzetten van een draft issue naar een issue gedaan (wat alleen mogelijk is als je daadwerkelijk een repo hebt aangemaakt die aan dit project is gekoppeld).  Als ik het eerste issue bewerk dan zie je ook dat de omschrijving zonder toevoeging van het nummer is.

Work item management in GitHub

 

Wat ook opvalt is dat het heel lastig is te onderscheiden wat de Epics, Features of PBI’s zijn. Wat je kunt doen is een naamconventie af spreken, bijvoorbeeld EPIC – naam, FEATURE – naam et cetera, maar dat is lastig om consequent door te voeren (zeker niet wanneer er veel mensen zijn die bijdragen kunnen leveren).

Extra veld

Een andere oplossing om dit te verduidelijken is een extra veld aanmaken, genaamd type. Hier heb ik een lijst van gemaakt en daarin de drie beschikbare waardes meegegeven (altijd nog uit te breiden met Bugs, Tasks et cetera). Als eerste heb ik een icoontje erin gezet en daarna de omschrijving (en om dicht bij Azure DevOps te blijven, icoontjes die lijken op de in Azure DevOps gebruikte iconen).

Work item management in GitHub

Iconen kun je toevoegen door “:” gevolgd door omschrijving van de icon te typen. Bijvoorbeeld “:crown” , “:trophy” en “:book” en dit aan te vullen met de omschrijving. Na het toevoegen van de types heb ik elk issues het juiste type gegeven.

Work item management in GitHub

Kolommen verplaatsen

Persoonlijk zie ik graag als eerste welk type issue het is. Je kunt de volgorde van kolommen eenvoudig veranderen door deze te slepen. Als je op de titel van de kolom staat komt er een handje, met behulp van de rechtermuisknop selecteer je de kolom en kun je hem verplaatsen. De eerste kolom is het positie op de backlog en kun je niet veranderen, maar verder kun je hem op elke andere plek neerzetten.

Work item management in GitHub

Het eindresultaat:

Work item management in GitHub

Ordenen

Volgende stap is de issues ordenen, zodat er een hiërarchie ontstaat. Op deze manier kun je eenvoudig zien wat bij elkaar hoort. Je ordent door met je muis bij het issue nummer (eerste kolom) te staan, er verschijnt een handje en je kunt de regel verplaatsen naar de gewenste plek. Nu staan de work items gegroepeerd.

Work item management in GitHub

Issues linken

Er is nog geen hiërarchie in issues. We hebben nu zelf een hiërarchie gemaakt door het type mee te geven en de issues te ordenen. Nadeel is nu nog dat als je een issue opent je niet ziet waar deze nu bij hoort, en als we in de loop van de tijd issues gaan toevoegen, verplaatsen et cetera dan ben je al snel het overzicht kwijt. Om dit te voorkomen heb ik 2 extra velden gemaakt:

  • Epic
  • Feature

Dit zijn vrije tekst velden die je kunt vullen met alles wat je wilt, wat ik doe is er een hyperlink in zetten. Je kunt ook de naam invoeren, maar mocht deze wijzigen dan is een hyperlink naar het nummer een beter alternatief. In onze demo is het eerste Epic Payments. De Feature Shipping & Delivery hoort hierbij. Bij de  Feature Shipping & Delivery heb ik in het veld Epic de link naar de Epic Payments opgenomen. En bij de PBI’s die horen bij de Feature Shipping & Delivery heb ik in de kolom Feature de link naar het Feature opgenomen.

Work item management in GitHub

 

Dit alles vereist nog steeds handwerk, discipline en goed opletten. Totdat er een oplossing is voor hiërarchie in GitHub is dit een goed alternatief. Er is op dit moment een beperkte beta waarin deze functionaliteit uitgebreid getest wordt, maar er is nog geen datum wanneer dit uitgerold wordt naar alle gebruikers.

View maken

Je kunt nu ook een view maken waarbij je groepeert op bijvoorbeeld alle features en bijbehorende PBI’s. Selecteer bovenin “New view”

Work item management in GitHub

Hernoem de nieuwe view naar Features, selecteer de dropdown icon en kies filter (of gebruik de shortcut)

Work item management in GitHub

Selecteer type is PBI

Work item management in GitHub

Voeg vervolgens het veld Feature toe

Work item management in GitHub

Groepeer de view op Feature, kies Table view en sla de wijzigingen op.

Work item management in GitHub

 

In deze view heb je nu een overzicht van alle Features die 1 of meerdere PBI’s gelinkt hebben.

Work item management in GitHub

Op deze manier kun je ook een view maken per feature, bijvoorbeeld:

Work item management in GitHub

Dagelijkse wijzigingen en verbeteringen

In de toekomst kijken is lastig. GitHub heeft een pagina beschikbaar waar dagelijks alle GitHub updates en verbeteringen geplaatst worden. Door de hoge frequentie van wijzigingen kunnen bepaalde items in dit blog niet meer of anders werken. Mocht je hier tegenaan lopen dan hoor ik dat graag.

Publieke roadmap

GitHub publiceert online ook de GitHub roadmap voor de komende periode (op moment van schrijven tot en met Q3 2023 (en als laatste de kolom Future). Op deze pagina kun je de geplande en gerealiseerde items zien. Op dit moment kun je zien wat er in Q3 geshipped is en in Q4 gepland en deels al geshipped is daar waar het gaat om work item management.

Workitem management in GitHub - roadmap

Conclusie

Wanneer je deze stappen hebt doorlopen heb je:

  • Visueel inzicht in wat voor type een issue is: Epic, Feature of PBI
  • Issues aan elkaar gelinkt waar nodig: Feature aan Epic en PBI aan Feature
  • Een view waarin je alle Features ziet waar 1 of meerdere PBI’s voor zijn
  • Een view voor 1 feature, mocht je alleen willen focussen op een specifieke feature

Mocht je er toch niet uitkomen, vragen of feedback hebben dan hoor ik het graag.

Of schrijf je in voor ons webinar over workitem management in GitHub op vrijdag 3 maart.

Marcel Groennou, Business Unit Manager DevOps

Webinar workitem management in GitHub terugkijken

In een volgend blog ga ik verder in op het gebruik van Kanban boards binnen GitHub.

  • Wil jij ook werken aan een Modern Ontwikkelproces bij klanten? Bekijk vacatures!