Estimations, quality, testing...

Fran García-Linares & ALGM ops team

July 2020

Agenda (30~60min)

The problem

The side effects

The solution

Q & A

Reality check

We are having more complex work and it results in writing a lot of custom code (contrib opportunity)

The problem(s)

When reaching the "estimated" time, we rush things and don't "polish" as much as we should.
- Then we either don't run code by QC 😱
- Or we run it but we're reluctant to make changes due to time

Quality suffers and... IT WILL COME BACK!

We'll need to spend time fixing the old and the new issue
Maybe it'll land on somebody without context of the initial solution - could be PM, dev and/or client

Code smells:

Hardcoding values that can be computed or retrieved using Drupal calls
Too generic changes (side effects on other parts of the site)
Unfinished "projects" just because they're not live yet (polishing starts from day 1)

We need to factor quality vs estimation within reason, and it's ok to take the conversation to PM and/or client
Quality should always be first goal and drive the process
Tools:
- #algm-estimations (or estimation round, or sync estimation...)
- #algm-raisetheflag
- #algm-qc
- Zoom, slack, tech stand up
Think contrib when possible (since the moment of estimation)
If we cannot delivery quality, then we should make all aware of why and it should be agreed by all, but as a rule, we should ALWAYS deliver quality.
- Differentiate quality vs nice-to-have