attendee manual

Upload: eduardo-quintanilla

Post on 14-Apr-2018

226 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/30/2019 Attendee Manual

    1/160

    Module 1: Introducing ApplicationLifecycle Management

    Table of Contents

    Module Overview 1Lesson 1: The Business Case for ALM 2

    Lesson 2: What is ALM? 5

    Lesson 3: Supporting ALM with VSTS 13

    Module Review 26

  • 7/30/2019 Attendee Manual

    2/160

    Information in this document, including URL and other Internet Web site references, is subject to change

    without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-

    mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any

    real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or

    should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting

    the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval

    system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or

    otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

    The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft

    makes no representations and warranties, either expressed, implied, or statutory, regarding these

    manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or

    product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third

    party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of

    any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not

    responsible for webcasting or any other form of transmission received from any linked site. Microsoft is

    providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of

    Microsoft of the site or the products contained therein.

    Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights

    covering subject matter in this document. Except as expressly provided in any written license agreement from

    Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,

    copyrights, or other intellectual property.

    2007 Microsoft Corporation. All rights reserved.

    Microsoft are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or

    other countries.

    The names of actual companies and products mentioned herein may be the trademarks of their respective

    owners

  • 7/30/2019 Attendee Manual

    3/160

    Module 1: Introducing Application Lifecycle Management 1

    Module Overview

    This module introduces Application Lifecycle Management (ALM), and explains the

    business rationale and business benefits of ALM. The module explains how an

    organization can get started with ALM. It also introduces VSTS as Microsofts solution

    to support ALM through tooling and process enactment.

    Objectives

    After completing this module, you will be able to: Describe the business case for ALM.

    Explain what ALM is.

    Explain how VSTS supports ALM.

  • 7/30/2019 Attendee Manual

    4/160

    2 Module 1: Introducing Application Lifecycle Management

    Lesson 1: The Business Case for ALM

    This lesson presents the business rationale for ALM. Business and technology executives

    including CTOs, CIOs and IT managers are being asked to do more with less.

    Maintenance of legacy systems and current technology support consumes vast amounts

    of a typical enterprise software budget. This leaves precious few resources to develop

    new, standards based, adaptive applications that meet the core needs of the business.

    Managing complexity, aligning IT with the business, and enabling agility are top

    priorities for CIOs who are under pressure to do more for the business with fixed or

    diminishing budgets.

    So how can you measure the real value of IT? How can you ensure that it helps you

    effectively run your business? Your core business and your IT departments must coalesce

    and your software initiatives must deliver measurable business benefits. To help achieve

    this, a common lifecycle management solution is needed to help you track, balance, and

    communicate the systems that are being created to effectively run your business.

    Application Lifecycle Management (ALM) provides such a solution by addressing the

    overall alignment and synchronization of business goals and IT investment priorities. It

    relies on automation, integration and a coordinated approach to optimize the software

    development process. Acquiring tools to support ALM, such as Microsoft Visual Studio

    Team System (VSTS) is straightforward. Introducing and driving an ALM strategy

    within your organization, and understanding the necessary changes required within your

    business is more difficult.

    Objectives

    After completing this lesson, you will be able to:

    Describe the business case for ALM.

  • 7/30/2019 Attendee Manual

    5/160

    Module 1: Introducing Application Lifecycle Management 3

    Software Development The Last Ten Years

    How have software projects been doing over the last 10 years? How successful have they

    been and are they getting any better? According to industry data the track record for

    reducing costs is fairly impressive. You can see from the left hand graph that 200% cost

    overruns have been reduced to around 50% cost overruns between 1994 and 2004. While

    still not great, things have improved.

    However if you take the same data and look at it differently as shown by the right hand

    graph, the succeeded bars (the green lines) are stuck at around 30% indicating that only

    about one third of projects actually succeed. In virtually every other industry this wouldnot be acceptable. Why should it be an acceptable state of affairs for software

    engineering?

    So the good news is that cost overruns are down by 100%. The bad news is that still only

    30% of software projects succeed, which is not a good story. The bottom line is that it

    now costs less to fail!

  • 7/30/2019 Attendee Manual

    6/160

    4 Module 1: Introducing Application Lifecycle Management

    Key Business Issues

    Business and technical decision makers generally face a number of common issues with

    their IT and software initiatives. These issues are highlighted on the slide.

    The predominant issues, common to most development organizations today are:

    Lack of visibility into project status. This is a primary project management issue

    that can also include the inability to enforce responsibility, accountability, sign-offs

    and checkpoints. The inability to enforce stakeholder involvement, to perform

    accurate estimation, and to adjust project schedules accordingly are also symptomatic

    of project management issues.

    Ineffective team communication. Coordinating efforts across functional, geographic,

    and organizational boundaries is a particularly challenging communication issue.

    Balancing business demands with project risk. Poorly defined and changing

    requirements, scope creep, unreliable estimates, unclear business objectives and

    complex and rapidly evolving technology compound this issue and increase risk.

    Unpredictable delivery times and quality. Balancing quality of service

    requirements, functional requirements, budget and schedule is a tough challenge.

    Eleventh hour bugs found during test and in production are all too frequent

    occurrences.

    There are many different areas and factors that can contribute to these core issues and

    discovering and addressing the underlying issues is non-trivial. Additional demands

    include having to balance new project requirements with the financial burden of

    maintaining existing applications and the need to meet ever more stringent compliance

    requirements.

  • 7/30/2019 Attendee Manual

    7/160

    Module 1: Introducing Application Lifecycle Management 5

    Lesson 2: What is ALM?

    This lesson defines ALM and its principles, and how multiple roles (from both the

    business and technical groups within an organization) are involved in ALM. It also

    presents an approach and a process for getting started with ALM.

    This next set of topics introduces ALM. To begin, consider what you may already know

    about ALM. How does your organization manage software development? How does it

    gather the data necessary to manage software development? Does your organization need

    to change the way it manages software development? Why would that be, and what is the

    goal of the change?

    As you learn about ALM, you will find it does not offer a single solution to any question.

    In the end, the best solution is the one that works for the team and adds value to the

    business.

    Objectives

    After completing this lesson, you will be able to:

    Explain what ALM is.

  • 7/30/2019 Attendee Manual

    8/160

    6 Module 1: Introducing Application Lifecycle Management

    What is ALM?

    Forrester Research provides a definition of ALM that you may already know. ALM

    describes methods to manage software development and IT initiatives by automating the

    process from end to end, and integrating the information from the various steps.

    Integration provides consistency and accuracy and also introduces opportunities for

    automation.

    Application Lifecycle Management (ALM) aligns the three capabilities of the

    organization -- Business, Development and Operations -- by integrating the organizations

    tools and activities. Aligning these three capabilities can produce applications that meetbusiness demands and while making the development process more manageable.

    Microsofts vision of ALM is to look at the broad landscape of application development

    and the software development lifecycle. Using Visual Studio Team Foundation Server as

    a driving platform, Microsofts goal is to drive business governance, infrastructure

    management, operations and support so that software teams can focus, be productive and

    add value to the business.

  • 7/30/2019 Attendee Manual

    9/160

    Module 1: Introducing Application Lifecycle Management 7

    What is ALM?

    Application Lifecycle Management (ALM) aligns the three capabilities of the

    organization: Business, Development and Operations by providing integration between

    the various tools used and activities performed within each of these capabilities.

    Aligning these three capabilities results in applications that meet business demands and

    that are better manageable.

    The three core pillars of ALM are:

    Traceability of relationships between artifacts. This is traditionally a laborintensive, manual process, where the effort varies with the number and size of

    projects, the varying size and scope and the number of artifact interdependencies.

    Compliance requirements make traceability a necessity.

    Automation of high level processes. Development organizations commonly use

    paper-based approval processes to control handoffs between functional areas. ALM

    solutions improve efficiency by automating these handoffs and by providing central

    storage for all associated documentation. Automated and executable process models

    are used by ALM solutions to ensure process adherence.

    Reporting to increase visibility. Most managers have limited visibility into the

    progress of development projects. What visibility they have is typically gleaned fromsubjective testimonials, and not objective data. The lack of proper reporting also

    hinders opportunities for process improvement. The ALM reporting functions benefit

    from integration and automation to provide real time status information and deep

    analysis of all activities.

  • 7/30/2019 Attendee Manual

    10/160

    8 Module 1: Introducing Application Lifecycle Management

    ALM Practices

    VSTS supports the three core pillars of ALM by providing:

    Traceability of relationships between artifacts. VSTS provides traceability

    between artifacts primarily through its work item tracking capability. Work items can

    include scenarios, quality of service requirements, tasks, bugs and risks. Individual

    work items can be linked. For example you can relate specific tasks to specific

    scenarios or QoS requirements and in this way track their progress throughout the

    lifecycle. Work item history is also provided to provide an audit trail, which is

    important for compliance.

    Automation of high level processes. VSTS enables you to avoid paper-based

    approval processes to control handoffs between functional areas. VSTS provides

    central storage for all associated documentation. It also provides process templates

    which enable you to enact key processes and automate specific practices to help

    ensure process adherence.

    Reporting to increase visibility. VSTS provides an extensive range of reporting

    options to help you view and track the current status of your development efforts.

    This enables you to use objective data to ascertain project progress rather than relying

    on subjective input. VSTS reporting provides real time status information and deep

    analysis of all activities.

  • 7/30/2019 Attendee Manual

    11/160

    Module 1: Introducing Application Lifecycle Management 9

    The Business Benefits of ALM

    Introducing ALM to organizations has accomplished the following business benefits:

    Increased ROI from your IT spending.

    Increased accountability, enabling stricter compliance to governance initiatives.

    Increased collaboration between business and IT better alignment of the business

    with IT.

    Improved project management, including better estimation, better tracking, and better

    reporting through a single, unified view of the project. The improved integration

    stems from the use of tools that work together rather that disparate tools, poor

    integration and duplicated data.

    Quality improvements, so the final application meets the requirements of your

    customers, and meets quality of service requirements.

    Shorter development cycles and improved productivity through shared best practice

    and process learning and improvement.

    Increased ability of the IT department to rapidly build and adapt applications to

    support dynamically changing business requirements.

    The net result of these benefits is increased synchronization between IT and yourbusiness to deliver improved business value to your customers and to provide an

    additional competitive advantage.

  • 7/30/2019 Attendee Manual

    12/160

    10 Module 1: Introducing Application Lifecycle Management

    ALM Roles and Responsibilities

    Many different roles are involved throughout the application lifecycle. Roles include

    development executives, project managers, business analysts, architects, UI designers,

    DBAs, developers, testers and operations. Note that roles are fluid, and are a set of a

    responsibilities, and not simply a job title.

  • 7/30/2019 Attendee Manual

    13/160

    Module 1: Introducing Application Lifecycle Management 11

    A Process for Introducing ALM

    Introducing an ALM strategy takes time and your focus should be on practices and

    process improvement -- and not simply introducing tools. You should aim to implement

    ALM iteratively, for example by phasing in new practices over time. When drawing up

    your implementation plan, you should also make sure that it is aligned with your key

    business drivers.

    A key requirement when getting started is to first understand your organizations current

    strengths and weaknesses when it comes to application development and IT delivery. If

    you know the current strengths and weaknesses, and where your organization is today,you can determine how it needs to adapt in order to realize the true benefits of ALM.

    Microsoft provides resources that can help evaluate your organizations ALM needs and

    determine solutions. Start by readingApplication Life-cycle Management (ALM) for

    Software Teams at http://msdn2.microsoft.com/en-us/teamsystem/bb400737.aspx. You

    can also complete an in-depth assessment to learn more at

    https://www.microsoft.com/almAssessment.

    The primary objective for ALM is to turn your IT function from a basic cost center that

    delivers brittle, unconnected applications and platforms into a strategic asset capable of

    delivering a service oriented application platform that supports your business functions.

  • 7/30/2019 Attendee Manual

    14/160

    12 Module 1: Introducing Application Lifecycle Management

    Discussion: Moving Towards ALM

    During this discussion, you should consider to what extent your current organization has

    adopted ALM practices. You should reflect on where your organization is now in terms

    of its processes, team roles and development practices. Consider what would need to

    change to move towards a more integrated ALM approach.

  • 7/30/2019 Attendee Manual

    15/160

    Module 1: Introducing Application Lifecycle Management 13

    Lesson 3: Supporting ALM with VSTS

    This lesson explains how VSTS provides the integrated tooling to help support your

    ALM initiatives.

    This lesson starts with a top level overview of the VSTS/TFS landscape and then explains

    how different VSTS features help support the three key pillars of ALM -- traceability,

    process enactment, and visibility.

    Objectives

    After completing this lesson, you will be able to:

    Understand how Visual Studio supports traceability, process enactment, and visibility.

  • 7/30/2019 Attendee Manual

    16/160

    14 Module 1: Introducing Application Lifecycle Management

    ALM and VSTS

    ALM is a discipline as well as a product category. ALM doesnt support specific

    lifecycle practices, but rather it keeps them in sync manual processes can be more

    efficient and effective through tool integration. Development efforts can still fail even if

    separate development activities are done correctly. ALM ensures the coordination of

    these activities. An ALM solution is therefore the integration of lifecycle tools, not

    merely a collection of those tools. Furthermore ALM is labor intensive without the

    integration of lifecycle tools, in other words, automation is necessary.

    VSTS is a process platform, where you adopt and adapt practices accordingly. It enablesyou to take overhead out of what people do, while not dictating what they do. VSTS is

    designed to facilitate the ALM discipline and process your team chooses.

  • 7/30/2019 Attendee Manual

    17/160

    Module 1: Introducing Application Lifecycle Management 15

    The Visual Studio Team System / Team Foundation Server

    Landscape

    VSTS provides an integrated set of tools, processes and guidance to support ALM. The

    Team Foundation Server (TFS) component provides a centralized repository for all

    project artifacts such as project work items, workflow settings and status, requirements

    and design documents, source code with versioning, branching and merging, and test and

    build results. Reports are driven from a centralized data warehouse. All artifacts are

    linked to each other where necessary to achieve high degrees of integration.

    VSTS is licensed in four different editionsTeam Edition for Software Architects, TeamEdition for Software Developers, Team Edition for Database Professionals, and Team

    Edition for Software Testers. Each edition of Visual Studio Team System is configured to

    deliver tools and solutions out-of-the-box. However, each edition is highly extensible and

    can be customized as necessary to fit the needs of each organization. Further extensibility

    is available by joining the Microsoft Visual Studio Industry Partner (VSIP) program. This

    enables a licensee to access the VSTS APIs, letting you integrate virtually any tools you

    have into the VSTS Integrated Development Environment.

    Team Foundation Server is the "team" in Team System. Without it, the other components

    of VSTS are standalone components that run on a client machine. Once TFS is installed,

    the various client pieces work together as a cohesive unit.

  • 7/30/2019 Attendee Manual

    18/160

    16 Module 1: Introducing Application Lifecycle Management

    Supporting ALM with VSTS

    Software development processes are complex, involving many levels of interdependent

    activities. Processes are generally available in documentation form but are not enforced

    by tools. This makes it difficult for your development teams to learn and follow the

    processes consistently. Project managers might use a variety of different tools for project

    management, requirements management, bug tracking, or review management and they

    are often not integrated in any way.

    By using different tools you make it difficult to enforce a consistent implementation

    methodology across multiple projects and to generate consistent reports with commonunderstanding. This makes process analysis unreliable, which makes it difficult to

    identify process improvements over time.

    VSTS provides an integrated environment that supports most of the process activities

    involved in a software development project. It implements software development

    lifecycle methodologies by using process templates. If the supplied templates are not a

    good match for your teams development process you can create a new process template

    or modify an existing template. The following topics demonstrate VSTS and its support

    for processes and reporting.

  • 7/30/2019 Attendee Manual

    19/160

    Module 1: Introducing Application Lifecycle Management 17

    Traceability with VSTS

    The basic unit of measurement in project management is the work item. To accommodate

    this, VSTS/TFS provides project wide work item tracking and reporting; and work items

    are at the heart of VSTS -- it uses work items to track all planned, active and completed

    work for the team. The detailed history of the changes made to work items provides

    important data about the actions and decisions taken regarding the work.

    Different types of work items can be recorded and tracked in VSTS, including scenarios,

    Quality of Service (QoS) requirements, risks, bugs, and tasks. Visual Studio supports

    viewing and managing work items using a number of different applications, includingVisual Studio Team Explorer, Sharepoint Services, Excel and Microsoft Project.

  • 7/30/2019 Attendee Manual

    20/160

    18 Module 1: Introducing Application Lifecycle Management

    Process Enactment with VSTS

    VSTS/TFS provides two software development project wide process templates. These

    templates are based on the Microsoft Solutions Framework implementation of CMMI and

    Agile processes.

    However, VSTS supports more than MSF based processes. Using third party templates,

    or by building and customizing your own process templates, other processes can be

    utilized. The next topic provides more details about these resources.

    Regardless of the template you choose, the VSTS provided process templates are

    customizable so that your businesses specific processes can be accommodated.

  • 7/30/2019 Attendee Manual

    21/160

    Module 1: Introducing Application Lifecycle Management 19

    What About My Processes

    VSTS supports more than MSF based Agile or CMMI processes. Depending on the

    development management process used by your organization, you can add third party

    templates for other processes, such as SCRUM. Consistent with the VSTS provided

    templates, third-party templates can be customized to suit the needs of your specific

    organization.

    For more details see: http://msdn.com/process.

  • 7/30/2019 Attendee Manual

    22/160

    20 Module 1: Introducing Application Lifecycle Management

    Visibility with VSTS

    VSTS provides extensive and flexible report creation. The process template used in

    creating the team project determines which reports are available by default, but you can

    also add your own custom reports. The content and use of each report created by the

    process template is explained in the process guidance for that template.

    Team Foundation Server is built on SQL Server 2005 and uses SQL Server to store data

    about work items, quality attributes, testing, test results, and build results. Team

    Foundation Server then uses SQL Server Analysis Services to aggregate and analyze the

    data and drive reporting. The reports that are created by the process template or byindividual team members using Microsoft Excel or Visual Studio 2005 Report Designer

    are made available through SQL Server 2005 Reporting Services and the team report site.

    For more information see: http://msdn2.microsoft.com/en-

    us/library/ms194922(VS.80).aspx

    The following slides highlight some of the reports Team Foundation Server can produce

    to help managers measure productivity, development practices and quality. Each of these

    reports will be presented in greater detail later in the course.

  • 7/30/2019 Attendee Manual

    23/160

    Module 1: Introducing Application Lifecycle Management 21

    Reports About Productivity

    Team Foundation server can produce a standard productivity report that shows how much

    work is being completed over a certain period of time.

    It can also mine its warehouse of data and produce reports that show how much work has

    been added since the original work estimates were made. This latter report allows

    managers to get a handle on their teams work estimation skills and improve them for

    future iterations and projects.

  • 7/30/2019 Attendee Manual

    24/160

    22 Module 1: Introducing Application Lifecycle Management

    Reports About Development Practices

    Team Foundation Server can generate standard reports showing how effectively the

    development team is finding, fixing and closing bugs.

    Because code check-ins are tracked and related to bugs and work items, Team

    Foundation Server can determine how much of that development work is having to be

    redone.

  • 7/30/2019 Attendee Manual

    25/160

    Module 1: Introducing Application Lifecycle Management 23

    Reports About the Quality of the Software

    Team Foundation Server can generate reports showing how productive the Test team is.

    Using multiple metrics, Team Foundation Server can produce a report that helps to

    estimate the quality of the software.

  • 7/30/2019 Attendee Manual

    26/160

    24 Module 1: Introducing Application Lifecycle Management

    Demonstration: VSTS Process Templates

    This demonstration will show how VSTS uses process templates and associated process

    guidance to help apply process governance. The demonstration looks at what you get

    when you create a new team project based on a project template. Items highlighted by

    this demonstration include:

    Process guidance.

    Initial default work items.

    Initial project areas and iterations.

    Reports.

    Default Team portal site with SharePoint doc library and contents.

  • 7/30/2019 Attendee Manual

    27/160

    Module 1: Introducing Application Lifecycle Management 25

    Return on Investment Customer Evidence

    Microsoft provides case studies about the adoption of Visual Studio Team System so that

    managers have quantitative data regarding return on investment. Twenty-one studies are

    available detailing the experience of customers such as Dell, EDS. Additional resources

    detail Microsofts experience using VSTS/TFS to plan, manage, and develop Microsoft

    software. Return on Investment studies, Technical Case Studies and other customer

    adoption information is available at http://msdn2.microsoft.com/en-

    us/teamsystem/bb676820.aspx.

  • 7/30/2019 Attendee Manual

    28/160

    26 Module 1: Introducing Application Lifecycle Management

    Module Review

    ALM can deliver a number of key business benefits

    Increased ROI, increased accountability, improved compliance and increased

    responsiveness to business needs.

    ALM relies on integrated toolsets that support and unite lifecycle activities including:

    Requirements management

    Design/ modeling

    Development

    Testing

    Configuration Management

    VSTS supports ALM by establishing systems and processes. VSTS allows greater

    visibility of project activities, enables collaboration and communication, and helps to

    ensure software quality using advanced tooling.

  • 7/30/2019 Attendee Manual

    29/160

    Module 1: Introducing ALM

    Student Group Exercise: Moving Towards ALM

    In this exercise, consider to what extent your current organization (or anorganization you have experience of) has adopted ALM practices. The objective is foryou to consider where your organization is now in terms of processes, team rolesand development practices, and to think about areas of weakness and what youthink needs to change to move towards a more integrated ALM approach.

    Use the following questions to help guide your thinking and subsequent discussion.Feel free to consider and discuss additional questions.

    What would you say are your organization s key strengths and weaknesses

    with regard to s/w development and IT delivery?

    What are its main strengths and why?

    What are its main weaknesses and why?

    How effective would you say your current processes are?

    How well defined are your processes?

    How do you enforce process to ensure consistency?

    Do your teams and processes help foster a culture of continuous

    improvement?

    How well defined are your team roles and development practices?

    What tools do you use to manage the s/w development process?

    Who are your customers? Who are your other stakeholders?

    How would they variously answer these questions?

    How do you know theyd answer like that?

  • 7/30/2019 Attendee Manual

    30/160

    Module 2: Value-Up SoftwareDevelopment

    Table of Contents

    Module Overview 1Lesson 1: Moving from Work-Down to Value-Up

    Practices 2

    Lesson 2: Supporting Value-up Practices with VisualStudio Team System 15

    Module Review 22

  • 7/30/2019 Attendee Manual

    31/160

    Information in this document, including URL and other Internet Web site references, is subject to change

    without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-

    mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any

    real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or

    should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting

    the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval

    system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or

    otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

    The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft

    makes no representations and warranties, either expressed, implied, or statutory, regarding these

    manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or

    product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third

    party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of

    any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not

    responsible for webcasting or any other form of transmission received from any linked site. Microsoft is

    providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of

    Microsoft of the site or the products contained therein.

    Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights

    covering subject matter in this document. Except as expressly provided in any written license agreement from

    Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,

    copyrights, or other intellectual property.

    2007 Microsoft Corporation. All rights reserved.

    Microsoft are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or

    other countries.

    The names of actual companies and products mentioned herein may be the trademarks of their respective

    owners

  • 7/30/2019 Attendee Manual

    32/160

    Module 2: Value-Up Software Development 1

    Module Overview

    This module introduces the notion of value-up software development. It compares and

    contrasts core value-up principles and practices with conventional work-down

    approaches. The latter have proved over the years, largely ineffectual for team-based

    software development and are part of the reason why only 30% of software projects

    succeed.

    After completing this module, you will be able to:

    Explain the benefits of a value-up approach to software development.

    Describe how Visual Studio Team System (VSTS) supports and encourages value-up

    practices.

  • 7/30/2019 Attendee Manual

    33/160

    2 Module 2: Value-Up Software Development

    Lesson 1: Moving from Work-Down to Value-UpPractices

    This lesson compares and contrasts work-down and value-up practices and explains the

    main benefits of a value-up approach to software development.

    Objectives

    After completing this lesson, you will be able to:

    Explain the benefits of a value-up approach to software development.

  • 7/30/2019 Attendee Manual

    34/160

    Module 2: Value-Up Software Development 3

    The Driving Forces

    So why do things need to change in the way software development is approached? The

    answer to this question provides the motivation for value-up practices.

    There are three primary driving forces that need to be reconciled and this cannot happen

    without a paradigm shift in the way the software lifecycle is approached. The three

    driving forces are:

    Agility. Agile software development methods have become mainstream. Agile

    methods are seen as a lightweight alternative to traditional software engineering

    management practices, such as CMMI (Capability Maturity Model). Today, you can

    think of agile as a term that represents approaches and practices that work.

    Outsourcing. There are many pressures on teams related to financial resources.

    Primary management issues related to managing costs of software development are

    global competition and outsourcing. Outsourcing is a result of the excessive

    development costs associated with traditional development. Increased economic

    freedom, increased communications bandwidth, and a highly skilled labor force in

    emerging markets makes outsourced software development to lower-wage countries

    profitable.

    Compliance. Increased attention is required to address regulatory compliance.

    Management of publicly traded companies have come under increased scrutiny as

    more investors have purchased shares and fiscal accounting has become more and

    more complex. In the United States, federal law, specifically the Sarbanes-Oxley Act,

    holds business executives criminally liable for financial misrepresentation. Software

    and systems that process financial information are subject to a high level of scrutiny

    and audit.

  • 7/30/2019 Attendee Manual

    35/160

    4 Module 2: Value-Up Software Development

    Modern economics demand agility with accountability. To reconcile these different

    forces requires a shift in the way software is developed and new approaches to both the

    process and the tooling that supports the process. Traditional software development is

    failing to deliver sufficient business benefit and return on investment.

  • 7/30/2019 Attendee Manual

    36/160

    Module 2: Value-Up Software Development 5

    The Business Context for Software Development

    Software development is risky. This is the business reality.

    With most engineering disciplines, there are previous examples to follow. For example,

    when you build a road or a bridge you can study hundreds of other similar examples. By

    building a new one just like an existing one, you de-risk the whole process. Software

    engineering and building IT systems in general is quite different. If a system already

    exists like the one you want to build, economics dictate that you go out and buy it or

    license it commercially. In other words, you would never build it yourself.

    As a result of this, you need to view software development in a completely different

    business context. Virtually all of your software development projects are concerned with

    building products and solutions that dont already exist so the risk is immediately

    higher. This business reality is the key factor that makes software development so hard

    and risky and this makes attention to process essential.

  • 7/30/2019 Attendee Manual

    37/160

    6 Module 2: Value-Up Software Development

    A Value-Up Approach to Software Development

    Non-software engineering disciplines have established the foundation of modern top-

    down project management. In top-down, burn down or work down project management,

    the priority is to determine an engineering design early, carefully decompose the design

    into implementation tasks, schedule and resource the tasks according to their

    dependencies and resource availability, and monitor the project by checking off tasks as

    completed (or tracking percentages completed). This style of project management the

    work-down approach is easily envisioned as burning down a list of tasks.

    The work-down approach succeeds for engineering projects with low risk, low variance,and well-understood design. Many software development projects are customizations of

    commercial-off-the-shelf software, such as data base systems. Often, the development is

    a small part of the project relative to the business analysis, project management, and

    testing. Typically, these projects have lower variability than new development projects,

    so the wisdom of roads and bridges works better for them than for new development.

    Value up process management recognizes and accepts the inherent risks of software

    development. It views early planning and design as costly, especially if it constrains one

    of the benefits of software development system development and changes are relatively

    inexpensive throughout the development lifecycle. Consider the bridge building analogy,

    for example. If a bridge fails to line up by 1, a rework is probably the cost of the bridge.

    Fixing an analogous amount of error in a software project is far less expensive than the

    cost of the project.

    Value-up processes attempt to capture the unique benefits of engineering software by

    measuring value delivered rather than tasks completed. Value-up seeks to incrementally

    build a solution and measure the value of the software delivered to the customer at

    instrumented points during the project. Value-up processes consider this value to the

  • 7/30/2019 Attendee Manual

    38/160

    Module 2: Value-Up Software Development 7

    customer to be the purpose of the project, and seek to ensure that this value flows from

    the beginning of the project to the end. So value-up systems look continually look for

    ways to improve the flow of value throughout the software lifecycle.

  • 7/30/2019 Attendee Manual

    39/160

    8 Module 2: Value-Up Software Development

    Comparing Value-Up and Work-Down Practices

    There are several key differences between work-down and value-up practices. The main

    difference between the two is the primary measurement of progress. Work-down treats

    the project as a fixed set of tasks, each with some associated cost that need to be

    completed, and measures the expenditure against these tasks. Value up measures value

    delivered at each point in time and treats the inputs as variable flows rather than a fixed

    stock.

  • 7/30/2019 Attendee Manual

    40/160

    Module 2: Value-Up Software Development 9

    The Core Principles of Value-Up

    When software is developed using a value-up process, planning and design is done

    regularly throughout the life of the project. This is in contrast to traditional software

    project management that front loads the project with almost all design work. In a value-

    up project, the overhead of creating planning and design artifacts should be limited to just

    enough planning and design to understand risk and to manage the next small increment.

    Value-up methods, such as those that are managed using an Agile process, are generally

    characterized by the following six tenets:

    Increase return on investment by making continuous flow of value the focus.

    Deliver reliable results by engaging customers in frequent interactions and shared

    ownership.

    Expect uncertainty and manage for it through iterations, anticipation, and adaptation.

    Capture creativity and innovation by recognizing that individuals are the ultimate

    resource necessary to create value, and to create an environment where they can

    deliver that value.

    Boost performance through group accountability for results and shared responsibility

    for team effectiveness.

    Improve effectiveness and reliability through specific strategies, processes, and

    practices, based on the current situation.

  • 7/30/2019 Attendee Manual

    41/160

    10 Module 2: Value-Up Software Development

    The Importance of Project Flow

    In a value-up project, the deliverables that the customer values (working software,

    completed documentation) are the only work-products that count. The project plan is

    designed so the value of the software to the customer can be measured at regular intervals.

    In this way, the flow of work that creates value to the customer can be measured

    concretely. A value-up perspective to managing this flow of work and value treats interim

    measurements of value and quality skeptically. The end product of an iteration and how

    much the customer values that end product is the primary measure of project health.

    Therefore, do not measure planned tasks completed as the primary indicator of progress.The project plan should count units of value delivered.

  • 7/30/2019 Attendee Manual

    42/160

    Module 2: Value-Up Software Development 11

    Measuring Flow

    This graph is an example of a VSTS Remaining Work report that shows scenario

    completion on a daily basis and the flow of progress.

    In this example, planned work for an iteration is progressing well through development,

    but is increasingly getting stuck in testing. This accumulates as work-in-process. If a

    project manager was tracking development tasks completed, the reduction of active work

    items would be declining, and the expected completion date would be met. However, in

    this example, by looking at the work completed related to the resolution of scenarios it is

    possible to see that because of the bottleneck of work-in-process, testing will not finishwork on time.

  • 7/30/2019 Attendee Manual

    43/160

    12 Module 2: Value-Up Software Development

    Exercise: Work-Down vs. Value-Up

    During this exercise, students will be divided into groups and will be asked to identify

    and consider their current practices. To help frame the exercise, the instructor can start by

    writing the following set of headings onto a whiteboard. He can then ask students to

    identify and consider their own practices in regard to each of these areas.

    Planning and change process

    Primary measurement

    Definition of quality

    Acceptance of variance

    Intermediate work products

    Troubleshooting approach

    Approach to trust

    The idea is for students, having identifies some of their own practices for each of these

    categories, to decide whether or not they can be classified as work-down or value-up.

    Students will be given 20 minutes or so to consider this and will then report back to the

    wider class.

    When gathering answers from the different groups, the instructor will write the practices

    down on the whiteboard next to the adjacent core assumption. The group providing the

    list can explain what they consider to represent work down practices and what they

    consider embody value-up thinking. For those identified as work down practices, the

    wider class can be asked to consider what some of the inherent problems may be with

    these practices and how they could be adapted to benefit from value-up thinking.

  • 7/30/2019 Attendee Manual

    44/160

    Module 2: Value-Up Software Development 13

    The instructor can use the following table to help frame the exercise (and possibly use

    this as a recap at the end of the exercise to reinforce the key attitudinal differences

    between work-down and value-up paradigms.

    Core assumption Work-down attitude Value-up attitude

    Planning and change process Planning and design are the

    most important activities to get

    right. You need to do these

    initially, establish accountability

    to plan, and monitor against the

    plan, and carefully prevent

    change from creeping in.

    Change happens, embrace it.

    Planning and design will

    continue through the project.

    Therefore you should invest in

    just enough planning and

    design to understand risk and to

    manage the next small

    increment.

    Primary measurement Task completion. Because we

    know the steps to achieve the

    end goal, we can measure

    every intermediate deliverable

    and compute earned value

    running as the % of hours

    planned to be spent by now vs.the hours planned to be spent

    to completion.

    Only deliverables that the

    customer values (working

    software, completed

    documentation, etc.) count.

    You need to measure the flow

    of the work streams by

    managing queues that delivercustomer value and treat all

    interim measures skeptically.

    Definition of quality Conformance to specification.

    Thats why you need to get the

    specs right at the beginning.

    Value to the customer. This

    perception can (and probably

    will) change. The customer

    may not be able to articulate

    how to deliver the value until

    working software is initially

    delivered. Therefore, keep

    options open, optimize for

    continual delivery and dont

    specify too much too soon.

    Acceptance of variance Tasks can be identified and

    estimated In a deterministic

    way You dont need to pay

    attention to variance.

    Variance is part of all process

    flows, natural and man-made.

    To achieve predictability, you

    need to understand and reduce

    the variance.

    Intermediate work products Documents, models, and other

    intermediate artifacts are

    necessary to decompose the

    design and plan tasks, and they

    provide the necessary way to

    measure intermediate progress.

    Intermediate documentation

    should minimize the uncertainty

    and variation in order to

    improve flow. Beyond that, they

    are unnecessary.

    Troubleshooting approach The constraints of time,

    resource, functionality andquality determine what you can

    achieve. If you adjust one, you

    need to adjust the others.

    Control change carefully to

    make sure that there are no

    unmanaged changes to the

    plan.

    The constraints may or may not

    be related to time, resource,functionality, or quality. Rather,

    identify the primary bottleneck

    in the flow of value, work it until

    it is no longer the primary one,

    and then attack the next one.

    Keep reducing variance to

    ensure smoother flow.

    Approach to Trust People need to be monitored

    and measured to standards.

    Pride of workmanship and

    teamwork are more effective

  • 7/30/2019 Attendee Manual

    45/160

    14 Module 2: Value-Up Software Development

    Core assumption Work-down attitude Value-up attitude

    Incentives should be used by

    management to reward

    individuals for their

    performance relative to plan.

    than individual incentives.

    Trustworthy transparency,

    where the whole team can see

    all the teams performance

    data, works better than

    management directive.

  • 7/30/2019 Attendee Manual

    46/160

    Module 2: Value-Up Software Development 15

    Lesson 2: Supporting Value-up Practices with VisualStudio Team System

    This lesson compares and contrasts work-down and value-up practices and explains the

    main benefits of a value-up approach to software development.

    Objectives

    After completing this lesson, you will be able to:

    Describe how Visual Studio Team System supports and encourages value-up

    processes and practices.

  • 7/30/2019 Attendee Manual

    47/160

    16 Module 2: Value-Up Software Development

    Why Value-Up Requires Tooling

    Value-up practices require tool support. Traditional methods use manual process

    enactment or use disparate tools that do not integrate well and do not provide a unified

    view. This make tracking project progress and obtaining a current snapshot of project

    health very difficult. Collecting data and tracking progress is traditionally expensive,

    requiring lots of documentation, training and management. Also, the resulting process

    artifacts and the associated effort do not deliver customer value.

    With traditional approaches, there is often disparity among the priorities and expectations

    of different team members. Most approaches to software engineering have lots of placesto track the work spreadsheets, project plans, requirements databases, bug data bases,

    test management systems, triage meeting notes, and more. When information is scattered

    this way, it is difficult to get a whole picture of the project. You need to look in too many

    sources and it is hard to balance all the information into one schedule. Also, when there

    are so many sources, the information you find is often obsolete.

  • 7/30/2019 Attendee Manual

    48/160

    Module 2: Value-Up Software Development 17

    Benefits of a Common Product Backlog

    By providing a common product backlog you -fragment data, and enable a unified view

    of data to be acquired by using tools most appropriate for the role, such as Microsoft

    Excel and Microsoft Project for project managers, Team Explorer for developers, and so

    on. A common product backlog also benefits from the ability to automate data collection

    as the various elements of the process proceed. For example, data can be captured each

    time a developer checks in code to resolve work items. Build and test results can be used

    to help measure quality.

    VSTS has a central work item database containing the product backlog used to track allplanned, active and completed work together with a history of actions and decisions made

    for that work.

    For example, VSTS has a central work item database containing the product backlog used

    to track all planned, active and completed work together with a history of actions and

    decisions made for that work.

  • 7/30/2019 Attendee Manual

    49/160

    18 Module 2: Value-Up Software Development

    Benefits of Instrumenting Daily Activities

    Collecting accurate data is traditionally an error prone and very time consuming task. By

    driving the data capture from daily activities (such as code check-in, builds, test runs) this

    becomes an automated process increasing accuracy and saving countless hours of

    additional overhead work related to creating reports.

    Vast majority of the data that a team needs is directly correlated to other actions that are

    already managed by software. Developers check in code, builds parse that code, testers

    write and run tests, and all these activities are tracked somewhere Project, Excel, bug

    database or timesheets. Often collecting data becomes a major activity. Disciplinedattention to bookkeeping is rarely sustained in practice, especially during periods of

    intense activity.

    Instrumenting a daily activity allows the collection and processing of data with minimal

    overhead. For example, each time a developer checks updated code into version control,

    work items are updated to reflect the tasks and scenarios updated by this code. The

    relationships are captured in a changeset, and when the next build runs, it identifies the

    change sets included and updates work items again with the build number. When tests

    execute, the tests use the same build umber. Test results, code changes, and work items

    are all correlated automatically.

    This automatic data collection populates a data warehouse with metrics. This allows for

    the creation of reports that reveal trends and evaluate the flow of quality from many

    dimensions on a regular, incremental basis.

  • 7/30/2019 Attendee Manual

    50/160

    Module 2: Value-Up Software Development 19

    Assessing Quality

    Assessing software quality is more than looking at bug count metrics. Such a metric

    covers only a narrow slice of testing progress, let alone software quality. Simple charts of

    single dimension metrics can carry a lot of useful information and can lead you to a lot of

    useful questions. However, such charts can provide support for conclusions that are in

    fact invalid.

    In this example, you might conclude from a bug count report that the Data Access Layer

    (first bar) is in great shape because it has a high test pass rate and a low bug count so

    youd look for problems elsewhere.

  • 7/30/2019 Attendee Manual

    51/160

    20 Module 2: Value-Up Software Development

    Assessing Quality (Continued)

    To assess software quality, it is necessary to report multidimensional patterns, rather than

    single measures or a few measures along the same line. Being able to see the interactions

    between different metrics allows you to consider more fully the quality of the software.

    This example illustrates the danger of relying on too few metrics. Consider what happens

    when you overlay code churn (the number of lines added, modified or deleted), and code

    coverage from testing on the same axes as the bug count.

    The ability to analyze data in different ways and to present different views is a direct

    benefit of the VSTS multi-dimensional metrics warehouse. You can achieve the high

    visibility levels necessary for the strictest compliance reporting, while working in an

    agile manner. This level of reporting, process management and visibility is the same for

    local, remote, and even outsourced projects.

  • 7/30/2019 Attendee Manual

    52/160

    Module 2: Value-Up Software Development 21

    Benefits of Iterative Development

    An iteration is a fixed set of time used to schedule a set of tasks. Iterations are used as an

    interval in which to schedule intended scenarios, measure the flow of value, asses actual

    process, examine bottlenecks, and make adjustments. The benefits of iterations include:

    Improved risk management.

    Ability to review priorities frequently.

    Improved focus on specific tasks.

    Better motivation from seeing early and frequent releases.

    Improved estimation.

    Improved stakeholder confidence and involvement (seeing results early).

    Continuous learning. The ability to learn from previous iterations and adjust and

    improve as necessary.

    Iterations also help with the instrumenting of development activities. This enables the

    measurement of flow customer value delivered in the current feature set, assessment of

    processes, elimination of bottlenecks and making adjustments.

  • 7/30/2019 Attendee Manual

    53/160

    22 Module 2: Value-Up Software Development

    Module Review

    Traditional engineering project management fails to take advantage of the unique benefits

    software development can accommodate. A paradigm shift from work-down project

    management to value-up project management can provide added value unique to software

    engineering:

    Benefits of a value-up approach to software development.

    Key differences between value-up and work-down practices:

    Work-down sees completing a list of tasks as a measurement of progress. Value-up measures progress by having customer regularly evaluate the value of

    delivered features.

    VSTS supports and encourages value-up practices:

    Single work-item database.

    Scenario based development.

    Flexible processes.

  • 7/30/2019 Attendee Manual

    54/160

    MODULE 2: VALUE-UP SOFTWARE DEVELOPMENT

    STUDENTGROUPEXERCISE: WORKDOWN VS. VALUE-UP

    In this exercise, consider your current software development practices in each of thecategories listed below. Perform this exercise as individuals to start with and thendiscuss your answers and findings with your group. Contrast your practices withother definitions and practices that others in your group have used. Considerwhether youd categorize specific practices as work down or value up. After 20minutes individual and group work, you will be asked by your instructor to discussyour practices and findings with the wider class.

    x Planning and change processo When do you perform your planning?o Who do you hold accountable for the plan?o What is your attitude to change?o How do you prevent scope creep?

    x Primary measuremento How do you measure progress?o What do you consider are your main deliverables that you use to trackprogress?

    x Definition of qualityo How do you define quality?o How would your customers and stakeholders define quality?o How to you measure quality?o How do you ensure quality?

    x Acceptance of varianceo Do you accept that variance is a natural occurrence within all projects?o How to you recognize and measure variance?o What do you do about it?

    x Intermediate work productso What kind of intermediate work products do you use?o What do you use them for?o Do you use them to measure progress and how effective is this approach?

    x Troubleshooting approacho How do you ensure a smooth flow of progress through your project?o What are some symptoms of an out of control project?

    x How do you balance the constraints of time, resource, functionality and qualityApproach to trusto What kind of performance incentives do you use?o Are they individual or team based and why?

  • 7/30/2019 Attendee Manual

    55/160

    Module 3: The Business AnalystsPerspective

    Table of Contents

    Module Overview 1Lesson 1: Gathering Functional Requirements 2

    Lesson 2: Using Personas and Scenarios 8

    Module Review 15

  • 7/30/2019 Attendee Manual

    56/160

  • 7/30/2019 Attendee Manual

    57/160

    Module 3: The Business Analysts Perspective 1

    Module Overview

    This module focuses on gathering the requirements your system must deliver. It examines

    the process of gathering requirements and introduces techniques to help capture and

    manage requirements throughout the software development lifecycle. This module also

    explains some of the challenges associated with deciding precisely what to build and it

    presents techniques for capturing and evolving requirements to ensure that requirements

    stay current throughout the software development lifecycle.

    Objectives

    After completing this module, you will be able to:

    Describe techniques for capturing functional requirements.

    Explain the benefits of using scenarios and personas.

    Identify key quality of service requirements that should be captured and tracked.

  • 7/30/2019 Attendee Manual

    58/160

    2 Module 3: The Business Analysts Perspective

    Lesson 1: Gathering Functional Requirements

    This lesson describes some of the techniques for gathering functional requirements.

    Objectives

    After completing this lesson, you will be able to:

    Describe techniques for capturing functional requirements.

  • 7/30/2019 Attendee Manual

    59/160

    Module 3: The Business Analysts Perspective 3

    Starting with a Vision Statement

    Every project should have a vision statement that each stakeholder can understand. The

    vision statement is helpful to clarify the core values of the project. It should state why a

    customer or end user will want the solution the project team is building. The shorter the

    vision statement is, the better it is. A sign of a successful vision statement is that

    everyone on the project team can relate to it and connect their daily work to it.

    Vision statements will be different depending on the end goal of the project. One way to

    think about these differences is to consider whether your project is a Strategic project or

    an Adaptive project.

    Strategic project vs. Adaptive projects

    Strategic projects involve significant investments based on a plan to improve appreciably over

    their predecessors.

    Adaptive projects are those that make incremental changes to existing systems.

  • 7/30/2019 Attendee Manual

    60/160

    4 Module 3: The Business Analysts Perspective

    Knowing When to Capture Requirements

    Requirements are a quantifiable way to communicate and measure the work necessary to

    complete a project. However, it is often possible for a project to stall because there are

    an unrealistic amount of requirements or the requirements themselves are not achievable.

    When a project stalls due to continual requirements analysis and writing this is called

    analysis paralysis.

    Value-up processes attempt to avoid analysis paralysis by considering two factors: first,

    requirements have to be written so an audience can use them; and second, for

    requirements to be useful they are considered to have a limited lifetime. Goodrequirements accept:

    The business environment or problem domain changes.

    The knowledge that led to the initial requirements becomes stale as lessons are

    learned during later iterations.

    There is a limit to the number of requirements that a team can realistically deliver.

    When a team has fewer and more granular requirements, the team can focus more

    attention on quality design and implementation.

  • 7/30/2019 Attendee Manual

    61/160

  • 7/30/2019 Attendee Manual

    62/160

    6 Module 3: The Business Analysts Perspective

    Gathering and Tracking QoS Requirements

    Quality of Service requirements can define global attributes of a system or specific

    constraints on particular scenarios. For a project to be complete, you need to determine

    the Quality of Service requirements that apply to your system.

    As with scenarios, QoS requirements need to be explicitly understandable to the

    stakeholder audiences, defined early; and when planned for implementation during an

    iteration, the requirements must be testable.

    Define your Quality of Service (QoS) requirements for each of the scenarios to be

    developed during the iteration. You repeat this step for each iteration cycle. This helps

    define the acceptance criteria for the scenario.

    Sources for QoS requirements come from project goals and requirements and

    specification documentation. A Quality of Service requirement can start with a general

    statement about performance, for example. For development during an iteration you will

    need to add detail, including setting specific targets on specific transactions at specific

    loads. If the requirement cannot be tested, then it is impossible to determine when the

    requirement is complete.

    VSTS tracks Quality of Service requirements as work items. As the requirement is

    identified, it begins in the Proposed state. When a requirement is accepted for the currentiteration, it moves to the Active state and is analyzed to create tasks to implement it.

    When the tasks are complete and system tests are passed showing that the requirement is

    successfully implemented, it moves to the Resolved state. Finally, when the requirement

    is validated, it is moved to the Closed state.

  • 7/30/2019 Attendee Manual

    63/160

    Module 3: The Business Analysts Perspective 7

    Discussion: Gathering Functional Requirements

    Discuss with students how they gather functional requirements. What works? What does

    not work? Why not?

  • 7/30/2019 Attendee Manual

    64/160

    8 Module 3: The Business Analysts Perspective

    Lesson 2: Using Personas and Scenarios

    This lesson describes why personas and scenarios are effective tools for understanding

    and communicating customer value.

    Objectives

    After completing this lesson, you will be able to:

    Explain the benefits of using scenarios and personas.

  • 7/30/2019 Attendee Manual

    65/160

    Module 3: The Business Analysts Perspective 9

    Identifying and Creating Personas

    In value up software engineering quality is measured as value to the customer. In some

    project teams, the customer can participate, in person or via a representative, and provide

    the required feedback. In other circumstances, the customer is an abstraction. One way to

    make the abstraction of the customer more concrete is to use personas and scenarios.

    Personas and scenarios are tools that can be used to understand and communicate the

    value of software to a customer.

    Personas are the personification (person-ification) of user groups represented as a specific

    individual. Personas are intended to be very useful implementation guides for the peopleimplementing a product.

    Good personas are:

    Memorable.

    Three-dimensional.

    Sufficiently well described to be decisive when necessary.

    Personas describe categories of users in terms of:

    Personality.

    Work environment.

    Usage environment.

    Education.

    Computer experience.

    Any other characteristics that make the imagined person come to life.

  • 7/30/2019 Attendee Manual

    66/160

  • 7/30/2019 Attendee Manual

    67/160

    Module 3: The Business Analysts Perspective 11

    Techniques for Capturing Scenarios

    In the Microsoft Solutions Framework, functional requirements are written as scenarios.

    Scenarios capture the steps necessary for a user to achieve a specific goal. A scenario

    includes:

    A persona.

    A goal.

    The steps necessary for the persona to accomplish a goal.

    A scenario details how a persona reasons through the specific steps taken as the personaattempts to reach the goal. The goal is stated in the users language. For example, on a

    shopping Web service, the end goal of the user may be to place an order.

    Throughout iterations, specific sequences in the scenario may evolve, however the goal

    should not.

    Scenarios capture tangible customer value. Questions in the form of What if you could

    [accomplish goal] like [this scenario]? help to establish prototypes and working

    functionality. Researching the answers to such questions can involve focus groups and

    contextual interviews with users observing and questioning users as they function in

    their work environment.Write specific scenarios early and start with the scenario goal. Break down the goal into a

    list of steps with a level of granularity that is understandable to the persona and in the

    personas language. Focus on defining the problem space, and not the solution.

    A good scenario should have one focus -- the goal. It should not capture alternate goals,

    paths, and exceptions. If these situations arise, note them and save them as requirements

    for another scenario.

  • 7/30/2019 Attendee Manual

    68/160

    12 Module 3: The Business Analysts Perspective

    Once a scenarios sequence is complete, document how the solution is expected to

    respond. So for each persona-does-step there is a solution-shows-result. Those steps

    that would elicit a wow from a persona are high value scenarios.

    Other solution frameworks use different concepts to capture the vision of users and their

    requirements. The terms Actor and Use Case are used as part of the Rational Unified

    Process. eXtreme Programing uses the concept of user stories.

  • 7/30/2019 Attendee Manual

    69/160

    Module 3: The Business Analysts Perspective 13

    Validating Scenarios

    Breaking down a project into iterations allows the customer to have several opportunities

    to review the solution as it evolves. One technique to validate scenarios for each iteration

    is to answer the following questions:

    Do I have enough scenarios? Is it possible to map scenarios from end-to-end so that

    they present a complete solution story?

    Are the scenarios complete enough so that a customer can provide specific and

    meaningful feedback? Are all the steps the customer needs complete? Are all steps

    relevant?

    Can the test team define positive and negative tests from your scenarios? Can the test

    team identify how to test the sequence of steps? Can the test team determine what

    data is necessary? Can the test team determine what variations need to be explored?

    Can architects and developers identify component interaction? Can architects and

    developers identify interfaces? Can architects and developers identify the

    dependencies between services? Can architects and developers identify the features

    necessary to realize the scenarios?

  • 7/30/2019 Attendee Manual

    70/160

    14 Module 3: The Business Analysts Perspective

    Evolving Scenarios Through the Lifecycle

    In early iterations, the high value wow scenarios are developed. As the iterations

    progress, add scenarios to cover features that make the software complete and satisfying,

    as well as eliminating dissatisfies. This should lead to scenarios that explore alternate

    paths through the solution.

    If during an iteration you discover that scenarios dont capture the intended functionality

    sufficiently for stakeholders, add more detail or extend scenarios.

    Dissatisfiers can be difficult to turn into scenarios. This is because dissatisfiers are

    usually assumed to be absent. Statements such as you didnt tell me x, the customer

    didnt specify x, and x didnt show up in our research are all symptoms of failing to

    consider the requirements necessary to eliminate dissatisfiers.

  • 7/30/2019 Attendee Manual

    71/160

    Module 3: The Business Analysts Perspective 15

    Module Review

    Designing a software system is about considering the solution to be delivered and

    envisioning the details necessary to deliver that solution. Writing a vision statement helps

    to capture the problem domain of the software. Personas and scenarios help define the

    features necessary to deliver a complete system to the customer. Quality of Service

    requirements, and other requirements (Usability, security, etc.) can be captured by

    considering specific user needs and questioning whether the requirements as written are

    complete.

    After completing this module, you are able to:

    Describe techniques for capturing functional requirements.

    Explain the benefits of using scenarios and personas.

    Identify key quality of service requirements that should be captured and tracked.

  • 7/30/2019 Attendee Manual

    72/160

    Mo u e 3: T e Bus ness Ana yst s Perspect ve

    Student Group Exercise: Gathering Requirements

    In this group exercise, consider and discuss how you currently capture and manageboth functional and non-functional (QoS) requirements, considering the followingquestions as you do so:

    What s the purpose of requirements?

    What makes good requirements?

    What is a functional requirement?

    What is a non-functional requirement?

    Where do you get your functional and non-functional requirements from?

    What are the most effective and lest effective examples you can think of?

    When are requirements knowable?

    How do you capture requirements?

    How and where do you record them?

    Do you expect requirements to change and if so how often?

    How do you handle changes to requirements?

    How long (typically) do you spend gathering requirements?

    At what stage or stages of the lifecycle do you capture them?

    How do you decide when you have enough requirements?

    How do you validate your requirements?

    How do you manage your requirements as your project progresses?

    How do you ensure that your requirements are implemented successfully?

  • 7/30/2019 Attendee Manual

    73/160

    Module 4: The Project ManagersPerspective

    Table of Contents

    Module Overview 1Lesson 1: Traditional Software Project Management 2

    Lesson 2: Value-up Project Management Practices 7

    Lesson 3: Monitoring Project Health 16

    Lesson 4: Recognizing the Warning Signs 25

    Module Review 31

  • 7/30/2019 Attendee Manual

    74/160

  • 7/30/2019 Attendee Manual

    75/160

    Module 4: The Project Managers Perspective 1

    Module Overview

    This module highlights common problems associated with traditional software project

    management theory and presents the theory of value-up project management. The

    module goes on to describe techniques project managers can use to evaluate whether their

    projects are out of control.

    Objectives

    After completing this module, you will be able to: Explain the problems inherent with traditional software project management

    disciplines.

    Describe the benefits of value-up project management practices.

    Identify effective metrics that can be used to monitor project health and answer

    common project management questions.

    Recognize warning signs of out of control projects.

  • 7/30/2019 Attendee Manual

    76/160

    2 Module 4: The Project Managers Perspective

    Lesson 1: Traditional Software Project Management

    This lesson describes the characteristics and inherent problems associated with traditional

    software project management approaches and disciplines.

    Objectives

    After completing this lesson, you will be able to:

    Explain the problems inherent with traditional software project management.

  • 7/30/2019 Attendee Manual

    77/160

  • 7/30/2019 Attendee Manual

    78/160

  • 7/30/2019 Attendee Manual

    79/160

    Module 4: The Project Managers Perspective 5

    Whats Wrong with the Iron Triangle?

    Traditional project management is based on the Iron Triangle (or tetrahedron if you

    include quality as a 4th dimension) view of resource allocation.

    The iron triangle view of project management is the concept that there are only three

    variables a project manager can manipulate. These are time, resources, and functionality.

    Some projects separate quality from functionality and consider quality as a fourth

    variable to be managed. In such a case, the iron triangle of project resources has an

    additional dimension that captures the quality of a project to form a tetrahedron.

    According to this view, a project manager has an initial stock of resources and time. Any

    change to functionality or quality requires a corresponding increase in time or resources.

    You cannot stretch one face without stretching the other because all of the faces form an

    equal area.

    In such a model, resource allocation is a zero-sum game. Resource productivity is

    uniform, there is little variance in the effectiveness of task completion, and no spare

    capacity exists throughout the system.

    Agile methods have tended to disprove the iron-triangle model. For example, if a team

    improves the flow of value through the system using tools, it is possible to shorten the

    amount of time required to produce work items.

  • 7/30/2019 Attendee Manual

    80/160

    6 Module 4: The Project Managers Perspective

    Discussion: Project Management Practices

    In this group exercise, students are divided into groups and asked to discuss their own

    project management experiences. What works? What doesnt and why not? Students will

    be posed the following questions to help guide them.

    What are the key questions you want your project managers to be able to answer?

    What metrics do you use for assessing whether or not your projects are on track?

    How and when do you capture these metrics?

    How do you recognize an out of control project what are your key indicators?

    How do you control scope creep?

    What are your key quality indicators?

    How do you measure the quality of the software you develop?

    How do your project managers communicate with the wider team?

    How effective is your team communication and how could it be improved?

    How do you measure the productivity of your development team?

    What incentives do you give your developers?

    While considering these questions, students will also be asked to think about which of

    their practices they would consider embody value-up thinking and which do not. Groups

    will present back to the class.

  • 7/30/2019 Attendee Manual

    81/160

  • 7/30/2019 Attendee Manual

    82/160

  • 7/30/2019 Attendee Manual

    83/160

    Module 4: The Project Managers Perspective 9

    What Is Variation?

    The concept of natural variation is central to value-up project management. Variation is

    used to distinguish in and out of control projects. Monitoring variation has proved very

    difficult to do in the past.

    Value-up software development expects variation from expected norms. Variation in a

    deliverable is itself normal and an aspect of all process flows. The key point to

    understand about variation in value-up software development is that its appearance is

    expected and thus predictable within certain bounds. To achieve predictability, you need

    to understand the causes of variance and iteratively work to reduce these causes.

    Variation can be classified into two types

    Common-cause variation.

    Special-cause variation.

    Common-cause variation is variation that occurs as a part of the process. The presence of

    variation is predictable from day-to-day. An illustration is the fact that similar tasks may

    take longer or shorter amounts of time to accomplish: a system may not integrate given

    the stability of the system on a given day, or a scenario might delight a customer as

    expected while another scenario might not. Accepting and planning for such natural

    variation is common in project management. A full day may be scheduled for an

    integration work item, rather than assuming the system will integrate once all the

    development work is complete. Value-up processes accommodate scenarios that have to

    be reworked because the customer is dissatisfied by allowing for a following iteration to

    improve the feature. Schedules may include pad to deal with unforeseen variation.

    Special-cause variation is variation that occurs due to something outside of the process.

  • 7/30/2019 Attendee Manual

    84/160

    10 Module 4: The Project Managers Perspective

    Failing to determine and monitor variation accurately causes mistakes that are

    detrimental to the project. Mistake #1 is to react to an outcome as if it came from a

    special cause, rather than identifying the variation as a result of a common cause. This

    can cause a project manager to miss a systemic problem and dismiss it as a unique

    circumstance. Mistake #2 is to treat an outcome as if it came from common causes of

    variation, when it actually came from a special cause. This can cause a drain on project-

    wide resources or unnecessary changes to the scope of a project as entire processes are

    changed.

    Tracking and determining the causes of variation have generally been ignored in

    traditional software project management simply because broad system and project data

    has been very difficult to collect. Even Agile methods have suffered from this difficulty.

    For example, the Yesterdays Weather pattern, common to XP and SCRUM, requires a

    team not to sign-up for more work in an iteration than was assigned in the previous

    iteration. This contradicts the value of iterations. Iterative development allows a team to

    continuously learn from its experiences, correct problems with the project through a

    manageable process, and to improve the projects processes.

  • 7/30/2019 Attendee Manual

    85/160

    Module 4: The Project Managers Perspective 11

    Exercise: Problems with Prescriptive Metrics

    In this group exercise, students will be presented a number of descriptive metrics that

    could (but shouldnt) be used to measure productivity. These will include the following:

    Measuring programmer productivity based on lines of code written per day.

    Rewarding programmers based on number of bugs fixed.

    Rewarding the team for creating tests and code to achieve 90% code coverage.

    Measuring testers based on number of bugs found.

    Students will be asked to consider why using such metrics is counterproductive and leads

    to dysfunction.

  • 7/30/2019 Attendee Manual

    86/160

  • 7/30/2019 Attendee Manual

    87/160

    Module 4: The Project Managers Perspective 13

    it producing code that is self-documenting and written well enough so bugs are easily

    discovered?

    Multi-dimensional metrics are more complex metrics that require gathering data from

    multiple sources at the same time. Prior to VSTS / TFS, the tools necessary to provide

    multi-dimensional measurements have been lacking or deficient.

  • 7/30/2019 Attendee Manual

    88/160

    14 Module 4: The Project Managers Perspective

    Preventing the Distortion

    Traditional project management tools produce reports, usually from disparate sources,

    about time spent on tasks, bug counts, task completion and resource utilization. Each

    measurement is usually reported separately. It was the Project Managers job to gather

    these reports and find a way to use these correlate the reports and deduce the state of the

    project. In general producing and correlating these reports are an inefficient use of a

    Project Managers time.

    Value-up project management reads such reports skeptically and sees them only as

    approximations of the projects objective -- customer satisfaction with the solution. Theteams real goal is to deliver a product of value to the customer. From the perspective of

    traditional project management, measuring the development of customer value is difficult,

    especially when the entire project is developed over a long period of time. So available

    single-dimensional metrics such as task completion, test pass rate or bug count are used

    as easily quantifiable proxies.

    Such individual measurements of a software project may be relevant during an iteration.

    However, in a value-up paradigm, an iteration is designed to be short enough so that

    these easily quantifiable proxies do not have to be relied upon as the measurement of

    value delivered. An iteration is complete when the customer receives and evaluates the

    delivered feature set. With short iterations that produce discrete features it is possible to

    assess the value delivered, and thus the projects health, as frequently as the end of each

    iteration. Until the customer can assess a working feature, interim measurements of

    quality related to that feature, such as task completion, are hypothetical.

    Visual Studio Team Server / Team Foundation Server is designed to facilitate measuring

    the health of a project by having a common project backlog maintained in a single work

    item database. The work items that make up an iteration are organized into a changeset

  • 7/30/2019 Attendee Manual

    89/160

    Module 4: The Project Managers Perspective 15

    keyed to a versions builds and tests. Such instrumentation allows many dimensions of

    project data to be gathered, stored and correlated automatically in a metrics warehouse.

    This facilitates frequent assessment of the project during an iteration and allows a Project

    Manager to compare data from one iteration to another.

  • 7/30/2019 Attendee Manual

    90/160

    16 Module 4: The Project Managers Perspective

    Lesson 3: Monitoring Project Health

    This lesson explains key project health indicators. It will demonstrate how you can

    monitor project health using multi-dimensional metrics. It will also show you how

    Visual Studio Team System/Team Foundation Server can be used to answer common

    project management questions.

    Objectives

    After completing this lesson, you will be able to:

    Identify effective metrics that can be used to monitor project health and answer

    common project management questions.

  • 7/30/2019 Attendee Manual

    91/160

  • 7/30/2019 Attendee Manual