| Action Plan | Notes |
|---|
| November Retro |
- Engage operators, dev ops, security team to conversation and get feedback from them to decide which improvements can be done. Jakub Skoczen / Dilshod_Khusanov organize this conversation
|
|
|
|
- Come up with long term objectives for the next release and later discuss on TL. Julian can provide and input. Jakub Skoczen will create document to provide Objectives
|
|
|
|
| September Retro |
- Update User story for Improving documentation for working with scratch env -
Steve Ellis | Done |
- Create User Story for Creating jenkins job to allow for platform complete deployment to scratch -
Steve Ellis | Ongoing. I didn't create a user story but the dev ops people are actively working on improving the Jenkins pipelines to build the scratch environments. |
- Add this part to the US about creating jenkins job for platform complete Consider creating a rancher/k8s reference environment for platform complete - Steve Ellis
|
|
- Create User Story "Improve folio-helm repo with better container defaults for ram and cpu" - Steve Ellis
| Done - This has been covered in
RANCHER-59
-
Getting issue details...
STATUS
. |
- document experience of running Karate tests against rancher env and share/demo this for other dev teams - Steve Ellis
| Done |
| July Retro |
| keep doing this |
- Emphasize one more time to management and stakeholders that CP team has not enough resources to accomplish tasks. OL took a lot of time but still not done. We can't commit to anything with this set up - Jakub Skoczen
|
|
| keep doing |
| June Retro |
| keep doing |
| keep doing |
| keep doing |
| April Retro |
|
|
- Jakub SkoczenTalk to devOps about creating snapshot env for CP team only and grand CP with all required perms
| we did not need this for R2. wait for Abdu to create env (Hanna check with Abdu) |
| keep doing |
|
|
| keep doing |
| keep doing |
| February Retrospective |
|
|
|
|
| keep doing |
| keep doing |
| keep doing |
| 2020 |
Retro board link - Sprint 56: https://funretro.io/publicboard/DEeWRRqubCaQXm7WfKdjSZfC3wK2/-LYC7zUogkzCb1L-kjlT Retro board link - Sprint 57: https://funretro.io/publicboard/DEeWRRqubCaQXm7WfKdjSZfC3wK2/-LZEjgi7I9h-MaMVbKvy Retro board link - Sprint 59: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/-La1-uNe83Y7e7s0DpVp?pageId=14459935 Retro board link - Sprint 64: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/-LeqW9y38TmHZ22UOOaj Retro board link - Sprint 69: https://funretro.io/publicboard/uhS7lurEs9WACO0ZcntIKkeLqUq1/de9a18bd-dfc0-406d-95d8-8db4040b6106 |
- Add detailed acceptance criteria before story estimation
|
|
- Keep meetings as short as possible
|
|
- Groom stories before sprint starts
|
|
- Organize grooming backlog in streams (Devops/Backend/Common)
| Not effective |
- Form working groups about particular tickets outside of stand-ups
|
|
- Verify that issue is not blocked when including in the sprint
|
|
- Try not to add stories in the middle of the sprint
|
|
- Reserve some bandwidth to operational issues
|
|
- Become familiar with the ticket before grooming.
| Effective |
- Conduct two grooming sessions for Devs and DevOps.
| Not effective |
| Check with the team if we are going to spend more time on it after 10 minutes |
- If we groom a story and there is not enough description - we move it into the DRAFT status and don't pick up into the sprint.
|
|
- On standup inform the team (+ creator of the story) when more description is needed.
|
|
All big features should start with an investigation.
Then it should be discussed with a group of engineers.
The feature should be 'drived' be someone.
We should have a special event in order to discuss a big solution. Raise a request for such an event during the daily scrum. |
|
Set up times to review spikes / new infrastructure. Either synchronous or start PRs early for review. |
|
Each spike should have some outcome: a document, PoC and it should be reviewed by the team. |
|