Agile Practical File Ekansh
Agile Practical File Ekansh
TECHNOLOGY
JALANDHAR
Understand the
1 3-5
background and
driving forces for
taking an agile
approach to
software
development
Understand the
background and
driving forces for
taking an agile
approach to
software
development
2
Understand the
background and
driving forces for
taking an agile
approach to
software
development
Understand the background and driving forces for taking
an Agile Approach to Software Development.
3
Task 1: Understand the background and driving forces for taking an Agile Approach
to Software Development.
Principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of
months ,with a preference to the shortest timescale.
4. Build projects around motivated individuals. Give them the environment and the
support they need, and trust them to get the job done.
5. Working software is the primary measure of progress.
6. Simplicity the art of maximizing the amount of work not done is essential.
5
7. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation
7
●Agile development is heavily dependent on the inputs of the customer. If the customer
has ambiguity in his vision of the final outcome, it is highly likely for the project to get off
track.
●Face to Face communication is harder in large-scale organizations.
●Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it’s a difficult situation for new programmers to adapt to the
environment.
8
feedback from customers
and stakeholders, enabling
teams to quickly respond to
changing requirements and
deliver value. This approach
leads to higher customer
satisfaction because the
customer is involved in the
development process and
can see the
product evolving and
responding to their needs.
2. Flexibility: Agile
development allows teams
to adapt to change and
respond quickly to
9
shifting priorities and new
information, making it ideal
for complex and rapidly
changing
environments. The Agile
approach is designed to be
flexible, with a focus on
delivering
value incrementally and
iteratively, making it easier
for teams to adapt to
changing
requirements.
3. Collaboration: Agile
development encourages
collaboration between
cross-functional
10
teams, including
developers, product
owners, and stakeholders,
leading to better
decision-making and faster
delivery. Teams work
together to define and
prioritize
requirements, and regular
meetings, such as daily
stand-ups, help keep
everyone on the
same page.
4. Quality: Agile
development prioritizes
regular testing and
11
inspection, enabling teams
to
catch and fix defects early
in the development
process, leading to higher-
quality software.
By regularly testing and
inspecting code, teams can
catch and fix defects early,
reducing
the risk of more serious and
expensive problems down
the line.
5. Predictable delivery:
Agile development uses
iterative development
cycles and frequent
12
releases, allowing teams to
make steady progress and
deliver value to customers
faster.
The Agile approach
provides a more predictable
delivery schedule, with
regular releases
and a focus on delivering
value incrementally,
enabling teams to meet
customer needs
and expectations.
6. Increased productivity:
The Agile approach focuses
on delivering value
incrementally
13
and iteratively, enabling
teams to work more
efficiently and effectively.
Teams are
empowered to make
decisions and take
ownership of their work,
leading to increased
motivation and
productivity.
The following provides
a practical
understanding of the
background and
14
driving forces behind
the adoption of the
Agile approach:
1. Customer satisfaction:
Agile development places a
strong emphasis on
continuous
feedback from customers
and stakeholders, enabling
teams to quickly respond to
changing requirements and
deliver value. This approach
leads to higher customer
satisfaction because the
customer is involved in the
development process and
can see the
15
product evolving and
responding to their needs.
2. Flexibility: Agile
development allows teams
to adapt to change and
respond quickly to
shifting priorities and new
information, making it ideal
for complex and rapidly
changing
environments. The Agile
approach is designed to be
flexible, with a focus on
delivering
value incrementally and
iteratively, making it easier
16
for teams to adapt to
changing
requirements.
3. Collaboration: Agile
development encourages
collaboration between
cross-functional
teams, including
developers, product
owners, and stakeholders,
leading to better
decision-making and faster
delivery. Teams work
together to define and
prioritize
requirements, and regular
meetings, such as daily
17
stand-ups, help keep
everyone on the
same page.
4. Quality: Agile
development prioritizes
regular testing and
inspection, enabling teams
to
catch and fix defects early
in the development
process, leading to higher-
quality software.
By regularly testing and
inspecting code, teams can
catch and fix defects early,
reducing
18
the risk of more serious and
expensive problems down
the line.
5. Predictable delivery:
Agile development uses
iterative development
cycles and frequent
releases, allowing teams to
make steady progress and
deliver value to customers
faster.
The Agile approach
provides a more predictable
delivery schedule, with
regular releases
and a focus on delivering
value incrementally,
19
enabling teams to meet
customer needs
and expectations.
6. Increased productivity:
The Agile approach focuses
on delivering value
incrementally
and iteratively, enabling
teams to work more
efficiently and effectively.
Teams are
empowered to make
decisions and take
ownership of their work,
leading to increased
motivation and
productivity.
20
Task 2: Build out a backlog and user stories.
Product Backlog
The product backlog is the list of all the work that needs to get done. It usually
contains user stories, bugs, technical tasks, and knowledge acquisition. The
backlog is periodically refined by the product owner and scrum team to ensure
2–3 sprints worth of work is always defined and prioritized.
Detailed: Sufficiently detailed such that any member of the scrum team can
work on the user stories independently
Emergent: Flexible, work will fluctuate based on the needs of the team,
business, or customer
Estimated: Size and complexity is estimated using story points — If a story
comes with a high estimate, it is likely large enough to break apart into more
than one user story
Prioritized: User stories are ordered in the backlog based on product priority
— If all stories in the sprint are completed early the team should pull in the
next user story on the backlog
Backlog refinement sessions are led by product managers. You will always want
your user stories to meet the INVEST criteria. Some simple tips to make that
refinement meeting run smoothly:
User Stories
User stories are simple, powerful constructs that describe functionality from the
point of view of your user. Simple enough! They usually look something like
this:
As a <role or personal>, I can <goal or need>, so that <why>
As a <user class>, I want to <perform or do something>, so that <I get
some value or benefit>
User stories need to meet specific criteria to be considered “ready” by the scrum
team. The most popular is INVEST:
Valuable: Demonstrated value to the business and the user — each user story
represents an increment of product that can be demonstrated to a potential
customer of the system
Estimable: Sufficient knowledge about how the user story will be developed
(and tested) that the scrum team can provide a high-level estimate for how
long the user story will take to implement
Sized to Fit: Such that the work to deliver the user story can be completed in
a sprint to facilitate faster time to market and feedback from customers
Let’s expand on testable criteria. Every great user story has even better
acceptance criteria! Acceptance criteria is focused on the intended outcome as a
result of the action specified in the user story. It should always focus on “what”
instead of “how”. Here is a simple format to follow when writing your
22
acceptance criteria:
23
Task 3: To study and use automated build tool.
Jenkins
Price: Free
Fig.1 Jenkins
Jenkins is an open-source tool. It can perform the task of building, testing, and
deploying software. The platform is easy to install. For any project, Jenkins will
work as a CI server and as a continuous delivery hub. It has features of
extensibility and easy configuration.
24
Features:
o Testing of isolated changes in a larger codebase.
o Automation of testing of builds.
o Work Distribution.
o Automation of software deployment.
Verdict: You will get good community support for Jenkins. It supports all major
platforms. It
can test and deploy on multiple platforms at a fast rate. It can distribute the work
across multiple machines.
25
Best for small to large businesses.
Website: Jenkins
Maven
Price: Free
Fig 2 Maven
Features:
o It supports working on multiple projects simultaneously.
o There will be consistent usage for all projects.
o It has features for dependency management.
o It provides a large and growing repository of libraries and metadata.
o It provides functionality for release management: It can distribute individual
outputs.
o For managing the releases and distributing the publications, Maven will
get integrated with your system. No additional configuration will be
required for this.
Verdict: As per the customer reviews, the tool is good for build automation and
dependency management. For dependency management, it provides support to
the central repository of JARs.
Best for small to large businesses
26
Website: Maven
Gradle
Price: Gradle offers a free trial of 30 days for Gradle Enterprise. You can
contact the company for the pricing of Enterprise subscriptions.
Fig 3 Gradle
Gradle can be used for multiple project types i.e. mobile apps to microservices.
It has functionalities for building, automating, and delivering software. It is an
open-source platform. For dependency management, it provides the
functionalities like transitive dependencies, custom dependency scopes, file-
based dependencies, etc.
Features:
For software development, it will allow you to use any programming language.
It can deploy on any platform.
It supports monorepos as well as multi-repo strategy.
It will help you to deliver continuously.
It has various execution options like Continuous build, Composite
Builds, Task Exclusion, Dry Run, etc.
Verdict: As per the customer reviews it has good integration capabilities.
Gradle has features of web-based build visualization, collaborative debugging,
parallel execution, incremental builds, task time outs, etc.
Best for small to large businesses
Website: Gradle
Travis CI
Price: It is free to test open-source projects. It provides the first 100 builds for
27
free. There are four pricing plans i.e. Bootstrap ($69 per month), Startup ($129
per month), Small Business ($249 per month), and Premium ($489 per month).
Fig 4 Travis CI
GitHub projects can be synced with Travis CI. It can perform auto deployments
on passing the builds. It will be able to deploy on multiple cloud services. The
tool can be used by signing up and linking the repository. It will allow you to
build the apps and test them.
Features:
GitHub integration.
It has pre-installed database services.
It supports pull requests.
It will provide a clean VM for every build.
Verdict: Travis CI is easy to install and configure. It has a clean interface. This tool
will be
the best option if you are creating an open-source project as it provides free
services for open- source projects.
Best for small to large businesses
Website: Travis CI
Bamboo
Price: The price of Bamboo will be based on the number of agents. An increase
in the number of agents will increase the number of processes that can run
concurrently. It provides a free trial of 30 days. Bamboo offers two pricing plan
28
i.e. for small teams and growing teams.
The plan for small teams will cost you $10 (No remote agent) for a maximum
of 10 jobs. The plan for growing teams will cost you $1100 (One remote agent)
with unlimited jobs.
Fig 5 Bamboo
Features:
It will allow you to create multi-stage build plans.
You can assign agents to critical builds and deployments.
The tool can run parallel automated tests.
It can release in each environment.
While releasing, the flow can be controlled through pre-environment settings.
Verdict: With this tool, all tasks like automated builds, tests, and releases can be done
in one
workflow. It has various built-in capabilities and doesn’t require plugins.
Best for small to large businesses.
29
Task 4: To study version control tool.
Introduction
A version control system (VCS) tracks changes to a file or set of files over time.
The most common type is a centralized VCS, which uses a server to store all the
versions of a file. Developers can check out a file from the server, make
changes, and check the file back in. The server then stores the new version of
the file.
The two most popular types are centralized and distributed. Centralized version
control systems store all the files in a central repository, while distributed
version control systems store files across multiple repositories. Other less
30
common types include lock-based and optimistic.
31
Lock-Based: A lock-based version control system uses file locking to manage
concurrent access to files and resources. File locking prevents two or more users
from making conflicting changes to the same file or resource.
Optimistic: In an optimistic version control system, every user has their own
private workspace. When they want to share their changes with the rest of the
team, they submit a request to the server. The server then looks at all the
changes and determines which ones can be safely merged together.
Quality: Teams can review, comment, and improve each other’s code and assets.
Acceleration: Branch code, make changes, and merge commits faster.
Visibility: Understand and spark team collaboration to foster greater release
build and release patterns.
The three most well-known version control tools are Git, Subversion, and Mercurial.
Git
Git is the most popular option and has become synonymous with "source code
management."Git is an open source distributed system that is used for software
projects of any size, making it a popular option for startups, enterprise, and everything
in between.
Subversion
SVN is a widely adopted centralized VCS. This system keeps all of a project's
files on a single codeline making it impossible to branch, so it's easy to scale for large
projects. It's simple to learn and features folder security measures, so access to
subfolders can be restricted.
Mercurial
Mercurial is a distributed VCS that offers simple branching and merging
capabilities. The system enables rapid scaling and collaborative development, with
an intuitive interface. The flexible command line interface enables users to begin
using the system immediately.
32
Task 5: To study Continuous Integration tool.
Introduction
Continuous integration (CI) is an agile and DevOps best practice that enables
multiple developers to contribute and collaborate in a shared code base at a rapid
pace. Without continuous integration, developer collaboration is a tedious manual
process of coordinating code updates and merges.
Automated testing: Most serious software projects include an additional code base
that is not explicitly responsible for the business product and features. This
secondary code base is a test suite and acts as a set of assertions that assures
the primary code base is working correctly without bugs. During development,
these tests are run by developers to validate that new code has not caused any
regression on existing features. These test cases can also be run by extraneous tools
to automate this validation process. CI service products will automatically run the
test cases for a project on user-specified events. Generally, when a developer pushes
code using the version control system an event will trigger the full test suite to run
automatically.
Build Automation: “Builds” are the artifacts created to snapshot the current release
version of a software project. Builds are distributed to end users through various
networks. There is generally a set of scripted steps a project will take to create a
build artifact. CI tools help streamline this build process with the use of automatic
triggers from the version control system. One example trigger would be when new
code is merged to the production branch of the codebase upload the build to a
remote server for users to download.
33
Automated Deployments: When builds are ready to be distributed they go through
a deployment process. Depending on the project deployment can have a variety of
outcomes. For example, web projects are deployed to publicly accessible web
servers. During this deployment, the artifact that was generated in the build phase is
copied onto the web servers. The deployment process for mobile and desktop vary
and may involve uploading to a ‘store’ so users may download the app.
Continuous Integration Tools
Bitbucket Pipelines
Bitbucket Pipelines is a CI tool directly integrated into Bitbucket, a cloud version
control system offered by Atlassian. Bitbucket Pipelines is an easy next step to
enable CI if your project is already on Bitbucket. Bitbucket Pipelines are managed
as code so you can easily commit pipeline definitions and kick off builds. Bitbucket
Pipelines, additionally offers CD. This means projects built with Bitbucket Pipelines
can be deployed to production infrastructure as well
Website: https://bitbucket.org/product/features/pipelines
Jenkins
Jenkins is a veteran CI Tool with a long proven track record. It is open source and
driven by community updates. Jenkins is primarily intended to an on-premise
installation. Jenkins is a great option when your organization needs on-prem support
for handling sensitive customer like HIPAA compliance data.
Website: https://jenkins.io/
Circle CI
Circle CI is CI Tool that gracefully pairs with Github, one of the most popular
version control system cloud hosting tools. Circle Ci is one of the most flexible CI
Tools in that it supports a matrix of version control systems, container systems, and
delivery mechanisms. Circle Ci can be hosted on-premise or used through a cloud
offering.
Website: https://circleci.com/
GitLab
Gitlab is a new CI Tool which offers a full DevOps experience. Gitlab was created
with intentions to improve Github’s overall experience. Gitlab offers a modern UX
with container support.
34
Website: https://about.gitlab.com
Atlassian Bamboo
Another CI offering from Atlassian. Whereas Bitbucket Pipelines is purely a cloud
hosted option, Bamboo offers a self hosted alternative
35
Task 6: Apply Design principle and Refactoring to achieve agility.
DesignPrinciple
1. Single-Responsibility Principle
“There should be never more than one reason for a class to change.”
As you can see, this principle states that an object/class should only have one
responsibility and that it should be completely encapsulated by the class. Here,
when we talk about a responsibility, we mean a reason to change. This principle
will lead to a stronger cohesion in the class and looser coupling between
dependency classes, better readability, and code with lower complexity.
It is much more difficult to understand and edit a class when it has various
responsibilities. So if we have more than one reason to change, the
functionality will be split into two classes and each will handle its own
responsibility.
We care about separating the functionalities because each responsibility is an
access of change. When a class has more than a single responsibility, those
responsibilities become coupled and this coupling can lead to a fragile code base
that is difficult to refactor when your requirements emerge.
2. Open-Closed Principle
“Software entities (classes, modules, functions, etc.) should be open for
extension, but closed for modification.”
Here, the idea is that an entity allows its behavior to be extended but never by
modifying its source code. Any class (or whatever you write) should be written
in such a way that it can be used as is. It can be extended if need be, but it can
never be modified. You can consider this when you are writing your classes.
Use the class in any way you need, but modifying its behavior comes by adding
new code, never by modifying the old. The same principle can be applied to
modules, packages, and libraries.
By applying the open-closed principle you will get a loose coupling, you
will improve readability and, finally, you will be reducing the risk of
breaking existing functionality.
Here, it’s about how to write interfaces. So what is stated? Basically, once an
interface is becoming too large/fat, we absolutely need to split it into small
interfaces that are more specific. And the interface will be defined by the client
that will use it, which means that the client of the interface will only know
about the methods that are related to them.
Actually, if you add methods that shouldn’t be there, the classes implementing
the interface will have to implement those methods as well. That is why the
client shouldn’t be forced to depend on interfaces that they don’t use. ISP is
intended to keep a system decoupled and thus easier to refactor, change, and
deploy.
The last of the SOLID principles, but not the least, this principle is primarily
concerned with reducing dependencies amongst the code modules. Basically,
the Dependency Inversion Principle will be of a great help when it comes to
understanding how to correctly tie your system together.
If your implementation detail will depend on the higher-level abstractions, it
will help you to get a system that is coupled correctly. Also, it will influence
the encapsulation and cohesion of that system.
37
Refactoring
1. The changes make the code easier to understand and thus cheaper to modify.
2. The changes never change the functionality, the observable behavior, of the
code.
That second constraint bears repeating: a refactoring should never change the
behavior of a program. This means that if the program is called before and
after a refactoring with the same set of inputs, the resulting set of output
values will be the same.
Code refactoring aims to keep software from degrading, or, when it’s already
degraded, to improve its design so it becomes easier to understand and change.
Code refactoring is important to eliminate design flaws, achieve
maintainability, and extensibility of a software system.
Crucially, code refactoring changes the design of the code, but never the
behavior of the software. Never the twain shall mix.
The Process of Refactoring
38
1. Ensure you can back out — restore to a version that was proven to work
correctly. Make sure you’ve committed all your changes and all tests
against the committed code succeed. This way you can restore back to
this point if your refactoring doesn’t go as you envisioned.
2. Identify what you want to refactor and how — which refactorings to use.
3. If you have multiple refactorings to execute to accomplish a bigger
restructure, you can optionally, select a subset of automated tests to verify
unchanged behavior after each individual refactoring.
4. Iteratively: apply a refactoring and verify behavior is unchanged. If the
tests show you did change the behavior, change the code, never the tests.
5. If you used a subset of automated tests during the refactoring process, run
all tests to verify unchanged behavior for the whole application.
Here again, if something broke, change the code to make the tests pass —
don’t change the tests.
If you realize that you’re just not going to be able to get the tests passing
again in a reasonable amount of time, restore back to the working code
you had before the refactoring process.
Benefits
More readable code! Be sure to give the new method a name that
describes the method’s purpose: createOrder(), renderCustomerInfo(),
etc.
Isolates independent parts of code, meaning that errors are less likely
(such as if the wrong variable is modified)
39
Task 7: Perform Testing activities within an agile project.
Agile Methodologies
There are several Agile Methodologies that support Agile Development. The
Agile Methodologies include −
40
Scrum
Scrum is an Agile development method that emphasizes on team-centric approach.
It advocates participation of the entire team in all the project development
activities.
XP
Extreme programming is customer-centric and focuses on constantly
changing requirements. With frequent releases and customer feedback, the
end-product will be of quality meeting customer requirements that are
made clearer during the process.
FDD
Feature Driven Development (FDD) involves designing and building
features. The difference between FDD and other Agile Development
Methodologies is that the features are developed in specific and short
phases separately.
DSDM
Dynamic Software Development Method (DSDM) is based on Rapid
Application Development (RAD) and is aligned to the Agile Framework.
DSDM focuses on frequent delivery of the product, involving users
actively and empowering the teams to make quick decisions.
Lean Software Development
In Lean Software Development, focus is on eliminating waste and giving value
to the customer. This results in rapid development and product of value.
Waste includes partially done work, irrelevant work, features that are not used
by the customer, defects, etc. that add to delays in delivery.
Kanban
Kanban focuses on managing work with an emphasis on just-in-time (JIT)
delivery, while not overloading the team members. The tasks are
displayed for all the participants to see and for the Team Members to pull
work from a queue.
Kanban is based on −
Kanban Board (Visual and Persistent across the Development)
Work-in-progress (WIP) Limit
Lead Time
41
Agile Testing Methodologies
The testing practices are well defined for every project, whether Agile or
not, to deliver quality products. Traditional Testing principles are quite
often used in Agile Testing. One of them is Early Testing that focuses on −
o Writing Test Cases to express the behavior of the system.
o Early Defect Prevention, detection and removal.
o Ensuring that the right test types are run at the right time and as part
of the right test level.
In all the Agile Methodologies we discussed, Agile Testing in itself is a
Methodology. In all the approaches, Test Cases are written before Coding
The other commonly used Agile Testing Methodologies are −
Test-Driven Development (TDD) − Test-Driven Development (TDD)
is based on coding guided by tests.
Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven
Development (ATDD) is based on communication between the customers,
developers and testers and driven by pre- defined Acceptance Criteria and
Acceptance Test Cases.
Behavior-Driven Development (BDD) − In Behavior-Driven
Development (BDD) testing is based on the expected behavior of
the software being developed.
42
Testing is iterative and sprints based as depicted in the diagram given
below −
43
Task 8: Mini Project: based on tools
STEP 1: Search gitlab on google
44
STEP 3: Fill your email and password to login or you can directly login using existing
google account
STEP 4: Next , create new project and choose create blank projec
45
STEP 6: Click on create project button given at the bottom
STEP 7: Since you have created a project successfully, so now you can send invitation for
team members to join the group by clicking first on project information and then on
activity
46
STEP 8 : Now , you can see all the team members and can work on the project collectively
47
Creating a milestone
STEP 1: Click on ‘Issues’ and then on ‘Milestones’ present on the left side of the screen
48
STEP 3: Following tab will be opened.
STEP 4: After filling the required details about your project, you can click on ‘create
milestone’
49
STEP 6:Creating a requirement and raising an issue
Step 2:Write the documentation and click on save changes to publish it.
50
Version Control
51
Step 2: For checking the logs in Wikis, click on wiki section
35