University of Computer Studies, Yangon (UCSY)

Agility and Process

IS-101
Dr. Hsu Myat Mo
Faculty of Information Science, UCSY

FIS UCSY 1
References
 Software Engineering: A Practitioner's Approach, 9th Edition, Roger Pressman and Bruce Maxim,
McGraw Hill Education, 2019.

Software Engineering: A Practitioner’s Approach,

9th Edition,
Roger S. Pressman, Bruce R. Maxim, 2020

 Software Engineering: A Practitioner's Approach, 8th Edition, Roger Pressman and Bruce
Maxim, McGraw Hill Education, 2014.
 Software Engineering: A Practitioner's Approach, 7th Edition, Roger Pressman, McGraw Hill
Education, 2010.
FIS UCSY 2
Outlines

 What is Agility?
 Agility and the Cost of Change
 What is an Agile Process?
 Scrum
 Other Agile Frameworks
 Summary

FIS UCSY 3
What is Agility?

 Agility is more than an effective response to change.

 Agile software engineering combines a philosophy and a set of development guidelines.
 The philosophy encourages customer satisfaction and early incremental delivery of
software; small, highly motivated project teams; informal methods; minimal software
engineering work products; and overall development simplicity.
 The development guidelines stress delivery over analysis and design (although these
activities are not discouraged).
 Emphasizes an incremental delivery strategy that gets working software to the customer
rapidly
 Effective (rapid and adaptive) response to rapidly changes.
 Has the ability to reduce the costs of change through the software process

FIS UCSY 4
What is Agility?

 Involves the customers as a part of the development team

 Software engineers and other project stakeholders (managers, customers, end users)
work together on an agile team—a team that is self-organizing and in control of its own
destiny.
 Effective communication among all stakeholders
 It encourages team structures and attitudes that make communication (among team
members, between technologists and business people, and between software
engineers and their managers) more facile.

FIS UCSY 5
What is Agility?

 The work product is an operational “software increment”.

 Emphasizes rapid delivery of operational software and deemphasizes the importance
of intermediate work products.
 The most important documents created are the use stories and their associated test
cases.
 it recognizes that planning in an uncertain world has its limits and that a project plan
must be flexible.
 Agility is achieved by fitting the process to the project, i.e. removing activities that may
not be necessary for a specific project.
 Agile methods are sometimes referred to as light methods or lean methods.

FIS UCSY 6
Agility and the Cost of Change

Fig: Change costs as a function of time in development

FIS UCSY 7
What Is an Agile Process?
 Three key assumptions
 It is difficult to predict in advance which software requirements will persist and which will
change. It is equally difficult to predict how customer priorities will change as the project
proceeds.
 For many types of software, design and construction are interleaved.
 Analysis, design, construction, and testing are not as predictable (from a planning point of
view) as we might like.
 It is needed to create a process that can manage unpredictability.
 Process adaptability (to rapidly changing project and technical conditions).
 An agile process, therefore, must be adaptable.
 An agile software process must adapt incrementally.
 An agile team requires customer feedback
 An effective catalyst for customer feedback is an operational prototype
 Incremental development strategy should be instituted
FIS UCSY 8
 Software increments must be delivered in short time periods
Manifesto for Agile Software Development
Four Values of the Agile Manifesto:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

FIS UCSY 9
Agility Principles
Twelve Principles of the Agile Manifesto:
 Customer satisfaction through early and continuous software delivery: Agile focuses on
delivering valuable software increments frequently, allowing customers to provide
feedback early in the process, and ensuring their satisfaction.
 Welcome changing requirements, even late in development: Agile recognizes that
requirements can change, and the team should be responsive to these changes,
adapting plans and priorities as needed.
 Deliver working software frequently, with a preference for shorter timescales: Agile
promotes iterative development and regular delivery of working software to provide
tangible value to customers and stakeholders.
 Collaboration between business stakeholders and developers throughout the project:
Agile emphasizes close collaboration, transparency, and regular communication
between stakeholders and the development team to ensure shared understanding and
FIS alignment. UCSY 10
Agility Principles
 Build projects around motivated individuals and give them the environment and
