During our first week on the MA Indie Game Development course, we have been focusing on time management skills and agile development. We were presented with two popular forms of the System Development Lifecycle (the System Development Lifecycle includes all parts of development from hardware through to software and can be abbreviated as SDLC):
· The Waterfall Method
· Scrum Agile Framework
The Waterfall Method
The waterfall method was introduced by Dr. Winston W. Royce in 1970 and he was adamant that a series of rational steps be adhered to through the SDLC. Despite Agile methodologies becoming more and more popular since then, it is undisputable that this paved the way in which design practices can be more coordinated and comprehensible. Because of the rigidity of the step-by-step process, the scheduling of the stages is far easier to implement. Although with this methodology being so linear, it can leave no time or space for critical reflection, little chance of any adaptation. Especially with the added risk of the late execution of development within the lifecycle.
The steps are:
1. Plan
2. Define
3. Design
4. Build
5. Test
6. Deploy
7. Maintain
Scrum Agile Framework
Differentiating from the waterfall method due to the issues it possesses and restrictions it imposes, the Agile approach exists because the waterfall model can be deemed inflexible or unable to grant the necessity for change. In a scrum, a non-hierarchical team of seven experts specifically chosen due to their appropriate skills work together to fulfil a cohesive product vision. Job titles and roles are of no significance as the main focus is simply put on finishing the project. If the project is of greater complexity, then the practice ‘scrum of scrums’ will be implemented which is essentially the launch of additional scrum teams to help manage the workload rather than adding members to the existing team.
Twelve fundamental values are to be dedicated to in relation to the very spirit of Agile frameworks, these are:
1. To ensure customer satisfaction in the early stages and consistently through the delivery of valuable software
2. To be welcoming towards requirement changes, even in late stages of development
3. Working software is to be delivered frequently (weeks rather than months)
4. To keep a close, daily cooperation between businesspeople and developers
5. Projects are to be built around motivated individuals who should be trusted
6. Face-to-face conversation is to be the best form of communication (co-location)
7. Working software is to be the principal measure of progress
8. To ensure sustainable development and able to maintain a constant pace
9. To keep continuous attention to technical excellence and good design
10. Stick to simplicity and the art of maximising the amount of work not done
11. To demonstrate that the best architectures, requirements, and designs emerge from self-organising teams
12. Regularly, the team is to reflect on how to become more effective, and adjust accordingly
Before the Scrum Project Life Cycle can begin, there needs to be a clear product vision. As soon as a product vision is established and the team understand the aims and objectives, then a product backlog can be generated. A product backlog is a “detailed list of product features in form of user stories.” After being provided an in-depth product backlog, development can commence. A sprint backlog is formed of, as you can imagine, sprints. Sprints are effectively the product development process broken down into fragments to make the workload easier to manage and understand. Usually, these fragments or sprints are two weeks in length, but it can depend. A planning meeting will initiate the sprint of which negotiations will lead to the determination of tasks to be moved out of the product backlog and into the sprint backlog of which they will be completed in the current sprint. After a planning meeting, the sprint backlog is locked in and will not change throughout the duration of the sprint. Daily, a 15-minute meeting takes place solely to ensure that everyone is kept up to date with each other’s progress. Only three questions will be asked: what had the person managed to accomplish the day before, were there any obstructions hindering them, and what their goals are for the current day. Nothing will be delved into deeper at this point, rather any issues will be rectified in due course after being documented by the scrum master. Finally, two meetings will tie up the product development life cycle. A sprint review provides the means to go over all progress made for the duration of the current sprint and how this correlates with the goals and plans. The last of the two meetings is a sprint retrospective which simplistically, for me, is in the same ballpark as an evaluation of which the following questions should be considered: What went well, what went wrong, and what could be improved? From this point on, it all begins again.
Comments