Kanboard
The Velandel Staff is working with an Agile Methodology using the KanBan method, associated with Kanboard, created by F. GUILLOT. The KanBan method allows us to be more reactive, agile and increases the communication among the team. Moreover, this method allows us to know who is working on what and follow the evolution of every new feature.
Our team contains few people so we tried to adapt the KanBan method to fit our constraints.
It is important to use the Kanboard effectively and we have set some rules to make its use easier.
The most important is: "For everything you are working on, you must have a task associated to it."
This rule is very important because it allows us to know what everybody is doing and what has already been done in the project. But first of all, you have to understand how a Kanboard works.
As you can see on the previous picture, a task is an element of the Kanboard that contains all the information you need to develop a new feature or enhance an existing one in the game. Keep in mind that one task always takes one slot in the column on the kanboard, and columns have a limited slot value. Also, you have to understand that once a task is created it must be done. You should always think twice before creating a new one.
New let's take a look at the elements that a task contains.
| Element | Description |
|---|---|
|
|
This is the Task ID. Every ID is unique so you can not have two tasks with the same ID. This element is used by the Database. |
|
|
On the right of the Task ID, you will find the name of the assigned developer. This person is currently working on this task. |
|
|
This is the Category of the task. It is useful to understand the general scope of the future. Also, you can use that to find or sort tasks which belong to the same category. Please note that the category automatically attributes a color to the task. |
|
|
This flag shows that this task is very important for the project. It represents an hard goal to reach. |
|
|
This is the complexity level of the task. The complexity level should be set between 0 for easy tasks and 5 for really hard tasks. |
|
|
This represents the developement of time (left) versus the estimated time (right). The estimated time is given by the developer who creates the task in order to have an idea of how much time we should spend on this task. The developement time is the actual time all developers have spent on the task. |
|
|
This symbol represents the number of linked tasks to this one. If you hover the mouse over that, you will see which tasks are linked to this one with the kind of link. |
|
|
This is the Sub-tasks progressions. A task can be divided into many sub-tasks. When all the sub-tasks of a task are finished, the value of the progression is set to 100%. Please note that if you hover the mouse cursor over this symbol, you will see all the sub-tasks associated to the task. |
|
|
Here you can see the number of comments attached to this task. Comments can be information, questions, or simply a discussion between developers regarding this task. |
|
|
This element can be hovered over by the mouse to display on the screen the detailed description of the task. |
|
|
This can be called the TimeLine of the task. On the left, you can see the time elapsed since the creation of the task. On the right, you have the time that has passed since the last movement of the task (from a column to another). If you substract the two values you will obtain the elapsed time between the creation of the task and its current position on the board. |
|
|
This is the priority of the task. The priority can be set from P0 (low priority) to P3 (high priority). We usually set priority to 0 except if we encounter a bug or if a task is prioritized by the specifications of the sprint. |
Swimlanes are different sections (lines) for the project. When you create a new task, you have to choose which swimlane you want to put it in. They are 4 differents swimlanes with associated tasks in our project.
-
Emergency Swimlane:
We must try to avoid this swimlane as much as possible. This swimlane contains tasks that requires all of the developers of the project as a task force. It is used to create a task when we have a major production bug that requires to be fixed as fast as possible. -
Project Swimlane:
This is the basic swimlane of the project. This swimlane is used by developers. It contains all tasks that are attached directly to the game. -
Environment Project Swimlane:
This swimlane is a little bit special. It is a swimlane made by developers for developers. Here, we create tasks that allow us to enhance the environment of the project which is associatated to our tools, or the server or the Kanboard itself. These tasks are very importants because they aim to help us in the project swimlane. -
Modelisation Swimlane:
This swimlane is reserved for our graphic designers. It contains all tasks directly linked to the 3D models, animation, textures etc.
When you create a task, please be sure to put it in the correct swimlane. This is very important because some tasks will not be treated (a dev' may never take a look at the Modelisation Swimlane for example).
Columns are the different steps that a task must pass to be closed, in accordance with the KanBan method rules. Some columns have limited slots to keep control on what we are doing. You should never add a task to a column that has already reached its maximum threshold. They are 7 different swimlanes with associated tasks in our project.
-
Waiting: Unlimited Slots
This column should be the starting point of all our tasks. A task in this column was created little time ago and we should talk about it. Some "obvious" tasks such as bug fixes or minor fixes can be switched from Waiting to Ready immediately but this should not become usual. -
Ready: 5 Slots
Tasks in this column are ready to be developed. It has enough elements in the description to be understadable easily and it is a usefull task for the project. -
In Development: 5 Slots
At this point every task must have someone assigned to it. A task in this column is in the development process. -
Tests: 3 Slots
Tasks in this column are currently in a kind of unit test. You should try to test your fresh feature with the fewest possible elements in order to understand why it is working so well! -
Comments: 3 Slots
The Comments column is probably one of the most important. It allows us to have free official time to comment our code. What a wonderful idea, don't you think? Keep in mind that comments are key in the development process. It allows us to be very effective. -
Pre-Production: 1 Slot
The Pre-production column is a little bit harder to understand. It contains tasks that are tested in the production scene. In that way, we can see how a new feature is interacting with all of the elements of the game. This column can only contains one task. The idea is to have a maximum of control over the test. The fewer features you are testing at the same time, the fewer side effects you will encounter. Please, try to respect this rule and only test features one by one in this column. -
Finished: Unlimited Slots
Tasks is this column have finished their courses. You should close these tasks only once they have been approved in a pull request on git. Good job! A good practice is also to wait for the Weekly Meeting before closing a task. In this way, we can all see what we did during the past week.
Keep in mind that a task must start its life in the Waiting column and end it in the Finished one. It also must cross all the column and can not come back to one of the previous column it has already crossed. The kanboard is a oneway road, from left to right.
We also have simple rules to describe the Life Cycle of Tasks in the section below.
Keep this question in mind when you create a task: Is it really useful? Our objective is to have as many tasks as possible but theses tasks must have a real interest inside the project. Then, think about the scope of your task: is it too large? Is it too small? We usually try to create tasks that are achievable in 1 to 20 hours.
- If your task is smaller, try to think how you can include it into another task.
- If your task is bigger, try to split it into smaller tasks.
Finally, you should always keep in mind that freshly created tasks should stay in the "Waiting" column until we decide together to start them.
For more information, please read how to Create tasks and sub-tasks page.
The life cycle of a task is really easy. Once created, it passes through every column, from the "Waiting" one to the "Finished" one. Every time you switch a task from a column to the next one, you let the entire team know that your reached the objective of the column it was placed in. These objectives can be decribed as follows:
-
Waiting --> Ready:
The team decided that this task is useful and ready to be developed. It has enough elements in the description to be completed with no issues. -
Ready --> In Development:
You decided to take this task and develop it. -
In Development --> Tests:
You finished developing the feature and now you are ready to test your feature in a closed space (personal scene) with the fewest elements possible. -
Tests --> Comments:
All your tests have succeeded, your are now ready to comment your code. A good practice is to comment every Class and every method. Try to not put comments inside code blocks. -
Comments --> Pre-Production:
You finished commenting your code. Now you are ready to test your feature within the entire game. Please remember that if you encounter an error during your tests or your pre-production tests, you can update your code without making the task go back to develop. Remember that a task should never go back on board. -
Pre-Production --> Finished:
Your task is over and you made a pull request on Git with this task inside. Do not mark the task as finished until the pull request is approved by the team.
For more information on the use of the KanBoard, please follow the following links 👍
- Tasks evolution over time - Warning: Broken Link: Work in progress
- Link, Promote and Comment your tasks
The Kanboard was designed to work in team. But you have to keep in mind some elements to work effectively with your co-workers.
-
Be Explicit: When you create or work on a task, please add as many details as you can. If someone else is going to work on this task they must have all the elements they need to be efficient.
-
Work Together: If you see that a co-worker is working on something you worked on, ask if they need help. Try to be aware of everything other people are working on by taking a look at every task and every comment.
-
Think about tour coworkers: When you are working on a task, you are taking a slot in a column. Be sure that you are in a the right column and do not begin several tasks at the same time. In this way, the board won't be blocked and everybody will have enough space to work in every column.
-
Make it Live!: If Unity and Git are like the Heart and Brain of this project, we can say that the Kanboard is its lungs. We can not make this project live if the Kanboard is dead. Make it live, create tasks, make them move and communicate with comments and chat to make sure we are moving in the right direction.