Folijet - Retrospective / Action plan
Action plan | Notes |
|---|---|
| |
KS: Discuss with Kitfox issues with Karate failing on envs |
|
Lotus release retrospective: focus on TC preparation before the bug-fest instead of during the bug-fest (as we are planning into the MG release) |
|
Kiwi retro: Be given access (including cloud watch access for easily retrieving and filtering logs) to AWS Bugfest evn for developers in read only
|
|
KS: create a ticket to address fixing problem with Karate test and plan it for the nearest sprint |
|
Organize a call with BE team+SA+PTF on performance testing process |
|
Make comment on the approach in the PR so that to make it easier for the reviewers; and sent a short message for urgent PRs either Slack or Skype |
|
Every morning check for PRs to review |
|
Make sure all backlog items are estimated; "won't" do items should have 0 estimate |
|
Plan the sprints for 80% for development and 20% for unexpected work |
|
@Taisiya Trunova make a presentation of updates for the development process (new statuses, workflow changes) |
|
@Taisiya Trunova Have bug fix flow (statuses), hot fix flow, regular feature development flow in Wiki page |
|
| |
@Kateryna Senchenko FST to track update of Rancher weekly |
|
@Ann-Marie Breaux (Deactivated) Add limited permissions, users, logs on in Folijet channel |
|
|
|
R2. Sprint 115. | |
@Taisiya Trunova Shift formal sprint closure/start to Monday 12 am |
|
Folijet team: finish development on the second Wednesday evening and reserve Thursday and Friday for code reviews, stories reviews, last-minute fixing, etc | BP |
@Taisiya Trunova work with the team to create feature readiness check list/DoR and user story DoR. | Need to review |
@Taisiya Trunova search for best practices of bug description guideline | DoR |
@Ann-Marie Breaux (Deactivated) review and update the description of bugs in the backlog so that the team has the actual vision of the fixing request to be able to estimate accurately and plan the sprints |
|
@Ann-Marie Breaux (Deactivated) @Yevheniia Panchenko create a new bug in status "draft"; try to reproduce then groom with devteam before opening it | BP |
@Taisiya Trunova Make the Sprint progress towards the Sprint goal and progress on features development visible to the PO and the team so that to be able to make appropriate decisions on improvement, plans adaptations, next releases forecasting |
|
|
|
TL to check migrassion issues/schema changes needed before a release | Done |
Devs to create Jira tickets to account for the time spent on supporting other teams and troubleshooting Rancher issues | Done |
To review and update tickets for data-import documentation. Involve Vladimir to create/update the documentation. Plan for 116S | In progress |
To follow boy/girl scout rule to cleaned up the code | In progress |
@Ann-Marie Breaux (Deactivated) To keep description in bug-tickets actual and keep it in right format (steps+ expected/actual results) | In progress |
@Ann-Marie Breaux (Deactivated) to start spend some time for triaging new bugs (during Grooming meetings) | In progress |
To make sure the additional testing tasks are created for feature | Review with every feature |
keep in mind OAI-PMH update and notify teams in case of breaking changes from our side |
|
to keep testing performance |
|
check the dependencies carefully before the release |
|
Add integration tests (postman collection) for new functionality (from the previous retro) |
|
@Kateryna Senchenko to create a check list what should be done after schema update and add to git repository. | done |
Devs do not bump snapshot version | done |
Do not push changes after pre-demo (on Monday) until successful demo | done |
Pull only bugs and tasks for testing in release sprint | done |
Add step to defect's and tasks description: additional PR to release branch (related to bugfix, hotfix) | done |
Add integration tests (postman collection) for new functionality |
|
@Kateryna Senchenko to ask David C for a check list for kafka testing and add it to Readme of pubsub | done |
To prevent demo tasks from failing: 1 - Avoid late PR merges if possible: it's always better to merge code earlier during the day to be able to check it one more time. 2 - Check the task ready status on TESTING env before SNAPSHOT if possible cause it rebuilds each 2 hours. 3 - If the story/task is not merged by the last Friday standup at the end of the script, we should believe it at risk, PO should be notified. 4 - Prefer local merges/branch updates over automatic github ones if possible. | done |
UI team to Update the platform after each sprint demo | done |
@Taras Tkachenkoto create simplified UI modules release procedure docs. New modules release + add to platforms procedures should also be covered. | in progress |
To discuss Q1 roadmap and priorities. @Tetyana Afanasyeva Organize a regular review of this roadmap. | done |
Discuss SRS performance, set up a meeting with architects. | done |
@Taras Tkachenko to create bug for Zak Burk to fix stripes workspace installation scripts. | not relevant |
@Taras Tkachenko to fix newly created platform installation article. | is not started |
Team prepared a list of issues related to RMB and shared with Core team. To be discuss during next Tech Leads meeting. | done |
@Taras Tkachenko to create positive and negative examples of releasing new version of Stripes components. | done |
To organize Q4 priorities discussion | done |
RuleProcessor: Rework only places where we need to apply certain changes, but do not touch the general algorithm of rule execution |
|
Add meaningful comments for squashed merge commits |
|
@Oleksii Kuzminov to create KB page about DoD for PRs. | in progress |
@Anatolii Starkov to prepare code style points to discuss. | not required |
@Tetyana Afanasyeva to set up a meeting to formalize code style and discuss/accept by team | + |
The Team to add 'tech debt' tag for items to refactor. | + |
The Team Start squash commits before merge | + |
@Oleksii Kuzminov to set up a meeting to discuss team’s code quality | + |
Devs to notify the team when making changes in API, do not forget to link Jira tickets, leave comments in order to avoid unwanted bugs |
|
PO needs to get some long-outstanding issues sorted out (new wireframes, details of profiles, 001/003/035 handling in MARC records) and ready for dev |
|
Check old-estimated stories on Planning meeting before adding to sprint. |
|
When creating stories/bug, make sure they have an Epic and are linked as "defines" to a feature |
|
To improve planning: pay attention to any dependencies, do not take blocked stories to the spring, do not assign all key tasks to one developer. | done |
TL to delegate his responsibilities for someone when he is out @Oleksii Kuzminov | done - Kate is TL's deputy |
To think about how we can merge Groomings/Retros and daily stand-ups. And how to make stand-ups in this case shorter. | done - no change |
@Igor Gorchakov to organize a team building | not done |
The team enter cards on the retro board before the retro meeting | done |
@Taras Tkachenko to create a Wiki page how to set up BigTest framework for Windows users | done |
@Viktor Soroka to update Newcomer's first steps page | done |
@Igor Gorchakov to organize a team building | not done |
The team enter cards on the retro board before the retro meeting | not done |
Try to close stories at the end of the previous sprint, not at the start of the next sprint | done |
Write placeholder stories and add to backlog for non-happy path and "would be nice to have" stuff. |
|
Be more careful updating interface versions |
|
Add an item to check-list before updating interface versions and notify UI devs in Jira |
|
To add more cards on the retro board |
|
Best practice | Note |
|---|---|
Finish development on the second Wednesday evening and reserve Thursday and Friday for code reviews, stories reviews, last-minute fixing, etc |
|
Create a new bug in status "draft"; try to reproduce then groom with devteam before opening it |
|
Plan the sprints for 80% for development and 20% for unexpected work |
|
Make sure all backlog items are estimated; "won't" do items should have 0 estimate |
|
Every morning check for PRs to review |
|
Make comment on the approach in the PR so that to make it easier for the reviewers; and sent a short message for urgent PRs either Slack or Skype |
|
During planning of upcoming sprint parallelize work most efficiently to avoid simultaneous editing of the same code within different tasks |
|
|
|