SOFTWARE ENGINEERING

(CSE 2014)
Module 3
Agile Principles & Devops
Department of Computer Science and Engineering
School of Engineering,
PRESIDENCY UNIVERSITY
Module 3
• Agile: Scrum Roles and activities, Sprint Agile software
development methods - Scaling, User Stories, Agile estimation
techniques, Product backlogs, Stake holder roles, Dynamic System
Development Method.
• Devops: Introduction, definition, history, tools.
Agile Technology
• The Agile methodology is a way to manage a project by
breaking it up into several phases. It involves constant
collaboration with stakeholders and continuous improvement at
every stage.
• Once the work begins, teams cycle through a process of
planning, executing, and evaluating.
The Key Values and Principles 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.
SCRUM Roles
1. Scrum Master
• A Scrum Master is responsible for ensuring a Scrum team is
operating as effectively as possible with Scrum values.
Some of the responsibilities are
• Facilitate daily Scrum meetings (also called “daily standups”)
• Lead sprint planning meetings
• Conduct “retrospective” reviews to see what went well and what
can be improved for the following sprint
• Keep a pulse on team members, through individual meetings or
other means of communication.
• Manage obstacles that arise for the team by communicating with
stakeholders outside of the team
SCRUM Roles
2. Product owner
A product owner ensures the Scrum team aligns with overall
product goals. They understand the business needs of the product,
like customer expectations and market trends.
Some of the responsibilities are
• Manage the product backlog by ordering work by priority
• Set the product vision for the team
• Communicate with external stakeholders and translate their
needs to the team
• Make sure the team is focused on hitting product needs through
communication and evaluating progress
SCRUM Roles
3.Development team
A development team is composed of professionals who do the
hands-on work of completing the tasks in a Scrum sprint. This
means development team members can be computer engineers,
designers, writers, data analysts, or any other role needed to reach
sprint goals.
Some of the responsibilities are
• Help in sprint planning and goal setting
• Lend expertise to program, design, or improve products
• Use data to find best practices for development
• Test products and prototypes, plus other forms of quality assurance
SCRUM Activities
• There are five Scrum Events,
• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective.
Sprint Planning
• The Sprint Planning event takes place on the first day of the Sprint.
• Its purpose is to plan the work to be done during the Sprint and the
whole Scrum Team is involved in this event.
• Sprint Planning should have roughly three parts. Topic One should
focus on the “Why?”. The outcome should be a defined Sprint Goal.
Topic Two covers the “What?”. During this topic, the developers
should work to decide which Product Backlog Items are going to be
worked on during the Sprint, and if necessary, refine the Sprint Goal
to reflect this. Finally, Topic Three deals with the “How?”. During this
final stage of the meeting, the developers create an actionable plan
to get the work done.
Daily Scrum
• The Daily Scrum is the moment where the Developers step back for
15 minutes, analyze where they are in respect to the Sprint Goal,
and collectively decide what is the most important thing each
Developer has to do in the next 24 hours to get closer to the Sprint
Goal.
• It is a planning meeting, not a generic synchronization meeting.
• It is important to focus the conversation on the most important
Sprint Backlog Items, not on individuals stating what they have
done.
• The Daily Scrum is not a status report meeting. The SM should help
create the right environment to encourage open communication,
identify obstacles, and promote quick decision-making.
Sprint Review
• The sprint review is a Scrum event that takes place at the
end of the sprint, just before the retrospective.
• The purpose of the review is to evaluate the latest features and
to consider the plan for the product in the future.
• The purpose of the Sprint Review is to inspect the outcome of
the Sprint and determine future adaptations.
• The Scrum Team presents the results of their work to key
stakeholders and progress toward the Product Goal is
discussed.
Sprint Retrospective
• The final Scrum Event is the Sprint Retrospective.
• The Sprint Retrospective is the only event in Scrum that is
exclusive to the Scrum Team.
• The intention is to create a safe space where everyone in the
Scrum Team feels comfortable to openly share their observations
and express their views and ideas.
• The purpose of the event is to inspect how the last Sprint went
and plan ways to increase quality and effectiveness.
Scrum vs. sprint
• Scrum is the specific, framework used under the Agile umbrella
to develop complex products. The term scrum is also used to
describe the daily, standup meetings that occur during a sprint.
• Sprints are time-boxed periods of one week to one month,
during which a product owner, scrum master, and scrum team
work to complete a specific product addition. During a sprint,
work is done to create new features based on the user stories
and backlog. A new sprint starts immediately after the current
sprint ends.
Agile Estimation
• Agile estimation is the process for estimating the effort
required to complete a prioritized task in the product
backlog. This effort is usually measured with respect to the
time it will take to complete that task, which, in turn, leads to
accurate sprint planning.
• Agile estimation helps for proper planning, management and
estimation of the total efforts that will be used for implementing,
testing and delivering the desired product to the customers in
terms of time within the specified deadlines. A well-prepared
preliminary estimate is essential.
Agile Estimation Techniques
• Three-point estimate
• Planning poker
• Affinity grouping
• Random distribution
• T-shirt sizes (Estimation units)
• Buckets
• Large, small, uncertain
• Dot voting
Stakeholder Roles

 In simple words, anyone having any type of

