Agile Software Development Lab File (2003263)

Department of Computer Science &
Engineering
Subject: Agile Software Development Lab

(BTCS 711-18)
B.Tech 4th Year- 7th Semester
Submitted to: Submitted by:

Mr. Rajeev Sharma Sunny Vats
Assistant Professor 2003263
Chandigarh Engineering College Landran,

Mohali-140307
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
INDEX
SNO. PRACTICALS PAGE NO. REMARKS
1. Understand the background and driving forces for taking an Agile 3-13
Approach to Software Development.
2. Build out a backlog and user stories. 14-22
3. To study automated build tool. 23-28
4. To study version control tool. 29-32
5. To study Continuous Integration tool. 33-40
6. Apply Design principle and Refactoring to achieve agility. 41-51
7. Perform Testing activities within an agile project. 52-57
Sunny Vats_2003263 CEC-Landran Page 2

Practical No. 1
AIM: Understand the background and driving forces for taking an Agile Approach to Software
Development.
OBJECTIVE:
1. Difference between agile software development model and waterfall model.
2. Why Agile is better?
3. Understanding the Agile Manifesto.
4. Discussing Important Characteristics that make agile approach best suited for Software
Development.
THEORY:
1. Difference between agile

software development model and waterfall model.
Waterfall Model-
Waterfall Model methodology which is also known as Liner Sequential Life Cycle Model.
Waterfall Model followed in the sequential order, and so project development team only moves
to next phase of development or testing if the previous step completed successfully.
Agile methodology-
Agile methodology is a practice that helps continuous iteration of development and testing in the
software development process. In this model, development and testing activities are concurrent,
unlike the Waterfall model. This process allows more communication between customers,
developers, managers, and testers.
Agile methodology Waterfall Model

It separates the project development lifecycle Software development process is divided into
into sprints. distinct phases.
It follows an incremental approach. Waterfall methodology is a sequential design

process.
Agile methodology is known for its Waterfall is a structured software

flexibility. development methodology so most times it
can be quite rigid.
Agile can be considered as a collection of Software development will be completed as

many different projects. one single project.
Agile is quite a flexible method which allows There is no scope of changing the
changes to be made in the project requirements once the project development
development requirements even if the initial starts.
planning has been completed.
Agile methodology, follow an iterative All the project development phases like
development approach because of this designing, development, testing, etc. are
planning, development, prototyping and other completed once in the Waterfall model.
software development phases may appear
more than once.
Test plan is reviewed after each sprint. The test plan is rarely discussed during the
test phase.
Agile development is a process in which the The method is ideal for projects which have
requirements are expected to change and definite requirements and changes not at all
evolve. expected.
In Agile methodology, testing is performed In this methodology, the "Testing" phase

concurrently with software development. comes after the "Build" phase.
Agile introduces a product mindset where the This model shows a project mindset and
software product satisfies needs of its end places its focus completely on accomplishing
customers and changes itself as per the the project.
customer's demands.
Agile methodology works exceptionally well Reduces risk in the firm fixed price contracts

with Time & Materials or non-fixed funding. by getting risk agreement at the beginning of
It may increase stress in fixed-price scenarios. the process.
Prefers small but dedicated teams with a high Team coordination/synchronization is very
degree of coordination and synchronization. limited.
Products owner with team prepares Business analysis prepares requirements

requirements just about every day during a before the beginning of the project.
project.
Test team can take part in the requirements It is difficult for the test to initiate any change
change without problems. in requirements.
Description of project details can be altered Detail description needs to implement

anytime during the SDLC process. waterfall software development approach.
2. Why Agile is better?

Agile development is a methodology, not a tool. It’s an iterative approach that builds software
incrementally, instead of delivering the complete product near the end of the timeline. This
process is streamlined and flexible, allowing you to make changes on an as needed basis.
Agile has become the go-to framework for helping app startups and development agencies
maintain a focus on delivering a quality app ー quickly and efficiently. Agile maximizes value
throughout the development process and significantly reduces the overall risk of any given project.
Reasons Why Agile is Best for App Development
1. Quality Product
It was common to test software before launch, but with Agile, testing is integrated throughout every stage
of development to ensure a quality end product. Continuous testing allows room for adjustments and can
catch issues and bugs before they manifest.

2. Faster Time to Market
Sprints play a major role when working Agile. These set periods of time allow teams to deliver frequently
and rapidly.
3. Flexibility
Flexibility is praised as one of the most beneficial reasons to use Agile. Because the methodology allows
for change, there is always room for mistakes and opportunity to iterate.
4. Cost Effective
Becoming more Agile is proven to save money, and most importantly, it helps you invest funds wisely.
5. People Focused/Collaborative
Agile puts a strong focus on people and collaboration, Which provides the development team with many
opportunities to work with the client and understand their vision.
6. Reduced Risk
Working on small tasks that build up to the big picture will help you identify issues early. Reducing risk
and making it easier to respond to any changes.
7. Enjoyable Work Environment
Instead of team members and clients working in complete isolation for hours, everyone will be working
together to deliver a quality end product. Workshops, brainstorming sessions, and meaningful
conversations are all part of the development process.
8. User Feedback
In most cases, Agile utilizes user stories to determine product features. When you create user stories,
you’ll focus on solving the real needs users have, instead of developing features that could turn out
useless.

9. Quick Decision Making
Working under set deadlines and timeframes will force you to be on your toes at all times. This applies to
decision making as well, because you won’t b to sit down with your team to agree on every decision.
10. Results Driven
Instead of focusing on the process itself, you and your team will be driven to achieve milestones and
results.
3.Understanding the Agile Manifesto.
The Agile Manifesto is a document that identifies four key values and 12 principles that its
authors believe software developers should use to guide their work. Formally called
the Manifesto for Agile Software Development, it was produced by 17 developers.
The Four Values of The Agile Manifesto-
1. Individuals and Interactions Over Processes and Tools

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing
people more highly than processes or tools is easy to understand because it is the people who respond to
business needs and drive the development process. If the process or the tools drive development, the
team is less responsive to change and less likely to meet customer needs. Communication is an example
of the difference between valuing individuals versus process. In the case of individuals, communication
is fluid and happens when a need arises. In the case of process, communication is scheduled and requires
specific content.
2. Working Software Over Comprehensive Documentation

