From this weeks material I learnt the key phases of the System Development Life Cycle (SDLC), two different approaches to application development; Waterfall and Agile, and reflected on how I make my applications and what I could do better.
An Agile approach is largely considered to be the best method of developing software. For the reasons that it allows for a constantly evolving development cycle that provides a focused and rapid delivery of an application. In other words, It creates the most “bang for your buck” in as short as time as possible whilst project requirements are changing.
Over the last 11 weeks I have been learning to apply the 12 simple principles of the agile manifesto to my app development so that I can be a more efficient and agile developer as well as providing greater career prospects for the future, as many companies now implement agile methodologies. For example my full time employee ETC uses Scrum to develop software for its consoles and applications.
- Customer satisfaction by early and continuous delivery of valuable software.
- 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.
Some principles I have been unable to develop at this time as they relate to working in a team. I have though been able to work on becoming better at planning and communicating my work, which would help with team collaboration in the future. The methods I have applied have been a collaboration of Scrum and Kanban methodologies.
Tying this to my current projects, I can see that I am good at acquiring detailed user stories, working in an agile, iterative manor but I lack the broader strokes of managing a product and developing “epics” which focus on the business strategy. I will often develop areas of my application to which I find most interesting or personally challenging. For example, just yesterday, instead of working on a feature which allows multiple users to interact with my application Stamp, I looked to implement an idea from a user. The featured would add great value to the application and is an interesting project to work on but does not relate to the broader overarching development I need to achieve with Stamp, gaining more customers. I need to not only define customer user stories but those of my companies that reflect the mission and business strategy. I need to develop these strategies into epics and stay rigid to the work I do towards them within the allocated sprints I set myself. I must not deviate to user stories that are of more interest to me as developer.
- Specific - Conduct a session of planning, categorising all of Stamps current user stories. Plan and order “epics” with regards to both user and business strategy. Develop a two week sprint that corresponds with the tasks that need to be done to complete the currently scheduled epic.
- Measurable - Each task should be categorised where possible and 3 epics that will span the next 6 months of development.
- Attainable - Use GitKraken Glo Boards to organise the user and company stories categorising them by using the labels feature.
- Relevant - Provide a clear plan of action that should deter from deviation but remain flexible to changes at each two week sprint interval.
- Time-Based - By the end of the next study block.