relation/interest in the project is known as stakeholder.
The term Software Project Stakeholder refers to, “a
person, group or company that is directly or indirectly
involved in the project and who may affect or get affected
by the outcome of the project”.
 What is Stakeholder Identification?
It is the process of identifying a person, group or a
company which can affect or get affected by a decision,
activity or the outcome of the software project. It is
important in order to identify the exact requirements of
the project and what various stakeholders are expecting
from the project outcome

Dept. of CSE, SOE, Presidency University

17
Dept. of CSE, SOE, Presidency University
18
Type of Stakeholders:
1.Internal Stakeholder:
An internal stakeholder is a person, group or a company that is
directly involved in the project.
a)Project Manager:
Responsible for managing the whole project. Project Manager is
generally never involved in producing the end product but he/she
controls, monitors and manages the activities involved in the
production.
b)Project Team:
Performs the actual work of the project under the Project Manager
including development, testing, etc.
c)Company:
Organisation who has taken up the project and whose employees are directly
involved in the development of the project.
d)Funders:
Provides funds and resources for the successful completion of the project.
2. External Stakeholder:
An external stakeholder is the one who is linked indirectly to the project but
has significant contribution in the successful completion of the project.
For example,
a)Customer:
Specifies the requirements of the project and helps in the elicitation process of
the requirement gathering phase. Customer is the one for whom the project is
being developed.
b)Supplier:
Supplies essential services and equipment for the project.
c)Government:
Makes policies which helps in better working of the organization.
Dynamic Systems Development Method
(DSDM)
• The Dynamic Systems Development technique (DSDM) is an
associate degree agile code development approach that provides a
framework for building and maintaining systems.
• The DSDM tool (www.dsdm.org) could be a worldwide cluster of
member companies that put together tackle the role of “keeper” of
the strategy. The pool has outlined AN Agile Development Model,
known as the DSDM life cycle that defines 3 different unvarying
cycles, preceded by 2 further life cycle activities:
• Feasibility Study:
It establishes the essential business necessities and constraints
related to the applying to be designed then assesses whether or
not the application could be a viable candidate for the DSDM
method.
DSDM life cycle
• Business Study:
It establishes the use and knowledge necessities that may permit
the applying to supply business value; additionally, it is the
essential application design and identifies the maintainability
necessities for the applying.
• Functional Model Iteration:
It produces a collection of progressive prototypes that
demonstrate practicality for the client.

• The intent throughout this unvarying cycle is to collect further

necessities by eliciting feedback from users as they exercise the
paradigm.
• Design and Build Iteration:
It revisits prototypes designed throughout useful model iteration
to make sure that everyone has been designed during a manner
that may alter it to supply operational business price for finish
users. In some cases, useful model iteration and style and build
iteration occur at the same time.
• Implementation:
It places the newest code increment (an “operationalized”
prototype) into the operational surroundings. It ought to be noted
that:
• (a) the increment might not 100% complete or,
• (b) changes are also requested because the increment is placed into
place. In either case, DSDM development work continues by returning to
the useful model iteration activity.
• DSDM is often combined with XP to supply a mixed approach that
defines a solid method model (the DSDM life cycle) with the
barmy and bolt practices (XP) that are needed to create code
increments. additionally, the ASD ideas of collaboration and self-
organizing groups are often tailored to a combined method model.
Agile software development
methods