support they need: Agile recognizes the importance of motivated individuals and
supports their autonomy, fostering an environment that enables their success.
 Use face-to-face communication as much as possible: Agile values direct, face-to-face
communication because it allows for clearer understanding, faster feedback, and
stronger collaboration.
 Working software is the primary measure of progress: Agile emphasizes that the
progress of a project should be measured by the functionality and value delivered in
the form of working software.
 Agile processes promote sustainable development: Agile teams strive to maintain a
sustainable pace of work, avoiding excessive overtime or burnout, to ensure long-term
productivity and quality.

FIS UCSY 11
Agility Principles
 Continuous attention to technical excellence and good design enhances agility: Agile
teams prioritize technical practices, such as continuous integration, automated testing,
and refactoring, to ensure the maintainability, scalability, and quality of the software.
 Simplicity—the art of maximizing the amount of work not done—is essential: Agile
encourages teams to focus on delivering the most important features and to avoid
unnecessary complexity that can hinder productivity and maintainability.
 Self-organizing teams make the best architecture, requirements, and designs emerge:
Agile promotes self-organizing teams that have the authority and responsibility to
make decisions and adapt to changing circumstances, fostering creativity and
innovation.
 Regularly reflect on how to become more effective and adjust behavior accordingly:
Agile teams regularly reflect on their processes, performance, and interactions to
identify areas for improvement and adjust their practices accordingly.
FIS UCSY 12
Scrum
 Is an agile software development process.
 Is a light weight process for managing and controlling software and product
development in rapidly changing environment.
 Focus on delivering the highest business value in the shortest time.

Scrum is where the team comes together to move the product forward.

FIS UCSY 13
Scrum Principles
 Scrum principles are consistent with the agile manifesto
 used to guide development activities within a process that incorporates the following
framework activities: requirements, analysis, design, evolution, and delivery.
 Within each framework activity, work tasks take place in a relatively short time-boxed
period(a sprint).
 Quality work: empowers everyone involved to be feel good about their job
 Assume simplicity: Scrum is a way to detect and cause removal of anything that gets in
the way of development. Focus on simplicity in both the software being developed and
in the development process.
 Embracing Change: Team based approach to development where requirements are
rapidly changing
 Incremental Changes: Scrum makes this possible using sprints where a team is able to
FIS deliver a product (iteration) deliverable within
UCSY 30 days 14
Characteristics of Scrum
 One of the “agile process”
 Self organizing teams
 An empirical process, where decisions are based on observation, experience and
experimentation.
 Product progresses in a series of month-long “sprints”
 Requirements are captured as items in a list of “product backlog”
 No specific engineering practices prescribed

FIS UCSY 15
Scrum Value

FIS UCSY 16
Scrum Process Flow

Fig: Scrum Process Flow

FIS UCSY 17
Scrum Framework

FIS UCSY Fig: Scrum Framework 18

Scrum Framework

Roles
• Product Owner
• Scrum Master
• Development Team Ceremonies
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting Artifacts
• Product backlog
• Sprint backlog
• Burndown charts
FIS UCSY 19
Scrum Framework (Cont’d)
Scrum Team
 The fundamental unit of Scrum is a small team of people, a Scrum Team.
 The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.
 Within a Scrum Team, there are no sub-teams or hierarchies.
 It is a cohesive unit of professionals focused on one objective at a time, the Product
Goal.
 Scrum Teams are cross-functional, meaning the members have all the skills necessary
to create value each Sprint.
 They are also self-managing interdisciplinary team, meaning they internally decide who
does what, when, and how.

FIS UCSY 20
Scrum Framework (Cont’d)
Product Owner
 Is typically a project's key stakeholder
 Is commonly a lead user of the system or someone from marketing, product
management or anyone with a solid understanding of users, the market place, the
competition and of future trends for the domain or type of system being developed.

