18 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.

Schoon overzicht

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:

Taggen van personen

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.

Mijn pagina

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.

Het XSARUS issue format

Als een issue wordt geschreven is het voor de schrijver heel duidelijk waar het issue over gaat en wat moet gebeuren. Voor de lezer van het issue is dit vaak niet het geval.

Om te voorkomen dat een issue onvolledig is en niet direct kan worden opgepakt bij een refinement sessie kan het helpen om een vaste structuur aan te houden in een issue. Als hulpmiddel kan je gebruik maken van de XSARUS bookmarks. Er zijn twee standaard bookmarks beschikbaar:

Bookmark t.b.v. nieuwe wensen:
Deze bookmark kan worden ingezet bij een issue waarin nieuwe wensen worden beschreven:

javascript:var issueField=($("#issue_notes").length ? "#issue_notes" : "#issue_description"); $(issueField).val("*Context:*\n\n\n*Uitgebreide omschrijving:*\n\n\n*Afhankelijkheden:*\n\n\n*Test scenario(s):*\n\n\n*Bijlagen:*\nJa/Nee ");if(issueField=="#issue_notes"){ showAndScrollTo("update", "issue_notes"); }

Bookmark t.b.v. een probleembeschrijving:

Deze bookmark kan worden ingezet bij een issue waarin een probleembeschrijving wordt uitgewerkt:

javascript:var issueField=($("#issue_notes").length ? "#issue_notes" : "#issue_description"); $(issueField).val("*Context:*\n\n\n*Uitgebreide omschrijving:*\n\n\n*Frontend URL waar het problem zich voordoet:*\n\n\n*Artikelnummer/ordernummer ter referentie:*\n\n\n *Bijlagen:*\nJa/Nee ");if(issueField=="#issue_notes"){ showAndScrollTo("update", "issue_notes"); }

Voeg deze bookmarks toe aan de favorieten in je browser. In Google Chrome doe je dit als volgt:

  1. Open Google Chrome
  2. Open de bladwijzer manager
  3. Klik op Nieuwe bookmark toevoegen
  4. Geef de bookmark een naam en kopieer bovenstaande javascript code in de URL

Bookmark toevoegen

Als je de bookmarks hebt aangemaakt dan kan je in het vervolg, als je een issue aanmaakt in Redmine, de vaste structuur inladen in de beschrijving van het issue. Dit doe je door op de bookmark te klikken nadat je in het description veld hebt geklikt:

Voorbeeld ticket opbouw

Werk onder de vijf kopjes het issue uit en sla het issue op. Dit resulteert uiteindelijk in de volgende opbouw:

Voorbeeld kopjes

Hiermee word je bij het aanmaken van een issue getriggerd om de minimale vereisten van een issue in te vullen en weet je bijna zeker dat het voldoende informatie bevat om te worden gerefined.

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.