In the early days, there was no specific management process for software development. Then came the waterfall development process (Waterfall), which proposed that software development activities can be defined by the time spent developing and building applications.
At that time, because there were no review links and trade-off considerations in the development process, it often took a long time to develop, test, and deploy software. The delivered software is also poor quality software with defects and bugs, and the delivery time does not meet the requirements. At that time, the focus of software project management was on long-term and protracted plans.
The waterfall process is related to the triple constraint model, which is also called the project management triangle. Each side of the triangle represents one of the three elements of project management: scope, time, and cost. As Angelo Baretta writes, the triple constraint model “thinks that cost is a function of time and scope. These three constraints interact in a definite and predictable way... If we want to shorten the timetable (time), we must increase the cost. If we want to increase the scope, we must increase cost or time."
The transition from a waterfall process to agile development
The waterfall process comes from the production and engineering fields, which are suitable for linear processes: just as the supporting wall needs to be built before the roof of a house. Similarly, software development problems are believed to be solved by planning ahead. From beginning to end, the development process is clearly defined by the roadmap, and the final delivered product can be obtained along with the roadmap.
In the end, the waterfall model is considered to be unfavorable for software development and counterintuitive, because the value of the project is usually not reflected until the end of the development process, which leads to many projects eventually failing. Moreover, the client cannot see any working software before the end of the project.
Agile uses a different approach. It abandons planning the entire project, promises an estimated time point, and simply follows the plan. In contrast to the waterfall process, it assumes and embraces uncertainty. Its philosophy is to respond to changes instead of discussing the past, and it believes that changes are part of customer needs.
Agile is endorsed by the Agile Manifesto, which defines 12 principles (LCTT Annotation: The original abbreviated sentence of this article is not used here, but an excerpt from the official Chinese translation of the Agile Software Development Manifesto):
1. Our most important goal is to satisfy customers by consistently delivering valuable software early.
2. Facing changes in requirements happily, even in the later stages of development.
3. Deliver working software frequently, a few weeks or one or two months apart, and tend to take a shorter cycle.
4. Business people and developers must cooperate, and every day in the project is no exception.
5. Stimulate individual fighting spirit and build projects with them as the core. Provide the required environment and support, supplemented by trust, to achieve the goal.
6. Face-to-face communication is the best and most efficient way to convey information.
7. Working software is the primary metric of progress.
8. The agile process advocates sustainable development, and the responsible person, developers, and users must be able to maintain a stable and continuous pace.
9. Persevere in the pursuit of technical excellence and good design, which enhances agility.
10. Based on simplicity, it is the art of reducing unnecessary workload.
11. The best architecture, requirements, and design come from self-organizing teams
12. The team regularly reflects on how it can improve effectiveness, and adjusts its behavior accordingly.
The four core values of agile are:
• Individuals and interactions are higher than processes and tools
• Working software is above detailed documentation
• Customer cooperation is higher than contract negotiation
• Responding to changes is better than following a plan
This is the opposite of the rigid planning style of the waterfall process. In an agile process, the customer is a member of the development team, not just participating in the definition of project requirements at the beginning of the project, and accepting the final product at the end of the project. The client helps the team complete the acceptance criteria and keeps input throughout the process. In addition, agile requires changes and continuous improvement throughout the organization. The development team works with other teams, including the project management team and the testing team. What to do and plan when to do it is led by a designated role and agreed upon by the entire team.
Agile software developmentAgile software development requires adaptive planning, evolutionary development, and delivery. Many software development methods, frameworks, and practices follow the agile philosophy, including:
• Kanban (visual workflow)
• Xtreme Programming (XP)
• Lean Method (Lean)
• Feature-Driven Development (FDD)
• Test-Driven Development (TDD)
• Crystal method (Crystal)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
All of these have been used individually or together to develop and deploy software. The most commonly used are Scrum, Kanban (or Scrumban), and DevOps.
Scrum is a framework. The team that adopts the framework is usually composed of a Scrum coach, product manager, and developers. The team operates in a cross-functional, autonomous way of working, which can speed up software delivery and bring huge business value to customers. The focus is on fast iterations in smaller increments.
Kanban is an agile framework, sometimes called a workflow management system, which helps teams visualize their work to maximize efficiency (and thus become agile). Kanban is usually presented by a digital or physical display board. The work of the team moves with the progress on the display board, for example, it is never started to in progress, until it is tested and completed. Kanban allows each team member to view the status of all work at any time.
DevOps valuesDevOps is a culture, a state of mind, a way of software development or infrastructure, and a way of building and deploying software and applications. It assumes that there is no barrier between development and operation and maintenance. They work together and there is no contradiction.
DevOps is based on practices in two other areas: Lean and Agile. DevOps is not a position or role within a company; it is an organization or team's persistent pursuit of continuous delivery, continuous deployment, and continuous integration. Gene Kim (the author of the Phoenix project and the Unicorn project) believes that there are three ways to define the philosophy of DevOps:
• The first type: process principle
• The second type: feedback principle
• The third type: the principle of continuous learning
DevOps software developmentDevOps does not arise out of thin air; it is a flexible practice, and its essence is a shared culture and way of thinking about software development and IT or infrastructure implementation.
Authors of "Accelerating the Construction and Expansion of High-Performance Technology Organizations," explained:
Software delivery ability is very important, it greatly affects the results of the organization, such as profit, market share, quality, customer satisfaction, and the achievement of organizational strategic goals.
Excellent teams can achieve high delivery, stability, and quality; they do not make trade-offs in order to obtain these attributes.
You can improve your capabilities by implementing practices in Lean, Agile, and DevOps.
Implementing these practices and capabilities will also affect your organizational culture, and will further improve your software delivery capabilities and organizational capabilities.
Knowing how to improve abilities requires a lot of work.
DevOps vs. AgileDevOps and agile have similarities, but they are not the same. Some people think DevOps is better than agile. To avoid confusion, it is important to understand them in depth.
• There is no doubt that both are software development techniques.
• Agile has been around for more than 20 years, and DevOps has only recently emerged.
• Both pursue the rapid development of software, and their concepts are based on how to quickly develop software without harming customers or the interests of operation and maintenance.
• The difference between the two lies in what happens after the software development is completed.
• In DevOps and Agile, there are stages of software development, testing, and deployment. However, the agile process will end after these three stages. On the contrary, DevOps includes subsequent continuous operation and maintenance. Therefore, DevOps will continuously monitor the software operation and carry out continuous development.
• In agile, different people are responsible for software development, testing, and deployment. The DevOps engineering role is responsible for all activities, development is operation and maintenance, and operation and maintenance is development.
• DevOps is more focused on cutting costs, while agile is synonymous with lean and waste reduction, focusing on concepts like agile project accounting and minimum viable products.
• Agile focuses on and embodies empiricism (adaptation, transparency, and inspection) rather than predictive measures.
ConclusionAgile and DevOps are very different, although their similarities make people think they are the same. This hurts both agile and DevOps.
Based on my experience as an agile expert, I found that it is very important for organizations and teams to understand what agile and DevOps are at a high level, and how they can help teams work more efficiently, deliver high-quality products faster, and improve customer satisfaction. valuable.
Agile and DevOps are by no means adversarial (or at least not intended). In the Agile Revolution, they are more like allies than enemies. Agile and DevOps can collaborate in unison, so they can coexist on the same occasion.