Agenda
Item | Description | Link |
|---|---|---|
Introductions | Team introductions as necessary | |
Project Overview | Workstreams and aspirations / expectations within each | https://bigdigit.atlassian.net/wiki/spaces/VOY/overview?homepageId=2472280264#Charter-%F0%9F%9A%A2 |
Roles and Responsibilities | Project team setup | |
Ways of Working | Agreed SDLC approach, and supporting systems | |
Business Requirements | Review of business requirements | |
Technical Landscape | Discuss the proposed technical frameworks/patterns/approaches | |
Actions
Action & Owner | Description |
|---|---|
Team | Create & Agree Project Name PROJECT SUEZ |
Mark Blair | Set up call with Sergey V around microservices - potential add dedicated resource to support |
Mark Blair / Alon | Provide Luca with access to Angular Playground - everything except for base Kendo components |
Adam & Steve | Model Knauf fields into DOM |
Adam | Building Design into the Process - separate workstream? |
Adam & James | Big Picture, Miro, and Figma licences from Alon |
Alon | Indigina email for Luca |
Adam | Get Stuart to manage the feedback / updated process |
Objectives
Project Plan & Communication - Status Updates, etc
More information on the system requirements
Agreement on agile process, team operation etc
First steps on technical/team standup
Responsibilities - putting items on the backlog, refinement, definition of ready
Tooling - Team Gantt, JIRA, Big Picture etc
Clarification of interactions with other projects
Bounded context & microservices, break down application as much as possible
How to implement the design process within the overall approach
Notes
Dedicated team - division of responsibilities
Use Agile methodologies
Communication will be key
Compliance checks - e.g. T1 created, delivered etc
API gateway for microservices
Visibility of user discussions with Steven
Using Angular Playground currently - so when they have a re-usable component can validate whether existing component works
Retain Kendo for good components
Css preprocessor - using less, may move to sass
Build in early the ability to set users/teams against activities
Maestro - identify changes/exceptions and raise events/alerts etc
Potential for the carrier to log in to complete their status updates (in the event they’re not integrated)
Configuration - different clients want different stuff at different times (and other clients may want more detail than Knauf do)
Phase out CW1 for job costing - keep the invoicing maybe as a interim/rollout
One Booking per file - no need early to create bookings on-screen, but would need the capability to create by interface
Manual record the confirmation of booking with carrier
Client frontend - may exclude certain data from the API call (client app projections vs api check jwt type thing)
How to deal with LTLs - what if one instruction becomes a consol, or if we cancel stuff
Get access any logs on-screen
General setup for each story:
Persisted storage layer (e.g. database)
Service definition - CRUD operations
Validation
Interactions with other services?
Frontend Interactions
Split stories into two:
Frontend / Backend
Frontend steps:
Ready for Design
Start Design
Refine Design
Finalise Design (agreed)
Develop Design
Deployment process - allow each service to be deployed independently, allow for A-B testing in time etc (i.e. not monolithic deployment)
iTrans PM - 5th
Backend Dev - 5th
UI Dev (Senior) - Push back a little
UI Dev - Maybe swap for backend?
Risks/Issues
Risk/Issue | Type | Mitigation |
|---|---|---|
Spec not detailed enough in time | Risk | Ensure sufficient detail for development team to start prototype designs using agreed frameworks/patterns |
Parking Lot
Raised by | Description |
|---|---|
Mark Blair | Angular Playground vs Storybook |