1 Introduction To Continuous Delivery, Devops, and Modern Apps

This lesson describes the agile software development methodology and compares it with
legacy methodologies. The values and principles of the agile movement, a brief description
of agile practices, and the benefits achieved with these new techniques are also covered.
Copyright 2015 EMC Corporation. All rights reserved. Introduction to Continuous Delivery, DevOps, and Modern Apps 1
It has been well-established that a significant percentage of IT software projects fail. From
small to large, software development has been tricky to plan and predict, and often delivers
results that fail to meet customer expectations.
These failures are typically attributed to a variety of causes:
• Poor or ambiguous sponsorship
• Confusing or changing requirements
• Inadequate skills or resources
• Poor design or inappropriate use of new technology
Source: Ditmore, J. (2013, October 28). Why Do Big IT Projects Fail So Often? -
InformationWeek. Retrieved from http://www.informationweek.com/strategic-cio/executive-
insights-and-innovation/why-do-big-it-projects-fail-so-often/d/d-id/1112087?
To deliver successful software projects, both the technology and the business values must
align. If they are not aligned, the software may not meet customer needs, or it may meet
some customer needs, but not deliver business value. In either case, the value of aligning
business and technology is increasingly magnified once the product reaches the customer.
Software cannot simply meet the interest and curiosity of the developers, it must also meet
the needs of the business.
Typical project management techniques, when applied to software development, have
failed. The most common technique, commonly referred to as the waterfall methodology,
fails because it expects a complete understanding of the problem, a complete
understanding of all the systems the software will interact with, and well-defined
unchanging requirements. Applied to software projects, this methodology has historically
resulted in over-budget projects that are delivered late and fail to meet user needs. The
methodology fails because it is almost impossible to meet all of the initial conditions.
When any of the above mentioned conditions cannot be achieved, there is significant risk of
failure to meet schedule and functionality expectations because it is difficult to
accommodate new or changing requirements, and it is difficult to address issues found late
in development. Furthermore, because the working product is not available until the end,
functionality and integration issues are often not discovered until it is too late to correct
them. For the types of complex, scalable, evolutionary software being developed, this
methodology often creates more problems than it solves.
Trying to speed software cycles through the traditional waterfall development process
usually exacerbates these challenges. In modern apps, this is further magnified because
development, testing, and operations teams must all be operating in synch to deliver the
finished product. Often this synchronization cannot be achieved, resulting in bottlenecks
that delay product delivery.
As a developer implementing an application using the waterfall process, it can feel quite
challenging, perhaps even frightening. You’re going to go a long way before having a
chance to ensure that you’ve been on the right track, and when you’re finished, it’s likely to
be painful if you’ve made the wrong choices.
The end result is often exactly what you might expect falling off a waterfall.
This pain and the likelihood of failure drove a team of visionaries to meet and discuss
alternate development techniques.
A collection of lightweight software development methods evolved in the mid-1990s in
reaction to the perceived heavyweight waterfall-oriented methods, which critics called
heavily regulated, regimented, and micro-managed. In February 2001, 17 software
developers met at the Snowbird resort in Utah to discuss lightweight development methods.
They published the Manifesto for Agile Software Development. In this manifesto, the
authors state a set of values for software development. The authors went on to identify a
set of principles to accompany these values. Several methodologies have emerged to
replace waterfall in a desire to achieve these agile values and principles.
Source: www.agilemanifesto.org
Agile development methodologies focus on an iterative approach to developing applications.
The waterfall methodology attempts to identify all requirements, understand all
technologies, and foresee all issues before work even begins, and then it defines a project
plan that rarely changes despite discoveries, challenges, or feedback encountered during
the development process. In contrast, agile methodologies define application development
projects as a sequence of short projects. Each of these short projects completes a portion
of the functionality of the final application. As these shorter projects are completed they can
be evaluated and new discoveries and feedback can be incorporated into the overall project.
With agile, at the end of each development iteration some amount of functionality has been
completed. When enough functionality exists in the completed application, it can be tested,
released, deployed, and run by users. Because this style of project management regularly
produces finished results, it provides a more transparent process enabling more predictable
schedules and higher user satisfaction.
There are several well-established methodologies that embrace the values established in the Agile
Manifesto. There are specific differences in the practices within each, but they all share some common
principles.
1. Deliver frequently
• Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
2. Build the right team

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
3. Empower the team to make decisions