FIS UCSY 21
Scrum Framework (Cont’d)
Responsibilities of product owner
 is to have a vision of what he or she wishes to build, and convey that vision to the
scrum team.
 is accountable for maximizing the value of the product resulting from the work of the
Scrum Team.
 developing and explicitly communicating the Product Goal (also the development goal
for the increment to be completed in the upcoming sprint);
 creating and clearly communicating Product Backlog items which is a prioritized
features list for the product; ensuring it is transparent, visible and understood.
 ordering Product Backlog items to meet the most important goals of all stakeholders;
 Is the only person who decides whether to end a sprint prematurely or extend the
sprint if the increment is not accepted
FIS UCSY 22
Scrum Framework (Cont’d)
Scrum Master
 Represents management to the project
 The Scrum master serves as facilitator to all members of the Scrum team
Responsibilities of scrum master
 enact scrum values and practices
 is accountable for the Scrum Team’s effectiveness
Main Job of scrum master
 runs the daily Scrum meeting
 remove impediments
 removing barriers between stakeholders and Scrum Teams.

FIS UCSY 23
Scrum Framework (Cont’d)
The Scrum Master serves in several ways :
 Helping the product owner find techniques for effective Product Goal definition and
Product Backlog management (eg.,ensure that backlog items are stated in clear and
concise terms);
 Helping the Scrum Team understand the need for clear and concise Product Backlog
items;
 Coaching the team members in self-management and cross-functionality;
 Helping establish empirical product planning for a complex environment; and,
 Facilitating stakeholder collaboration as requested or needed.
 Ensuring that all Scrum events take place and are positive, productive, and kept
within the timebox.

FIS UCSY 24
 Scrum Framework (Cont’d)
Developers (Development Team)
 Developers are the people in the Scrum Team that are committed to creating any
aspect of a usable Increment each Sprint.
 The specific skills needed by the Developers are often broad and will vary with the
domain of work.
Responsibilities of developers
 Creating a plan for the Sprint, the Sprint Backlog and create a plan for delivering a
software increment;
 Instilling quality by adhering to a Definition of Done;
 Adapting their plan each day toward the Sprint Goal;
 Holding each other accountable as professionals.
 Decide when the increment is done and ready to demonstrate to the product owner
FIS UCSY 25
 Scrum Framework (Scrum Artifacts )
Scrum Artifacts
 Scrum’s artifacts represent work or value.
 They are designed to maximize transparency of key information.
 Thus, everyone inspecting them has the same basis for adaptation.
 Each artifact contains a commitment to ensure it provides information that enhances
transparency and focus against which progress can be measured:
 For the Product Backlog it is the Product Goal.
 For the Sprint Backlog it is the Sprint Goal.
 For the Increment it is the Definition of Done.
 These commitments exist to reinforce empiricism and the Scrum values for the Scrum
Team and their stakeholders.
FIS UCSY 26
Scrum Framework (Scrum Artifacts )
Product Backlog
 a prioritized list of product requirements or features that provide business value for the
customer / A list of all desired work on project
 usually a combination of
 Story-based work (“let user search and replace”)
 Task-based work (“improve exception handling”)
 prioritized/ ordered by the product owner(sometimes with development team) to
meet the most important goals of all stakeholders.
 can be added to the backlog at any time with the approval of the product owner and
the consent of the development team.
 The product backlog is never complete while the product is evolving to meet
stakeholder needs
FIS UCSY 27
Scrum Framework (Scrum Artifacts )
Sprint Backlog
 Subset of product backlog items selected by the product team
(SM&D) to be completed as the code increment during the
current active sprint.
 The Sprint Backlog is composed of the Sprint Goal (why), the
set of Product Backlog items selected for the Sprint (what), as
well as an actionable plan for delivering the Increment (how).
 It is a highly visible, real-time picture of the work that the
Developers plan to accomplish during the Sprint in order to
achieve the Sprint Goal.
 Consequently, the Sprint Backlog is updated throughout the
Sprint as more is learned. It should have enough detail that
they can inspect their progress in the Daily Scrum.
FIS UCSY 28
Scrum Framework (Scrum Artifacts )
Increment
 The increment – the union of all product backlog items completed in previous sprints