Historically, enormous amounts of time were spent on documenting the product for development and
ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface
design documents, test plans, documentation plans, and approvals required for each. The list was
extensive and was a cause for the long delays in development. Agile does not eliminate documentation,
but it streamlines it in a form that gives the developer what is needed to do the work without getting
bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a

software developer to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.
3. Customer Collaboration Over Contract Negotiation

Negotiation is the period when the customer and the product manager work out the details of a delivery,
with points along the way where the details may be renegotiated. Collaboration is a different creature
entirely. With development models such as Waterfall, customers negotiate the requirements for the
product, often in great detail, prior to any work starting. This meant the customer was involved in the
process of development before development began and after it was completed, but not during the
process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the
development process, making. This makes it far easier for development to meet their needs of the
customer. Agile methods may include the customer at intervals for periodic demos, but a project could
just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the
product meets the business needs of the customer.
4. Responding to Change Over Following a Plan

Traditional software development regarded change as an expense, so it was to be avoided. The intention
was to develop detailed, elaborate plans, with a defined set of features and with everything, generally,
having as high a priority as everything else, and with a large number of many dependencies on
delivering in a certain order so that the team can work on the next piece of the puzzle.

Fig.1.1
The Twelve Agile Manifesto Principles-
The twelve principles of agile development include:
1. Customer satisfaction through early and continuous software delivery – Customers are happier
when they receive working software at regular intervals, rather than waiting extended periods of
time between releases.
2. Accommodate changing requirements throughout the development process – The ability to avoid
delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the team
operates in software sprints or iterations that ensure regular delivery of working software.
4. Collaboration between the business stakeholders and developers throughout the project – Better
decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver
their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development teams
are co-located.
7. Working software is the primary measure of progress – Delivering functional software to the
customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a repeatable and
maintainable speed at which they can deliver working software, and they repeat it with each
release.
9. Attention to technical detail and design enhances agility – The right skills and good design
ensures the team can maintain the pace, constantly improve the product, and sustain change.
10. Simplicity – Develop just enough to get the job done for right now.
11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and
motivated team members who have decision-making power, take ownership, communicate
regularly with other team members, and share ideas that deliver quality products.
12. Regular reflections on how to become more effective – Self-improvement, process improvement,
advancing skills, and techniques help team members work more efficiently.

4. Discussing Important Characteristics that make agile approach best suited for Software
Development.
Key Characteristics for Agile Software Development Methodology:
1. Scrumis the most popular way of introducing Agility due to its simplicity and flexibility. Scrum
emphasizes empirical feedback; team self-management, and striving to build properly tested
product increments within short iterations.
The benefit includes increased visibility of project goals and how to achieve them. This clear
characteristic of agile projects, inevitably contributes toward the even more significant goal of
delivering software on time.
Requirements Timeliness
Agile approach Changing rapidly Changing rapidly
Traditional structuredNeed for fast deliveryNo immediate requirement
2. Quality
Testing is integrated throughout the lifecycle, enabling regular inspection of the working product
as it develops. This allows the product owner to make necessary adjustments gives the product
team early sight of any quality issues.
3. Visibility
Agile development principles encourage ‘user/client’ active involvement throughout the

product’s development process. This provides excellent visibility for key stakeholders, both the
project’s progress and the product itself, which in turn helps to ensure that expectations are
effectively managed.
4. Early identification and resolution of issues
Small incremental releases made visible to the product owner and product team through its
development help to identify any issues early and make it easier to respond to change. The clear

visibility in agile development helps to ensure that any necessary decisions can be taken at the
earliest possible opportunity, while there’s still time to make a material difference to the outcome.
5. Accommodating change due to volatile requirements (Flexibility / Agility)
In agile development, change is accepted. Instead the timescale is fixed and requirements emerge
and evolve as the product is developed. Of course for this to work, it’s imperative to have an
actively involved stakeholder who understands this concept and makes the necessary trade-off
decisions, trading existing scope for new.
6. Iterative releases, Communication, continuous integration
The active involvement of a user representative/product owner, the high visibility of the product
and progress, and the flexibility to change when change is needed, creates better business
engagement and customer satisfaction. This is an important benefit that can create much more
positive and enduring working relationships.
Above all other points, the ability for agile development requirements to emerge and evolve, and
the ability to embrace change, the team builds the right product. It’s too common in more
traditional projects to deliver a “successful” project and find that the product is not what was
expected, needed or hoped for. In agile development, the emphasis is absolutely on building the
right product.
7. More Enjoyable!
The active involvement, cooperation and collaboration make agile development teams a much
more enjoyable place for most people. Instead of big specs, we discuss requirements in
workshops. Instead of lengthy status reports, team collaborates around a task-board discussing
progress. Instead of long project plans and change management committees, there are
discussions on what’s right for the product and project and the team is empowered to make
decisions. In my experience this makes it a much more rewarding approach for everyone. In turn
this helps to create highly motivated, high-performance teams that are highly cooperative.
8. Transparency

An Agile approach provides a unique opportunity for clients to be involved throughout the
project, from prioritizing features to iteration planning and review sessions to frequent software
builds containing new features. However, this also requires clients to understand that they are
seeing a work in progress in exchange for this added benefit of transparency.
9. Early and Predictable Delivery
By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly
and frequently, with a high level of predictability. This also provides the opportunity to release
or beta test the software earlier than planned if there is sufficient business value.
10. Predictable Costs and Schedule
Because each Sprint is a fixed duration, the cost is predictable and limited to the amount of work
that can be performed by the team in the fixed-schedule time box. Combined with the estimates
provided to the client prior to each Sprint, the client can more readily understand the
approximate cost of each feature, which improves decision making about the priority of features
and the need for additional iterations.

Practical No. 2
AIM: Build out a backlog and user stories.
OBJECTIVE:
1. Describe Product backlog.
2. Managing the product backlog between the product owner and scrum team.
3. Discuss user stories.
THEORY:
1. Product backlog
A product backlog is a prioritized list of work for the development team that is derived from the
roadmap and its requirements. The most important items are shown at the top of the product backlog so
the team knows what to deliver first. The development team doesn't work through the backlog at
the product owner's pace and the product owner isn't pushing work to the development team. Instead, the
development team pulls work from the product backlog as there is capacity for it, either continually
(kanban) or by iteration (scrum).
The product backlog is the single authoritative source for things that a team works on. That means that
nothing gets done that isn’t on the product backlog. Conversely, the presence of a product backlog item on a
product backlog does not guarantee that it will be delivered. It represents an option the team has for
delivering a specific outcome rather than a commitment.
Fig.2.1