Department of Computer Science and Engineering

School of Engineering, Presidency University
Agile software development

 Agile software development -- is a type of development

methodology that anticipates the need for flexibility and applies a
level of pragmatism to the delivery of the finished product.
 Agile software development requires a cultural shift in many
companies because it focuses on the clean delivery of individual
pieces or parts of the software and not on the entire application.

Dept. of CSE, SOE, Presidency University

27
 Scaling
The process of translating established Agile methods, like Scrum
and Kanban, to larger groups of people.
Traditional Agile teams, according to the Scaled Agile
Framework (SAFe), work best with groups of five to eleven
members.
As companies see success in these small groups, they often want
to replicate it at a larger team, department, or organizational level.
That’s where scaling Agile comes in.
Scaling Agile is a systematic approach for achieving enterprise
wide goals, by extending an organization’s existing implemented
agile framework to multiple teams.

Dept. of CSE, SOE, Presidency University

28
 There are two conventional ways

Bottom up and Top down

 For a bottom up approach, you need to start scaling from the
team level and go upwards to other teams and management in
the organization. This works perfectly for teams that are
independent of each other’s work. But if the teams are
dependent on each other, then you need to revaluate your
strategy.
 The top down approach is when the agile transition is embraced
by the higher management first, and then it trickles down to the
team level. This can be better achieved by hiring a consultant or
an agile coach that can guide you towards transitioning to
scaling agile.

Dept. of CSE, SOE, Presidency University

29
Popular Scaling Agile
models

• Scaled Agile Framework (SAFe)

• Disciplined Agile (DA)
• Large Scale Scrum (LeSS)
• Tribe

Dept. of CSE, SOE, Presidency University

30
Benefits of Scaling
Agile
• Following consistent process and practices
• Getting executive support from stakeholders
• Using common tools across the teams
• Consultation or help from agile coaches
• Strong foundation of contextual agile knowledge
• Shorter time to market
• More flexible and responsive work environment
• Mutual respect for co-workers
• Increased overall productivity
• Decentralized decision making

Dept. of CSE, SOE, Presidency University

31
User Stories

• In Agile software development and product management User Story

refers to a short, informal, and simple description of software features
that are required by the end-users in the software system.
• Its main purpose is to provide software features that will add value to
the customer requirements.
• User stories are considered an important tool in Incremental software
development.
• Mainly a user story defines the type of user, their need, and why they
need that.
• So in simple, a user story is a simple description of requirements that
needs to be implemented in the software system.

Dept. of CSE, SOE, Presidency University

32
Pattern of User Story
User stories are completely from the end-user perspective which
follows the Role-Feature-Benefit pattern.

As a [ type of user ], I want [ an action ], so that [ some reason ]

For example :
As the project manager of a construction team, I want our team-
messaging app to include file sharing and information update so that
my team can collaborate and communicate with each other in real-time
as a result the construction project development and completion will be
fast.

Dept. of CSE, SOE, Presidency University

33
 Writing User Stories
• User stories are from a user perspective. So when user stories are
written, users are given more importance during the process.
• Some points outlined which are taken into consideration during
writing user stories like
1.Requirements
2.Tasks and their subtasks
3.Actual user
4.Importance to user words/feedback
5.Breaking user stories for larger requirements

Use Case Diagram of Safe Home System

Dept. of CSE, SOE, Presidency University
34
Importance of creating User stories

1. Stories clear idea about requirements

2. Makes it easy to understand the features
3. Delivers higher customer satisfaction
4. Fasten development process
5. Creates an effective work environment
6. Enables collaboration between teams
7. Delivery of valuable software

Dept. of CSE, SOE, Presidency University

35
DEVOPS

