Agile &DevOps Innovation
COURTESY :- vrindawan.in
Wikipedia
In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved.
Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.
While there is much anecdotal evidence that adopting agile practices and values improves the effectiveness of software professionals, teams and organizations, the empirical evidence is mixed and hard to find.
Iterative and incremental software development methods can be traced back as early as 1957, with evolutionary project management and adaptive software development emerging in the early 1970s.
During the 1990s, a number of lightweight software development methods evolved in reaction to the prevailing heavyweight methods (often referred to collectively as waterfall) that critics described as overly regulated, planned, and micromanaged. These lightweight methods included: rapid application development (RAD), from 1991; the unified process (UP) and dynamic systems development method (DSDM), both from 1994; Scrum, from 1995; Crystal Clear and extreme programming (XP), both from 1996; and feature-driven development (FDD), from 1997. Although these all originated before the publication of the Agile Manifesto, they are now collectively referred to as agile software development methods.
Already since 1991 similar changes had been underway in manufacturing and management thinking derived from Lean management.
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss lightweight development methods. They were: Kent Beck (Extreme Programming), Ward Cunningham (Extreme Programming), Dave Thomas (Prag Prog, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim High smith (Adaptive Software Development), Alistair Cock burn (Crystal), Robert C. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD and UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (Extreme Programming), Jon Kern, Brian Marick (Ruby, TDD), and Steve Mellor (OOA). Together they published the Manifesto for Agile Software Development.
In 2005, a group headed by Cockburn and Highsmith wrote an addendum of project management principles, the PM Declaration of Interdependence, to guide software project management according to agile software development methods.
In 2009, a group working with Martin wrote an extension of software development principles, the Software Craftsmanship Manifesto, to guide agile software development according to professional conduct and mastery.
In 2011, the Agile Alliance created the Guide to Agile Practices (renamed the Agile Glossary in 2016), an evolving open-source compendium of the working definitions of agile practices, terms, and elements, along with interpretations and experience guidelines from the worldwide community of agile practitioners.
Based on their combined experience of developing software and helping others do that, the authors of the manifesto declared that they valued:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is to say, while both sides have value and the items on the right should be considered, the authors felt that the items on the left should have more influence on how people approach their work.
As Scott Ambler explained:
- Tools and processes are important, but it is more important to have competent people working together effectively.
- Good documentation is useful in helping people to understand how the software is built and how to use it, but the main point of development is to create software, not documentation.
- A contract is important but is no substitute for working closely with customers to discover what they need.
- A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders’ priorities, and people’s understanding of the problem and its solution.
Some of the authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto’s values and principles. Introducing the manifesto on behalf of the Agile Alliance, Jim High smith said,
The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. Dev Ops is complementary with Agile software development; several DevOps aspects came from the Agile way of working.
Other than it being a cross-functional combination (and a portmanteau) of the terms and concepts for “development” and “operations”, academics and practitioners have not developed a universal definition for the term “DevOps”. Most often, DevOps is characterized by key principles: shared ownership, workflow automation, and rapid feedback.
From an academic perspective, Len Bass, Ingo Weber, and Liming Zhu—three computer science researchers from the CSIRO and the Software Engineering Institute—suggested defining DevOps as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality”.
However, the term is used in multiple contexts. At its most successful, DevOps is a combination of specific practices, culture change, and tools.
In 1993 the Telecommunications Information Networking Architecture Consortium (TINA-C) defined a Model of a Service Life cycle that combined software development with (telecom) service operations.
In 2009, the first conference named devops days was held in Ghent, Belgium. The conference was founded by Belgian consultant, project manager and agile practitioner Patrick Debois. The conference has now spread to other countries.
In 2012, the State of DevOps report was conceived and launched by Alanna Brown at Puppet.
As of 2014, the annual State of DevOps report was published by Nicole Forsgren, Gene Kim, Jez Humble and others. They stated that the adoption of DevOps was accelerating. Also in 2014, Lisa Crispin and Janet Gregory wrote the book More Agile Testing, containing a chapter on testing and DevOps.
In 2016 the DORA metrics for throughput (deployment frequency, lead time for changes), and stability (mean time to recover, change failure rate) were published in the State of DevOps report.
Many of the ideas fundamental to DevOps practices are inspired by, or mirror, other well known practices such as Lean and Deming’s Plan-Do-Check-Act cycle, through to The Toyota Way and the Agile approach of breaking down components and batch sizes. Contrary to the “top-down” proscriptive approach and rigid framework of ITIL in the 1990s, DevOps is “bottom-up” and a flexible practice, created by software engineers, with software engineer needs in mind.
The motivations for what has become modern DevOps and several standard DevOps practices such as automated build and test, continuous integration, and continuous delivery originated in the Agile world, which dates (informally) to the 1990s, and formally to 2001. Agile development teams using methods such as Extreme Programming couldn’t “satisfy the customer through early and continuous delivery of valuable software” unless they subsumed the operations / infrastructure responsibilities associated with their applications, many of which they automated. Because Scrum emerged as the dominant Agile framework in the early 2000s and it omitted the engineering practices that were part of many Agile teams, the movement to automate operations / infrastructure functions splintered from Agile and expanded into what has become modern DevOps. Today, DevOps focuses on the deployment of developed software, whether it is developed using Agile oriented methodologies or other methodologies.
ArchOps presents an extension for DevOps practice, starting from software architecture artifacts, instead of source code, for operation deployment. ArchOps states that architectural models are first-class entities in software development, deployment, and operations.
Automation is a core principle for achieving DevOps success and CI/CD is a critical component. Plus, improved collaboration and communication between and within teams helps achieve faster time to market, with reduced risks.