2. Managing the product backlog between the product owner and scrum team.
The goal both of them share is creating a viable product through the use of Agile methodologies. To
accomplish this, the Product Owner and Scrum Master should make every effort to collaborate
closely in the following areas:
1. Backlog Grooming – While this is the Product Owner’s responsibility, the Scrum Master is in an
excellent position to help the Product Owner groom the backlog. With the results of each sprint
retrospective fresh in mind, the Scrum Master can work with the Product Owner to ensure the next
sprint is even more in line with reality and set the team up for success.
2. Enhancing Team Communication – Working closely with the Scrum Master, who works directly
with the team every day, the Product Owner can make sure all necessary communications regarding
the project and the product vision are clear to the team, and can carry back any necessary messages
to other departments, teams, or levels of the organization.
3. Improving Team Morale – By collaborating throughout a project, the Product Owner and Scrum
Master can keep a team’s morale and productivity at the highest levels simply by keeping lines of
communication open and setting priorities based on what is reasonable rather than on arbitrary
business goals.
4. Ensuring Cross-dependencies With Other Teams – Both the Product Owner and Scrum Master
likely have close relationships with other teams, other owners and Scrum Masters, as well as past
team members that may work elsewhere in the organization. Leveraging those relationships can help
both to improve the current project and smooth any bumps in the road.
5. Clarifying the Product Vision – While the Product Owner is responsible for establishing and
communicating the strategic vision behind the product, the Scrum Master is responsible for bringing
the team on board and making that vision a reality. It makes sense for both to be fully engaged in the
vision and be able to clearly communicate it appropriately.

6. Facilitating Engaging Meetings – While each role is responsible for various meetings, in practice
it can be much more effective for the team to see the Product Owner and Scrum Master switch up
the norm in meeting facilitation for the sake of maintaining interest and engagement. Each individual
will have their own strengths and personal style in facilitation and can use those differences to bring
out the best in each meeting.
3. Discuss user stories.
User stories are part of an agile approach that helps shift the focus from writing about requirements to
talking about them. All agile user stories include a written sentence or two and, more importantly, a
series of conversations about the desired functionality.
Fig.2.2

Example-
Video Training Website-
Course Catalog
 As an instructor, I can create a description of a course so that prospective participants can learn
about it.
 As an instructor, I can maintain a bio about myself so that it is used on any course listing for
which I’m the instructor.
 As a site visitor, I can view a detailed page about each course so that I can learn all about it.
 As a site visitor, I can browse a catalog of all courses available so that I can pick the right one for
me.
 As a site visitor, I can see a list of other related courses when viewing a course so that I can see
other courses I might be interested in.
Account Management
 As an instructor, I can create a description of a course so that prospective participants can learn
about it.
 As an instructor, I can maintain a bio about myself so that it is used on any course listing for
which I’m the instructor.
 As a site visitor, I can view a detailed page about each course so that I can learn all about it.
 As a site visitor, I can browse a catalog of all courses available so that I can pick the right one for
me.
 As a site visitor, I can see a list of other related courses when viewing a course so that I can see
other courses I might be interested in.
Course Creation
 As an instructor, I can upload videos to be part of a course so that participants can watch those
videos.
 As an instructor, I can create a quiz to include in a video course so that participants can take
those quizzes to ensure they are learning.

 As an instructor, I can properly sequence the elements of course so that I can assemble them into
an amazing course.
 As an instructor, I indicate whether a discussion forum is part of a course so that I can add a
forum to some but not all courses.
 As an instructor, I can indicate the schedule for a course so that prospective participants and
participants can see what course elements will be presented each week and what they’ll be.
 As an instructor, I can set the publication date for course elements (for a scheduled course) so
that items become available when I want and not sooner.
 As an instructor, I can add subtitles to any video so that it is more accessible.
 As an instructor, I can set the thumbnail image for each video so that the image is one I like
rather than randomly selected.
 As a site owner, I want all videos to be watermarked with a Front Row Agile logo so that the
videos are clearly from the Front Row Agile site.
Buying Courses
 As a trainer, I can set the prices for my course so that I can make filthy lucre.
 As a trainer, I can set quantity thresholds and discounts so that I can offer lower prices for larger
orders such as “buy three, get 10% off”.
 As a trainer, I can create discount codes I can give to people so that I can customize pricing.
 As a site visitor, I can put courses in my shopping cart so that I can purchase them and
participate in (watch) them.
 As a site visitor, I can put one chapter of a course in my shopping cart so that I can purchase just
a part of a course.
 As a site visitor, I can pay for the courses in my cart with a credit card so that I can purchase
them and participate in (watch) them.
 As a site visitor, I can pay for the courses in my cart with PayPal so that I can purchase them and
participate in (watch) them.
 As a buyer, I receive a receipt for any course I pay for so that I can prove I paid for it.
 As a participant, I can announce my participation in a course at various times to various social
media sites so that I can tell others about what I’m doing.

 As a user, I can view the license terms before purchasing or subscribing so that I know what I’m
getting.
 As a participant, I can sign up for a monthly or annual subscription so that I can take all (video?)
courses.
 As a company, I can purchase multiple licenses so that I can manage course registrations for a
group of people.
 As a company, I manage a set of course registrations so that I can control which employees in
my company have access to which courses.
 As a company, I can purchase a site license so that everyone in my company can take the course.
License Admin
 As a buyer, I can easily apply a license I buy to myself so that I can instantly start viewing a
course.
 As a buyer, I can distribute out licenses to others in my company so that they can view a course I
pay for.
 As a buyer, I can share a company-wide license with everyone in my company so that everyone
in the company can view the course. .
Viewing Courses
 As a participant, I want each course element (such as a video) marked as viewed after I view or
complete it so that I can see which parts of a course I’ve completed.
 As a participant, I can re-watch any video so that I can make sure I understand it.
 As a site visitor, I can view some videos for free so that I can decide if I want to buy the full
course.
 As a participant, I can set a mode on the videos so that one begins as the previous one finishes so
that I can watch without having to touch my keyboard, mouse or screen.
Course Completion
 As a participant, I am shown a page telling me how to get my PDUs after I complete the course
so that I earn the credit I might have been interested in.

 As a participant, I can earn a certificate of completion by finishing a course so that I have proof
that I completed a course.
 As a participant, I can earn a badge showing that I completed a course so that I can display that