and all backlog items to be completed in the current sprints.
 An Increment is a concrete stepping stone toward the Product Goal.

FIS UCSY 29
Scrum Framework (Scrum Artifacts )
Sprint Burndown Charts
 Are used to represent “work done” Sample Burndown Chart
 Are wonderful information radiators
 Three types:
 Sprint burndown chart (progress of the sprint)
 Release burndown chart (progress of release)
 Product burndown chart (progress of the product)

FIS UCSY 30
 Scrum Framework (Cont’d)
The Sprints
 Sprints are the heartbeat of Scrum, where ideas are turned into value.
 Sprints are time-boxed (fixed length event of one month or less) to be completed in 3
to 4 weeks
 A new Sprint starts immediately after the conclusion of the previous Sprint.
 Development proceeds by braking the project into a series of incremental prototype
development periods.
 All the work necessary to achieve the Product Goal, including Sprint Planning, Daily
Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
 Each sprint begins with the daily scrum meeting.

FIS UCSY 31
FIS UCSY 32
Scrum Framework(Scrum Events/Ceremonies)

Product Backlog

FIS UCSY 33
Scrum Framework (Cont’d)
Sprint Planning
 A collaborative meeting in the beginning of each sprint between the product owner,
the scrum master and the development team

Fig : Sprint Planning

FIS UCSY 34
Scrum Framework (Cont’d)
Sprint Planning
 Prior to starting each sprint, the product owner states the development goal for the
increment to be completed in the upcoming sprint.
 The Scrum master and the development team select the items to move from to the
sprint backlog.
 The development team determines what can be delivered in the increment within the
constraints of the time-box allocated for the sprint and, with the Scrum master, what
work will be needed to deliver the increment.
 The development team decides which roles are needed and how they will need to be
filled.

FIS UCSY 35
Scrum Framework (Cont’d)

FIS UCSY 36
Scrum Framework (Cont’d)
Daily Scrum meeting
 The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt
the Sprint Backlog as necessary, adjusting the upcoming planned work.
 To synchronize the development team’s activities
 A 15-minute event scheduled
 At the start of each workday
 Make plans for the next 24 hours
 Participants:
 The Scrum master
 The development team
 The product owner (occasionally)
 The Scrum master leads the meeting andUCSY
FIS assesses the responses from each person. 37
Scrum Framework (Cont’d)
Daily Scrum meeting
 Three key questions are asked and answered by all team members:
 What did you do since the last team meeting?
 What obstacles are you encountering?
 What do you plan to accomplish by the next team meeting?
 Helps uncover potential problems as early as possible
 Not problem-solving meetings
 Leads to Knowledge socialization and thereby promote a self-organization team
structure.

FIS UCSY 38
Scrum Framework (Cont’d)
Sprint Review Meeting
 Occurs at the end of the sprint when the development team has judged the increment
complete.
 Time-boxed as a 4-hour meeting for a 4-week sprint.
 Participants
 (i) The Scrum master
 (ii) the development team
 (iii) the product owner
 (iv) selected stakeholders
 The primary activity - a demo of the software increment completed during the sprint.
 The product owner may accept the increment as complete or not.
FIS UCSY 39
Scrum Framework (Cont’d)
Sprint Retrospective
 Before beginning another sprint planning meeting, the Scrum master will schedule e.g, a
3-hour meeting (for a 4-week sprint) with the development team called a sprint
retrospective.
 During this meeting, the team discusses:
 (i) What went well in the sprint
 (ii) What could be improved
 (iii) What the team will commit to improving in the next sprint
 The scrum master leads the meeting and encourages to improve its development
practices to become more effective for the next sprint
 The team plans ways to improve product quality by adapting its definition of “done.”
 Should have a good idea about the improvements needed in the next sprint
FIS UCSY 40
Other Agile Framework
 Will present a brief overview of three popular agile methods:
 Extreme Programming (XP)
 Kanban
 DevOps

