You are on page 1of 13

7 UNIT VIk

Applications of Software
Project Management
in Industry

Syllabus
Management & Azure
Agile Project Management with Azure DevOps: An Overview
of Application Lifecycle
i s dnd AZure
between Microsoft DevOps,
Devops, Traceability, Visibility, Collaboration, and Extensiblity. Difference
Project Management, Agile Project
Agile Practice: Introduction
Metrics in to Metrics inAgile Practice, Metrics for
Management in Azure DevOps and TFS

7.1 of Application Lifecycle Management


& Azure Devops
An Overview
7.1.1 An Overview of Application Lifecycle Management
life cycle. It
is the thread that ties together the improvement
The term application life cycle administration (ALM) are a fair one portion of the
essential to facilitate advancement in life cycle activities. Operations
includes all the steps such as the build-and-
to more technical things
extend from prerequisites gathering
ALM process. Other components

deploy process.

Aspects of the ALM Process


different steps performed by individuals playing particular parts
All software development incorporates
the flow from the birth of an
few of its aspects. You'l be able
to see
ALM and a
Look at Fig. 7.1.1, which outlines requires now not exists and
to when the business
application, when the business requires to begin with arises,
the application dies.

Change Request or New release

Software
Postfoie Development Operations Business Value
Business Needs aionaisaton Life Cycle (SDLC

Retirement of System

Fig. 7.1.1: The Application life cycle management process


the
framework must be built, you enter the Software Development Life Cycle (SDLC) and develop
The new
that
so
into operation. 1ypically the point at which you are doing a handover
framework, testit, and deploy it
and r e n e the Iramework. Once in production, the system (ideally)
conveys
Operations work force can keep up
Software Project Management (SPPU) Manag. in Industry
Applications of Software Project
7-2
the planning business esteem until retirement. Whereas in operation, the system ordinarily is upgradeu o
experiences bug fixes; atsuch times, change requests (CRs) are composed. For each CR, you go thrOugn a

process again.
ALM process so that you simply perform this process within the most ideal way. The roles within the ALM nan

incorporate, but aren't restricted to, the following:


takenolders : Stakeholders are as a rule the individuals who either pay for the project or have decision
as
making rights about what to build. We like to moreover incorporate conclusion users in this group, so not
it were management incorporates a stake in a
project.
Business manager : It has got to decide that a development action is attending to begin. After beginning
or
analysis of the business needs, business manager chooses
a to initiate a project to create an application
system that conveys the anticipated business value.
chosen to fill these
o Project manager, product owner, or Scrum master: Appropriate individuals are

roles, and they are arranged to work on the project after the decision to go ahead is made. In a perfect world
these people continue driving the project all the way through, so that you have continuity in project

management.
Project Management Office (PMO) decision makers: These people are too included in planning because

a new project may change or extend the company's portfolio.


Business analyst: After prerequisites collection starts, the business analyst has much to do. As a rule,
initial requirements are assembled when the business need arises, but the genuine work regularly starts
after portfolio rationalization. A business analyst is capable for analyzing the business needs and
prerequisites of the stakeholders to help identify business issues and propose solutions.
Architect: The architect draws an initial picture of the solution. In brief the architect draws the outline of
the system, and the system designers or engineers use this outline. The outline incorporates the level of
freedom essential within the system: adaptability, hardware replacement, new user interfacing, and so on.
The architect must consider all these issues.
User Experience (UX) design team: UX design should be a core deliverable, not something you take off to
the developers to handle. Unfortunately, this plan is often overlooked; it should be given more
consideration. It's important to have near collaboration between the UX group and the development team.
The leading arrangement is to have a UX expert on the development team all through the project, but in
some cases that isn't possible. The UX design is important in making beyond any doubt users can perceive
the value of the system.
Database administrators (DBAs): Almost every business framework or application uses a database in
some way. DBAs can make your databases run like lightning, with great uptime, so it's basic to utilize their
expertise in any project including a database.

O Developers: These are the people who work their enchantment to realize the system by using the
architecture outline drawn from the requirements. Additionally, developers alter or extend the code when
CRs come in.

Testers: It's a role, but testing is something you should consider from the primary time you write down a
necessity and should proceed doing during the entire process. Testers and test managers help to secure
quality, but present day development practices include testing by developers as well.

Tech Kneuledge
PubTTcations
Applications of Software Project
Manag.in Industry
7-3
Software Project Management (SPPU)

Four Ways of Looking at ALM


7.1.2
7.1.2.
The following are the four ways of looking at ALM Fig.
1. The SDLC View
or Operations
View
2. The Service Management

3. The APM View


The Unified View
4

SDLC

The Unified View

APM
Operations

of looking at ALM
Fig. 7.1.2 :The four ways
because development has
maybe the most common way of looking at ALM,
The SDLC View: The SDLC view is
long time. This may be an impact of the gap between the
"owned" management of the application life cycle for a

the lead.
business side and the IT side in most organizations, and IT has taken
View : Operations has too been unfortunately separated from IT
The Service Management or Operations
view of ALM and the problems that can happen in
development. This has resulted in Operations having its
own

this area.
The APM View : Again, perhaps because of the gap between business and IT, we've seen many organizations
with a portfolio ALM strategy in which IT development is as it were one little part. From a business viewpoint,
the focus has been on how to handle the portfolio, not on the complete ALM process.

The Unified View: Fortunately, a few organizations focus on the complete ALM process by counting all three of
the preceding views. Typically the as it were way to require control of, and optimize, ALM. For a Chief
Information Officer (CI0), it's basic to have this view all the time; otherwise, things can get out of hand easily.

7.1.3 Three Pillars of Traditional.ALM

1. Traceability
2. Automation of High-Level Processes

3. Visibility into the Progress of Development Efforts

Tech Knoule
Publicati
Industry
Project Manag.in
of S o f t w a r e
Software Project Management (SPPU) 7-4
Applications

Let's presently see at a few vital columns of ALM that are free of the see you might have Fig

Process
Traceability Autormation

Visibility

Fig. 7.1.3:The three pillars of ALM

1. Traceability: since c

systems running
in producion
c C e n t s we have seen have stopped doing updates on
expensive to
as well
it was far
For these clients,
Opanies had poor or no traceability in their frameworks.

a little change might have.


do upgrades because of the unexpected impacts even within tne
were implemented
which unique requirements
COpanies had no way of knowing another portion, which woula

applications. For a little change in one portion of the code might influence
in advance.
the code connection
come as a shock since poor traceability implied they had no way of seeing
architect models, design
the way to conveyed code through
n e r e must way to follow requirements all
be a
back into the
create it simpler to go
models, build scripts, unit tests, test cases,
and so on not as it were to
delivered the things
illustrate that the system has
to
system. when implementing bug fixes, but
moreover

outside compliance with rules


require traceability to achieve inner as well as
the business wants. You too

and regulations
2. Automation of High-Level Processes:
The other pillar of ALM is automation of high-level processes. All organizations have processes. For example

approval processes control handoffs between the analysis


and design or build steps, or between deployment
andtesting
Much of it is typically done manually in many projects, and ALM stresses the significance of automating

effective and less time-consuming process. Having an automated process also


these tasks for a more

decreases the error rate compared to dealing with the method manually.

3. Visibility into the Progress of Development Efforts:


The third and final pillar of ALM is providing visibility into the progress of development efforts. Many
managers and stakeholders have limited visibility into the advance of improvement projects.
The visibility they have often comes from directing group meetings, amid which the PM reviews the current
situation.
A few would argue that this limitation is good; but, if you need an effective handle, you must guarantee
visibility.

TechPublications
Kneuledge
FSoftware Project Management (SPPU) 7-5 Applications of Software Project Manag.inIndustry

7.2 An Overview of Azure DevOps

Azure DevOps may be a flexible tool, as we have specified. It is additionally very extensible, because all
functionality can be gotten to through web services. This is a very pleasant feature that enables you to build your own
Support for Azure DevOps in other applications as well. Many third-party vendors have done this, and a wide array off

add-ins and tools are available.

2.1 Traceability
The traceability in your DevOps processes is key to the successful delivery and maintenance of your applications

and systems. I once visited a company that ceased making changes to its frameworks fair since no one ever knew

where a change or bug-fix might have its affect. You don't have to bargain with such a circumstance.

Azure DevOps highlights can assist you with traceability so you will avoid such problems:

Work item tracking

TDD/unit testing
Azure Pipelines

Check-in policies
Version control framework

7.2.2 Visibility

Information about project status is important to all members ofa project-and we don't mean group members
as itwere, but stakeholders and decision makers as well. As extended managers, we have gone through a lot of
time chasing down information to reply to questions about the status of projects, how much work remains, and
what the most recent bug status is. Azure DevOps gives three essential ways ofempowering visibility:
1. Widgets and dashboards Customizable, highly configurable dashboards give us and our teams the
adaptability to share data, monitor progress and patterns, and move forward our workflow.
2. Inquiries Questions utilized to ask questions of
are
the work thing following benefit A few questions
might be: How many bug work things do we have? How many and which are devoted to me? How
bugs are there? And so on. You will make new queries when necessary.
many
3. Power BI : The integration of the analytics service with Power BI makes getting the information into Power
BI easy, so you'll focus on making Power BI reports
By utilizing these components, it is easier to accumulate the information
you require for your status reports for a
controlling group meeting or project meeting. You won't have to be see around in
several places and in several
applications for this data anymore; instep, you will utilize the automated
reports and inquiries from inside Azure
DevOps.
7.2.3 Collaboration
The Azure DevOps project, they can view reports and queries, for instance,
the
as well
get to the records within
as
project. Developers can get to the version control system as well
as build
Explorer is fully highlighted, but it is still a tool for people utilized to systems, tests, and so on. Team
issue; but, for most PMs and stakeholders, the GUI working in Visual Studio. For us, that's no
is confusing.
get to significant information.
They need to have a tool that's simple to use to

Tech Knowledge
PubiTC aticns
in Industry
Software Project Management (SPPU) 7-6 Applications of Software Project Manag.
Each project made with Azure DevOps includes a project portal created as we
well. This portal gives you access to

through a web interface, which


ents, project process guidance, and other proiect-related data
the information they require
p e o p l e who are not utilized to the Visual Studio interface to retrieve
effortlessly.
C w O r k ltems for Collaboration: You can utilize the work item features of Azure DevOps to enabie your

work items into AZure


PrOCess orkflows. Let's say a PM, or somebody canable of inputting requirements as
be assigned to a developer
O p s , makes an unused work item of the Situation sort, This scenario should likely
to implement.

7.2.4 Extensibility
to and
the extensibility features grow
w I e n the built-in features of Azure DevOps are not suficient, you can use
when it's more hke an
upgrade 1t. Azure DevOps is often seen asclosed dark box that Microsoft ships,
a
must be customized tor
Enterprise Resource Planning (ERP) framework for DevOps. Any DevOps environment
an organization's processes, existing applications, and administrations.

looking into wnat


wnen you have starting thought of how you need to conduct the Dev0ps process, begin
a

Azure DevOps gives you out of the box. Use what can be utilized, change other things,
and build your own

solution when needed. One extraordinary quality of Azure DevOps is its extensibility and flexibilit
You can adjust the entire tool to fit most parts of your DevOps process. If you need to, you'll be able create your

own add-ins by giving support to roles not included from the start. We strongly encourage you to utilize these
to
extensibility features; but, within the conclusion, it is your choice. Extensibility could be an extraordinary way
coordinate existing frameworks and potentially migrate a few of them into Azure DevOps to decrease the

instrument set in the organization.

7.3 Difference between Microsoft TES and Azure DevOps


Since it was launched in 2005, Team Foundation Server (TFS) has evolved significantly until Microsoft launched
Azure Devops in 2018. As a part of the broader shift to cloud services, the company renamed the cloud-based
Visual Studio Team Services (VSTS) to Azure DevOps Services and TFS as Azure DevOps Server.

Azure DevOps Services and Azure DevOps Server are the new releases of Visual Studio Team Services (VSTS) and
Team Foundation Server (TFS) respectively. Azure DevOps Services is a cloud-based environment. As its name
suggests, Azure DevOps Server provides the services of Azure DevOps on-premise.

The key difference between VSTS, TFS, and Azure DevOps is that the first two comprise a single service. In
theAzure DevOps release, this service is split into five improved services Boards, Pipelines, Repos, Test Plans,
and Artifacts which can be used separately.

Let us look at some of the additional benefits when you upgrade from TFS to Azure DevOps.

1. Improved Navigation Experience


TES was primarily designed for admins. Despite incremental improvements, many users found
complicated to use, With Azure Devops, users enjoy a seamless experience that is consistent across bot
Azure DevOps service and Azure DevOps Server.

The navigation inspired by Microsoft's Fluent design language that is being rolled out across its
is
offering
for consistency and predictability. With this capability, users can switch between services
easily.
TechPubIC
Knoule-
ati
in Indust
Software Project Management (SPPU) 7-7 Applications of Software Project Manag. astry
ne user intertace is more responsive, and users can focus on their work better. The Ul overhaul is the most
t

notable difference between TFS and Azure DevOps.


2. Simplified Artifact and Release Management
Users can leverage Artifacts even with the Basic License. Additionally, the Release Management Deployment
Pipelines will not have to be procured separately as it has been integrated with Azure DevOps Server.

With this, users can take advantage of the new Build and Release pages and use the YAML data serialization

standard to code configuration files. This was not supported in TFS 2018.

3. Tighter GitHub Enterprise Integration


As a part of enhancing project management capabilities, teams using Azure DevServer can connect GitHub

Enterprise with Azure Boards.


The commits and pull requests in GitHub can be used in conjunction with the backlogs, different work item

types, tools, and boards in Azure Boards that is a part of Azure DevOps.
There is no disruption in the workflow as commitments will be merged in the appropriate branches.

4. Azure SQL Database Support


Both Azure DevOps server and TFS require sQL Server. With Microsoft's focus shifting to the cloud, Azure
DevOps server can be hosted on virtual machines running on Azure.
These support Azure SQL Database that can give users superior scaling and backup options without
increasing administrative costs for running these complex services.
5. Advanced Search Capabilities

There have been considerable enhancements in the search capabilities in Azure DevOps Server. The first
addition is the introduction of my work flyout. With this feature, information from other components of the
product will be accessible from whichever part users are currently working on.

This is similar to a notification bar on which you search for


important updates without dropping your
can

current activity. The other


improvement is the ability to expand the search box from the product header.
This has been added based on user feedback to improve
navigation.
7.4 Introduction to Metrics in Agile Practice

To get good metrics about the status of your


projects, ite's important to measure your progress. You will be able to
do this in few ways. On the off chance that you are
a
using Agile as a strategy, many of these metrics and reports
should be familiar. To others, they may be modern. Be
beyond any doubt that not all of these reports are accessible in
Azure DevOps, but only in TFS on-prem.

Metrics in Agile Practice :

Let's see at a few important reports that are commonly utilized in Agile practices:
1 Backlog overview 2. Sprint burndown
3. Velocity report Release burndown
5 Remaining work 6. Unplanned work

Tech Knouledge
udiicatin0s
Software Project Management (SPPU) Applications of Software Project Manag,inIndustry
- 8

1 Backlog overview: The backlog overview report records all user stories, filtered by labels and iteration, and
arrange of significance. Essentially, usually a list of user stories filtered by the criteria you wish. Many people
utilize Excel (or another spreadsheet application) to form this report, but many DevOps tools have a built- in back

for creating it

2. Sprint burndown: In the spring burndown, you can predictwhen the team will wrap up the work assigned to
this sprint, either during the sprint or after the sprint is finished. Based on this information, the team and the
product owmer can take activities to form beyond any doubt they deliver what they have committed to convey

3. Velocity report: In simple words velocity is basically how much work a team can take on in a sprint, So velocity
Is important, especially for a product owner arranging how much work can be accomplished in coming sprints.
Velocity is more often than not a degree of the effect per story point that the team can accomplish. Before any
work is begun, the product owner calculates a theoretical velocity to start planning. As time goes by, it's updated
with the team's real velocity based on how much work it conveys in each sprint. This makes a difference as the

product owner estimates how much work the team can take on in coming sprints.
Release burndown: The release burndown report appears the same thing as the sprint burndown, but for the

work included in a release.

5. Remaining work: The remaining work report is another valuable metric. You can utilizeit to track the team's
progress and distinguish any issues within the flow of work. With some tools, you'll be able to see this report in

either an Hours-of Work view or a Number-of-Work-Items view.

6. Unplanned work: The unplanned work report is useful when the team plans an iteration by distinguishing all
work items it extraordinary to resolve or close during the course of the iteration. Work items assigned to the
iteration by the arranged completion date of the report are considered planned work. All work items included to
the cycle after that date are identified as unplanned work.

7.5 Metrics for Project Management

To get good metrics about the status of your projects, it's important to measure your progress.

The following are the some Metrics for Project Management:

1. Agile Metrics
2. Metrics for Architecture, Analysis, and Design

3. Metrics for Developer Practices

Metrics for Software Testing

1. Agile Metrics:

Backlog overview, Sprint burndown, Velocity report, Release burndown, Remaining work and Unplanned work
are the agile metrics used for project management

Tech Knowledge
PubliC ationS
Software Project Management (SPPU) 7-9 Applications ofSoftware Project
Manag.in Industry

2. Metrics for Architecture, Analysis, and Design:


but you ll utilize a
assessment for architecture,
e p s tooIs don't many metrics you'll use for KPI
incorporate
rew taken from the development area. Using code metrics, vou'll get information about how your architecture

and design are working, including the following:


Lines of code : Presents an in exact number based on Intermediate Language (IL) code. A high count may

Indicate that a type or method is doing too much work and ought to be part up. This may too be a warning

that code will be difficult to preserve.


Class coupling: Measures the coupling to unique classes through parameters, local variables, return types,

interface implementations, defined on


fields
Strategy calls, generic or template instantiations, base classes,
external types, and attribute beautification. Strive for low coupling. High coupling shows a plan that is

troublesome to reuse and keep up since of its many interdependencies on other types.

to the root of the class


Depth of inheritance: Demonstrates the number of class definitions that amplify
hierarchy. The more profound the hierarchy, the more difficult it may be to get it where specific strategies

and areas are defined and/or redefined.


Cyclomatic complexity: Is decided by calculating the number of different code ways within the stream of
the program. It demonstrates the code's complexity. A high complexity makes maintainability suffer, and it
can also be difficult to induce great code coverage.

Maintainability index : Is an index value between and 100 that speaks to the relative ease of keeping up
the code. The higher the better; a rating of more than 60 is good. Less than that, maintainability suffers.

3. Metrics for Developer Practices

Metrics for developer practices are KPIs that can assist you get it if you are working effectively to improve
your
code. Some of the important metrics are available
naturally in many tools and can assist you get a great
understanding of the quality of your development work:

Code coverage : Code coverage shows you how much of the


code has been covered by automated unit
You get the esteem as a rate of the whole code base. tests.
The difficulty frequently is
choosing what percentage
is
enough.
Code metrics: You can see a few distinctive code metrics. Lines
of code, class
coupling, profundity of legacy
cyclomatic complexity, and the
maintainability record. The Measurements for Architecture,
and Plan moreover apply to code metrics. Investigation,
Compiler warnings Errors and notices should be
maintained
Permitting more than zero errors or
strategic distance from in a project.
a

warnings tends to result within the team


the code base, which over time
causes the code to
accepting lower quality within
lose
Code
maintainability.
analysis warnings: Code analysis in
which makes a difference
improvement devices performs inactive
designers distinguish potential plan, investigation on code,
security issues, to title a few. globalization, interoperability, execution, and

TechPticatiens
Knouledge
Software Project Management (SPPU) 7-10 Applications of Software Project Manag. in Industry

4. Metrics for Software Testing:


Software testing is an important area. Testing should be a constant portion of any development exertion, not fair

a stage at the conclusion of a project. The following are a some of the metrics you can use as KPls for program

testing:
Number of bugs per state: This metric tells you how many bugs are active, resolved, or closed; whether
the number of active bugs is increasing and whether the number of resolved and closed bugs is constant. If

the numbers remain constant, you would like to see how you perform your testing.
automated unit
Code coverage: This metric appears to show how much of the code has been covered by
tests. You get the esteem as a rate of the whole code base.
Test run results : This metric indicates how your tests are performing, and whether you have got many

failed tests. If you are, doing you would like to see what can be done to improve the tests.

the rate of
Percentage of requirements covered by test cases : As the title infers, this metric shows

requirements covered by test cases.

7.6 Agile Project Management in Azure DevOps and TFS


Azure DevOps is a Software as a service platform offering a set of complete end-to-end tools needed for

software the cloud. Earlier, known Visual Studio Online (VSO) or Visual Studio
developing and deploying on as

Team Services (VSTS), this Microsoft offering is a centralized service that can be used for any software project.

The software development teams can leverage Azure DevOps to design projects using a single platform via Agile
methodology. The several functions achieved by Azure DevOps are work item tracking. code management,
applications deployment, tests management, running builds, and visualization.

Azure DevOps allows choosing from a wide option of Azure Board's planning tools that are perfect for agile

project management
The planning and portfolio management of the Azure Board enables the user to plan swifdy and track all work
across the entire team. Major features that altogether help the project team track their worklow throughout the
development cycle without any hassles are

Task boards

O Product and sprint backlogs

Dashboards

Analytics reports, etc.

Users if paired with a project and portfolio management platform ie. PPM Express can easily connect to Azure
DevOps within a single system. This will provide clear visibility of project-related information across groups,
systems, and portfolios.

Tech Kneuledg
Pubiit ation
Software Project Management (SPPU) 7-11 Applications of Software Project Manag,inIndustry

7.6.1 Feature of Azure DevOps Project Management


or web browser.
embedded with integrated features which are accessible either via IDE
Azure DevOps comes

The prominentfeatures available with Azure DevOps include:

Azure Boards
Code Deploy
Azure Artifacts
Azure Repos
Pan
espajeH

Monitor
Test

A~ure Test Plans


Azure Pipeline

Fig.7.6.1

your Azure Active Directory.


Plus, it establishes a
User Control: Azure allows you to connect with
synchronization with on-premises AD and can even helpinvite guests. However, certain access rules are

them from certain elements. But, when users are allocated to teams,
applicable to users, restricting watching
they become capable of accessing code, evaluating work and colluding with others.

Azure Guests: This feature provides you the flexibility to invite guests from other institutions to join the team
simply by entering their mail id.

Groups/Permissions: Under group management, this attribute allows adding members to the pertinent group
on the organization setting page. Further, permissions on a group are also configurable for a project

Teams: This lets users be delegated to one or more teams. This, as a consequence, restricts users to see only
what is permitted by a particular team.

Processes and Types: Azure DevOps comes with pre-made customized templates. The four common work item
templates offered by Azure DevOps include Basic, scrum, agile, and CMMI.

Backlogs: Backlog is nothing but a place where you can monitor, plan, and organize your projects. Generally
there are three basic backlogs in Azure DevOps which include the Portfolio backlog, Requirement backlog, and
Iterationbacklog
Boards: Boards offer an intuitive interface to manage and organize yourwork All yourwork items are placed in
card format and arranged according to their latest status for easy understanding.

Iteration Path: Itis used to assign work items to time intervals and is also known as sprints.

Areas: These find utility in breaking down work in a logical sequence, coordinating it with functional areas, and
building websites for varied business segments.

Tech Knouledge
Software Project Management (SPPU) 7-12 Applications of Software Project Manag.in
Industry
Oncadons : Send alerts to keep your team notified of every important task. Whether it's a work assignment
or activity failure/ success, you can always send alerts as and when needed
Dashboards : Construct your own dashboard for varying purposes based on your team members demand, work

item criteria, and other attributes as deemed appropriate.


Azure Repos: Azure Repos refers to a set of version control tools that allow developers to monitor changes in

coding over time.


Analytics : Leverage Azure DevOps's built-in analytics features, such as cumulative flow diagrams, conro
charts, and burn charts to get real-time updates on your workflow patterns.
7.6.2 Fundamental Components of Azure DevOpss
There are five components:
Boards

Repos
Pipelines
Test plans

Artifacts
1) Azure Boards : Azure Boards is the service where you track your backlog items and categorize them based on