badge on my own website.
 As a participant, I have a page I can link to and share with others that shows all the training
courses I’ve completed so that people can see all the great stuff I’ve learned.
Miscellaneous
 As a site visitor, I can read an FAQ so that all my questions are answered.
 As a search engine, I can view a site map so that all pages are indexed.
 As a site visitor, I can read a privacy policy so that I know what’s private.
 As a site visitor, I can sign up for a newsletter so that I get announcements about new courses
and other information.
 As a site visitor, I see “Featured Products” on the home page so that I see the products the site
most wants all visitors to see.
 As a participant, I do not want the site shut down while I’m in the midst of a quiz or video so that
my progress isn’t interrupted.
Forms
 As a participant, I can participate in a forum for a course so that I can discuss questions and
topics with the instructor and other participants.
Announcements
 As an instructor, I can post announcements to a project “home page” for a Scheduled Course so
that I can tell participants about important thinks such as “I’m delayed in posting chapter 7.”.
 As a participant, I can read announcements from an instructor for a Scheduled Course so that I
can keep up to date on news.
Quizzes
 As an instructor, I can create quizzes so that participants can assess their learning.

 As a participant, I can take a quiz as part of a course so that I can get feedback on how well I
learned material in the previous video(s).
 As a participant, I see if I pass a quiz after I finish taking it so that I can get feedback on how
well I learned material in the previous video(s).
 As a participant, I can see which quizzes I’ve passed, not passed, or not yet taken when viewing
the course outline so that I know which quizzes I need to take or possibly re-take.
 As an instructor, I want quiz responses stored in the database so that I can see how people are
doing at various questions, perhaps so I can fix one that is worded poorly.
 As a participant, I want to receive feedback after each quiz question so that I can see if I got the
question right or wrong.
 As a participant, I can navigate a quiz by submitting an answer or by pressing skip (forward) or
back so that I can answer questions in a different order if I’d like.
 As a participant, I can get answers via video rather than text so that I watch rather than read an
answer.
Non-Functional Requirements
 As a visitor, I want to be able to view the site and videos in any reasonable browser so that I can
use what I’m accustomed to.
Affiliates
 As a partner company, I would like to provide links to FrontRowAgile.com and get paid for
referring people to the site so that I can become part of the 1%.
 As a partner company, I can embed Front Row Agile videos (free ones only) on my site so that
people can enjoy those videos on my site, possibly giving me affiliate revenue but possibly just
being about putting good content on my site.
Comments
 As a participant, I can leave a comment about a course so that I can tell the world what I think of
it.

 As an instructor, I can leave a comment about a sample video or the course so that I can respond
to other comments.
Course Evaluation
 As a participant, I am shown an evaluation form after completing a course so that I can tell
FrontRowAgile.com what I think of their classes and their devilishly good-looking trainers.
 As an instructor, I can opt into receiving an email of every course evaluation as it completed by a
participant so that I get real-time feedback on my courses.
 As an instructor, I can view all feedback for a course when logged in so that I can see historical
or aggregate data on my courses.
 As an instructor, I can export all feedback for a course to a CSV file so that I can perform more
in-depth analysis.
Reporting
 As a site owner, I receive a periodic email summarizing registrations for the day, week. and
month to date. so that I know how we’re doing.
 As a trainer, I receive a periodic sales summary at the frequencies I select so that I know how my
courses are doing.
 As a trainer, I can run a few helpful reports to be determined later so that I can monitor various
aspects of my courses.
 As a sys admin, I can run any report a trainer can run so that I can see overall information for any
trainer on the site.
Practical No. 3
AIM: To study automated build tool.
OBJECTIVE:
1. Understand automated build tool.
2. Understand ANT tool.
THEORY:
1.Understand automated build tool.
Favro.com
Favro is the most adaptable platform for organization wide agility ever made. Instead of agile being
siloed to product development, Favro brings agility to all teams in the organization to master any
complexity that anyone can learn regardless of being a newbie, leader, coach or an executive.
Fig 3.1
Origin-
Favro was founded by serial deeptech entrepreneurs Hans Dahlström, Erik Olofsson, and Patric Palm.
Before Favro they built a product and company serving customers worldwide in telecom, aerospace,
defence, and game development, with tools for enterprise scale agile planning and management. The
business reached profitability and was later sold to an American acquirer. With Favro the founders are
now pursuing a vision of taking the agile way of working beyond software development to any kind of
team in need of increased adaptability, autonomy and organizational alignment.

Purpose-
Favro enables individuals and teams from the world's most progressive companies to operate with
agility, autonomy and alignment. Our objective is to become the first choice collaboration product for
makers and managers, entrepreneurs and enterprises.
The collaboration app that makes work flow. It combines killer features from the tools you already use,
all in one workspace.
Enabling seamless collaboration, communication and creation.
Providing one source of truth across the business.
So whether you're crafting the strategy, roadmap or campaign.

Setting objectives, budgets or deadlines.
Making notes, docs, lists or sheets.
Managing your teams, tasks or timelines.
Sharing ideas, feedback and knowledge or searching for what's new.
You can switch to a view that fits your own workflow without losing sight of your shared goals.
Simple enough to handle basic tasks and powerful enough to tackle the biggest challenge.
Favro is enterprise-grade compliant, military-grade secure, gamer-grade fast and consumer-grade
gorgeous.
And it just works. Everywhere.So for entrepreneurs and enterprises that want to change the game, it's a
complete game-changer. Run your squad, business or project with agility, autonomy and alignment.
‍Simple enough to handle basic tasks and powerful enough to tackle the biggest challenge.
Favro is enterprise-grade compliant, military-grade secure, gamer-grade fast and consumer-grade
gorgeous.
And it just works. Everywhere.So for entrepreneurs and enterprises that want to change the game, it's a
complete game-changer. Run your squad, business or project with agility, autonomy and alignment.
Here’s a breakdown of the columns:

 Selected. Cards in this column have been picked out from either our product backlog or
escaped production bugs board by the product owner. The team can simply pull a card from
here and get to work on it.
 Doing. If someone is currently working on something, they’ll pull the card into this column.
 Ready For Review. Great! The code is ready for another developer to take a look at before
merging into master.
 Done. The code has passed review and has been merged.
 Deployed in TEST. The team’s embedded QA have seen that there is new work ready for
testing (and that our continuous integration builds have passed) and have built these changes
to a test server.
 Testing. The previously built changes are now currently undergoing testing. The developer
