|
|
|
|
|
|
|
|
|
|
|
| # | 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 | Feature DoR | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
Denis Link to Feature Readiness checklist: linkNFRs - to be additionally discussed |
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 | | | | | | | |
| 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 | | | | | | | |
| Define perf baseline & reserve time to test performance at early stages. Factor knowledge in the feature estimates and timeline. | | | | | | | |
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 | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
recommend to QA to test | | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | | |
| Review/update GitHub template | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
mod-oai-pmh | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | | | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| |
| Create Users with a minimal set of permissions to verify the task (where applicable) | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | 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 | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
| | | |
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 | | | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
|
|
|
| | Status |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | in progress |
|---|
|
|
|
5 | Automate critical paths to easier catch issues introduced in other modules. | Automate test cases. | AQA team | | | | | | | |
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 |
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 | 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. |
| |
|
|
| |
|
9 | Discuss Quality Metrics during Sprint review | Include Quality metrics analysis into Sprint summary report | SM | | | | | | | |