• Introduction
• How are we going to organize
• Milestones and sprints
• Risk and Contingency List

In this document we will present how we will organize ourselves as a group, including all the tools with links to these that we will use. In addition, all meetings and all project sprints will be planned with all the included tasks also shown in a calendar. This calendar will be accompanied by a Gantt chart and all the milestones of the project.

In order to avoid future problems, a list of possible risks has been defined with their degree of possibility and impact with the solutions to which we would turn.

During the course of the project, we will use the union of the following two agile methodologies: Kanban and Scrum.

As a result, we plan to use ClickUp as the main tool, which allows us to keep track of the tasks to be performed, establishing deadlines in order of importance, and provides us with a shared calendar linked to a Kanban style board. The set of these characteristics, among others, provides us with the ability to maintain an updated view of the current status of the project for all team members.

In addition, we will do one weekly sprints to keep a more concrete track of all the tasks that are being done in parallel to solve possible problems that may arise during the development of each one before each build, maintaining a rate of 1 build per week. For this, we will use the Excel tool of the Google drive to distribute the tasks to be realized in each sprint based on the available time of each member.

On the other hand, it will allow us to keep a total record of the estimated and dedicated time of all the tasks performed before the current sprint and the same sprint separately, where once the current sprint is finished, these tasks go to the total registry and will be filled the sprint with the next tasks. In this way we can calculate the log of average estimation deviation automatically and we will have a reference of the time that each member spends, which will allow us to redistribute the tasks to improve the efficiency of the team.

1 grupal for the current sprint:

1 for each member:

Click here to go to excel.

For the whole process to work, it requires a great effort of communication by the team. Because of this, we plan to hold a face-to-face meeting every Wednesday from 12:00 to 15:00 in order to discuss all those questions or issues that have not been resolved. In addition, one Postmortem will be made online every Monday at 20:00 with a maximum duration of 1 hour, and one online meeting on Saturday at 16:00 with a maximum duration of one hour too, in order to see the status of each member's individual tasks in order to react according to how the project progresses.

For the Postmortems and to maintain a good communication between members, we will constantly use the Discord application and to share all the necessary documents we will use Google drive. The reasons for which we have decided to use Discord are based on the creation of a server dedicated especially to work in a group and connected among all. In addition, within this server we can create different specific channels to talk or write things in a specific and orderly way. Another feature in favor of the use of this tool is based on the possibility of sharing different screens of each member simultaneously, so that the communication problems that may arise when not doing them in person are drastically reduced. As a result, we provide personal comfort by conducting meetings at home each time reducing problems of schedules or trips to reach a meeting in person.

To reach our goal of creating Tankerfield, we have different milestones in which we have divided and classified the most important parts of our game.

As the project progresses, we will have to complete four fixed deliveries. Each delivery will consist of some tasks to be done that we will distribute among team members to complete them and get to have a final version of our game.

The duration of the project consists of 14 weeks, 2 for the Concept discovery, 6 for the Vertical slice, 4 for the Alpha and 2 for the Gold.

(Click on the photos to open them).

The objective of this first milestone is to establish and write all the information required by the following documents plus an analysis of the game from which we started. In addition, there will be a presentation with the publisher in order to attract their attention to our project and make an investment with which to create the best version of the game.

Duration: 1 week.

Content:

• Welcome Page of the wiki
• Half Game Design Document
• User Interface Document
• Art Bible
• Technical Design Document
• Production Plan

Duration: 1 week.

Content:

• Quality Assurance Plan
• Audio Bible
• Analysis of the original game
• Finish Game Design Document
• Pitch
• Revise and correct the wiki.

The elements of which this milestone consists are based on all those elements necessary to make a playable version of our project to check how good the initial idea is. From there, tests will be carried out to enhance the elements that work and eliminate or change those that do not.

Duration: 1 week.

Content (Build 0.0):

• All Modules and functions we will needed.

Duration: 1 week.

Content (Build 0.1):

• Gamepad Controller .
• Player Control.
• First version of basic enemy.
• Isometric testing map.

Duration: 1 week.

Content (Build 0.2):

• First map version.
• enemy movement with pathfinding.
• UI in game.
• Game loop.

Duration: 1 week.

Content (Build 0.3):

• Diferent enemies.
• Cooperative.
• Splitscreen.
• First IA and behaivor of enemies.

Duration: 1 week.

Content (Build 0.4):

• First skills and bonuses.
• First Boss.
• Progressive difficulty.
• All menus.

Duration: 1 week.

