XSARUS Redmine workflow

17 januari 2024

Redmine

Redmine is de centrale projectmanagement tool die door XSARUS wordt gebruikt. De volgende drie workflows maken gebruik van deze tool: projecten, doorontwikkeling en servicedesk. Dit document heeft betrekking op de workflow doorontwikkeling.

Redmine voorkomt dat informatie per mail of telefoon bij individuen wordt aangeleverd en daardoor mogelijk niet bekend is bij het team dat aan het project werkt. Hiernaast zorgt Redmine voor een vaste workflow om nieuw werk aan te nemen en uiteindelijk op te leveren op de productieomgeving.

De standaard overzichten van Redmine kunnen onoverzichtelijk overkomen als hier tientallen issues in staan geregistreerd. Als je gebruik maakt van de kolom-, filter- en groepeerfunctionaliteiten creëer je al gauw meer overzicht.

Gecreëerde overzichten kunnen worden opgeslagen zodat je deze makkelijk opnieuw kunt gebruiken als je op een later moment weer inlogt.

Redmine structureren

In Redmine kan de kolom Business Value worden toegevoegd aan de overzichten. Dit doe je door in het tabblad Issues te klikken op options en de kolom BV toe te voegen aan de selected columns:

Verplaats veld naar rechts

Schoon vervolgens in hetzelfde scherm het kolomoverzicht op zodat je enkel nog onderstaande kolommen hebt geselecteerd en groepeer de resultaten per status.

null

Je hebt nu een overzicht gecreëerd dat alle informatie bevat om gestructureerd in Redmine te werken. Sla het overzicht op zodat deze in het rechter menu zichtbaar is onder “My custom queries”.

Toelichting op belangrijke kolommen

In de werkwijze van XSARUS zijn enkele kolommen leidend. Correct gebruik van deze kolommen bevordert de doorstroom van werkzaamheden.

Status
De status geeft aan in welk stadium een issue zich bevindt.

Status opties:

  • New
  • Analyse: doing
  • Analyse: done
  • Development: to do
  • Development: planned
  • Development: doing
  • Development: done
  • Test: to do
  • Test: OK
  • Test: NOK

Omgeving
De kolom Environment in combinatie met de status zegt iets over voortgang van het issue en de locatie waar de werkzaamheden zich afspelen.

Omgeving opties:

  • Leeg
    In dit geval is het issue niet beschikbaar op één van de omgevingen of betreft het enkel consultancy werk waarvoor geen omgeving vereist is.
  • Development/Preview/Staging
    Als een issue aan één van deze omgevingen is toegewezen, dan is het onderhanden of beschikbaar op de staging omgeving om te testen.
  • Production
    Een issue met de omgeving productie is beschikbaar op de productie c.q. live omgeving en kan op deze omgeving worden getest.

Business Value
Met de Business Value (BV) kan worden aangegeven wat de volgorde van issueverwerking is. Hiermee wordt gewerkt met waarden van 0 tot 100:

  • Geen BV of BV 0: onbelangrijk
  • BV 100: urgent

Alle waarden tussen 0 en 100 kunnen worden gebruikt om issues ten opzichte van elkaar te prioriteren.

Prioriteit
Prioriteit kan worden ingezet om issues (met name tijdens de refinement of plansessie) extra onder de aandacht te brengen, maar is ondergeschikt aan een Business Value.

Issues toewijzen

In Redmine kan je in de kolom “Assignee” zien aan wie het issue is toegewezen. Op dat moment ligt de verantwoordelijkheid en actie bij de desbetreffende persoon.  

Is er een issue aan je toegewezen en heb je het issue opgevolgd? Koppel het issue dan terug aan de persoon die het issue aan jou heeft gekoppeld.

Wil je iemand extra attenderen op een issue? Gebruik dan een apenstaartje (@) en typ de naam in:

null

Wanneer je dit doet ontvangt diegene een e-mail dat hij/zij is genoemd in een issue.

Mijn issue overzicht

Als je linksboven op “My page” klikt dan krijg je in één overzicht alle issues te zien die aan jou zijn toegewezen.

null

Beschrijving van issue

Bij een efficiënte doorstroom en dus korte doorlooptijd van werkzaamheden is iedereen gebaat. Hoe vollediger een issue wordt aangemaakt hoe eerder dat het issue kan worden gerefined*. Hoe eerder een issue is gerefined, hoe vlotter het op de planning kan worden opgenomen.

*Wekelijks houdt het development team een refinement meeting. Tijdens deze meeting worden issues technisch uitgewerkt en op basis van de informatie in het issue beoordeeld op complexiteit. Hieruit volgt een ureninschatting op basis van de informatie in het issue. Pas als een issue een ureninschatting heeft kan het worden ingepland tijdens de plan meeting.

Redmine sneltoetsen

Om je gebruik van Redmine te vereenvoudigen en administratieve handelingen te verminderen, is in Redmine een floating element beschikbaar met hierin vijf snelkoppelingen:

📋 Titel van ticket kopiëren
Hiermee kan je eenvoudig de titel van een ticket kopiëren.

🔗 URL van ticket kopiëren

Hiermee kan je eenvoudig de url én de titel van een ticket kopiëren, handig voor communicatie met collega’s en communicatie richting het team waarmee je samenwerkt bij XSARUS.

