Add reflection content

docs/source/project/management/study_project/reflection.rst

@@ -4,5 +4,14 @@
 Reflection
 ==========
 
-TODO: add content...
+Black Fennec version 1.0 is soon to be released, and it's a good time to look back and reflect on our achievements. We were able to reach our goals through careful planning.
 
+In the previous project, we found that using a full-fledged Scrum approach with two-week sprints that we only worked on one day per week was excessive and had a lot of unnecessary overhead. As a result, we streamlined our project management process and extended our sprints to three weeks. This change worked out exceptionally well and allowed us to accomplish significantly more during this project compared to the previous one.
+
+At the start of the project, we had plenty of time to dedicate to Black Fennec and were determined to stick to our project plan by focusing on maintaining the scope rather than the timeline. However, as we prepared for a presentation about the project in the "Project Management and Quality Management" module, we realized that we had been spending too much time on Black Fennec and decided to reduce our efforts. We adjusted the timeline instead of the scope and made up for the overtime. At the same time, we also had many other modules to attend to, many of which were evaluated during the semester. We significantly underestimated the amount of time they would require.
+
+Fortunately, as we gained familiarity with the technologies and codebase, the time needed to implement changes or features decreased over the course of the project. This allowed us to maintain the original scope and timeline without needing to adjust either.
+
+We believe that the time required to make changes to the codebase is highly correlated with the maintainability of our code. As we progressed with refactoring, which we did to a large extent at the beginning of the project, it also influenced the time needed. These refactoring efforts would not have been possible without our rigorous testing.
+
+That's why we place a high value on test coverage. It required discipline to write test cases for every path in every function we wrote or modified, but we motivated each other through code reviews and a definition of done that emphasized good coverage. The rewards of this effort were well worth it, as effective and efficient refactoring allowed us to make significant improvements to large parts of the application. Without these efforts, it would have been impossible to push the boundaries as far as we did.
\ No newline at end of file