Een nieuwe feature ontwikkelen met scrum: een kijkje in de keuken

Een nieuwe feature ontwikkelen met scrum: een kijkje in de keuken

01/03/2023

Ook wij werken met het ontwikkelen van software met de scrum methodiek. Onze developer Thijs Roggekamp laat in dit blog zien hoe hij stap voor stap een nieuwe feature ontwikkelt.

Nieuwe Sprint

Het is maandag, de eerste dag van een nieuwe twee wekelijkse sprint. De dag begint met een stand-up in Teams van alle aanwezige softwareontwikkelaars. Iedereen vertelt iets leuks van afgelopen weekend. Maar al snel worden we tot de orde geroepen om de stand-up niet te veel te laten uitlopen. Dus snel: Wat ging er vrijdag mis? Heb je nog hulp nodig? Wat ga je vandaag doen?

De sprintplanning is het volgende overleg. Dit keer met een kleinere groep ontwikkelaars. We gaan hier snel doorheen, want alle taken zijn goed beschreven in de laatste backlog refinement.

Nieuwe feature

Deze sprint bestaat voornamelijk uit het realiseren van een nieuwe feature voor onze ERP-connector. De ERP-connector is een standaardproduct dat geautomatiseerd gegevens synchroniseert tussen Autodesk Vault en diverse bekende ERP-systemen. De Product owner heeft van meerdere klanten de wens ontvangen om ook een afbeelding van het artikel zichtbaar te krijgen in het ERP systeem. Een plaatje zegt immers meer dan 1000 woorden. In de vorige sprint heeft de Product owner al de klantwens geformuleerd in de backlog.

De afbeelding van het Item in Autodesk Vault ziet er zo uit:


Zo ziet het eindresultaat eruit in het ERP-systeem:

Ontwikkelomgeving en productieomgeving

Gelukkig hebben we een afzonderlijke ontwikkelomgeving op een virtuele machine die in Azure draait. waardoor al onze softwareontwikkelaars eenvoudig de development omgeving kunnen benaderen. Een demo-omgeving voor onze consultants en testers kunnen hierdoor ongehinderd hun werk blijven doen. Op de ontwikkelomgeving staat alle benodigde software al geïnstalleerd. (Autodesk Vault/ERP systemen voor de ERP-connectoren en Visual Studio.)

Maken nieuwe feature

Het starten van de nieuwe feature gaat voorspoedig. Aangezien de plaatjes in Vault relatief klein zijn (96×96 pixels) hebben we besloten om deze data encoded op te slaan als tekst zodat uitwisseling via web-api eenvoudig mogelijk is. Aan de ERP kant kan deze informatie eenvoudig worden omgezet naar het datatype wat het ERP-systeem graag wil (byte array). Ik heb eerst een proof of concept gemaakt om de flow te testen. Al snel had ik een werkend voorbeeld. ‘Eureka!’ roep ik. Trots laat ik een collega het resultaat zien. Ook hij bevestigt de toegevoegde waarde van deze nieuwe functionaliteit.

Mappings

Uiteraard moet configureerbaar zijn welk veld in Vault het plaatje bevat en welk veld in het ERP systeem het plaatje kan ontvangen. Net als alle andere configureerbare velden is het veld voor de afbeelding toegevoegd aan de lijst van item-mappings van Vault naar ERP.

Unit tests

Bij de implementatie van deze feature is een aantal conversie methodes toegepast. Deze wil ik graag ook werkend zien. Om de werking te testen heb ik unittests toegepast. Deze draaien mee in de continuous build die ’s nachts draait om fouten op te sporen. Zo zijn we alvast voorbereid als Autodesk ineens besluit om datatypes of veldnamen te wijzigen.

Documentatie

Het lijstje van taken die gedaan moeten worden voor deze feature wordt steeds kleiner. Aangezien de configuratie kan worden ingeregeld voor deze feature moet de documentatie worden aangepast. Er mag immers geen onduidelijkheid ontstaan wat en hoe je deze feature kunt inregelen.

Quality assurance

Code review

Een collega developer doet een codereview. Hij controleert de broncode en de werking van de software. Bij de codereview worden de gewijzigde bestanden gecontroleerd op:

  • Zijn er duidelijke logische fouten in de code?
  • Is de feature volledig geïmplementeerd, kijkend naar de vereisten van het Backlog?
  • Zijn de nieuwe geautomatiseerde tests voldoende voor de nieuwe code?
  • Missen er nog rand gevallen in de testen?
  • Voldoet de nieuwe code aan de bestaande stijl richtlijnen?
  • Slaagt de build die alle testen draait?

De feedback wordt geregistreerd in het backlogitem en door mij verwerkt.

Testen development

Het testen wordt bij ons uitgevoerd door de collega developer in de ontwikkelomgeving. Om deze collega te ondersteunen schrijf ik een testplan. In dit testplan beschrijf ik de elementen die invloed hebben op de vereisten van de feature in de Backlog. Dit proces kan worden herhaald totdat geen feedback meer is van development.

Testen Product owner

Nadat de feedback van development is verwerkt wordt het testplan aangepast voor de product owner. De product owner heeft zijn/haar eigen demo omgeving waar de software kan worden getest. Het testplan beschrijft de installatie- /configuratie handelingen om de nieuwe feature te kunnen testen. De feedback wordt geregistreerd in het backlogitem en ik verwerk het. Dit proces kan worden herhaald totdat geen feedback meer is van de product owner.

Vrijgeven product

Release Notes

Bijna klaar! Ik moet alleen nog de release notes bijgewerken met een korte samenvatting van deze nieuwe feature. Zo zijn Marketing en gebruikers geïnformeerd over de laatste stand van zaken van dit product.

Release Build

De Release build mag pas handmatig worden gestart wanneer de verzamelde nieuwe features en bugfixes mogen worden vrijgegeven voor het betreffende product. De Release build geeft de software een nieuw versienummer. Ook zorgt hij ervoor dat de installatie software wordt voorzien van een certificaat. Daarna plaatst hij het resultaat (msi) in een folder op SharePoint. Zo kan iedereen binnen ons bedrijf de nieuwste versie van de software vinden.

Thijs Roggekamp
Developer