Rossberg - Agile Project Management using Team Foundation Server 2015

Agile Project Management using Team Foundation Server 2015 — read online for free the complete book (whole text) full work

Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Agile Project Management using Team Foundation Server 2015" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.

Light

Font size:

↓

↑

Georgia Tahoma Arial Verdana

Reset

Interval:

↓

↑

Bookmark:

Make

1234567...48

Joachim Rossberg 2016

Joachim Rossberg Agile Project Management using Team Foundation Server 2015 10.1007/978-1-4842-1870-9_1

1. Introduction to Application Lifecycle Management

Joachim Rossberg 1

(1)

Goteborg, Sweden

What do you think about when you hear the term Application Lifecycle Management (ALM) ? During a seminar tour in 2005 in Sweden, presenting on Microsoft Visual Studio Team System, we asked people what ALM was and whether they cared about it. To our surprise, many people equated ALM with operations and maintenance. This is still often the case when we visit companies, although more people today are aware of the term.

Was that your answer as well? Does ALM include more than just operations? Yes, it does. ALM is the thread that ties the development lifecycle together. It involves all the steps necessary to coordinate development lifecycle activities. Operations are just one part of the ALM process. Other elements range from requirements gathering to more technical things like the build and deploy processes.

Aspects of the ALM Process

All software development includes various steps performed by people playing specific roles. There are many different roles, or disciplines, in the ALM process, and we define some of them in this section. (The process could include more roles, but we focus on the primary ones.)

Look at Figure , which illustrates ALM and some of its aspects. You can see the flow from the birth of an application, when the business need first arises, to when the business need no longer exists and the application dies. Once the thought of a new application (or system) is born, many organizations do some portfolio rationalization. This means you discuss whether an existing system can handle the need or whether a new system has to be developed. If a new system must be built, you enter the software development lifecycle (SDLC) and develop the system, test it, and deploy the system into operation. This is the point at which you do a handover so that operations can maintain and refine the system. Once in production, the system (hopefully) delivers the intended business value until retirement. While in operation, the system usually is updated or undergoes bug fixes; at such times, change requests (CRs) are written. For each CR, you go through the same process again.

Figure 1-1.

The Application Lifecycle Management process

Its essential to understand that all business software development is a team effort. The roles require collaboration in order to deliver business value to the organization. If you dont have this collaboration, the value of the system most likely will be considerably lower than it could be. One step up from the project level, its also important to have collaboration between all roles involved in the ALM process, so that you perform this process in the most optimal way.

The roles in the ALM process include, but arent limited to, the following:

• Stakeholders: Stakeholders are usually the people who either pay for the project or have decision-making rights about what to build. We like to also include end users in this group so not only management has a stake in a project.
• Business manager: Somebody has to decide that a development activity is going to start. After initial analysis of the business needs, a business manager decides to initiate a project to develop an application or system that will deliver the expected business value. A business manager, for instance, must be involved in the approval process for a new suggested project, including portfolio rationalization, before the company makes a decision to go ahead. IT managers are also part of this process, of course, because IT staff will probably be involved in the projects development and deployment into the infrastructure.
• Project manager, product owner, or Scrum master: Suitable individuals are selected to fill these roles, and they set to work on the project after the company decides to go ahead with the project. Ideally, these people continue leading the project all the way through, so that you have continuity in project management.
• Project Management Office (PMO) decision makers: These individuals are also involved in planning, because a new project may change or expand the companys portfolio.
• Business analyst: After requirements collection starts, the business analyst has much to do. Usually, initial requirements are gathered when the business need arises, but the real work often begins after portfolio rationalization. A business analyst is responsible for analyzing the business needs and requirements of the stakeholders, to help identify business problems and propose solutions. Within the systems development lifecycle , the business analyst typically performs a collaborative function between the business side of an enterprise and the providers of services to the enterprise.
• Architect: The architect draws an initial picture of the solution. We dont go into detail here, because Chapter does that. But briefly, the architect draws the blueprint of the system, and the system designers or engineers use this blueprint. The blueprint includes the level of freedom necessary in the system: scalability, hardware replacement, new user interfaces, and so on. The architect must consider all these issues.
• User experience (UX) design team: UX design should be a core deliverable and not something you leave to the developers to handle. Unfortunately, its often overlooked; it should be given more consideration. Its important to have close collaboration between the UX team (which could be just one person) and the development team. The best solution is obviously to have a UX expert on the development team throughout the project, but sometimes that isnt possible. The UX design is important in making sure users can perceive the value of the system. You can write the best business logic in the world, but if the UX is badly designed, users probably wont think the system is any good.
• Database administrators (DBAs): Almost every business system or application uses a database in some way. DBAs can make your databases run like lightning with good up-time, so its essential to use their expertise in any project involving a database. Be nice to them; they can give you lots of tips about how to make a smarter system. Alas for DBAs, developers handle this work more and more frequently. This means developers are expected to have vertical knowledge and not just focus on coding.
• Developers: Developers, developers, developers! as Microsoft CEO Steve Ballmer shouted in a famous video. And who can blame him? These are the people working their magic to realize the system by using the architecture blueprint drawn from the requirements. Moreover, developers modify or extend the code when change requests come in.
• Testers: Id rather not see testing as a separate activity. Dont get me wrong, its a role, but testing is something you should consider from the first time you write down a requirement and continue doing during the whole process. Testers and test managers help you secure quality, but modern development practices include testing by developers as well. For instance, in Test Driven Development (TDD), developers write tests that can be automated and run at build time or as part of checking in to version control.
• Operations and maintenance staff: When an application or system is finished, its handed over to operations. The operations staff takes care of it until it retires, often with the help of the original developers, who come in to do bug fixes and new upgrades. Dont forget to involve these people early in the process, at the point when the initial architecture is considered, and keep them involved with the project until everything is done. They can provide great input about what can and cant be done within the company infrastructure. So, operations is just one partalthough an important oneof ALM.

Next page

1234567...48

Light

Font size:

↓

↑

Georgia Tahoma Arial Verdana

Reset

Interval:

↓

↑

Bookmark:

Make

Similar books «Agile Project Management using Team Foundation Server 2015»

Look at similar books to Agile Project Management using Team Foundation Server 2015. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.

Anthony C. Mersino

Agile Project Management: A Nuts and Bolts Guide to Success

Project Management Journal

Agile Project Management: Essentials from the Project Management Journal

Alan Moran

Valuing Agile : the Financial Management of Agile Projects.

Patrick Li

Jira Software Essentials: Plan, track, and release great applications with Jira Software, 2nd Edition

Layton

Agile Project Management For Dummies

Harry Brian

Visual Studio Team Foundation Server 2012: adopting agile software practices: from backlog to continuous feedback

Campbell

Agile: All You Need to Know about Agile Software Development. Team and Project Management using Scrum

Joachim Rossberg

Agile Project Management with Azure DevOps: Concepts, Templates, and Metrics

ClydeBank Business

Agile Project Management: QuickStart Guide A Simplified Beginner’s Guide To Agile Project Management

Mark C. Layton

Agile Project Management For Dummies

Malik J.

Agile Project Management with GreenHopper 6 Blueprints

Jakob Ehn

Team Foundation Server 2012 Starter

Discussion, reviews of the book Agile Project Management using Team Foundation Server 2015 and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.