• The best architectures, requirements, and designs emerge from self-organizing
teams.
4. Embrace change - Welcome changing requirements, even late in development. Agile

processes harness change for the customer's competitive advantage.
5. Build quality all the time

• Continuous attention to technical excellence and good design enhances agility.
• Simplicity—the art of maximizing the amount of work NOT done—is essential.
6. Reflect and Improve - At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
Agile methodologies bring several changes to software development. When projects are
chunked into smaller iterations, managing resources and estimating delivery times is easier.
At the end of an iteration, the completed functionality can be tested and evaluated by
stakeholders and customers. A quick feedback loop allows developers to validate the
usability of the features they have developed and implement corrections between iterations
instead of between product versions. As more and more iterations are completed, the
processes performed as a part of an agile methodology become habits, and the developer
performs them more rapidly and naturally as a part of their daily work.
Continuous review and improvement is another core value of agile methodologies. At the
end of each iteration, development teams review what worked well and what did not, so
they can adjust and improve their next iteration. In this way, agile practices are designed to
improve with use.
Agile is also a scalable practice which evolves as the project becomes bigger. There are
several different agile methodologies that can be applied to projects large and small.
Implementing an agile development methodology exposes and reinforces the value an
organization has for the quality of its software and the importance of its customers.
In practice, there are some important differences between plan-driven methodologies and
agile methodologies. Waterfall is the most well known plan-driven process model whereas
there are many iterative models to choose from in Agile. Every team employing an agile
strategy defines and adopts it in the manner that best fits their specific operation. Plan-
driven models dictate a detailed and dedicated phases for most phases of the software
development lifecycle including: project planning, requirements engineering, architecture
design, implementation, and QA. Agile models on the other hand usually begin with coarse
grained details that are expected to evolve into finer details that are implemented and
validated during each iteration and over the life of the project. Quality is not a phase for
Agile methodologies, it is the constant result of tight feedback loops occurring throughout
each iteration of development.
Agile software development projects tackle the software development in smaller, more
manageable chunks, so they do not suffer from the abrupt all-or-nothing, success-or-failure
fate that most waterfall software development projects encounter. Because these
methodologies enable the entire team to review and reconsider the path of the project at
regular intervals, adjustments can be made that reduce the risks that the application will
not meet user expectations. Also, because managers, developers, and users are all a part of
the team, everyone is a part of the communication and collaboration as the project
progresses, which reduces stress and makes for a much more successful project.
This lesson described the agile software development methodology and compared it with
legacy methodologies. The values and principles of the agile movement, a brief description
of agile practices, and the benefits achieved with these new techniques were also covered.
This developer toolbox covers the agile software development practices of the Scrum
methodology.
Scrum is an agile Software Development Lifecycle (SDLC) methodology that defines roles
and events needed for building products without including the explicit technical processes
for achieving these. A sub-group of agile project management, Scrum’s underlying goal is
to deliver new software functionality every 2-4 weeks. Scrum embraces the values and
principles defined in the Agile Manifesto as a guide for making decisions that positively
affect the quality and speed of software development. It builds on these by prescribing a
team’s day-to-day interactions and activities. Even though this methodology was specifically
devised for software development projects, Scrum has spread to many other business areas
where projects encounter similar complexity and ambiguity. This includes IT, marketing,
and leadership teams basing their agile management practices on Scrum.
Scrum mandates transparency of information and communication. The resulting agile team
can better adapt to change, estimate resources, report progress, and build software. This
transparency is focused on current conditions – a complete departure from legacy waterfall
methods whose focus has historically been on predicted conditions. A unique aspect of
Scrum is its replacement of blame with an ownership mentality, as evidenced by their aptly-
labeled retrospective meetings instead of post-mortems (the latter’s meaning of which,
“after death”, implies focus on only what went wrong).
Sources:
http://www.versionone.com/agile-101/what-is-scrum
https://www.versionone.com/agile-101/agile-methodologies/
http://www.seguetech.com/blog/2013/04/12/8-benefits-of-agile-software-development
[Scrum 101] Scrum and XP (Extreme Programming) -
https://www.youtube.com/watch?v=HwOMtectTkQ
Scrum 101 - A free online Scrum course -
https://www.youtube.com/playlist?list=PLwp2u4BGscVC-gaDY5YuPgthXV0gB3Amh
http://www.scrumdesk.com/professional/screenshots-cards/
https://www.visualstudio.com/features/agiletools-vs?WT.srch=1&WT.mc_id=SEM_DvlLxsoM
http://scrummethodology.com/scrum-user-stories/
There are three predefined roles in the Scrum framework. The product owner usually
provides the vision, desired outcome, budget, return on investment, release dates, content,
and funding for a given project. Product owners maintain the project’s feature list and
validate the team’s work between delivery cycles. The Scrum master ensures that the team
adheres to the Scrum process, removes any impediments to the their progress (both
internal and external), and enables close cooperation among all roles. They are also
expected to be change agents for the corporation by facilitating any change necessary for
better employment and adoption of the Scrum framework. The Scrum team is the product’s
software development team. They are given full responsibility for organizing in whichever
way they determine best meets the product commitments, and are tasked with presenting
results to the product owner at the end of each delivery cycle.
Roles and responsibilities often change when migrating from a Waterfall to an Agile
organizational structure. Because each organization is different, their path to Agile
adoption will also be different and can’t be specifically prescribed. It’s important to note
however, that Agile’s focus is not on completing projects but on delivering valuable
products, services and solutions. Therefor, moving away from a project-based Waterfall
methodology implies that project managers and those they manage are the first to
experience a change in their roles. The “top down” approach that traditionally favors
following the structure and scheduling practices of an organization need to be exchanged
for a “bottom up” approach that favors self-organizing teams of those that are best able to
develop and deliver the software features. Management no longer sets the pace and
scheduling because the self-organized team sets its own schedule based on product owner
priorities and the team’s currently available capacity. An important reason Agile moves
away from projects is because these typically are treated as independent of each other.
Because of this, a pipeline, or an efficiently repeatable system, is never allowed to form as
projects begin, end, and dispose of the knowledge and processes developed instead of
reusing and refining these. Many great articles have been written on this migration
process. Please see those listed in the resources below for further information.
Sources:
http://www.slideshare.net/RaviTadwalkar/agile-roles-responsibilities Jan 20, 2015, Ravi
Tadwalkar ICP-ATF, ICP-ACC, CSP, SPC, Lean/Agile/DevOps Coach & Trainer; Co-founder,
"Cisco Internal Coaches Network" and AgileCamp.org (The above graph is an adaptation
from this presentation)
https://www.atlassian.com/agile/effective-management-across-agile Atlassian’s
“Development managers vs. scrum masters”
https://www.scrumalliance.org/community/articles/2013/march/transitioning-to-agile
“Transitioning to Agile” by Rex Lester, 8 March 2013
Three artifacts (tangible items created from following this process) are generated by a
series of predefined events in the Scrum framework. Initially, the product owner is tasked
with compiling the entire list of features that should be part of the final product. This list is
known as the product backlog and is usually ordered from highest to lowest feature priority.
Once the product backlog is created, the product owner meets with the Scrum team during
the first part of their sprint planning meeting to decide how much of this list can be
completed in the next delivery cycle. Each delivery cycle is referred to as a sprint which is
bound by a predefined duration of time for completing work, usually between 2-4 weeks.
Next, the Scrum team holds the second part of their sprint planning meeting without the
product owner. In this meeting, design, architecture, and strategies for achieving the
current sprint items are discussed with the objective of creating a list of smaller, actionable
tasks to be completed during the current sprint. This list is known as the sprint backlog and
the first sprint begins after this becomes available. A daily stand-up meeting, or daily
Scrum, occurs every day of a sprint. The purpose is for each developer to communicate
three things to the rest of the team: what they achieved since the last meeting, what they
will be working on until the next meeting, and any impediments they are currently facing.
Daily Scrums are to be kept as short as possible and never to exceed 15 minutes.
When a sprint completes, the Scrum team and product owner hold a meeting called a sprint
review, to demonstrate the work results of the last sprint. Reviews are critical because
these meetings enable the stakeholders or customers to review the work done so far and
evaluate whether the development team is on target or not. This is why Scrum achieves
high customer engagement and satisfaction. Also the "work result" produced at the end of
the Sprint is now available to other teams – test, QA, documentation, training – to work
with so they can incrementally produce their "artifacts" as well. This is how Scrum achieves
higher transparency and faster delivery. Finally, organizations implementing DevOps
practices take the "work result" produced at the end of the sprint and use automation to
then run that through test, QA, prepare it for release, and potentially push it out into
production. Immediately after the sprint review meeting, the Scrum team holds a second
meeting called a sprint retrospective to reflect on the activities of the last sprint. This
reflection is done both in terms of what worked well and what needs improvement. Note
also that this cycle returns to the backlog before starting again. This is how Scrum achieves
adaptability to new requirements.
There are several tools used by practitioners of the Scrum methodology. User Stories and
Backlogs add refined clarity and prioritization to all remaining work, Scrum boards add
visibility to assigned tasks, and Burndown charts add visibility to overall development
progress.
These tools are often physical items like index cards or boards, but many virtual
implementations are made by the software industry as well. (Examples of companies that
produce tools used in the agile process include JiraSoftware, Pivotal Tracker, Visual Studio
Agile Tools, and ScrumDesk.)
User stories help developers stay focused on the customer by adding clarity to all remaining work.
They are basically use cases that document requirements with specific attention to the end user’s
point of view. There are many ways of writing these, but the following template developed by Mike
Cohn has been adopted by many Scrum practitioners: “As a [end user role], I want [the desire] so
that [the rationale].” This single sentence, often documented on index cards, elegantly clarifies who
the end user is, what they want, and why.
The backlog adds refined prioritization to the user stories. As mentioned, the product owner is in
charge of maintaining the product backlog, a list of not yet implemented product functionality. These
entries are ordered by highest to lowest priority and by granularity of available clarity. The goal is to
move the least well-defined and understood items, to the bottom 60% of the list, the items that have
some level of detail but still incomplete to the middle 20%, and the most well-defined and understood
items which are ready to be divided into workable tasks to the top 20%. As the project moves forward
and clarifying information becomes available for entries in the bottom two-thirds of the list, these
items are promoted up the list by the product manager. Maintaining the list in this manner is referred
to as refining or grooming the product backlog. This process is often referred to as "T-shirt" sizing
each user story. Is this a Small, Medium, Large, or eXtra Large user story? Stories are also often
measured using “story points”, where similar to the t-shirt sizing, each is assigned a number that
increases with the amount of perceived complexity, ambiguity, or effort required to complete these.
However, these points are meant as a gauge to discuss story size in the abstract and never as any
direct correlation to the number of hours to complete them.
User stories are selected from the top 20% of the product backlog when deciding on functionality to
be implemented by the Scrum team during the next sprint.
Their associated index cards are later used to create and assign tasks on a shared task board. Tasks
are a set of development activities that must be performed to complete a User Story and a Sprint
Backlog provides the prioritization of these tasks. Both product and sprint backlogs provide similar
prioritization functionality; the former prioritizes all user stories per project, the latter prioritizes all
tasks per sprint.
Source: https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point
Scrum (or task) boards add visibility to assigned tasks and measure the progress of the
team throughout a sprint. We’ll use this simple board as an example. At the beginning of
each sprint, all user stories that the team intends to complete are placed on the board in
the form of index cards or stick-it notes and then further divided into tasks. In this case,
let’s say the Scrum team has decided to complete two user stories in the first sprint. After
adding these to the board, each is divided into the number of tasks the team deems
necessary to implement the entire story. The team members who are not currently working
on anything assign themselves a task and move it to the WIP column as soon as they start
working on it. When each completes their task, they move it to the completed column.
Since the Scrum team is responsible for dividing the user stories into actionable
development tasks, each with their own implementation details and assigned developer,
each developer on the Scrum team is ultimately responsible for determining when these
tasks are complete and ready to move into this last column. However, all the tasks need to
meet the demands of the parent user story. This is first determined by the scrum team
during their Sprint and verified by the Product Owner when the Scrum team presents their
work product after the Sprint and during the Sprint Review. The board is updated each day
by moving tasks from left to right across the board until all user stories are implemented
and the sprint completes.
This simple mechanism is an effective way to measure a teams’ progress and track sprint
tasks to completion.
Two types of burndown charts are used: Sprint Burndown and Product Burndown.
Sprint Burndown charts show the unfinished tasks that are still in the sprint backlog.
Product Burndown charts show the unimplemented features that are still in the product
backlog.
Note here that these charts are critical for establishing development velocity, and this is
why Scrum has a much better track record for being more predictable than waterfall.
Because we evaluate how much work the team can do every 2 – 4 weeks, the team gets
better over time at assessing what will be available at the end of the sprint, and when the
entire product backlog can be completed. The burndown chart also makes it very visible,
very early, if release dates are realistic or not. This is how Scrum achieves higher
predictability.
Continuous planning is made available through its sprint planning meetings where clarity
and priority of remaining work is refined between development cycles. Self-organizing
teams divide work between themselves into tasks and keep track of these on visibly shared
task boards. Continuous communication occurs through tight and transparent feedback
loops between the customer, who maintains the product’s requirements list, and the
development team who implement each feature. Continuous reviews enable practitioners to
adapt well to changing requirements. These come in the form of sprint reviews between
customer and development team, and daily Scrums between each developer on the team.
The former enables customer feedback on the direction of the project and the latter enables
developers to give a daily status on their progress. Continuous releases are made possible
through Scrum’s short development iterations (2-4 weeks) where development focuses only
on the features needed during the current cycle and does not attempt to forecast future
changes.
A Continuous DevOps Pipeline is made possible by taking these iterative work results at
the end of each development cycle and using automation to run them through to other
teams: test, QA, prepare it for release, and potentially push it out into production.
Continuous Improvement is attained through the use of burndown charts and sprint
retrospective meetings. The former practice provides progress metrics on remaining
incomplete work for the current development cycle as well as the overall project. The latter
allows development to ascertain what worked and what didn’t during the cycle. Both
facilitate predictability of release dates, quotes, and the estimation of resources.
Continuous Health with a work-life balance is much easier to attain with these more
efficient and empowered team dynamics. Employees are generally happier, less tired, and
more creative than their waterfall colleagues.
In 2000 Nationwide was primarily using a waterfall development method to create the
software products that its members, customers, and agents used online. This was not
delivering the features the users wanted, and it created friction between IT and the
business. Software deliveries were not meeting software requirements.
In 2010 Nationwide began using agile software methodologies to build software with 6
teams of approximately 50 people. Early success easily demonstrated the value of this
transformation. Productivity increased from 8 defects per release with a 60% on-time rate,
to 1 defect per release with a 90% on-time rate.
Nationwide has embraced this transformation across technology domains including