1. Introduction
2. Definition
3. History
4. Tools
What is DevOps?
• The word DevOps is a combination of two words
Development and Operations.
• Before getting into what DevOps is, let us get an idea
about the two teams involved in software development.
• The development team is responsible for developing,
designing, and building the application.
• The operation team deals with the deployment and
testing of the application.
• If there are problems with the application, the operation
team also provides feedback to the development team.
History of Devops
Let us see some important events of DevOps :

• 2007-2008: The DevOps idea was started

• 2009: In the initial stage the first conference was ”
Deploys a day: Dev and Ops cooperation of
flicker.” Another conference called “DevOps Days in
Ghent, Belgium” also happened.
• 2010:DevOps days conference happened in the United
States at mount view, calif.
History of DevOps

• 2012: Allana browns at puppet creates a state of DevOps

report
• 2014: Publishing the annual “State of DevOps report”
• 2017: Forrester Research calls 2017 “The Year of DevOps
”
• 2018: 30 DevOps day conferences were scheduled across
the united states.
Why did we need DevOps?

• As we know about the problems faced in traditional models

like in the waterfall model there is a problem of a one-way
stream of work.
• Due to which if there is any mistake the whole process
repeats and there is no interaction with customers.
• Now, this is solved in agile by splitting the whole
development plan into several iterations for a better level of
production efficiency.
Why did we need DevOps?
• The agile model also includes customer interaction with
the company to rectify the mistakes. But there is another
problem faced in Agile too.
• Here, the problem arises when the development team
continuously changes the code for better performance
and sends the code to the operations team for testing.
• But there may be a delay in the operations team feedback
in situations like if the developers sent code for review at
night but due to the unavailability of the operations team,
there will be a delay in the project feedback.
Why did we need DevOps?

• So, DevOps is the solution to this problem.

• DevOps is a practice or a methodology in which the
development team and operations team work together by
including automation at the initial stages.
• So they can work on rapidly changing systems, fix bugs,
and help to deliver a good quality of software in time.
Why did we need DevOps?
DevOps Architecture:
DevOps Architecture:
• Plan – In DevOps planning plays an important role. In this
stage, all the requirements of the project and everything
regarding the project like time for each stage, cost. etc are
discussed.
• Code – In this Stage the code is written over here
according to the client’s requirements. Here the code is
divided into small codes called Units. Some of the
examples of the tools used are Git, JIRA
• Build – In this stage Building of the units is done. Some of
the examples of the tools used are maven, Gradle.
 DevOps Architecture:

• Test – Testing of all units is done in this stage. So we will get

to know where exactly the code is having bugs and if there
are mistakes found it is returned. Some of the examples of the
tools used are Selenium, Pytest
• Integrate – In this stage, all the units of the codes are
integrated. That means in this step we will be creating a
connection between the development team and the operation
team to implement Continuous Integration and Continuous
Deployment. An example of the tool used is Jenkins.
• Deploy – In this stage, the code is deployed on the client’s
environment. Some of the examples of the tools used are
AWS, Docker.

Dept. of CSE, SOE, Presidency University

46
DevOps Architecture:

• Operate – Operations are performed on the code if

required. Some of the examples of the tools used are
Kubernetes, open shift.
• Monitor – In this stage monitoring of the application is
done over here in the client’s environment. Some of the
examples of the tools used are Nagios, elastic stack.

Dept. of CSE, SOE, Presidency University

47
How is DevOps different from Agile?

DevOps Agile

DevOps deals with filling the time gap between the Agile methodology deals with filling the gap between
development team and the operations team. customers and the company.

Here the feedback will be coming from the Operations Here the feedback will be coming from the customers to
team to the development team. the company.

It focuses on constant testing and delivery. It focuses on constant changes.

Some of the tools used in DevOps: Puppet, AWS Some of the tools used for Agile: JIRA, Bugzilla,
Kanboard

Dept. of CSE, SOE, Presidency University

48
DevOps automation tools
• These are some of the popular DevOps automation tools:
• Jenkins. Jenkins. Jenkins is an open source and free automation
server that helps automate software development processes such
as building, facilitating CI/CD, deploying, and testing. ...
• Docker. Docker. ...
• Puppet. Puppet. ...
• Apache Maven. Apache Maven. ...
• Gradle. Gradle.
• END OF MODULE