Software Development Life cycle - vox-populi-mds/off-da-railz GitHub Wiki
Gary Buyn : 04/04/13 : Created
The requirements are written in the form of user stories. Each story is a single sentence that describes who, what and why e.g. "As a , I want <goal/desire> so that " (although it may have more information, it must include at least this).
The development timeline is split into sprints, typically 2-4 weeks long. At the start of each sprint, user stories are chosen from the product backlog (outstanding user story list) and planned for development during that sprint by adding them to the sprint backlog. At this stage they are split into smaller tasks which are then assigned and completed over the duration of the sprint. At the end of each sprint, the product should be stable. Any tasks that remain incomplete at the end of the sprint will be left out of the product and delayed to the next sprint (or possibly to an even later sprint if other more urgent tasks were added to the product backlog).
Progress is monitored using burndown charts and team members give daily reports during a standup meeting which include what they did yesterday, what they are going to do today and any problems they are having. The meeting is run by the scrum master (the team leader) who uses the information to engage people external to the team to solve any problems, balance the workload in response to tasks going over or under their expected duration and generally do whatever he can to keep the rest of the team working efficiently.
User stories and tasks will be prioritized as ‘must have’, ‘should have’ and ‘nice to have’.
A planning meeting will be held at the start of each sprint where the team, led by the scrum master, will divvy out the user stories. The team member that is assigned the user story will have to refine the requirements as part of the sprint and this should be accounted for when estimating effort.
All of the programmer members of the team have already been trained in the Scrum methodology. This avoids the overhead of teaching everyone how the methodology works which could be quite significant in such a short project.
To test gameplay as soon as possible prototypes should be available early and often. Scrum's sprints are perfect for this task. We will be using 2 week sprints to give us prototypes more often. There are many nice-to-have features of the game that have not been included in the plan below. Scrum is able to accommodate such features by simply creating a user story with a low priority. Since planning and refinement of requirements is not done until the user story is planned to be included in a sprint, the features will have negligible requirement gathering overhead unless we actually have time to implement them.