[Draft] Tracking of Recommendations implementation
- Denis
- Ivan Kryzhanovskyi
- Mikita Siadykh
Sеatuses:
IN PROGRESS BLOCKED DONE ONGOING N/A
| # | Proposal | Action item | Responsible | Firebird | Folijet | Prokopovych | Spitfire | Thunderjet | Vega | Volaris |
|---|---|---|---|---|---|---|---|---|---|---|
1 | Build more solid knowledge about the feature’s scope, its complexity, requirements to performance, whether SA involvement needed. Keep focus on performance with clear requirements on baselines. | Review/develop DoR (checklist) for features, attach NFRs list | DM group PO & Development team | |||||||
Have spikes early in release cycle to understand technical approach, identify missing requirements (if any). Spike's result should be reviewed by QA engineer Input: features should be available for teams (based on new scope deadline) - SMs to facilitate | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | |||
| Decide after feature review if team is ready to pull the feature in next release or further research is required to better understand/estimate/plan it based on DoR | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | |||
| Define perf baseline & reserve time to test performance at early stages. Factor knowledge in the feature estimates and timeline. | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | |||
2 | Review/update DoD, team’s templates to make those more robust on a team level where needed, for example: -adding module permission in mod descriptor -test on snapshot not with ‘diku admin’ but with user with required permissions, etc. | Review/update DoD | Dev Team SM to capture ideas and review/confirm with the team and update DoD | IN PROGRESS recommend to QA to test | ONGOING | IN PROGRESS | IN PROGRESS | ONGOING | ONGOING | ONGOING |
| Review/update GitHub template | IN PROGRESS mod-oai-pmh | IN PROGRESS | N/A | ONGOING | ONGOING | IN PROGRESS | N/A | |||
| Create Users with a minimal set of permissions to verify the task (where applicable) | IN PROGRESS | DONE | IN PROGRESS | IN PROGRESS | DONE | IN PROGRESS | IN PROGRESS | |||
3 | Help with better understanding of real use cases of the feature by end-users. | Update DoR for user stories so that real life scenario are included in the ticket Status: To Do Involve QA engineer to clarify | PO SM to update DoR | IN PROGRESS | ONGOING | N/A | IN PROGRESS | ONGOING | ONGOING | ONGOING |
4 | Have more test cases. Consider edge cases. Prepare diagrams for complex functionality. | Implement test case creation process across all teams (for example, every feature will contain test case creation tasks) | QA analyst PO | IN PROGRESS | IN PROGRESS | |||||
5 | Automate critical paths to easier catch issues introduced in other modules. | Automate test cases. | AQA team | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING |
6 | Consider using more integration testing (Rancher environment). | Discuss with KitFox team to trigger API test on request | KitFox team to implement Dev teams – to update DoD | check with Vitaly Demchenko dev teams are blocked with ^^^ | ||||||
7 | Have vagrant boxes according to plan to carefully verify schema upgrade testing. | Add action item in Release plan to request vagrant box 1 sprint before schema upgrade testing | Release Manager | DONE Added to Release plan Oleksii Petrenko | ||||||
8 | Careful reviewing of PRs from other teams. | Owning team to reserve time for reviewing incoming PRs. Feature team should inform the repo owner prior to Sprint planning on such a dependency and factor that in story estimates. | SM/TL from feature team and owning team. | ONGOING | ONGOING | |||||
9 | Discuss Quality Metrics during Sprint review | Include Quality metrics analysis into Sprint summary report | SM | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING | ONGOING |