03: Iteration Review - ZHAW-Team-Toxic/PM4-Team-Toxic GitHub Wiki

Review:

  1. Review Backlog
  2. Review Releases
  3. Demo Newest Release

1. Achievements

1.1 Completed Issues

Overview: https://github.com/orgs/ZHAW-Team-Toxic/projects/2/views/7

  • #39 Map rendering with Ashley
  • #25 Setup Continious Delivery
  • #66 Create Resource Tracker
  • #65 Create documentation for Skincomposer
  • #61 sonarqube disable coverage criteria
  • #9 Create Start screen
  • #78 Show \Prepare next time: Retro documentation, what we change in the process.
  • #63 Basic Enemy and simple behaviour draft (aka Dumb enemy)
  • #14 Create Pause Menu
  • #77 Fix test coverage reporting from sonarqube
  • #67 Create Resource Buildings
  • #90 Animation research
  • #71 Create base UI
  • #70 Create Resource UI
  • #73 Change Mouse icon
  • #91 Config file, to easily enable and disable debug mode.
  • #72 Create Building selection menu
  • #68 Implementation of the saving the GameState
  • #89 No Tech Bewertungraster abgabe image

Test Coverage:

Burnup Chart: https://github.com/orgs/ZHAW-Team-Toxic/projects/2/insights/2

Releases:


Mad

  • lot of cross dependencies in tasks

Sad

  • quality gates sonar not adjustable
  • to small tasks
  • pr took to long to review
  • pr status unclear
  • dod unclear at beginning

Glad

  • Programming Yay :smile:
  • For beginnners small issue were cool :sunglasses:
  • Test coverage :D
  • first releases
  • labels for PR's
  • base stuff is done
  • good reviews :receipt:

Actions

  • Define larger, more substantial issues: In the future, we’ll structure our issues to include more actual coding work and ensure they are meaningful and self-contained.
  • Keep smaller tasks for less experienced team members: At the same time, we’ll continue to define smaller, manageable tasks to support team members who are still building up their coding skills.
  • Reduce cross-dependencies: When breaking down tasks, we’ll aim to minimize cross-dependencies between issues to enable more parallel work and avoid blockers.
  • Keep integrating SonarQube, but accept temporary gaps: We’ll continue working on integrating and adjusting SonarQube to fit our project. However, for now, we’ll accept test coverage below 80% in some areas, especially tests covering UI rendering systems.
  • Issues will be defined based on our internal definitions of Definition of Ready (DoR) and Definition of Done (DoD).