Content (Build 0.5):

• Tutorial.
• leaderboard + Score.
• Test and polish.

This milestone aims to develop all the remaining elements of the game and create a very advanced version with everything that will include it, after having made an intense phase of testing.

Duration: 1 week.

Content (Build 0.6):

• All skills.
• All bonuses.
• Adjust the mechanics with the feedback we’ve received from our first playable demo.

Duration: 1 week.

Content (Build 0.7):

• 2 Vehicles.
• 2nd map.
• All enemies .

Duration: 5 days.

Content (Build 0.8):

• Last vehicle.
• Skippable cinematic.

Duration: 2 days.

Content (Build 0.9):

• Test cooperative with all tanks.

Duration: 1 week.

Content (Build 1.0 Alpha):

• Test All.
• Presentation.

Once the Alpha of the game is done, nothing new will be implemented that could influence the gameplay of the game. It will focus especially for this milestone in correcting those bugs that may arise or that have been dragged. The last phase of testing will also be carried out, from which the final version will be released.

Duration: 1 week.

Content:

• Adjust with the feedback we’ve received from our Alpha.

Duration: 1 week.

Content (Build 1.0 Gold):

• Last test and polish.
• Prepare the presentation.

To avoid possible cases that may interfere negatively with the development of the project, we have created a list of all the risks that may arise with the most optimal solutions to prevent how we will react to these cases.

The consequences of each problem that may arise will not be the same, and their probability of occurrence will vary depending on several factors. therefore, we have established a degree of probability and impact of its consequences on the project for each risk based on the following interval:

• Very Low
• Low
• Medium
• High
• Very High

Risk	Probability	Impact	Solution
A team member decides to leave the team.	Very Low	Very High	their work and responsibilities will be redistributed among the rest of the members.
A team member can not advance their work or is limited for personal reasons (e.x. disease).	Medium	High	he or she will contact the leader or management to determine the extent to which you can complete and distribute the remaining tasks among the team members.
A team member can not advance their work or is limited for technical reasons (e.x their computer stops working).	Low	Medium	An attempt will be made to find a solution to the problem and until it is solved, the computers of the university will be used in the time they are available. Depending on the situation, tasks that can not be carried out must be redistributed.
The objectives established by the sprint have not been completed.	Medium	Medium	Depending on the time available and the reasons, the delivery time will be extended and, if necessary, what is missing among the team members will be redistributed.
The objectives for a milestone have not been completed.	Low	Very High	The unrealized objectives will be in top priority and will be redistributed among team members.
A team member can not participate in the meeting.	High	Very Low	This will contact the leader or managment to communicate the points of the meeting and the conclusions drawn.
A member who must appear in a presentation does not arrive on time.	Low	Medium	In the case that a member can replace it, it will be done. If this is not the case, the leader will be responsible for presenting his part with the key information.
The build that has been formed is not valid.	Very Low	Very High	In order to avoid that the delivery build is incorrectly formed, we will leave a margin of time to ensure that it is valid and previous versions will be delivered in case the final one is not delivered correctly.
The game is not balanced, so it's not fun.	Low	High	Before each delivery will be left a long period dedicated to the testing and balancing of the game without implementing new factors that affect the gameplay that are not tested.
Some team members do the same job because of confusion.	Very Low	Low	At the beginning of each sprint, each task that each member must carry out will be detailed and the status of each task will be reviewed in the meetings.
A member of the team unintentionally modifies the work of another member negatively.	Low	Medium	We will use Branching policy to avoid the problem.
A member finishes his or her part and runs out of tasks to do.	Medium	Very Low	That member will help in the tasks of the rest that are more backward. If it is not necessary, the next task will begin, even if it is not within the current sprint as long as it has been confirmed by the leader that his task is well done.
An important bug causes a stoppage in the development of a task or several, affecting the development of the project.	High	High	First, the person in charge of QA will be informed, who will be responsible for choosing which members will be necessary to solve the bug according to its importance.
Some member of the team can not continue their task because it is necessary to finish another task of another member.	Medium	Medium	The member who can not progress will help the task that needs to be completed.
Poor code optimization influences the speed of the game and does not go to the one that should.	Medium	Medium	the responsibles for code will have as a priority to fix this problem.
The writing of the code of each member is different and interferes negatively in the development process.	High	Low	In the TDD is established the way in which the code should be structured and written to avoid similar problems or derivatives.
A team member has difficulty doing his or her task.	High	Low	This member will communicate with the leader and decide who will help or how tasks will be redistributed.

---