Reflections on Alpha Stage Issues of team Witness Paradox

Which course does this assignment belong to	EE308
Where are the requirements for this assignment?	Requirement of this project
Team Name	Witness Paradox
Reference documents	CSDN, 《构建之法》

1. Vision and objectives

1.① What problem is our software trying to solve? Is it clearly defined? Is there a clear description of typical users and typical scenarios?

Our software is designed to develop a first-person, puzzle-like 3D game. The definition is relatively clear, but there is room for improvement in describing typical users and typical scenarios.

1.② Did we achieve our goals (how many of the planned features did we achieve? Were they delivered on schedule?)

We have completed most of the planned features, including core functions such as task management, team collaboration, and progress tracking.
We have successfully delivered the first version of the software on time according to the original delivery schedule.

1.③ Has the quality of the team’s software engineering improved compared to the previous phase? Where, by how much, and how can it be measured?

In the previous phase, we focused on the functional implementation and basic stability of the software, while in this phase, we focused on improving the code quality and maintainability.
Through the introduction of code review process and strict implementation of code specifications, our code quality has improved significantly.
In terms of measurement, we use static code analysis tools and code review metrics to assess how much code quality has improved.

1.④ Is the number of users and the acceptance of important features consistent with our expectations? Are we closer to our goal?

At present, the number of users is gradually increasing, but there is still some gap compared to the initial expectation.
User acceptance of important features is generally in line with our expectations, and they have given positive feedback on task management and team collaboration features.
While we are getting closer, there is still some room for improvement, particularly in terms of user growth and satisfaction.

1.⑤ What are the lessons learned? If history were to be repeated, what improvements would we make?

Lesson learned: Define typical users and scenarios in more detail before the project starts to better meet user needs.
If history were to be repeated, we would pay more attention to user research and feedback to better understand user needs and adjust product direction and feature development plans in a timely manner.

2. Planning

2.① Is there enough time to plan?

We spent enough time in the planning phase, but there was some time pressure later in the development phase.

2.② How did the team resolve the differences between colleagues on the plan during the planning phase?

In the planning stage, we organized several meetings for team members to put forward their opinions and suggestions, and discussed and weighed them
Eventually, through consultation and compromise, we reached a consensus and made the final plan.

2.③ Did you end up getting all the work you planned to do? If you didn’t get them done, why?

Most of the work that was originally planned was completed, but there were some minor features and improvements that were not completed in the scheduled time.
This was mainly due to some technical challenges and priority adjustments encountered during the development process.

2.④ Ever find that you did something that in hindsight wasn’t necessary or didn’t have much value?

During the review process, we found that some features were developed and improved that may not have brought much value in actual use.
This is a valuable lesson, and we will pay more attention to the value and priority of features in future development.

2.⑤ Is there a clearly defined and measured deliverable for each task?

Most tasks have clearly defined and measured deliverables, but on some of the more complex tasks, there can be some ambiguity and uncertainty.

2.⑥ Did the entire process of the project go according to plan, and what went wrong with the project?

Most of the project went according to plan, but there were some technical difficulties and requirements changes during the development process.
These unexpected circumstances increased the investment of development time and resources, which had a certain impact on the project schedule.

2.⑦ Did you leave a buffer zone in your plan? Did the buffer zone work?

We have left some buffers in our planning, which are useful for dealing with unexpected situations and changes in requirements.
They have helped us to adjust the project schedule to some extent to meet changing needs and challenges.

2.⑧ What changes will be made to future plans?

In future plans, we will further optimize the definition and management of buffer zones to better cope with uncertainties and risks in projects.
At the same time, we will pay more attention to the work load and reasonable arrangement of team members to avoid excessive overtime.

2.⑨ What did we learn? If history were to be repeated, what improvements would we make?

Make more plans, let students in different departments cooperate better, and try not to work overtime.

3. Changing management

3.① Has everyone involved been informed of the change in a timely manner?

We made sure that all relevant employees were informed of the changes in a timely manner.

3.② What method do we use to determine “deferred” and “must implement” features?

We conduct a comprehensive needs assessment and prioritization to determine how important different features are to our users. Based on these assessments, we also consider technical and resource constraints and conduct feasibility analyses to ensure that features can be completed within a reasonable timeframe and that decisions to delay or require a feature are based on adequate analytical considerations.

3.③ Are Exit Criteria (what is “done”) clearly defined for the project?

The exit criteria for the project are to ensure that we have met the predetermined objectives and that the software has been completed and meets the specified criteria. Our definition of successful project completion is very clear and specific, and these definitions are determined based on specific criteria.

3.④ Do you have contingency plans for possible changes?

We have the ability to plan for temporary changes. We will pay close attention to the changes in requirements and flexibly adjust the contingency plan according to the actual situation to ensure that the task is fully and efficiently completed.

3.⑤ Are employees able to effectively handle unexpected work requests?

We focus on communication and collaboration to ensure that employees are able to support and collaborate with each other to cope with unexpected work requests. Each employee is able to effectively handle all kinds of unexpected work requests and make positive contributions to the development of the team.

3.⑥ What did we learn? If history were to be repeated, what improvements would we make?

Through this project, we not only learned skills and knowledge like unity, but also the importance of teamwork, the value of innovative thinking, and the ability to respond flexibly to challenges. If we had the opportunity to do it over again, we would further strengthen communication and coordination to ensure that everyone can leverage their strengths to improve the efficiency and results of the project. We will always maintain a learning and improving attitude to continuously enhance the capabilities and value of our team.

4. The role of the team, management, cooperation

4.① How is each role of the team determined? Is the team fully capable?

Work is assigned according to each person’s abilities and strengths.

4.② Do team members help each other?

Members pay attention to cooperation and mutual assistance.

4.③ When there are problems in project management and cooperation, how do team members solve the problems?

Communicate and negotiate in a timely manner to seek consensus, and solve conflicts and problems in a timely manner to achieve the smooth progress and completion of the project.

5. Design/implementation

5.① When and by whom did the design work take place? Was it the right person at the right time?

The team leader will assign tasks at the start of the project and adjust them according to the actual situation.

5.② Did the design work encounter ambiguities, and how did the team resolve them?

Yes, we will evaluate and weigh various factors, actively discuss to find the most suitable solution, and finally achieve a satisfactory result.

5.③ Did the team use unit test, test-driven development (TDD), UML, or other tools to help design and implement the solution? Are these tools effective?

Our team uses unit testing, test-driven development (TDD), UML and other tools to help with design and implementation. These tools are very effective in ensuring code quality and improving system stability and maintainability. Unit testing and TDD help to identify and resolve problems early, reducing the risk of code changes and refactorings, while UML helps team members better understand and communicate design scenarios.

5.④ How is the Code Review conducted and is the code specification strictly enforced?

When our team conducts the code review, we will strictly abide by the code specifications and carry out the review according to certain procedures. First of all, it will be checked and evaluated by personnel with relevant abilities, and suggestions will be made in time after problems are found, and then modifications and improvements will be made.

6. Test/release

6.①Does the team have a test plan? Why not?

Aye.

6.② Have formal acceptance tests been conducted?

Aye.

6.③ How does the team measure and track the performance of the software? Were the tests useful in terms of the actual performance of the software?

Teams use performance testing, user analytics, and more to measure and track the software’s performance. These tests are very useful to help the team find and solve performance problems in a timely manner, optimize system performance and improve user experience.