Voor de opleiding van de VDAB, php developer, startte vandaag de scrumweek. Hierbij werden 2 groepjes gemaakt van 3 en 4 personen.

De bedoeling is in deze week een FlexDating app te creëren. Dit door grotendeels gebruik te maken van bestaande code die gebruikers fetcht van een andere server. Deze responses worden nadien gebruikt voor het creëren van de front-end van een website.

Om een beetje feeling te hebben met de gehele groep werd er vandaag gekozen om pair programming een kans te geven. Dit om de zwaktes en sterktes van alle groepsleden in kaart te brengen.

Vandaag werd er in grote lijnen besproken hoe we het project zouden aanpakken. Enkele puntjes die aan bod kwamen:

  • Gebruik van bootstrap voor de gekregen data overzichtelijk te ordenen.
  • Prioriteiten
    • Login
    • Registratie
    • Startpagina
    • Zoekpagina

Vooral de login is belangrijk in deze sprint, dit aangezien er in principe geen (of weinig) data van gebruikers mag gezien worden, vooraleer de gebruiker zich zelf heeft aangemeld.

Problemen die in vandaag zelf heb ondervonden:

  • Een git server opzetten gaat niet altijd even vlot.
    • Er een groep aangemaakt waar iedereen lid van werd, dit om de code maximaal als eigenaar te hebben van alle leden
    • Hierbij een duidelijk workflow creëren, die daadwerkelijk gevolgd kan worden is niet altijd even gemakkelijk.
      (Vermoedelijk de eerste keer voor ieder van ons samen te werken aan een project).
      In onze groep hebben we bijvoorbeeld geen 2de keer van de develop geforkt voor de registratie te voltooien, maar hebben we dit rechtstreeks op de develop branch uitgevoerd.
  • Tijdens het pair programming kreeg ik te horen - en constateerde ik - dat de verdeling van zwaktes en sterktes niet geheel gecompenseerd werd. Denk dat de pair programming pas echt een meerwaarde heeft wanneer de verschillen zich beter uiten.
    Eventueel wel verder in het project nogmaals doen, maar dan switchen.
  • Heeft het pair programming, op basis van snelheid, wel een meerwaarde na dat er een sterke basis is?

Wat kan beter tegen morgen en wat wil ik behouden?

  • Nu dat we de basis code, en ieder zijn manier van werken (evenals de sterktes en zwaktes wat hebben gevonden) lijkt het me goed van de volgende dagen met deze basis code elk zijn bepaalde feature af te werken. De huidige features (index.html en registratie.html) zijn nog niet af. Is dit best van nog af te laten werken door de groepjes, of kunnen de groepjes nu al gesplitst worden tijdens de feature?
    Eventueel kan er een duidelijk scrum-master en project-owner gekozen worden die de volgende dagen dit toch proberen te bewaken.
  • Pair programming even op halt zetten?
  • Het meer communiceren met elkaar geeft toch steeds een meerwaarde, na een basiscursus javascript is het moeilijk van elke bestaande functie reeds te kennen. Eens kunnen samenkijken voor een probleem op te lossen kan hierbij toch wel de snelheid ten goede komen.

Later maakte ik nog een mirror van de Gitlab op GitHub, daar werd een GitHub Page van gemaakt. Deze website is hier te vinden. (dit toont steeds de master)