Project Organization
!
We attempted to adopt an Agile methodology to manage our work tasks. However, the sprint planning was overly rigid, which led us to shorten some work packages and exclude certain features. Additionally, we did not utilize burndown charts to track progress, and instead only reviewed completed and pending tasks at the end of each week. The process was not consistently followed, partly due to communication challenges. Coordination between frontend and backend development also proved difficult, often resulting in each side working independently based on their own priorities rather than integrating effectively. Below is a timeline outlining the development process.
| Week | Frontend | Backend | Integration |
|---|---|---|---|
| Week 1 (03.03. - 09.03) | Bootstrap Authentication | Bootstrap & Authentication | Authentication |
| Week2 (10.03 - 16.03) | Authentication & Homepage Draft | Authentication | |
| Week3 (17.03 - 23.03) | Offer Creation Draft & Frontend polishing | Authentication & Offer Creation | Dockerization |
| Week4 (24.03-30.03) | Booking Draft & Offer Pages Draft & Frontend Fixes | Booking Process | |
| Week5 (31.03 - 06.04) | Offer Pages, Homepage & Booking Polishing | Booking Process | |
| Week6 (07.04-14.04) | Offer List & Public Profile Page & Account & Profile Page | Booking Process | Offer Creation |
| Week7 (15.04–27.04) | Responsiveness | Accessibility | Booking Process |
| Week8 (28.04–04.05) | Homepage Sorting | Booking Process | Booking |
| Week9 (05.05–11.05) | Bug fixes & alertings | Testing | Public Profile Page & Account Profile Page |
We use a Feature Branch Workflow(GitHub Flow) centered on a single mainline branch:
- Single Integration Branch:
masteralways stay in a deployable state - Short-lived Branches: Every feature, bugfix or test is developed on its own branch and merged back into master when complete.
See the diagram below for the detailed branch history
Pull requests were used to introduce new features into the main branch. Each pull request was reviewed by a team member—typically Hafiz, our technical lead. This process aimed to keep feature development concise and manageable, ensuring that all team members stayed up to date with the latest changes in their respective working branches.