responsible for these changes will now spend their time explaining bugs away as
undocumented features…
 Ready for Release. A feature has now passed both manual and automated testing and is
ready for release either as a toggle feature or for immediate roll out to all users.
 Deployed in PROD. The feature has now been deployed to our production servers. It has
made it the whole way and is now in the hands of our users. Time for a celebration.
Defined workflow-
The defined workflow app allows us to ensure cards are only created in the Selected column and then
pass through each gate in the process. Since QA are so integral to our process when it comes to
determining if a feature is fit for public consumption, we also apply rules through the defined
workflows app to ensure that only QA can pull cards into TEST and so on.
Slack-

The Slack integration posts whenever cards are moved into the Done column, which notifies our QA
team when work is ready to be pulled into TEST.
WIP Limits-
With all of the automation tricks we employ above, we could easily get ourselves into a position
where developers start taking on work before their existing cards have gone through review. This is
where we enable the WIP limits app to set a strict WIP limit of one card per developer in the Ready for
Review column. We value finishing stories before taking on new ones.
2.Understand ANT tool.
A build tool is a programming tool which is used to build a new version of a program. It automates
the creation of an executable application from any source code.
Apache Ant is a Java-based command-line tool for building Java applications with the full
portability of pure Java code. It allows developers to adopt agile principles and test-driven
development to automate the repetitive development tasks like generating documentation, etc. Ant is
an acronym for Another Neat Tool.
Here, are important pros/benefits of using the Build tool:
 Build tool allows you to automate specific repetitive tasks for like compiling the source code,
running software tests, and creating files for the software deployment.
 Build tools mostly run without a graphical user interface.
 Helps you to convert source code into executable code
 Offers an option to recompile a file only if necessary
 Allows you to compile numbers of files in a relatively short time
 Two widely popular build tools used by Java developers are Apache Maven and Ant.

Fig3.2
History of Apache Ant
 James Duncan Davidson created an Ant on July 2000.

 It was initially used to build Tomcat and was comes as an in-built product of Tomcat distribution
kit.
 In May 2014, Apache Ant version 1.9.4 released with many advanced features.
 It's the latest version is 1.10.3 which was released on March 2018.
Features of Apache Ant
 It's an open-source project.

 Allow you to run builds on both Windows and UNIX/Linux systems.
 You only require JVM as It runs anywhere when JVM is available.
 Offers an extensive range of predefined tasks
 Helps you to copy from one location to another.
 Offers interface to develop custom tasks.

 Allows you to invoke from the command line which can easily integrate with free and
commercial IDEs.
 Allows you to deploy the binaries to the test server
 Offers Extensible Architecture
 Offers Backward Compatibility

Practical No. 4
AIM: To study version control tool.
THEORY:
What Is Version Control?
Version control, also called source control, allows you to manage changes to files over time, storing
these modifications in a database. You can use version control to version code, binary files, and digital
assets.
This includes version control software, version control systems, or version control tools. Version control
is a component of software configuration management. It's sometimes referred to as VCS programming.
How Do Version Control Systems Work?
Version control systems allow multiple developers, designers, and team members to work together on
the same project. Also known as VCS, these systems are critical to ensure everyone has access to the
latest code. As development gets more complex, there's a bigger need to manage multiple versions of
entire products.
Why Is Version Control Important?
Version control is important to keep track of changes — and keep every team member working off the
latest version. You should use version control software for all code, files, and assets that multiple team
members will collaborate on.
It needs to do more than just manage and track files. It should help you develop and ship products faster.
This is especially important for teams practicing DevOps.
That’s because using the right one:
 Improves visibility.
 Helps teams collaborate around the world.

 Accelerates product delivery.
Different Version Control Systems-
There are several types of version control systems that teams use today. Some are centralized. Some are
distributed.
There are several types of version control systems that teams use today. Some are centralized. Some are
distributed.
Here are a few of the most popular types of VCS:
 Helix Core (Perforce)

 Git
 SVN
 ClearCase
 Mercurial
 TFS
What Is Git Version Control?
Git version control is open source. It's a distributed free version control system. In fact, Git version
control is one of the most popular options. It's open source, so anyone can use it.
But there are some drawbacks to using Git. Git lacks security. It's impossible to scale. And it's very
difficult to get a single source of truth.
That's why teams who choose Git version control often add other tools on top. This includes Helix
TeamHub for Git hosting and code reviews. Or Helix4Git, a Git server inside a Perforce server that can
bring projects from third parties into your pipeline.

Features
 Provides strong support for non-linear development.
 Distributed repository model.
 Compatible with existing systems and protocols like HTTP, FTP, ssh.
 Capable of efficiently handling small to large sized projects.
 Cryptographic authentication of history.
 Pluggable merge strategies.
 Toolkit-based design.
 Periodic explicit object packing.
 Garbage accumulates until collected.
Pros
 Super-fast and efficient performance.
 Cross-platform
 Code changes can be very easily and clearly tracked.
 Easily maintainable and robust.
 Offers an amazing command line utility known as git bash.
 Also offers GIT GUI where you can very quickly re-scan, state change, sign off, commit
& push the code quickly with just a few clicks.
Cons
 Complex and bigger history log become difficult to understand.
 Does not support keyword expansion and timestamp preservation.
Open Source: Yes
Cost: Free

Fig4.1

Practical No. 5
AIM: To study Continuous Integration tool.
OBJECTIVE:
1. What is Continuous Integration
2. Understand Jenkins Continuous Integration
THEORY:
1. What is Continuous Integration?

Continuous Integration (CI) is a development practice where developers integrate code into a shared
repository frequently, preferably several times a day. Each integration can then be verified by an
automated build and automated tests. While automated testing is not strictly part of CI it is typically
implied.
One of the key benefits of integrating regularly is that you can detect errors quickly and locate them
more easily. As each change introduced is typically small, pinpointing the specific change that
introduced a defect can be done quickly.
In recent years CI has become a best practice for software development and is guided by a set of key
principles. Among them are revision control, build automation and automated testing.
Additionally, continuous deployment and continuous delivery have developed as best-practices for
keeping your application deployable at any point or even pushing your main codebase automatically into
production whenever new changes are brought into it. This allows your team to move fast while keeping
high quality standards that can be checked automatically.
“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and
remove.”
2. Understand Jenkins Continuous Integration