FIS UCSY 41
The XP Framework
Extreme Programming encompasses a
set of rules and practices that occur
within the context of four framework
activities: planning, design, coding, and
testing.
XP Practices:
 Simple Design
 Pair Programming
 Constant Testing
 Ongoing Integration
 Refactoring
 Coding Standard
 Small Releases
FIS UCSY 42
Fig: The Extreme Programming process
The XP Framework : Planning
The planning activity (also called the planning game) begins with a requirements activity
called listening.
Listening leads to the creation of a set of “stories” (also called user stories) that describe
required output, features, and functionality for software to be built.
Each user story is written by the customer and is placed on an index card.
The customer assigns a value (i.e., a priority) to the story based on the overall business
value of the feature or function.
Members of the XP team then assess each story and assign a cost—measured in
development weeks—to it.
New stories can be written at any time.
Customers and developers work together to decide how to group stories into the next
release (the next software increment) to be developed by the XP team.
A basic commitment (agreement on stories to be included, delivery date, and other
project matters) is made for a release.
FIS UCSY 43
The XP Framework : Planning
Three ways to order the stories that will be developed:
 All stories will be implemented immediately (within a few weeks)
 The stories with highest value will be moved up in the schedule and implemented
first
 The riskiest stories will be moved up in the schedule and implemented first.

FIS UCSY 44
The XP Framework : Planning
After the first project release (also called a software increment) has been delivered, the
XP team computes project velocity.
Project velocity is the number of customer stories implemented during the first release.
Project velocity can then be used to help estimate delivery dates and schedule for
subsequent releases.
The XP team modifies its plans accordingly.

FIS UCSY 45
What is User Story?
An informal, natural language description of one or more features of a software system
To capture a description of a software feature from an end-user perspective
The type of user, what they want and why.
Helps to create a simplified description of a requirement.

FIS UCSY 46
User Story Template
User stories only capture the essential elements of a requirement:
 Who it is for?
 What it expects from the system?
 Why it is important (optional?)?
Here is a simple format of user story used by 70% of practitioners:

FIS UCSY 47
User Story Template
User stories are a short description of a small piece of business functionality that usually
takes 1-3 days to complete.

FIS UCSY 48
User Story Example

1. As a [customer], I want [shopping cart feature] so that [I can easily purchase

items online].
2. As an [manager], I want to [generate a report] so that [I can understand
which departments need more resources].
3. As a [customer], I want to [receive an SMS when the item is arrived] so that
[I can go pick it up right away]

FIS UCSY 49
CRC Cards example
Every card should be a standard index card, with the name of the class on the top, and
the rest of the card split into responsibilities on the left and collaborators on the right.

FIS UCSY 50
CRC Cards example

FIS UCSY 51
CRC Cards example

FIS UCSY 52
The XP Framework : Design
A central notion in XP is that design occurs both before and after coding commences( as
refactoring is encouraged).
Follows the KIS (keep it simple) principle.
XP encourages the use of CRC cards as an effective mechanism for thinking about the
software in an object-oriented context.
CRC (class-responsibility-collaborator) cards identify and organize the object-oriented
classes that are relevant to the current software increment.
CRC cards are the only design work product produced as part of the XP process.
For difficult design problems, XP recommends the immediate creation of an operational
prototype of that portion of the design.
Refactoring (modifying and optimizing the code does not change the external behavior of
the software) means that design occurs continuously as the system is constructed.