on hierarchy, like Epic, Features, User Stories, Tasks and Bugs. Here is where we prepare our sprints and plan
the items inside. Of course business users are always involved during this preparation. Transparency is very
high. They are aware which items will be delivered at the end of each sprint.
2) Azure Repo : Here is the place where we can do version control of our source codes. Developers who are
familiar with Git will pickup Azure Repo easily. In Azure Repo, everyone is creating their branches and pushing
their developments to that branch. Later on this changes are merged (or rejected) with our master branch which
is ready to push to server.
3) Azure Pipeline : Azure Pipeline is the place where you can set up your Cl/CD pipelines. Here is the place where
we prepare our product for deployment and push to server. Azure Pipeline is an automated set of processes that
helps developers to compile, build, and deploy codes on other computation platforms. It is a continuous delivery
tool similar to open source Jenkins or CodeShip. The sole goal of this pipeline is that there is no manual
intervention, all the changes are automatically executed in the project.
4) Azure Artifacts: allows the teams to easily package the dependencies and other artifacts required for the
application deployment and its functionality, thus making it easier to publish and consume the application. There
can be different kinds of artifacts such as - Build Artifacts, Maven, Npm, Nuget, PyPl, Universal Packages, and
Symbols
5) Azure Test Plans : are a set of rich and powerful tools to test your application that includes manual/exploratory
testing and continuous testing. They are easy to use, and browser-based test management solution providing all
the capabilities required for different testing methodologies

