Version 9, last updated by Pilus at July 16, 2011 05:55 UTC
The Gryphonheart Project base – Assembla
The Gryphonheart Project are growing and we have started using more professional tools and methods in our development. The most important tool is our project base, hosted by Assembla. Most of the relevant information is available here and it can be reached directly as www.gryphonheart.org
SCRUM
The Gryphonheart AddOns are currently being developed using the agile development method SCRUM. In short it means that we work in short periods of time, called sprints and work following the agile manifest of not relying on heavy documentation. It is our goal to being able to develop faster and get feedback from the community to contribute to the shaping of the product. Two core elements of the way we use scrum are the cardwall and the scrum standup reports. More about those can be read in the following sections.
Milestones
Each sprint we work in is shown as a milestone in the project base. The milestone / sprint is normally equal to one public test or full release. It got a target deadline and a certain amount of tickets under it.
Tickets and the development process
The tickets can be seen as task. Each got information and instructions about what should be achieved or done. The tickets have several parameters and can be everything from a bug, to implementation of an improvement or development of a part of a new feature. he tickets are a core tool for the development process and they are best shown on the cardboard. At the cardboard all open tickets can be seen, sorted by category. As work progresses the tickets changes from one status to another. Sometimes they are also changed from one responsible team member to another. The status of a ticket and the responsible field is very important. The following are some explanation of the development process, and what happens as the status of a ticket is changed.
New |
When the ticket is created it is initially set as the status ‘New’. It needs to be accepted by another team member before it can move to ‘Accepted’. This acceptance is both a control of the technical content of the ticket as well as the quality of the information supplied. In most cases these tickets will be assigned to the team member who will be validating the ticket. If the ticket is not accepted it is set to invalid |
Accepted |
The accepted state is where most tickets are placed while they wait for someone to pick them up and work on them. This is one of the only states where the ticket should not have anyone set as responsible. When a team member wants to start work on a ticket he/she assigns the ticket to himself/herself and change the status to ‘In Progress’. If the ticket can not be started when it is set to accepted, because it requires another ticket to be completed first, it is moved to the status ‘Waiting for other ticket’ without anyone responsible. |
Waiting for other ticket |
The status of ‘Waiting for other ticket’ is for tickets that are awaiting the completion of other tickets because they depends on those tickets being completed. Once all the other tickets the given ticket depends on are completed (status fixed), the ticket can be moved into Accepted. |
Invalid |
The tickets that are declared invalid can be reopened by setting their status to new. This would typically happened if there is a reason to re judge a suggestion or if a rejected bug gets some new information confirming it. |
In Progress |
The status for tickets that are currently being worked on. When a ticket is complete and the result committed to the repository, it can be set to the status ready for test and preferably with another team member as responsible. It is crucial for the validation that another person tests the solution instead of the person creating it. If a team member reached a problem that stops the process to continue, the ticket can be set to the status ‘stuck’, with no one as responsible. |
Stuck |
If progress can once again continue or another team member attempts to solve the problem, the status can be changed from stuck to ‘In Progress’. The responsible should be the member working on the ticket now. |
Ready for test |
When the solution is tested, it can either be accepted or be failed. If accepted, it is set to status Fixed, with no one responsible. If it failed, it is set to ‘failed in re-test’ with the team member who have lastly worked on it as responsible. Remember that test does not only have to be test in-game, it can also include review of the code. When the ticket is set to fixed, remember to check if there are tickets depending on this ticket in status 'waiting for other ticket'. These tickets should then be moved to accepted. |
Failed in Re-Test |
The solution for the ticket did not pass the test and it is awaiting the member who last worked with it. When the team member got time, it can be reopened by putting it to ‘in progress’ and work on it can continue until it is again ready for test. |
Fixed |
The end of the line. The ticket is solved and all is well. When a milestone is completed the changelog is written based on the tickets that have been fixed in the given milestone. |
Stand-Up
As we do not always work on the same time, it is not efficient for us to work in Scrum in its true form, meaning 24 hour sprints. Normally a team would have a daily scrum meeting where they report about three things:
- What have you been doing yesterday?
- What do you plan to do today?
- Are there any issues stopping you?
As a daily meeting is not possible or practical for us, you can instead fill in a scrum report about what you are doing. This is done in the stand-up tab. This should be done at least once a week, but it is great to do it more often, to share more about to progress to the other team members. You are all free to read each other’s scrum report to see what is going on at the current moment.
Away reports
To help planning and estimate the resources available for a milestone all members should note when they expect to be unable to contribute to the project. It is in other words assumed that the team member can contribute unless other information is given. Such information can be supplied in the away reports in the stand-up tab of Assembla.
Repository
The repository used is a standard SVN repository. The URL for it is available in the repository tab. The root of the repository is placed directly in the AddOns folder. This makes it possible for us to have all AddOns and Sub-AddOns in the same repository.
There are also a folder called GH Documentation. This folder contains various kinds of documents and graphs used in the development.
In regards of committing work in progress then a rule of thumb is that it is better to commit often than rare. In other words, if the changes doesn’t stop the majority of the AddOn from working, then commit your progress. This allows the other team members to follow your progress as well as review and comment your code while the progress is ongoing.