FIS UCSY 53
The XP Framework : Coding
After user stories are developed and preliminary design work is done, the team does not
move to code, but rather develops a series of unit tests that will exercise each of the
stories that is to be included in the current release (software increment).
Once the unit test has been created, the developer is better able to focus on what must
be implemented to pass the test.
Once the code is complete, it can be unit-tested immediately, thereby providing
instantaneous feedback to the developers.
A key concept during the coding activity is pair programming that two people work
together at one computer to create code for a story.
This provides a mechanism for real-time problem solving (two heads are often better
than one) and real-time quality assurance (the code is reviewed as it is created).
As pair programmers complete their work, the code they develop is integrated with the
work of others. This “continuous integration” strategy helps uncover compatibility and
interfacing errors early.
FIS UCSY 54
The XP Framework : Testing
The unit tests that are created should be implemented using a framework that enables
them to be automated (hence, they can be executed easily and repeatedly).
This encourages implementing a regression testing strategy whenever code is modified.
XP acceptance tests, also called customer tests, are specified by the customer and focus
on overall system features and functionality that are visible and reviewable by the
customer.
These features and functionality are derived from user stories that have been
implemented as part of a software release.

FIS UCSY 55
Kanban (Kan=Card, Ban=Signal)
A lean methodology that describes methods for improving any process or workflow.
Kanban is focused on change management and service delivery.
Change management defines the process through which a requested change is
integrated into a software-based system.
Service delivery is encouraged by focusing on understanding customer needs and
expectations.
The team members manage the work and are given the freedom to organize themselves
to complete it.
Policies evolve as needed to improve outcomes.

FIS UCSY 56
Kanban Board
Agile Kanban Framework focuses on visualizing the entire project on boards in order to
increase project transparency and collaboration between team members.
Kanban focuses on managing and optimizing the work in progress.

FIS Fig. Example of a Kanban Board UCSY 57

Kanban Board
This board plays a vital role in displaying the task workflow.
It helps to optimize the flow of task between different teams.
It is a method for defining, managing and improving services for delivering knowledge
work.

Kanban board indicates

the current tasks that are being performed
the tasks to do in the future
the tasks that are completed

FIS UCSY 58
Kanban
Kanban itself depends on six core practices:
1). Visualizing workflow using a Kanban board.
The Kanban board is organized into columns representing the development stage for
each element of software functionality.
The cards on the board might contain single user stories or recently discovered defects
on sticky notes and the team would advance them from “to do,” to “doing,” and “done”
as the project progresses.
2). Limiting the amount of work in progress (WIP) at any given time.
Developers are encouraged to complete their current task before starting another.
This reduces lead time, improves work quality, and increases the team’s ability to deliver
software functionality frequently to their stakeholders.

FIS UCSY 59
Kanban
3). Managing workflow
Manage workflow in order to reduce waste by understanding the current value flow,
analyzing places where it is stalled, defining changes, and then implementing the
changes.
4). Making process policies explicit
Making process policies explicit (e.g., write down the reasons for selecting items to work
on and the criteria used to define “done”).
5). Focusing on continuous improvement
Focusing on continuous improvement by creating feedback loops where changes are
introduced based on process data and the effects of the change on the process are
measured after the changes are made.
6). Make process changes collaboratively
Make process changes collaboratively and involve all team members and other
FIS
stakeholders as needed. UCSY 60
Kanban
The team meetings for Kanban are like those in the Scrum framework.
Developers need to place their cards in the team process column by asking themselves:
Where are they now? Where did they come from? Where are they going?
The basis of the daily Kanban standup meeting is a task called “walking the board.”
The team members identify any items missing from the board that are being worked on
and add them to the board.
The team tries to advance any items they can to “done.”
The team looks at the flow and tries to identify any impediments to completion by
looking at workload and risks.
During the weekly retrospective meeting, process measurements are examined.
The team considers where process improvements may be needed and proposes changes
to be implemented.
Kanban can easily be combined with other agile development practices to add a little
FIS
more process discipline. UCSY 61
 Example:
Simplified Team:
Product owner (red),
Developers (blue),
& Deployment (green).

Product owner can only

select 2 items based on Limit
Work in Progress
(WIP) limit.

Developers PULL cards

to work on.

FIS UCSY 62
 Developers move items
to DONE when
complete.

Deployment can only

select 1 item to deploy
based on WIP limit.

Deployment encounters
problem and flags item
as having a BLOCK.

FIS UCSY 63
 Meanwhile Developers
are ready to PULL next
task, but wait, WIP is 2.

Developers see BLOCK

on the board and try to
help.