7.6.3 Best Practices for Agile Management

The many features and functionalities of Azure DevOps might get confusing, but if you're focusing on an
agile process, here are a few best practices to keep in mind:

echPubITC
Knowledg-
ation
Software Project Management (SPPU) 7-13 Applications of Software Project Manag. in Industry

Configure Your Teams


Each project has a default team. However, you should define the team if you have several features or
development teams.
To follow agile methodologies, you should form agile teams based on the deliverables. Define a team for each
group of developers and set scrum masters to streamline your agile project.

Configure Your Sprints


Iteration Paths specify sprints for a project, which are then chosen by teams. The sprint cadence may vary in
terms of duration or hierarchy. Sprint backlogs, Taskboards, Forecast, and Delivery plans are all used by Azure
Board tools to allocate sprints to a team.
Best practices for sprints in agile projects include defining a sprint cadence teams can use in your product group,
defining several iterations for future planning. determining how teams will use iterations to manage backlog
items and so on.

Work in Sprints

Sprints allow developer teams to concentrate on a particular set of tasks. Work assigned to a sprint shows in
the sprint backlog of the team. Only product backlogs have sprint backlogs; portfolio backlogs do not
Sprint Burn-down Chart
The sprint burn-down chart makes it simple to keep track of your progress. For sprint planning. use your
team's Sprint backlog to evaluate the deliverables.
For an iterative approach, each sprint item is assigned to a team member. These tasks are scoped to be
completed inside the sprint. You should also keep track of the sprint burn-down chart.
Besides, check in with other teams on dependencies that may affect your team. Regularly update the status of
sprint work items as they go from New to Active to Complete.

Besides following the best practices, pair up Azure DevOps with PPM Express to get maximum efficiency out of
your agile project. With PPM E>xpress, you can examine and manage all your projects and portfolio status, cost,
and progress in one spot.
Furthermore, PPM Express simplifies data analysis and reporting for your projects. It gives you control over the
tasks, deadlines, and costs involved in the process. It also enables all projects, portfolios, and other internal data
-

terms, budgets, and performance indicators -

to be connected in one system.

Review Questions

a.1 Explain application life cycle management process.


Q.2 What are the four ways of looking at ALM ?

Q.3 Explain Difference between Microsoft TFS and Azure DevOps.

Q.4 Write a short note on : 0verview of Azure DevOps.

a.5 Explain metrics for Project Management.


Q. 6 Write a short note on : Fundamental components of Azure DevOps.

You might also like