Skip to content

Scrum

End of Scrum

It's Wednesday now, the 5th day after the scrum week.

To me it felt like it went by far too fast. Not that the project wasn't finished - with the minimal functionality - but simply, it's hard to consider a project as "done".

How did it go?

First we felt out who would take on which parts; we mostly worked per page/feature.

Who did what?

  • Griet:
    • Pages: registration, own profile, edit profile, view user, ...
    • Functionality: input validation, adding a photo, displaying the zodiac sign, ...
  • Mesut:
    • Pages: messages, index, navigation
    • Functionality: everything related to messages (posting, reading, sorting, deleting, starting)
  • Wouter:
    • Pages: search, navigation
    • Functionality: everything related to search (number per page, searching by ..., ) and the pagination at the bottom.
  • Aldo:
    • Pages: navigation, registration, login (in navbar), own profile, ...
    • Functionality: login, localStorage, favorites, lovecoins (actions and adjustments), ...

What went well?

  • Communication; as far as I'm concerned this went very smoothly, everyone knew what the others were doing (even if only partially), questions could be asked of each other, and we almost never had to wait on each other (code-wise).

Mostly thanks to the daily standup, and the extra mid-week demos we scheduled. * The CSS; by using Bootstrap a large part of UI and UX was already solved, so as developers we had little left to think about or adjust.

What could be better?

  • The designation of Scrum Master and Product Owner; no real distinction was made between group members.

At least not on paper. * Indicating how many story points per feature; this wasn't always done, and it's hard to stick to.

Also, things were sometimes subdivided too much (CSS & code). * Because of the shorter period it was difficult to know clearly what could be included in each sprint (the 1st lasted 1.5 days)

At the interim demo (on Thursday) it was once again clearly discussed what could still be added, and what had to be cancelled. * A bit more commenting in the code, especially when others want to add things. * In my eyes the demo was not a complete result; the small bugs that were still found, the feature that wasn't nicely finished (the favorites). Plenty could still be improved to deliver a nicer, better result.

Afterwards some adjustments were made and merged into the master branch.

What do I take away?

Every project needs a solid base codebase before anyone can work further on their feature. Only after this base can work continue. Also, knowing better where each group member stands (not everyone knew Bootstrap) can be a great added value in other projects.

More info:

The code for this project can be found on GitHub and GitLab.

Everything was pushed to GitLab, where merge requests were accepted or declined (usually in the develop branch).

Later, always just before a small demo, the code was merged into the master branch. After which both the develop and master branches were automatically pushed to GitHub. So that a GitHub Page could be made from master there.

gitlab.com/vdab-flexidating

github.com/vdab-flexidating

vdab-flexidating.github.io

Start of the Scrum Week

For the VDAB php developer training course, the scrum week started today. Two groups were formed, of 3 and 4 people.

The goal is to build a FlexDating app this week, mostly by reusing existing code that fetches users from another server. Those responses are then used to create the front-end of a website.

To get a bit of a feel for the whole group, today we chose to give pair programming a chance. This to map out the weaknesses and strengths of all group members.

Today we discussed in broad lines how we would approach the project. Some points that came up: * Use Bootstrap to present the received data in an orderly way. * Priorities * Login * Registration * Home page * Search page

The login is especially important in this sprint, since in principle no (or very little) user data may be seen before the user has signed in themselves.

Problems I ran into today: * Setting up a git server doesn't always go smoothly. * Creating a group that everyone became a member of, so that all members would have maximum ownership of the code * Creating a clear workflow around it, one that is actually followed, is not always easy.

Probably the first time for each of us collaborating on a project.

In our group, for example, we didn't fork from develop a 2nd time to complete the registration, but did it directly on the develop branch. * During pair programming I was told - and I noticed myself - that the distribution of weaknesses and strengths wasn't entirely compensated. I think pair programming only really adds value when the differences show themselves more clearly. Maybe do it again later in the project, but then switch around. * Does pair programming actually add value, speed-wise, after there's already a strong foundation?

What can be better by tomorrow and what do I want to keep? * Now that we have the base code, and everyone's way of working (having also discovered some strengths and weaknesses), it seems good to spend the next days with this base code each finishing their assigned feature. The current features (index.html and registration.html) are not yet done. Is it best to have the groups finish them, or can the groups already split up during a feature? Perhaps a clear scrum-master and product-owner could be chosen who try to keep this on track over the next few days. * Pausing pair programming for now? * Communicating more with each other is always an added value; after a basic JavaScript course it's hard to know every existing function already. Being able to look together at solving a problem does help speed here.

Later I made a mirror of the GitLab on GitHub, and a GitHub Page was made from it. That website can be found here. (it always shows master)