mainframe, distributed systems, and business intelligence data solutions. The new
approaches are bringing new talent and new ways of doing thing to the mainframe
developers showing them improvements to the way they do things. This is improving
employee productivity, skills, and morale.
Source:
http://www-01.ibm.com/common/ssi/cgi-
bin/ssialias?subtype=AB&infotype=PM&appname=SWGE_RA_RA_USEN&htmlfid=RAC14305
USEN&attachment=RAC14305USEN.PDF
https://www.skytap.com/blog/gene-kim-and-others-share-what-devops-is-really-all-about/
Form a team of two (or more) to perform the activities and discuss the questions that
follow. Use your own notebook to record your group’s discussions.
Review what was performed in lab and address any questions the lab raised.

1 Introduction To Continuous Delivery, Devops, and Modern Apps

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

1 Introduction To Continuous Delivery, Devops, and Modern Apps

Загружено:

Авторское право:

Доступные форматы

This lesson describes the agile software development methodology and compares it with

These failures are typically attributed to a variety of causes:

• Poor or ambiguous sponsorship

• Confusing or changing requirements

• Inadequate skills or resources

• Poor design or inappropriate use of new technology

2. Build the right team

3. Empower the team to make decisions

4. Embrace change - Welcome changing requirements, even late in development. Agile

5. Build quality all the time

Nationwide has embraced this transformation across technology domains including

Вам также может понравиться