Team Foundation Server - Tracking & Reporting
•
44 j'aime•35,308 vues
Comprehensive presentation detailing reporting and tracking capabilities of Team Foundation Server. Focuses on Excel workbooks and Reporting Services, but touches on other technologies as well.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Team Foundation Server - Tracking & Reporting
Similaire à Team Foundation Server - Tracking & Reporting (20)
Plus de Steve Lange
Plus de Steve Lange (20)
Dernier
Dernier (20)
Team Foundation Server - Tracking & Reporting
- 1. Team Foundation Server Planning, Tracking, & Reporting Steve Lange Sr. Developer Technology Specialist | Microsoft - Denver, CO stevenl@microsoft.com | slange.me
- 2. Agenda Introductions Team Foundation Server Project Planning & Tracking Using Project or Project Server Process Templates Workbooks TFS Reporting Experience Dashboards Excel Reporting SQL Reporting Services Reporting
- 4. TFS Planning, Tracking & Reporting Project Planning & tracking
- 5. Project Planning & Tracking Success Characteristics Process Templates Project Scheduling Project or Project Server Planning & Tracking Workbooks
- 6. Project Planning & Tracking Success Characteristics Customer need drives the project High-levelplan for delivery Development over several iterations Refines high-level plan over time Effective tools for adapting to changes
- 7. Project Planning & Tracking – Process Templates MSF = Microsoft Solutions Framework CMMI = Capability Maturity Model Integration
- 8. The process template defines artifacts, planning, and reporting capabilities
- 9. Project Scheduling using Project Directly Integrates with TFS Work Items Use scheduling & planning tools in MS Project Determine over-allocation Manage hours, dependencies, constraints, & lead/lag time Create charts showing schedule & resource usage
- 10. Project Management using Project Server Enable data to flow from TFS work items to tasks in Project Server enterprise project plans in Project Server. Define requirements Approve status updates Review & set baselines Preview updates & impact to critical paths
- 11. TFS Planning & Tracking Workbooks
- 12. Workbooks Build your product backlog Plan work Track issues Quickly create work items Set rank, priority, state, & assignments of multiple work items at the same time
- 13. Workbooks Product Planning Workbook Iteration Backlog Workbook Issues Workbook Triage Workbook
- 14. Workbooks – Product Planning Workbook Balance workload across iterations Worksheets Product Backlog Iteration Planning Interruptions
- 15. Workbooks – Iteration Backlog Workbook Plan & track progress of work for each iteration/sprint Calculate team capacity & burndownbased on estimated & remaining effort Worksheets Iteration Backlog Settings Interruptions Capacity Burndown
- 16. Workbooks – Issues Workbook Review & rank problems that might block team progress References Issues team query Finds all issues in project
- 17. Workbooks – Triage Workbook Review, rank & assign bugs to be worked on for iteration/spring Triage driven by product owner or scrum master with input from team.
- 19. TFS Reporting Experience About TFS Reporting Excel Reporting Included Excel reports Excel report generation Dashboards Reporting Services Reports
- 20. About Team Foundation Server Reporting Two reporting databases Warehouse relational database Good for current state of projects, artifacts, etc. Analysis Services Cube Good for trending, historical reporting, etc.
- 21. Excel Reports TFS Reporting Experience
- 22. Excel Reporting Included Excel Reports Project Management Bug Backlog Management Build Management Test Management Excel Report Generation
- 23. Excel Reports - Project Management Burndown Task Progress User Story Progress Issue Trends
- 24. Excel Reports – Bug Backlog Management Bug Progress Bug Trends Bugs by Priority Bugs by Assignment Bug Reactivations
- 25. Excel Reports – Build Management Code Coverage Code Churn Build Status
- 26. Excel Reports – Test Management Test Plan Progress Test Case Readiness User Story Test Status Test Activity Failure Analysis
- 27. Excel Report Generation Create directly from Work Item query Generates Table of contents PivotTable & PivotChart reports Report options Current reports Trend reports
- 28. Excel Report Generation Current Work Item Count Work item Type Assigned To State Trend Work Item Count Work Item Type Assigned To State
- 29. Dashboards TFS Planning, Tracking, & Reporting
- 30. Dashboards Quickly find important information about team projects Show project data, support investigation, & help teams perform common tasks more quickly. Leverage SharePoint products through Web Parts Excel Web Access Team Web Access
- 31. My Dashboard What is the next set of Tasks, Bugs, or Test Cases that I should act on? What is the status of the team's most recent builds?
- 32. Project Dashboard Is the team likely to finish the iteration on time? Will the team complete the planned work based on the current burn rate? What were the most recent check-ins? Burn Rate Work Item Breakdown Burndown
- 33. Progress Dashboard Is the team likely to finish the iteration on time? Will the team complete the planned work based on the current burndown? How much progress has the team made on implementing user stories in the past four weeks? How quickly is the team identifying and closing Issues? What were the most recent check-ins?
- 34. Quality Dashboard Is the test effort on track? Is the team testing the appropriate functionality? Are the team's bug fixes of high quality? Are tests stale? Does the team have sufficient tests? Are any bottlenecks occurring?
- 35. Test Dashboard Is the authoring of Test Cases on track? Has the team defined Test Cases for all User Stories? What are the proportions of Test Cases that are passing, failing, and blocked? Do test failure metrics indicate a problem that requires further investigation? What is the status of last night's build? What are the most recent check-ins?
- 36. Bugs Dashboard How quickly is the team resolving and closing bugs? Is the team fixing bugs quickly enough to finish on time? How many bugs is the team reporting, resolving, and closing per day? Is the team resolving priority 1 bugs before priority 2 and 3 bugs? Does any team member have a backlog of priority 1 bugs that warrant redistribution?
- 37. Build Dashboard How volatile is the code base? How much of the code is the team testing? How high is the quality of the builds? Is the quality increasing, decreasing, or staying constant? Which builds succeeded? Which builds have a significant number of changes to the code?
- 38. SQL Reporting Services Reports TFS Reporting Experience
- 39. Reports Available Based on Process Template
- 40. Bug Status Report Is the team fixing bugs quickly enough to finish on time? Is the team fixing high priority bugs first? What is the distribution of bugs by priority and severity? How many bugs are assigned to each team member?
- 41. Bug Trends Report How many bugs is the team reporting, resolving, and closing per day? What is the overall trend at which the team is processing bugs? Are bug activation and resolution rates declining toward the end of the iteration as expected?
- 42. Reactivations Report How many bugs are being reactivated? How many user stories are being reactivated? Is the team resolving and closing reactivated bugs at an acceptable rate?
- 43. Build Quality Indicators Report What is the quality of the software? How often are tests passing, and how much of the code is being tested? Based on the code and test metrics, is the team likely to meet target goals?
- 44. Build Success Over Time Report What parts of the project have produced software that is ready to be tested? What parts of the project are having trouble with regressions or bad checkins? How well is the team testing the code?
- 45. Build Summary Report What is the status of all builds over time? Which builds succeeded? Which builds have a significant number of changes to the code? How much of the code was executed by the tests? Which builds are ready to install?
- 46. Burndown and Burn Rate Report Is the team likely to finish the iteration on time? Will the team complete the required work, based on the current burn rate? How much work does each team member have?
- 47. Remaining Work Report What is the cumulative flow of work? Is the team likely to finish the iteration on time? Is the amount of work or number of work items in the iteration growing? Does the team have too much work in progress? How is the team doing in estimating work for the iteration? Hours of Work # of Work Items
- 48. Status on All Iterations Report Is steady progress being made across all iterations? How many stories did the team complete for each iteration? How many hours did the team work for each iteration? For each iteration, how many bugs did the team find, resolve, or close?
- 49. Stories Overview Report (Agile) How much work does each story require? How much work has the team completed for each story? Are the tests for each story passing? How many active bugs does each story have?
- 50. Stories Progress Report (Agile) How much progress has the team made toward completing the work for each story? How much work must the team still perform to implement each user story? How much work did the team perform in the last calendar period?
- 51. Requirements Progress Report (CMMI) How much progress has the team made toward completing the work for each requirement? How much work must the team still perform to implement each requirement? How much work did the team perform in the last calendar period?
- 52. Requirements Overview Report (CMMI) How much work does each Requirement require? How much work has the team completed for each Requirement? Are the tests for each Requirement passing? How many active bugs does each Requirement have?
- 53. Release Burndown (Scrum) How much work remains in the release? How quickly is your team working through the product backlog?
- 54. Sprint Burndown (Scrum) How much work remains in the sprint? Is your team on track to finish all work for the sprint? When will your team finish all work for the sprint? How much work for the sprint is in progress?
- 55. Unplanned Work Report How much work was added after the iteration started? Is too much work being added during the iteration?
- 56. Test Case Readiness Report When will all the test cases be ready to run? Will all the test cases be ready to run by the end of the iteration? How many test cases must the team still write and review? How many test cases are ready to be run?
- 57. Test Plan Progress Report How much testing has the team completed? Is the team likely to finish the testing on time? How many tests are left to be run? How many tests are passing? How many tests are failing? How many tests are blocked?
- 58. Summary
- 59. Summary Use familiar tools for planning & tracking project status Project Project Server Excel Web Reporting available to everyone Visual Studio Excel Reporting website SharePoint Comprehensive, powerful, flexible reporting mechanisms
- 60. Questions?
- 61. Steve Lange Sr. Developer Technology Specialist Microsoft – Denver, CO Email: stevenl@microsoft.com Blog: slange.me Twitter: @stevelange
- 63. Appendix Links to Additional Resources
- 64. Links Project Planning & Tracking Using Project or Project Server Process Templates MSF for Agile MSF for CMMI Visual Studio Scrum Workbooks (Agile | CMMI) TFS Reporting Experience Dashboards (Agile | CMMI) Excel Reporting (Agile | CMMI) SQL Reporting Services Reporting (Agile | CMMI)
Notes de l'éditeur
- By using Visual Studio Application Lifecycle Management (ALM), you can manage customer needs more effectively. You can create a high-level plan that breaks your project down into potentially shippable increments, and you can create detailed plans to execute shorter iterations in which you develop those increments.Because you develop detailed plans at the start of each iteration, you have more certainty in how the plan progresses with each milestone that you reach. When your team finishes each iteration, you can refine the high-level plan based on what you might have learned during the iteration. You can also replan any work that was not completed.Your team can use Visual Studio ALM and apply an appropriate process template to plan, develop, and track your project iteratively.
- You can use the Product Planning workbook to manage the backlog and development of user stories, determine the team velocity, and balance the workload across several iterations, also known as sprints. To plan an iteration, you review, rank, prioritize, and assign points to the stories that will be implemented for a project. To balance workload, you assign each story to a specific iteration and adjust these assignments until the number of story points that are assigned across all iterations are roughly equal. Product Backlog: You use this worksheet to filter, rank, and prioritize the user stories that you want to manage. You can specify story points and assign user stories to iterations. The Product Backlog worksheet references the Product Backlog team query, which finds all user stories that are defined for the team project. Within the workbook, you can filter the stories based on product area. Iteration Planning: You use this worksheet to schedule the iterations, review the workload for each iteration, and determine how to balance the workload across the iterations. Interruptions: You use this worksheet to specify holidays or other dates when the team will perform no work.
- You can generate several reports in Microsoft Excel that show current status and historical data based on the filter criteria that you specify in a flat-list work item query. This is useful to show the distribution of work items according to selected criteria or to view trends for the past several weeks. In addition, it is an effective way for you to quickly generate PivotTable and PivotChart reports that you can customize to support other report views. When you create an Excel report from a query, you can choose which reports to generate based on the variables that are used to filter the query and the criteria that you select. By using these methods, you can generate the following types of reports:Current reports: Pie charts that show the count of work items according to the filter criteria that are specified in the work item query. Trend reports: Line charts that show the distribution of work items over the past six weeks according to the filter criteria that are specified in the work item query. After the reports are generated, you can easily change the date range.Each report includes several worksheets, and each worksheet shows a PivotTable report and a PivotChart report that derives data from the SQL Server Analysis Services cube.
- Team members can use the Bugs dashboard to determine whether they are managing the list of active Bugs according to established team goals and agile practices. By unit testing each increment of code before check-in, the team can reduce the overall number of bugs that the team must find. A team that focuses on being able to ship each increment of code removes defects incrementally and minimizes ongoing bugs.By using the Bugs dashboard, the team can answer the following questions:Is the number of active Bugs acceptable based on team goals? Is the team postponing too many Bugs?Is the team finding, fixing, and closing Bugs quickly enough to meet expectations and at a rate that matches previous development cycles? Is the team addressing high priority bugs before lower priority bugs?Does any team member need help in resolving bugs?
- You can use the Code Coverage and Code Churn reports to answer the questions that are listed in the following table. Which builds succeeded? Which builds have a significant number of changes to the code? How often are builds succeeding?How volatile is the code base?How much of the code is the team testing?How high is the quality of the builds? Is the quality increasing, decreasing, or staying constant?
- After the team has started to find and fix bugs, you can track the team's progress toward resolving and closing bugs by viewing the Bug Status report. This report shows the cumulative bug count based on the bug state, priority, and severity.
- You can use the Bug Trends report to help track the rate at which your team is discovering and resolving bugs. This report shows a rolling or moving average of bugs being reported, resolved, and closed over time. When you manage a large team or a large number of bugs, you can monitor the Bug Trends report weekly to gain insight into how well the team is finding, resolving, and closing bugs.The Bug Trends report calculates a rolling average of the number of bugs that the team has opened, resolved, and closed based on the filters that you specify. The rolling average is based on the seven days before the date for which it is calculated. That is, the report averages the number of bugs in each state for each of the seven days before the date, and then the result is divided by seven.
- As the team resolves and closes bugs, you can use the Reactivations report to determine how effectively the team is fixing bugs. Reactivations generally refer to bugs that have been resolved or closed prematurely and then reopened. The reactivation rate is also referred to as the fault feedback ratio.You can use the Reactivations report to show either bugs or user stories that have been reactivated. As a product owner, you might want to discuss acceptable rates of reactivation with the team. A low rate of reactivations (for example, less than 5%) might be acceptable depending on your team's goals. However, a high or increasing rate of reactivations indicates that the team might need to diagnose and fix systemic issues. The Reactivations report shows an area graph of the number of bugs or stories that are in a resolved state or that have been reactivated from the closed state.
- The Build Quality Indicators report shows test coverage, code churn, and bug counts for a specified build definition. You can use this report to help determine how close portions of the code are to release quality. Ideally, test rates, bugs, and code churn would all produce the same picture, but they often do not. When you find a discrepancy, you can use the Bug Quality Indicators report to examine the details of a specific build and data series. Because this report combines test results, code coverage from testing, code churn, and bugs, you can view many perspectives at the same time.
- The Build Success Over Time report provides a pictorial version of the Build Summary report. The Build Success Over Time report displays the status of the last build for each build category run for each day. You can use this report to help track the quality of the code that the team is checking in. In addition, for any day on which a build ran, you can view the Build Summary for that day.
- The Build Summary lists builds and provides information about test results, test coverage, code churn, and quality notes for each build.The data that appears in the Build Summary report is derived from the data warehouse. The report presents a visual display of the percentage of tests that are passing, code that is being tested, and changes in code across several builds. You can review the results for both manual and automatic builds, in addition to the most recent builds and continuous or frequent builds. The report lists the most recent builds first and contains build results that were captured during the specified time interval for all builds that were run, subject to the filters that you specified for the report.At a glance, you can determine the success or failure of several build definitions for the time period under review.
- After a team has worked on one or more iterations, also known as sprints, you can determine the rate of team progress by reviewing the Burndown and Burn Rate report. Burndown shows the trend of completed and remaining work over a specified time period. Burn rate provides calculations of the completed and required rate of work based on the specified time period. In addition, a chart shows the amount of completed and remaining work that is assigned to team members. You can view the Burndown and Burn Rate report based on hours worked or number of work items that have been resolved and closed.
- After the team has estimated its tasks and begun work, you can use the Remaining Work report to track the team's progress and identify any problems in the flow of work. The Remaining Work report summarizes the data that was captured during the specified time interval for each task, user story, or bug based on the filter criteria that were specified for the report. The data is derived from the data warehouse.You can view this report in either the Hours of Work view or the Number of Work Items view. The first view displays the total number of hours of work for the specified time period and the team's progress toward completing that work. The second view displays the number of work items for the specified time period and the number of work items in each state. Each view provides an area graph that charts the progress of completed work against the total estimated work for the specified time duration.
- After work has progressed on several iterations, also known as sprints, you can view the team progress by viewing the Status on All Iterations report. This report helps you track the team's performance over successive iterations. For each iteration that is defined for the product areas that you specify, this report displays the following information: Stories Closed: The number of user stories that have been closed. These values are derived from the current values specified for the iteration and the state of each user story.Progress (Hours): A two-bar numeric and visual representation that represents the values for Original Estimate (grey), Completed (green) and Remaining (light blue) based on the rollup of hours that are defined for all tasks. These values are derived from the current values that are specified for the iteration and the hours for each task. Bugs: A numeric value and visual representation for all bugs, grouped by their current states of Active (blue), Resolved (gold) and Closed (green). These values are derived from the current values that are specified for the iteration and the state of each bug.
- The Stories Overview report lists all user stories, filtered by area and iteration and in order of importance.Work Progress% Hours Completed: A numeric value and visual representation that shows the percentage of completed work based on the rollup of baseline and completed hours for all tasks that are linked to the user story or its child stories.Hours Remaining: A numeric value for the rollup of all remaining hours for all tasks that are linked to the user story or its child stories.Test StatusTest Points: A numeric value that represents the number of pairings of test cases with test configurations in a specific test suite. For more information about test points, see Reporting on Testing Progress for Test Plans.Test Results: A numeric value and visual representation that shows the percentage of test cases, grouped according to the status of their most recent test run, where the options are Passed (green), Failed (red), or Not Run (black).Bugs: A numeric value and visual representation that shows the number of bugs that are linked to the test case or user story, where the options are Active (blue) and Resolved (gold). If a user story is linked to one or more child stories, the values represent a rollup of all bugs for the user story and its child stories.User Stories that Appear in the ReportThe Stories Overview report lists and highlights user stories according to the following criteria:Stories appear in order of their importance, based on their assigned ranking.Stories appear in bold type when they are in the active or resolved state. Stories appear in normal type when they are in the closed state. Stories appear in gray type when their assigned iteration or area is outside the filtered set, but they have tasks or child stories that are within the filtered set of iterations or product areas.
- The Stories Progress report lists all user stories, filtered by product area and iteration in order of importance.This report displays the following information for each user story that appears in the report: Progress (% Completed): Numeric value that represents the percentage of completed work based on the rollup of baseline and completed hours for all tasks that are linked to the user story or its child stories.Hours Completed: A visual representation of the completed hours, displayed as a dark green bar.Recently Completed: A visual representation of those hours completed within the time interval specified for Recent (Calendar) Days, displayed as a light green bar.Hours Remaining: Rollup of all remaining hours for all tasks that are linked to the user story or its child stories.The Stories Progress report lists and highlights user stories according to the following criteria:Stories appear in order of their importance, based on their assigned ranking.Stories appear in bold type when they are in the active or resolved state. Stories appear in normal type when they are in the closed state. Stories appear in gray type when their assigned iteration or area is outside the filtered set but they have tasks or child stories that are within the filtered set of iterations or product areas.
- The Requirements Progress report shows the status of completion as determined by the tasks that have been defined to implement the requirement.
- The Requirements Overview report presents a snapshot of the work that has been performed for the filtered set of requirements to the current date.
- By reviewing a release burndown report, you can understand how quickly your team has delivered backlog items and track how much work the team must still perform to complete a product release. A release burndown graph shows how much work remained at the start of each sprint in a release. The source of the raw data is your product backlog. Each sprint appears along the horizontal axis, and the vertical axis measures the effort that remained when each sprint started. The amount of estimated effort on the vertical axis is in whatever unit that your scrum team has decided to use (for example, story points or hours).
- By reviewing a sprint burndown report, you can track how much work remains in a sprint backlog, understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.A sprint burndown report shows how much work remained at the end of specified intervals during a sprint. The source of the raw data is the sprint backlog. The horizontal axis shows days in a sprint, and the vertical axis measures the amount of work that remains to complete the tasks in the sprint. The work that remains is shown in hours. A sprint burndown graph displays the following pieces of data: The Ideal Trend line indicates an ideal situation in which the team burns down all of the effort that remains at a constant rate by the end of the sprint. The In Progress series shows how many hours remain for tasks that are marked as In Progress in a sprint. The To Do series shows how many hours remain for tasks that are marked as To Do in a sprint. Both the In Progress and the To Do series are drawn based on the actual progress of your team as it completes tasks.
- Toward the end of an iteration, you can use the Unplanned Work report to determine how much work was added to the iteration that was not planned at the start of the iteration. You can view the unplanned work as measured by work items added, such as tasks, test cases, user stories, and bugs. Having unplanned work may be acceptable, especially if the team has scheduled a sufficient buffer for handling the load of unplanned work (for example, bugs). On the other hand, the unplanned work may represent a real problem if the team does not have the capacity to meet it and is forced to cut back on the planned work.The Unplanned Work report is useful when the team plans an iteration by identifying all work items that they intend to resolve or close during the course of the iteration. The work items that are assigned to the iteration by the plan completion date of the report are considered planned work. All work items that are added to the iteration after that date are identified as unplanned work.
- The Test Case Readiness report provides an area graph that shows how many test cases are in the Design or Ready state over the time period that you specify. By reviewing this data, you can easily determine how quickly the team is designing test cases and making them ready for testing. When you create a test case, it is automatically set to the design state. After the team has reviewed and approved the test case, then a team member should change its state to Ready, which indicates that the test case is ready to be run.
- The data that appears in the Test Plan Progress report is derived from the data warehouse and the test results that are generated when tests are run by using Microsoft Test Manager. The report presents an area graph that shows the most recent result of running any test in the specified test plans over time. For more information, see Running Tests.The horizontal axis shows days in a sprint or iteration, and the vertical axis shows test points. A test point is a pairing of a test case with a test configuration in a specific test suite. For more information about test points, see Reporting on Testing Progress for Test Plans.