Jenkins
Fig 5.1
Jenkins is an open-source continuous integration tool. It is written using the Java programming language.
It facilitates real-time testing and reporting on isolated changes in a larger code base. This software
helps developers to quickly find and solve defects in their code base & automate testing of their builds.
Jenkins offers a simple way to set up a continuous integration or continuous delivery (CI/CD)
environment for almost any combination of languages and source code repositories using pipelines, as
well as automating other routine development tasks. While Jenkins doesn’t eliminate the need to create
scripts for individual steps, it does give you a faster and more robust way to integrate your entire chain
of build, test, and deployment tools than you can easily build yourself.
How Jenkins works

Jenkins is distributed as a WAR archive and as installer packages for the major operating systems, as a
Homebrew package, as a Docker image, and as source code. The source code is mostly Java, with a few
Groovy, Ruby, and Antlr files.
You can run the Jenkins WAR standalone or as a servlet in a Java application server such as Tomcat. In
either case, it produces a web user interface and accepts calls to its REST API.
When you run Jenkins for the first time, it creates an administrative user with a long random password,
which you can paste into its initial webpage to unlock the installation.

Jenkins plug-ins
Once installed, Jenkins allows you to either accept the default plugin list or choose your own plugins.
Fig
5.2
Once you have picked your initial set of plug-ins, click the Install button and Jenkins will add them.

Fig
5.3
The Jenkins main screen displays the current build queue and Executor status, and offers links to create
new items (jobs), manage users, view build histories, manage Jenkins, look at your custom views, and
manage your credentials.

Fig 5.4
A new Jenkins item can be any of six types of job plus a folder for organizing items.
Fig 5.5

There are 18 things you can do from the Manage Jenkins page, including the option to open a command-
line interface. At this point, however, we should look at pipelines, which are enhanced workflows that
are typically defined by scripts.
Fig 5.6

Features:
 Provide support to scale out to a large number of nodes and distribute the workload equally
among them
 Easily updated with all OS and versions of Linux, Mac OS or Windows
 It offers easy installation as Jenkins comes as a WAR file all you need to drop into your JEE
container and your setup up ready to run.
 Jenkins can be easily set up and configured with the help of its web interface
 It's can easily distribute work across several machines.
Fig 5.7
Possible steps executed by Jenkins are for example:
 perform a software build using a build system like Apache Maven or Gradle
 execute a shell script
 archive a build result
 run software tests

Jenkins monitors the execution of the steps and allows to stop the process, if one of the steps fails.
Jenkins can also send out notifications in case of a build success or failure.
Jenkins can be extended by additional plug-ins. For example, you can install plug-ins to support building
and testing Android applications.
Summary: 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.
Features:
 On-premise
 Open source
 Robust addon / plugin ecosystem
Practical No. 6
AIM: Apply Design principle and Refactoring to achieve agility.
OBJECTIVE:
1. Understanding different design principles
2. Understanding refactoring
THEORY:
1.Understanding different design principles
A. Single Responsibility Principle: SRP

A class should have only one reason to change.
In the SRP context, responsibility can be defined as "a reason to change". When the requirements of the
project modify, the modifications will be visible through the alteration of the responsibilities of the
classes. If a class has several responsibilities, then, it will have more reasons to change. Having more
coupled responsibilities, the modifications on a responsibility will imply modifications on the other
responsibilities of the class. This correlation leads to a fragile design.
Fragility means that a modification of the system leads to a break in design, in places that have no
conceptual connection to the part which has been modified.
Example:
Suppose we have a class which encapsulates the concept of phone and the associated functionalities.
class Phone
{
public void Dial(const string&
phoneNumber);
public void Hangup();

public void Send(const string&
message);
public Receive(const string&

message);
};
This class might be considered reasonable. All the four methods defined represent functionalities related
to the phone concept. However, this class has two responsibilities. The methods Dial and Hang-up are
responsible for performing the connection, while the methods send and Receive are responsible for data
transmission.
In the case where the signature of the methods responsible for performing the connection would be
subjected to changes, this design would be rigid, since all the classes which call the Dial and Hangup

methods would have to be recompiled. In order to avoid this situation, a re-design is necessary, to divide
the two responsibilities.
Fig 6.1
In this example, the two responsibilities are separated, so that the class that uses them - Phone, does not
have to couple the two of them. The changes of the connection will not affect the methods responsible
with data transmission. On the other hand, in the case where the two responsibilities do not show
reasons for modification in time, their separation is not necessary either. In other words, the
responsibilities of a class should be separated only if there are real chances that the responsibilities
would produce modifications, mutually influencing each other.
B. Open Closed Principle: OCP

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for
modification.
When a single modification on a software module results in the necessity to modify a series of other
modules, the design suffers from rigidity. The OCP principle advocates design refactoring so that further
modifications of the same type will no longer produce modifications on the existing code, which already
functions, instead it will only require adding new modules.
A software module observing the Open-Closed principle has two main characteristics:
 "Open for extensions."
This means that the behaviour of the code can be extended. When the requirements of the project are
modified, the code can be extended by implementing the new requirements, meaning that one can
modify the behaviour of the already existing module.

 "Closed for modifications."
The implementation of the new requirements does not need modifications on the already existing code.
Fig.6. 2 presents a block of classes that do not conform to the open-closed principle. Both the Client
class and the Server class are concrete. The Client class uses the Server class. If we want for a Client
object to use a different server object, the Client class must be changed to name the new server class.
Fig 6.2
Fig 6.3
A particular aspect in this example is the way we named the abstract class ClientInterface and not
ServerInterface, for example. The reason for this choice is the fact that abstract classes are more closely
associated to their clients than to the classes that implement them.
The Open-Closed principle is also used in the Strategy and Plugin design patterns .For instance, Fig.6.4
presents the corresponding design, which observes the open-closed principle.

Fig 6.4
The Sort_Object class performs a function of sorting objects, function which can be described in the
abstract interface Sort_Object_Interface. The classes derived from the abstract
class Sort_Object_Interface are forced to implement the method Sort_Function(), but, at the same time,
they have the freedom to offer any implementation for this interface. Thus, the behavior specified in the
interface of the method void Sort_Function(), can be extended and modified by creating new subtypes of
the abstract class Sort_Object_Interface.
In the definition of the class Sort_Object we will have the following methods:
void Sort_Object::Sort_Function()
{
m_sort_algorithm->sortFunction();
}
void Sort_Object::Set_Sort_Algorithm(const Sort_Object_Interface* sort_algorithm)
{
std::cout << "Setting a new sorting algorithm..." << std::endl;
m_sort_algorithm = sort_algorithm;
}
C. The Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types.
In languages such as C++ or Java, the main mechanism through which abstraction and polymorphism is
done is inheritance. In order to create a correct inheritance hierarchy we must make sure that the derived
classes extend, without replacing, the functionality of the base classes. In other words, the functions
using pointers or references to the base classes should be able to use instances of the derived classes
without being aware of this. Contrary, the new classes may produce undesired outcomes when they are

