-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Upload M3 team grading feedback (#337)
- Loading branch information
1 parent
ddfd63f
commit d376e19
Showing
1 changed file
with
133 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,133 @@ | ||
# Milestone M3: Team Feedback | ||
|
||
This milestone M3 is the culmination of your SwEnt journey, and it gives us the final opportunity to give you, as a team, formal feedback on how you performed in the project. By now, you should be capable of demonstrating a solid command of the Scrum methodology and collaborative teamwork, and be able to deliver a high-quality, application that is ready for real users. | ||
This feedback report is meant to complement the informal, ungraded feedback that you received from your coaches during the weekly meetings, over email, on Discord, etc. | ||
|
||
You can find the evaluation criteria in the [M3 Deliverables](https://github.com/swent-epfl/public/blob/main/project/M3.md) document. | ||
As mentioned before, the standards for M2 were elevated relative to M1, and this progression continued into M3: we now hold you to the highest professional standard in SwEnt. | ||
|
||
For this milestone, we looked at several aspects, grouped as follows: | ||
|
||
- Application | ||
- [Completeness](#app-completeness) | ||
- [Functionality](#app-functionality) | ||
- [User Experience](#app-user-experience) | ||
- [Design and Implementation](#design-and-implementation) | ||
- [Testing and CI Pipeline](#testing-and-ci-pipeline) | ||
- Process | ||
- [Documentation](#process-documentation) | ||
- [Autonomy](#process-autonomy) | ||
|
||
## App: Completeness | ||
|
||
We first evaluated the depth and complexity of the main __epics__ in your app, along with their contribution to the app, the tangible value they provide to the user, and their alignment with the app’s goals. | ||
We evaluated the extent to which your app meets the __course requirements__ articulated at the start of the semester, and whether they are implemented effectively, they integrate seamlessly, and are indeed essential to the app. | ||
We then looked at the __robustness and completeness__ of the different features you implemented: are all the features finished and polished, are they secure and bug-free, and are they thoughtfully designed. | ||
|
||
|
||
Multiple epics are fully implemented, which is great to see. Their implementation aligns well with the app’s goals and includes some complex features. You’ve met all the app requirements, and they function relatively well. The features you implemented are impressive, especially the more complex ones—great job on that! However, some minor bugs and one major issue were detected during testing. | ||
|
||
|
||
For this part, you received 7.1 points out of a maximum of 8.0. | ||
|
||
## App: Functionality | ||
|
||
In this context, we assessed your app's ability to __handle unexpected inputs__ provided by clueless or malicious users (including spamming buttons, entering wrong inputs, stopping a process mid-way, etc.); we wanted to see that your app handles all edge cases gracefully, has comprehensive error handling, and includes robust mechanisms for maintaining stability under stress. | ||
|
||
We then evaluated the performance and reliability of the final product, i.e., __the APK__: we wanted to see that your APK is stable and delivers excellent performance, the UI responds quickly and has seamless navigation. | ||
|
||
Next we looked into your implementation of __user authentication and multi-user support__: does the app correctly manage users, can users personalize their accounts, does the app support session persistence, are multi-user interactions well supported, can a user recover a lost password, can accounts be used on another device, and is account information preserved when switching devices. | ||
|
||
|
||
The app demonstrates strong functionality with well-implemented features, but a few issues were detected during testing: | ||
• Minor bug: An error popup appears when signing up with email, despite the account being successfully created. | ||
• Minor bug: The “saved hikes” tab name is not well formatted on smaller screens, splitting into two lines instead of one. | ||
• Minor bug: Users can plan a hike on a past date, which should not be allowed. | ||
• Minor bug: There’s an unusually long loading screen when changing the hiking level while offline and saving the changes. | ||
• Major bug: Hikes sometimes fail to display on the map, even though they appear in the hikes list. | ||
These issues should be prioritized and addressed to improve the app’s reliability and user experience. | ||
|
||
|
||
For this part, you received 7.8 points out of a maximum of 8.0. | ||
|
||
## App: User Experience | ||
|
||
For this part, we wanted to see how __intuitive and user-friendly__ the app is for real users. Beyond having good usability, did you pay attention to streamlining the interactions, is it easy to figure out, can new users start making good use of the app quickly, are the interaction flows well thought out and refined. | ||
|
||
|
||
The app is intuitive, providing a smooth and enjoyable user experience. However, implementing a few suggestions could further enhance the UX: | ||
• Add a start and end pin on the hike trail (when a hike is selected) instead of having a single pin on one side. | ||
• Include an option to show the password in the text field for easier input. | ||
• Add a ‘forgot your password’ option to assist users in recovering their accounts. | ||
These changes would make the app even more user-friendly and improve accessibility. | ||
|
||
|
||
For this part, you received 1.8 points out of a maximum of 2.0. | ||
|
||
## Design and Implementation | ||
|
||
We evaluated whether __your code is of high quality and employs best practices__, is it modular and robust, etc. | ||
We expect the codebase to be polished, well documented, follow consistent conventions, be modular, and allow for easy modifications. | ||
You should be able to employ advanced techniques by now, such as asynchronous functions (flows, coroutines), good resource management, and automated dependency injection (e.g., with Hilt). | ||
|
||
We assessed your overall __app architecture and design__, looking in particular at aspects surrounding robustness and scalability. | ||
We looked at both the codebase and the documentation of the app (Wiki and architecture diagram). | ||
We expect your design to demonstrate thoughtful consideration for performance, maintainability, and future growth. | ||
|
||
|
||
The code is really well done overall and follows good practices. It’s great to see that you’ve taken our feedback into account and applied it in your work. Well done! | ||
|
||
|
||
For this part, you received 7.6 points out of a maximum of 8.0. | ||
|
||
## Testing and CI Pipeline | ||
|
||
The first aspect we looked at here was your __test suite__, in terms of both quality and the final line coverage. | ||
We expect testing the be rigorous and to cover all components and edge cases, and they should validate every significant user journey. | ||
Line coverage should be getting close to 90%. | ||
Your end-to-end tests should be detailed and include error-handling scenarios. | ||
The tests should be well-documented and easy to maintain. | ||
Finally, your test suite should demonstrate advanced techniques, mock data for performance testing, and automated regression tests. | ||
|
||
We then considered the quality of your __repository setup and the CI pipeline__, and how professional it is and how easy it is for new developers to bring contributions to the project. | ||
We expect your repository to have a logical structure, use consistent naming, and take full advantage of CI (code quality checks, linting, formatting, etc.) | ||
Ideally, you should also have automated performance testing, deployment pipelines, and the CI should provide detailed feedback for developers. | ||
|
||
|
||
Your code has excellent test coverage—well done! Including the JaCoCo reports directly in the PRs is a great addition that enhances transparency and makes reviews easier. | ||
|
||
|
||
For this part, you received 7.2 points out of a maximum of 8.0. | ||
|
||
## Process: Documentation | ||
|
||
We looked at your `README` and GitHub Wiki to evaluate the quality and completeness of __your app’s documentation__. We expect the README and Wiki to be thorough and achieve professional-level clarity and completeness. | ||
They should provide detailed descriptions of the app's architecture, implementation of the features, and the development setup. | ||
We also assessed __your use of Figma and the architecture diagram__ for effective UI design, organization, and app structure planning. | ||
By this stage, we expect your Figma to be complete, up-to-date, and to include UI elements for future features, showing foresight and organization. | ||
The architecture diagram should be comprehensive, providing a clear and detailed overview of the app structure and dependencies. | ||
The architecture should be robust, scalable, and optimized for performance, security, and future development. | ||
|
||
|
||
The wiki and the repository README are well-done, providing clear and helpful documentation. To enhance them further, consider adding additional resources such as an app walkthrough video, demo GIFs, interactive architecture diagrams, or user stories. Both the Figma design and architecture diagram are up to date with the app, which is great. The Figma itself could also include some of the future work you intended to do but didn’t have time for. | ||
|
||
|
||
For this part, you received 3.5 points out of a maximum of 4.0. | ||
|
||
## Process: Autonomy | ||
|
||
A primary goal of SwEnt is to teach you how to __function autonomously as a team__. | ||
For this part of the evaluation, we assessed you team’s independence, spanning Sprint 6 to Sprint 10, based on the meetings with coaches, Sprint planning, and how you managed risk. | ||
By this stage, coaches should no longer be necessary for the team to operate, i.e., you can organize yourselves, you don't need to be reminded about tasks, and you can conduct the Scrum ceremonies on your own. | ||
|
||
|
||
The team demonstrated excellent autonomy, making confident decisions and effectively leading the Scrum meetings. Great work! | ||
|
||
|
||
For this part, you received 2 points out of a maximum of 2.0. | ||
|
||
## Summary | ||
|
||
Based on the above points, your intermediate grade for this milestone M3 is 5.62. | ||
|
||
The entire SwEnt staff wishes you the very best in your career, and we look forward to seeing you do great things with what you learned this semester. |