Product owner wants

Developers to work on
more but must wait.

FIS UCSY 64
 Developer come up with
solution to prevent issue
from happening again.

Product Owner sees

blockage and notifies
upstream management.

Item un-blocked and

work-flow proceeds in
improved system.

FIS UCSY 65
DevOps (Development Team & Operation Team)

Created to combine Development and Operations.

DevOps attempts to apply agile and lean development principles across the entire
software supply chain.
Is a software development method which focuses on communication, integration, and
collaboration among IT professionals to enables rapid deployment of products.
DevOps enhances customers’ experiences by reacting quickly to changes in their needs
or desires.
DevOps can provide organizations with increased capacity to innovate by reducing
rework and allowing shifts to higher business value activities.
By using DevOps techniques to decrease their time to deployment.

FIS UCSY 66
DevOps (Development Team & Operation Team)

Deployment Team Operation Team

Fig: An overview of the DevOps workflow
FIS UCSY 67
DevOps
The DevOps approach involves several stages that loop continuously until the desired
product exists:
Continuous development
Software deliverables are broken down and developed in multiple sprints with the
increments delivered to the quality assurance members of the development team for
testing.
Continuous testing
Automated testing tools are used to help team members test multiple code increments
at the same time to ensure they are free of defects prior to integration.
Continuous integration
The code pieces with new functionality are added to the existing code and to the run-
time environment and then checked to ensure there are no errors after deployment.

FIS UCSY 68
DevOps (Cont’d)

Continuous deployment
At this stage the integrated code is deployed (installed) to the production environment,
which might include multiple sites globally that need to be prepared to receive the new
functionality.
Continuous monitoring
Operations staff who are members of the development team help to improve software
quality by monitoring its performance in the production environment and proactively
looking for possible problems before users find them.

FIS UCSY 69
DevOps (Cont’d)

Continuous deployment
At this stage the integrated code is deployed (installed) to the production environment,
which might include multiple sites globally that need to be prepared to receive the new
functionality.
Continuous monitoring
Operations staff who are members of the development team help to improve software
quality by monitoring its performance in the production environment and proactively
looking for possible problems before users find them.

FIS UCSY 70
 Comparing agile techniques
Process Pros
Scrum The product owner sets priorities.
The team owns decision making.
Documentation is lightweight.
It supports frequent updating.
XP It emphasizes customer involvement.
It establishes rational plans and schedules.
There is high developer commitment to the project.
There is reduced likelihood of product rejection.
Kanban It has lower budget and time requirements.
It allows for early product delivery.
Process policies are written down.
There is continuous process improvement.
DevOps There is reduced time to code deployment.
The team has developers and operations staff.
The team has end-to-end project ownership.
There is proactive monitoring of deployed product.
FIS UCSY
Cons
It is difficult to control the cost of changes.
It may not be suitable for large teams.
It requires expert team members.
There is temptation to “ship” a prototype.
It requires frequent meetings about increasing costs.
It may allow for excessive changes.
There is a dependence on highly skilled team members.
Team collaboration skills determine success.
Poor business analysis can doom the project.
Flexibility can cause developers to lose focus.
Developer reluctance to use measurement.
There is pressure to work on both old and new code.
There is heavy reliance on automated tools to be
effective.
Deployment may affect the production environment.
It requires an expert development team.
71
Summary
Agile—to define maneuverable, adaptive, lean processes that can accommodate the
needs of modern business.
An agile philosophy for software engineering stresses four key issues:
 the importance of self-organizing teams that have control over the work they
perform,
 communication and collaboration between team members and between
practitioners and their customers,
 a recognition that change represents an opportunity,
 an emphasis on rapid delivery of software that satisfies the customer.
Agile process models have been designed to address each of these issues.

FIS UCSY 72
Summary
Agile developers work on self-directed teams and are empowered to create their own
process models.
Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight time lines, changing requirements, and business
criticality.

FIS UCSY 73
 End of Chapter 3

hsumyatmo@ucsy.edu.mm

FIS UCSY 74