used in the entities of the already existing program. The importance of the LSP principle becomes
obvious the moment it is violated.
Example:
Suppose we have a Shape class, whose objects are already used somewhere in the application and which
has a SetSize method, containing the mSize property which can be used as a side or diameter, depending
on the represented figure.
class Shape
{
public:
void SetSize(double size);
void GetSize(double& size);
private:
double mSize;
};
Fig
6.5
Conclusions
The LSP principle is a mere extension of the Open-Closed principle and it means that, when we add a
new class derived in an inheritance hierarchy, we must make sure that the newly added class extends the
behaviour of the base class, without modifying it.

D. Dependency Inversion Principle (DIP)

A. High-level modules should not depend on low-level modules. Both should depend on abstract
modules.
B. Abstractions should not depend upon details. Details should depend upon abstractions.
This principle enunciates the fact that the high-level modules must be independent of those on lower
levels. This decoupling is done by introducing an abstraction level between the classes forming a high
hierarchy level and those forming lower hierarchy levels. In addition, the principle states that the
abstraction should not depend upon details, but the details should depend upon the abstraction. This
principle is very important for the reusing of software components. Moreover, the correct
implementation of this principle makes it much easier to maintain the code.
Fig. 6.6 presents a diagram of classes organized on three levels. Thus, the Policy Layer class represents
the high-level layer and it accesses the functionality in the Mechanism Layer class, situated on a lower
level. In its turn, the Mechanism Layer class accesses the functionality in the Utility Layer class, which
is also on a low-level layer. In conclusion, it is obvious that, in this class diagram, the high-levels
depend upon the low-levels. This means that, if there is a modification on one of the low levels, chances
are rather high that the modification propagates upwards, towards the high-level layers, which means
that the more abstract higher levels depend on the more concrete lower levels. So, the Dependency
Inversion principle is violated.
Fig 6.6
E. The Interface Segregation Principle (ISP)

Clients should not depend on interfaces they do not use.
This principle stresses the fact that when an interface is being defined, one must be careful to put only
those methods which are specific to the client in the interface. If in an interface one adds methods which

do not belong there, then the classes implementing the interface will have to implement those methods,
too. For instance, if we consider the interface Employee, which has the method Eat, then all the classes
implementing this interface will also have to implement the Eat method. However, what happens if the
Employee is a robot? Interfaces containing unspecific methods are called "polluted" or "fat" interfaces.
Figure 6.8 presents a class diagram containing: the Timer Client interface, the Door interface and
the Timed Door class. The Timer Client interface should be implemented by any class that needs to
intercept events generated by a Timer. The Door interface should be implemented by any class that
implements a door. Taking into consideration that we needed to model a door that closes automatically
after a period of time, Fig.3.7 presents a solution in which we have introduced the TimedDoor class
derived from the Door interface, and in order to also dispose of the functionality from TimerClient, the
Door interface was also modified so as to inherit the TimerClient interface. However, this solution
pollutes the Door interface, since all the classes that will inherit this interface will have to implement the
TimerClient functionality (4), too.
class Timer
{
public:
void Register(int timeout, TimerClient* client);
};
class TimerClient
{
public:
virtual void TimeOut();
};
class Door
{
public:
virtual void Lock() = 0;
virtual void Unlock() = 0;
virtual bool IsDoorOpen() = 0;
};
The separation of interfaces can be done through the mechanism of multiple inheritance. In Fig.6.9, we
can see how multiple inheritance can be used to comply with the Interface Segregation principle in
design. In this model, the TimeDoor interface inherits from both Door and TimerClient interfaces.

Fig 6.8
Fig 6.9
2. Understanding refactoring
Refactoring is the activity of improving the internal structure or operation of a code or component
without changing its external behavior. The goal of software development is the continuous delivery of
business value to users and stakeholders. Constantly changing technology, coupled with evolving
business objectives makes it difficult to maintain and constantly increase business value. Two paths to

the future exist: Keep adding new functionality to an existing code base toward an eventually
unmaintainable “throw-away” state Continuously modify the system to provide a foundation for
efficiently delivering not just the current business value but future business value as well The second
choice, refactoring, is better. With continuous refactoring, the useful life of an Enterprise’s investment
in software assets can be extended as long as possible, and users can continue to experience a flow of
value for years to come. Refactors enable an emergent design to ensure the system continues to meet
future business needs. Refactors are a special type of Enabler story in SAFe and, like any other Story,
they must be estimable, demonstrable, and valuable, as well as accepted by the Product Owner.
Fig 6.10

The above figure illustrates the essence of Refactoring, which is the modification of any software
entity—a module, method, or program—to improve its structure or viability, without changing
the external functionality.
For example, refactors may accomplish such things as increases in processing speed, sourcing
different internal data, or improving security concerns. Another type of refactoring involves
streamlining some aspect of the code to make it more efficient, more maintainable, or more readable.
Refactoring mandates that each change is tested immediately to verify the accomplishment of the
desired goal. A refactor may be broken into a series of sequential micro-refactors in order to accomplish
a larger goal; each small refactor must be tested to ensure correctness. This iterative process preserves
the integrity of the software at any stage.
Fig 6.11

Refactors arise from various sources, as illustrated in above diagram.
Fig 6.12
The above diagram illustrates Refactor example.

Practical No. 7
AIM: Perform Testing activities within an agile project.
OBJECTIVE:
Understand selenium automated testing tool.
THEORY:
Selenium is a portable framework for testing web applications. Selenium provides a playback tool for
authoring functional tests without the need to learn a test scripting language (Selenium IDE).
It also provides a test domain-specific language (Selenese) to write tests in several popular programming
languages, including C#, Groovy, Java, Perl, PHP, Ruby, and Scala.
Selenium is an open-source, test automation tool that has become an important automation tool in the
software quality assurance world. This selenium testing tool consists of a different set of tools which
include Selenium WebDriver, Selenium RC, Selenium IDE, and Selenium Grid, all of which have
different features.
Selenium testing tool is a lightweight tool and is developer-friendly, commonly used for automating web
applications.
Test automation using selenium webdriver with java, automation testing can be used in any operating
system environment such as Windows, Linux, and OS X and has been first developed by Jason Huggins
in the year 2004.
Cross-browser testing in selenium is an effective selenium testing method used by testers and this tool is
also used for web application testing. This selenium testing tool is composed of several components that
provide different features.