📝 Nieuwe ticketbeschrijving toevoegen
Hiermee kan je in één klik het beschrijving veld van een nieuw ticket vullen met een vaste structuur. Hiermee zorg je ervoor dat het ticket compleet en duidelijk wordt opgesteld. Werk onder de vijf kopjes het issue uit en sla het issue op. Dit resulteert uiteindelijk in de volgende opbouw:

🛟 Probleem ticketbeschrijving toevoegen
Hiermee kan je in één klik het veld van een nieuw ticket vullen met een vaste structuur voor het beschrijven van een probleem. Je zorgt er met deze structuur voor dat het probleem duidelijk en reproduceerbaar wordt toegelicht. Werk onder de vijf kopjes het probleem uit en sla het issue op.

👍 Ticket goedkeuren (test: OK)

Met deze button kan je een ticket goedkeuren. De status wordt aangepast en in de notities van het ticket wordt gevraagd om een eventuele onderbouwing. Hierna kan je het ticket opslaan.


👎 Ticket afkeuren (test: NOK)

Met deze button kan je een ticket afkeuren. De status wordt aangepast en in de notities van het ticket wordt gevraagd om een onderbouwing. Hierna kan je het ticket opslaan.

Workflow van XSARUS

Ondanks dat veelal het werk zich aan de kant XSARUS afspeelt is het een gedeelde verantwoordelijkheid om issues vlot door de workflow heen te loodsen. Hierbij speelt bovenstaande een belangrijke rol. Tot slot is het laatste toe te lichten onderdeel de issue statussen.

Issue statussen

  1. Issuestatus “New” – zonder environment
    Een issue is aangemaakt en nog niet beoordeeld.
  2. Issuestatus “Analyse doing” of “Analyse done” – zonder environment
    Een issue wordt aangenomen en eventueel aangevuld door de Consultant of Lead Developer. Het kan zijn dat het issue nog niet volledig is door bijvoorbeeld:
    a. De beschrijving is niet volledig of onduidelijk, er zal om meer informatie worden gevraagd of op basis van de summiere informatie zal het issue verder worden uitgezocht/uitgewerkt door de auteur of een consultant van XSARUS.
    b. Het issue is te groot om in één keer op te pakken. In dit geval wordt het issue verder uitgewerkt en opgesplitst in verschillende subissues.
    c. Het issue is verplaatst naar de backlog omdat het geen prioriteit heeft of omdat het tijdelijk on-hold is geplaatst.
    Zodra het issue volledig is, zal de Consultant of Lead Developer het issue inbrengen in de wekelijkse refinement meeting van het operationele team.
  3. Issuestatus “New”, “Analyse doing”, “Analyse done” – environment development
    Het issue bevat voldoende informatie om het te refinen en zal op basis van Business Value worden opgepakt tijdens de eerstvolgende wekelijkse refinementsessie.
  4. IssuestatusOntwikkeling: to do” – environment development
    Het issue is gerefined. Dit wil zeggen dat door XSARUS een ureninschatting is gemaakt en dat het issue kan worden ingepland indien het aantal ingeschatte uren akkoord is bevonden. Het issue zal worden ingepland op basis van Business Value.
  5. Issuestatus “Ontwikkeling: gepland” – environment development
    Het issue is ingepland en de werkzaamheden zullen binnen één week worden opgestart. De planning vindt altijd aan het einde van de werkweek plaats.
  6. Issuestatus “Ontwikkeling: doing” – environment development
    Het issue is onderhanden.
  7. Issuestatus “Ontwikkeling: done” – environment development
    De werkzaamheden zijn afgerond. Het issue is nog niet beschikbaar op de staging omgeving om te testen
  8. Issuestatus “Test: to do” – environment development
    Het issue is beschikbaar op staging en kan worden getest.
  9. Issuestatus “Test: OK” – environment development
    Het issue is getest en akkoord bevonden. Met de eerstvolgende deploy kan het issue mee naar de productieomgeving.
  10. Issuestatus “Test: NOK” – environment development
    Het issue is getest en niet akkoord bevonden. In een reactie onder het issue dient duidelijk te zijn beschreven waarom het issue niet akkoord is bevonden.
  11. Issuestatus “Test: to do” – environment production
    Het issue is beschikbaar op de productie (live omgeving) en kan worden getest. 
  12. Issuestatus “Test: OK” – environment production
    Het issue is getest en akkoord bevonden op de productie (live omgeving).

Noodzaak van testen door XSARUS en klant

In de hierboven genoemde workflow/issue flow worden issues minimaal 2x door de klant en/of XSARUS getest. Tests vinden zowel op de staging en productie omgevingen plaats. Uiteraard zetten wij aan onze kant alles in het werk om:

  • Binnen ureninschattingen en budget werkzaamheden op te leveren
  • Te voldoen aan verwachtingen en afgesproken deadlines
  • Kwalitatief goed werk te leveren
  • Ondanks dat wij ons voor 100% inzetten en een hoge standaard nastreven kan het wel eens voorkomen dat werk wordt opgeleverd dat niet (geheel) voldoet. Daarom is het belangrijk dat zowel medewerkers van XSARUS als van de klant issues grondig testen.

Vragen?

Mogelijk dat voor jouw project andere afspraken of voorwaarden gelden. Heb je hier vragen over? Neem dan contact op met je Implementatie Consultant.