Waterfall used to be such a predominant collaboration model in software development, that I learned it on textbook in University. Numerous advocacies arose to challenge that.
Mary and Tom Poppendieck borrowed the lean methodology into the context of software development (reference: Lean Software Development: An Agile Toolkit) in 2003. The “Lean Manufacturing” methodology evolved from TPS (Toyota Production System), with the objectives of eliminating overburden (muri), inconsistency (mura) and waste (muda). In 2006, Mary and Tom further their thoughts (in their book Implementing Lean Software Development) with seven principles in software development, with eliminating waste as the core.
Another initiative to challenge traditional waterfall model is the Agile manifesto, published in 2001 that outlines 4 values and 12 principles.
DevOps is a continuation of these movements. In 2009, the “10+ deploy per day” speech by John Allspaw and Paul Hammond in Velocity 09 conference, marks the start of DevOps:
Other milestones includes the publish of the book the Phoenix Project in 2013, and later the DevOps handbook in 2016. At the time agile is adopted within development, and sometimes within operations as well. DevOps calls for a holistic agile approach across the boundary between Devs and Ops. So DevOps does require a working organization structure, as well as some tools in the process, such as:
Influence Map
Too much effort is made on building functionalities, while missing business goal. Influence map ensures that you do not get lost in the functionality during analysis.
User story
In a holistically agile approach, different roles in development must come to consensus on the requirements. With traditional document, developer, quality, product manager form different perspectives about requirement. We break requirement down to user stories, which allows all roles in SDLC to reach consensus on the user requirement.
Kanban
We also need all roles in development and operations to access the same information about workflow status. With Kanban, the followings are visualized
- Work items
- Delivery progress end-to-end
- Bottlenecks
It helps the team to limit the number of items in-progress, understand the movement of items during standup, and focus on the bottlenecks.
Non-functional requirement
The FURPS+ model breaks requirement into several categories, such as Funcionality, Usability, Reliability, Performance, Supportability. Common metrics of non-functional requirement include:
- Throughput: TPS (transactions per second), QPS (queries per second), and RT (response time)
- Reliability: MTTF(Mean Time to Failure), MTTR (Mean Time to Repair), MTBF (Mean Time Between Failure)
- Scalability: as workload increases, throughput and reliability should not deteriorate.
We also have SOLID principle in object oriented design, and IDEALS principle in micro-service development.