Project management is a key part of app development in order to manage time, workloads and communicate effectively. There are many useful tools and techniques to better manage your time, which are of great interest to me as I am often ambitious with how much I can get done and come unstuck time to time. For creative app projects to be successful, especially in a commercial aspect, timeliness and project management is very key. Larger projects bring together other developers in a much more expansive and ambitious manner, these projects are where constantly practicing good project management will pay dividend. Forming a foundation of knowledge over the next modules will greatly enhance my chance of success through future practice.
System development life cycle
System development is complex and takes a variety of forms; from small and narrow in focus, to vast and diverse. The teams brings experts from a wide variety of fields and expertise together which cab sometimes be difficult to manage. The system development lifecycle, specifically the models and methodologies that the team work by, coordinates the process in a streamlined manner. The following example is the waterfall method which is a traditional approach to systems development.
Waterfall model:
This model cascades in a linear sequential manner, with no overlap through the stages. The stages are: plan, define, design, build, test, deploy, maintain.
Plan: this includes a feasibility study that draws out the strengths and weaknesses of the project, that compares the overall cost against the value gained. The stakeholders are the key here as they are those affected by the product; from investors to customers. A risk assessment is carried out at the end of the stage.
Define: Here the project requirements are locked down in and informal documents that includes context, key objectives and constraints on the project. SMART objectives are often used here in order to give an end goal to your requirements.
Design: This stage is where exploration and iteration occur as system architects explore a variety of different solutions to achieve the requirements of the project outlined in the define stage. During this stage evaluation from the stakeholders also occurs where the appropriate software and hardware are chosen.
Build: Once everyone involved has a clear understanding of the final outcome, the build stage starts. Heavy development occurs during this stage.
Testing: Whilst testing is done throughout the systems development life cycle in this specific stage testing is more intense and focused before final deployment. A set of quality standards are often referred to and evaluated. Bugs are reported and fixed with user testing, known as beta testing, is ran.
Deploy: Once all the necessary quality and user checkpoints have been passed the software is ready for deployment.
Maintenance: This is an extremely important stage where post-deployment problems are reported and fixed. Incremental checks and repairing of hardware/ software is needed to keep it running smoothly.
Evaluation and disposal are two more possible stages that go beyond the scope of the original waterfall model. Evaluation calls for a review of the project as a whole and looks to create a document of positives and negatives of the entire process. What went wrong? How can this be fixed next time? Was the product successful etc. Running this at the end of a project will make the next project run more smoothly as these issues will not occur again. Disposal refers to what happens at the end of the systems lifecycle. How is hardware disposed of and what will happen to the important information during this disposal phase. Users information and data is a valuable resource and if it ends up in the wrong hands, without the user agreeing, then this may cause many problems for the developers.
The pros of this model are the rigid structure allows for very easy scheduling of each stage and clear documentation leading to little ambiguity. Nevertheless, the cons are there is little room for reflection, changes to take place, and there is a lot of risk as development happens at the end of the lifecycle leading to little room for iteration.
Agile development:
Agile development is an approach to development that looks to tackle problems of traditional approaches. Agile is an umbrella term that refers to a number of methodologies, practices, frameworks and tools to assist in every aspect of the system development lifecycle. Agile is based on 12 simple principles that are as follows:
- Customer satisfaction by early and continuous
- Welcome changing requirements, even in late development.
- Working software is delivered frequently (weeks rather than months).
- Close, daily cooperation between business people and developers.
- Projects are built around motivated individuals, who should be trusted.
- Face-to-face conversation is the best form of communication (co-location).
- Working software is the principal means of progress.
- Sustainable development, able to maintain a constant pace.
- Continuous attention to technical excellence and good design.
- Simplicity – the art of maximising the amount of work not done – is essential.
- Best architectures, requirements and designs emerge from self-organising teams.
- Regularly, the team reflects on how to become more effective, and adjust accordingly.
Scrum:
There are a huge variety of agile methods but here we are exploring the scrum method. The term scrum originates from Rugby and in development is a metaphor for a team working together to push the project forward with a singular, unified vision.
Scrum prioritises people over processes and with a non-hierarchical, self-organised team people work together with a unified vision. This team usually consists of around 7 people with job titles and roles less important here. If a problem is too large for a single team a new scrum team is created to work alongside the new team to keep it compact.
There are two unique roles that a Scrum team need to accommodate, the scrum master and a product owner. Despite the name the scrum master is considered equal to the other members and facilitates organisational aspects of scrum practice.
The scrum master keeps the project moving forward and maintains a unified product vision throughout the entire System Development Lifecycle. If obstacles arise, the scrum master will assist the team in finding solutions. If there are any outside complications or distractions, then the scrum master will try their best to shield the team from them.
The product owner should be someone with great insight and understanding of the product, vision and the intended users. Often, the product owner is the key stakeholder for the project. They manage and prioritise the product backlog, a core list of features to be implemented by the team.
Starting each sprint the product owner chooses which feature from the product backlog that is the most important to work on. The team decides which of these to implement within the sprint and the accepted feature moves from to the sprint backlog and the team starts working. The product development stage is split into increments and a sprint is generally 2 weeks but may vary depending on the project. All the tasks for the project are stored in product backlog and are only moved to sprint backlog when they are going to be worked on, as described above. Short daily meetings make sure the team and other stakeholders are kept up to date about progress.
During the scrum each member will outline what they managed to accomplish yesterday, what they intend to do today and whether there are any obstructions holding up their progress. The scrum master supports the members in overcoming these obstructions.
At the end of the sprint, two final meetings occur where the sprint is reviewed and weighed up against the goals of the sprint. The goal here is to have a completed feature of product ready for shipping. The second meeting is a retrospective where you acknowledge where there is room for improvement. Each member is asked to reflect over the duration of the sprint and consider these questions: What went well? What went wrong? What could be improved?
Conclusion:
In my personal practice I need to start employing more agile methodologies such as product backlogs and sprints in order to keep focussed, stay on track and manage my time better, especially as project get longer and contain more peers/ stakeholders. The idea of 2 week sprints may work well to organise my time and workload. I will be looking to employ this during my projects next semester and will also explore how it is possible to alter the scrum method to suit a one person team.
Nathaniel's Creative App Journal 