Components of Selenium-
Fig 7.1
There are various components of selenium tool which provide different features that support multiple
browsers, deliver parallel test capabilities and can be executed on multiple machines.
It has a suite of tools which cater to different needs of businesses and has the following components:
1. Selenium Remote Control (RC)
Selenium RC supports all major web browsers and this tool interprets commands to convert them into
javascript and further these scripts are injected into the browser.

2. Selenium IDE (Selenium Integrated Development Environment)
Selenium IDE is a simple record and playback kind of tool which is available as an add-on for Firefox
only.
3. Selenium WebDriver
Selenium WebDriver is one of the vital tools of the Selenium suite and it does not require any manual
process like Selenium server and has direct communication between code and browser.
4. Selenium Grid
The Selenium grid is the last component of selenium suite and is used for parallel testing and sometimes
even supports distributive testing.
Uses of Selenium Testing
Selenium testing tool is commonly used to automate the testing across various web browsers. Cross-
browser testing in selenium is most important as it supports various browsers such as Chrome, Mozilla,
Firefox, Safari, and IE.
Selenium tool can be easily used to automate browser testing across these browsers using Selenium
WebDriver.
Selenium testing tool is best suited with an automated testing selenium suite for all web applications
across browsers. It delivers good results for all tests as it is an integral part of automation testing.
The complete suite of Selenium software is mainly used to automate web browsers effectively.
Selenium UI testing is another testing method that can be done with this tool.

Selenium testing tool is available free of charge and is used for frequent regression testing. Selenium
testing enables rapid feedback to developers, as bugs are identified quickly and efficiently. This tool
typically supports unlimited iterations of test case execution.
Selenium testing framework supports agile and extreme development methodologies and enables
customized defect reporting. Selenium automation testing is used for finding defects that have been
undetected by manual testing.
Selenium tool also supports database testing using SQL commands and can be used to conduct database
testing.
Web services testing in selenium and cross-browser testing in selenium are the most commonly used
selenium testing services.
What are the benefits of test automation?

There are many advantages businesses achieve by leveraging Test automation, and some of them are:
– Helps to find bugs at an early stage

– Testing becomes easy with pre-recorded and predefined actions
– It becomes simple and easy to compare test results to know the expected behavior
– Testing can be done from any device and any time even from remote locations
– Automated tests are reusable and are more accurate than manual test outcomes
– Testers can reuse the code on different versions of the software
– Shortens overall testing time when compared to manual testing
– Lowers overall testing costs

– Ensures faster time to market
– Generates quicker ROI
Steps for Selenium testing
Fig 7.2
– Automate a smoke test or any functional test
– Develop the test automation framework
– Develop the test case
– Integrate the test case into a CI environment
– Establish proper logging and reporting for the developed test case

– Run the test cases through a Continuous Integration environment using Jenkins or any other CI tool
– When once test scripts are run and if they pass then that particular feature is developed and can be
integrated into the product or application
Best practices for Selenium Testing-
Fig 7.3

Agile Software Development Lab File (2003263)

Uploaded by

Copyright:

Available Formats

Agile Software Development Lab File (2003263)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Software Development Lab File (2003263)

Uploaded by

Copyright:

Available Formats

Department of Computer Science &

Subject: Agile Software Development Lab

B.Tech 4th Year- 7th Semester

Submitted to: Submitted by:

Chandigarh Engineering College Landran,

SNO. PRACTICALS PAGE NO. REMARKS

2. Build out a backlog and user stories. 14-22

3. To study automated build tool. 23-28

4. To study version control tool. 29-32

5. To study Continuous Integration tool. 33-40

6. Apply Design principle and Refactoring to achieve agility. 41-51

7. Perform Testing activities within an agile project. 52-57

Sunny Vats_2003263 CEC-Landran Page 2

1. Difference between agile software development model and waterfall model.

2. Why Agile is better?

3. Understanding the Agile Manifesto.

1. Difference between agile

Agile methodology Waterfall Model

It follows an incremental approach. Waterfall methodology is a sequential design

Sunny Vats_2003263 CEC-Landran Page 3

Agile methodology is known for its Waterfall is a structured software

Agile can be considered as a collection of Software development will be completed as

In Agile methodology, testing is performed In this methodology, the "Testing" phase

Sunny Vats_2003263 CEC-Landran Page 4

Products owner with team prepares Business analysis prepares requirements

Description of project details can be altered Detail description needs to implement

2. Why Agile is better?

Reasons Why Agile is Best for App Development

Sunny Vats_2003263 CEC-Landran Page 5

2. Faster Time to Market

7. Enjoyable Work Environment

Sunny Vats_2003263 CEC-Landran Page 6

9. Quick Decision Making

10. Results Driven

3.Understanding the Agile Manifesto.

The Four Values of The Agile Manifesto-

1. Individuals and Interactions Over Processes and Tools

2. Working Software Over Comprehensive Documentation

Sunny Vats_2003263 CEC-Landran Page 7

software developer to begin the task of building a new function.

3. Customer Collaboration Over Contract Negotiation

4. Responding to Change Over Following a Plan

Sunny Vats_2003263 CEC-Landran Page 8

The twelve principles of agile development include:

Sunny Vats_2003263 CEC-Landran Page 9

Key Characteristics for Agile Software Development Methodology:

Agile development principles encourage ‘user/client’ active involvement throughout the

4. Early identification and resolution of issues

Sunny Vats_2003263 CEC-Landran Page 10

5. Accommodating change due to volatile requirements (Flexibility / Agility)

6. Iterative releases, Communication, continuous integration

Sunny Vats_2003263 CEC-Landran Page 11

9. Early and Predictable Delivery

10. Predictable Costs and Schedule

Sunny Vats_2003263 CEC-Landran Page 12

Sunny Vats_2003263 CEC-Landran Page 13

Sunny Vats_2003263 CEC-Landran Page 14

3. Discuss user stories.

Sunny Vats_2003263 CEC-Landran Page 15