Skip to content

Home

Jump to bottom
Natayra Santos edited this page Oct 18, 2021 · 20 revisions

Agile Meeting

Sprint Review/Planning - Monday 8:30 - 9:30 CET Karen to sent the invite to Suntka Wednesday - Catch-up 8:30 - 9:00 Friday - Catch-up 8:30 - 9:00

Welcome to the deploy-impact-21-kona-c wiki!

Business

Mobile app for individuals and aid volunteers

Main objective is to guide users/individuals to the right organisations Save data for the users that interacted with the system - google analytics Language: English initially and translated to other languages Organisations should be able to register themselves on the Services

Use Case

Rules engine

  • Father with 2 issues
  • What area are you seeking help? Education
  • Are you looking for help for yourself or someone else Someone else
  • What age is the person? 8-12
  • Are you from the nationality

Meetings

18/10/2021 - First sprint planning meeting

1. Define how we are going to work

1.1. How are we going to work on branches? Convention? 1.2. How/Who is going to merge pull requests? (Suggestion: Any other developer should review the code of the pull request and approve it. The person that opened the pull request closes it and moves the ticket that originated it to "Done" for example) If the task is small and doesn't have dependencies we merge ourselves. 1.3. Structure of our task board: Backlog - tasks not part of the current sprint and haven’t been tackled yet To do - tasks part of the current sprint that have not been tackled yet In Progress - tasks someone is working on Review/Testing - tasks waiting for code review (after a pull request is done) Done - tasks completed during this sprint (that should be archive at the end of the sprint)

  1. Should we schedule meetings to features/tasks that we want to decide as a team instead of doing it on the already fixed ones? Ex: - "Feature kick-off" - features that are presented by product owner and discussed by the team
  • "Task grooming" - create tickets for tasks presented during “Feature kick-off” plus other things the developers think should be tackled
  • "Demo" - developers show everyone what has been done (maybe before product owner meetings)

  1. Participation form mentions sprint deliverables that are to be deliver on Sundays and our sprint retrospectives are on Monday mornings 3.1. Should we change our sprint retrospective meeting to meet the sprint deliverables? 3.2. Who is going to be in charge of filling the Participation form with the sprint deliverables every week?

  2. Sprint planning Create tasks that we think should be on the backlog (can be added at any moment of the sprint) Select which tasks on the “Backlog” are ready to be worked on. A task is ready if people have a common understanding of what it means for that task to be accomplished. Take dependencies into account. Assign tasks to people. Discuss if it’s too much or too little and adjust. Each task should be assigned to only 1 person unless the people will be working simultaneously together on it. Move the assigned tasks from “Backlog” to “To Do”. “Archive all” the “Done” tasks from the last sprints.

  3. Sprint retrospective Suggested template: What went well (personal tasks, team) - 1 row per person, people paste on their row and read What could have gone better (personal tasks, team) - same as previous Look into “What could have gone better” and create tickets or add points for discussion (next section) - no content, just to be done together Topics for discussion - single list, everyone can add to it (optional) Why did we not achieve our target for the sprint? - 1 row per domain of work

List of possible backlog tasks: Bolor - Devops - create github action (pipeline on gitlab) that builds the frontend to run every time you open a pull request or push new commits Bolor - Devops - create github action (pipeline on gitlab) that check if the code formatter (Prettier) has been run every time you open a pull request or push new commits Natayra - Devops - confirm if main/master branch is protected and if is not to do it Backend - create endpoint “create organization” Backend - create endpoint “edit organization” Backend - create endpoint “delete organization” Backend - create endpoint “list all organization” Bolor - Backend - create endpoint “registration” Bolor - Backend - create endpoint “login” Katlego and Kiran - Design - user journey Justyna - Frontend - define conventions and folder structure of the app Justyna - Frontend - decide on how we are going to write the style and share it Natayra - Frontend - add a new page/screen with a button to navigate to another page and back Claudia and Bolor - Database - connect to PostgreSQL from Flask

PS: Conventions should be written in a doc in the project (.md file)

https://docs.google.com/document/d/1wwEEJhsLhvak5_rIiTG3bmV15SsKMCmS/edit

Clone this wiki locally