Sprint 79 Review (2019-08-06)

Availability

(assume Team Availability Calendar is up to date, otherwise, everyone was available for 8.5 days of the 2-week Sprint)

Full team availability 8.5-day Sprint * 8 dev team members (adjusted as below)68 days

JohnO -7, Yafang -5, Andy D -2, Simon -1, John S -1


Total team availability this Sprint76%

POs present a review of Sprint goals and other committed work

Sprint Goal: Respond to user feedback on PPT and data in NDW to make both more usable.
Plus other committed-to work:
  • Implementing agreed coding standards / style
  • Prevent more than one RO per Local Office for Reval
  • SYNC SERVICE: add logic to sync service to check for failed jobs and rerun when necessary and alert to slack
  • Upgrade Angular from 5.2 to version 6
  • Develop a common understanding of "What is Angular Ahead of Time"
  • End to end test failing (both locally and in Jenkins) due to an auto-update of chrome version

POs supported by Dev team provide narrative on why, and what, emergency work was brought into the Sprint and which committed-to tickets were moved out as a result

Live Issues:

type summary story points (effort) assignee created status
Loading...
Refresh

Dev team demo 'done' work contributing to those goals (no more reference to specific list of Jira tickets, and no more reference to work not 'done')

ItemDemo - from Prod URL where feasibleDemo link

1.

Add UserProgramme table to daily NDW export

Some screenshots 

2.

When searching in Programmes for a Programme only allow users to see Programme that they have access to via their user role.

Programmes list for normal user and programme admin/observer role user:

https://www.loom.com/share/da0d81818e7d4e9ea57c691a38bb5bc8

3.

PPT - Planner does not render the full duration of a Placement if there is only one placement on display

PPT with Bug:


PPT with fix applied:




4.

Implementing agreed coding standards / style

Andy D:

Why have coding standards?

  • Devs generally spend much more time reading code than writing code (identifying issues, code reviews etc.). Having that be a consistent experience across the application speeds up assimilation of information.
  • Improves code quality and clarity (e.g. enforced minimum documentation).
  • Removes opinionated impediments to code acceptance.
  • New developers know what is expected and can get involved in productive code submission and review much more easily.

What coding standards?

We have chosen to use Google's published coding standards as a base. They are well documented which allows us to get up and running quickly.

Next steps

  • Apply standards to remaining services.
  • Reduce the current standards violations.
  • Enforce standards as part of our pipeline to ensure ongoing quality.

5.

Prevent more than one RO per Local Office for Reval

Pepe:

Previously:

Now:

User Management (Production)

6.

SYNC SERVICE: add logic to sync service to check for failed jobs and rerun when necessary and alert to slack

John/Pepe:


The problem:

  • Some (trust) users not seeing all trainees
  • Developers don't enjoy having to 'waste' time dealing with failures

The benefits (of mitigating restarts):

  • More time to do good stuff like developing features
  • Greater reliability in our users (especially Trust users) seeing the information they should

(Source: https://xkcd.com/1205/)

Other things we've done:

7.

Upgrade Angular from 5.2 to version 6

Noteworthy points for upgrade:

  • Introduction of breadcrumbs as an alternate navigation mode for TIS
  • Introduction of expiration time for toast messages within TIS
  • Updating of TIS's dependencies to bolster security and enhance efficiency of app
  • Removal of TIS's dependency on scaffolding
8.

Develop a common understanding of "What is Angular AoT"

Performance Metrics: What does it mean when we say we want TIS to be fast?

  • Quick loading of pages
  • Quick update of tables/forms
  • Quick navigation between pages

Current Implementation:

Aspirational Implementation:

9.End to end test failing (both locally and in Jenkins) due to an auto-update of chrome version
  • e2e tests are used to enforce the robustness and integrity of TIS prior to its deployment in the live environment
  • An update to google chrome driver resulted in the tests being unable to run. This was address in local development environments and on the server

Stakeholders / Users invited to query / interrogate / applaud (after Sprint Review POs convert consensus inputs into backlog tickets, giving the option to consider them in the coming Sprint Planning)

Review Sprint Goal: Respond to user feedback on PPT and data in NDW to make both more usable.

Next Sprint priorities