1 / 50

DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process

DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process. Randy Miller Program Manager Microsoft Corporation. MSF for Agile Software Development Overview. Creating New Team Projects. Plan. Plan. Plan. Plan. Plan. Plan. Plan. Plan.

norm
Download Presentation

DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DEV439Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process Randy Miller Program Manager Microsoft Corporation

  2. MSF for Agile Software Development Overview Creating New Team Projects

  3. Plan Plan Plan Plan Plan Plan Plan Plan Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Analyze Design Build Test Release Release Release Release Release Release Release Release Agile Methods Operative Principle Change is inevitable, so plan for it by doing the most valuable work first and adjusting the plan. Characteristics Cycle typically takes 2 weeks to 2 months Business value delivered iteratively & incrementally Advantages Business value realized early and often Change is an accepted part of the process Acceptance testing occurs during each cycle Bugs identified much earlier in process Whole team engaged throughout process Decision to release to public is in business’ hands Disadvantages Early adopters often encounter resistance Some practices seem to contradict common sense Some practices have a learning curve Best with very experienced team members Requires active “customer” participation in process

  4. Second Generation Agile Methods • Expand the roles to include architects, testers, … • Relax communication discipline • Standup meetings optional • Add Complexity • More activities • More values/principles

  5. Second Generation Readiness Some teams suffer from “me first” syndrome. Kent Beck, author of Extreme Programming, explains it as follows: “None of these groups saw themselves as part of a larger whole. Under stress, they reverted to trying to do all of their work up front. It was as if the different perspectives were roped together walking up a glacier and all they wanted to do was argue about who got to be first in line. It didn’t matter who was first. What the whole team was missing was a sense that they were roped together. Walking abreast, they could make more progress than if any one group tried to force the others to follow.” [Beck 2005]

  6. What We Will Cover Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing • Guiding Projects

  7. Functional/Exploratory Testing Iteration Planning Test Driven Development Shadow Architecture Context-Driven Test MSF for Agile Software Development Change Requests Process Improvement Activities Formal Reviews Approvals MSF for CMMI Process Improvement Requirements Analysis Agile vs. CMMI

  8. What We Will Cover • Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing

  9. Larry Sykes Business Analyst Jacqui AckermanProject Manager Art BensonArchitect Renee DavisTester Getting the Whole Team Involved Mort GainesDeveloper Ian Manning Release Manager

  10. Roles <-> Constituencies

  11. Principles and Mindsets

  12. Activities in MSF • Composed of 14 basic work streams • Basic activity building blocks of MSF • A work stream is an activity that is composed of other activities • Activities are described using the ETVX format • Contains 70 activities (not including work streams) • Most work streams are performed by a single role

  13. Scaling for Small Projects • Constituencies may be combined in small teams

  14. ProgramManagement Architecture Architecture Architecture Architecture ProductManagement ProgramManagement Development Site Engine & Design ReleaseOperations UserExperience Test Larger Projects…. Lead team Feature teams Function team Development UserExperience UserExperience Test ReleaseOperations ProgramManagement ProgramManagement Development Development Catalog Fulfillment UserExperience Test Test

  15. What We Will Cover • Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing

  16. Software Invisibility “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” Source: Brooks 1987

  17. Among the Customer Rights You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.

  18. Problems with the Onsite Customer • May be many customers (heterogeneous, homogeneous) • Customer must cover: • Commitment • Requirements • Planning • Testing (Basic and Comprehensive) • Adoption

  19. Customer Involvement Working Software Scenarios Personas Review Refine Linkages Real Customers

  20. Personas Source: http://www.research.microsoft.com/research/coet/Grudin/Personas/Pruitt-Grudin.doc

  21. What We Will Cover • Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing

  22. Date or Feature Driven • Projects can be driven by date or functionality. When a project is driven by date, project deadlines are usually determined by the market, events, competitors, regulations, financial implications, or other business reasons. • Understanding the progress of the system is critical to managing expectations and planning according. Additionally, organizational, technical, and project risks may need to be tracked when they have a time component. Even if a project is not date-driven, understanding the estimated time of arrival helps to other groups put the sales/deployment/marketing/training/operations elements in place.

  23. Iteration Planning Iteration 0 Brainstorming Scenarios Iteration Planning

  24. Brainstorm Quality of Service Requirements Vision Statement Quality of ServiceRequirement List Develop Lifestyle Snapshot Storyboard a Scenario Risk Plan an Iteration Write Vision Statement Define Personas Refine Personas Capture Project Vision Brainstorm Scenarios R Personas Lifestyle Snapshot Develop Lifestyle Snapshot R R Scenario List BusinessAnalyst Prioritize Quality of Service Requirements Prioritize Scenario List C Scenario Quality of Service Requirement Scenario Description Write Scenario Description Write Quality of Service Requirement C Reports Customer Storyboard Create a Quality of Service Requirement Estimate Quality of Service Requirement Review Objectives Estimate Scenario Create a Scenario Guide Project

  25. Evaluate Test Metric Thresholds Review Objectives Assess Progress Determine Iteration Length Schedule Scenario Test Approach Schedule QoS Requirement Iteration Plan Schedule Bug Fixing Allotment Risk Task Scenario Quality of Service Requirement Triage List Divide QoS Requirements Into Tasks Divide Scenarios Into Tasks Estimate Quality of Service Requirement Estimate Scenario Triage Bugs Identify Risk Guide Project R Monitor Iteration R R Project Manager Mitigate a Risk Conduct Retrospective Guide Iteration Plan an Iteration

  26. Partition The System Determine Interfaces Threat Model Iteration Plan Risk Task Quality of Service Requirement Divide QoS Requirements Into Tasks Divide Scenarios Into Tasks Plan an Iteration Develop Threat Model Develop Performance Model Create Architectural Prototype Create Infrastructure Architecture Create Solution Architecture R Application and System Diagrams Architect C Prototype Logical Datacenter And Deployment Diagrams

  27. Locate the Cause of A Bug Reassign a Bug Reproduce The Bug Cost a Development Task Code the Fix for a Bug Create or Update a Unit Test Create or Update a Unit Test Decide on a Bug Fix Strategy Perform Code Analysis Unit Test Code Perform a Unit Test Perform a Unit Test Bug Task Scenario Quality of Service Requirement Review Code Integrate Code Changes Integrate Code Changes Refactor Code Refactor Code Divide QoS Requirements Into Tasks Divide Scenarios Into Tasks Write Code For a Development Task Plan an Iteration R R R Developer C Review Code Fix a Bug Implement a Development Task

  28. Close the Bug Define Test Approach Verify Fix Close a Bug Write Performance Tests Define Test Approach Select and Run a Test Case Test Case Team Build Test Approach Write Security Tests Open a Bug Open a Bug Tester Bug Task Scenario Quality of Service Requirement Write Load Tests Select and Run a Test Case Conduct Exploratory Testing Conduct Exploratory Testing Write Stress Tests Divide QoS Requirements Into Tasks Divide Scenarios Into Tasks Write Validation Tests Plan an Iteration R R C R Test a Scenario Test a QoS Requirement

  29. Execute a Release Plan Validate a Release Create Release Notes Deploy the Product Release a Product Vision Statement Test Case Team Build Release Notes Test Approach Release Plan Bug Tester Release Manager Developer R C C

  30. Anatomy of an Iteration Iteration Retrospective Iteration Planning Meeting

  31. Iteration Retrospective - s + s if you could do it again, what kinds of improvements would you make?"

  32. What We Will Cover • Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing

  33. ProgramManagement Architecture Architecture Architecture Architecture ProductManagement ProgramManagement Development Site Engine & Design ReleaseOperations UserExperience Test Larger Projects…. Lead team Feature teams Function team Development UserExperience UserExperience Test ReleaseOperations ProgramManagement ProgramManagement Development Development Catalog Fulfillment UserExperience Test Test

  34. Shadows Leading • Sometimes we need to sketch out architecture/design before we implement them • Whiteboard is often used • Should become working code within the iteration – no BDUF Trailing • Should reflect the actual code • Should come for free

  35. A Leading Shadow

  36. Another Leading Shadow

  37. Actions • System Model/Whiteboard the architecture using leading shadows • Agree and move a single architectural change (such as a new web service) at a time to the trailing shadow • Create unit test/façade & scaffold • Run unit test • Write code • Run unit test • Verify Design/Code/Refactor • Run unit test

  38. What We Will Cover • Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing

  39. Example Test Approach

  40. Levels of Test Cases • Build Verification Tests (Automated) • Fail -> Build fails • Iteration Tests (Automated) • Track progress • Fail -> Build succeeds • Scenario and QoS Requirement Tests • Exploratory Tests • Captured in the Test Approach Document

  41. Why Exploratory Testing? • There are many areas that must be tested that fall outside of normal scenario and qos requirement tests • Pair-wise tests • States • Usability • …..

  42. Exploratory Testing • Formulate a hypothesis for area of concern • Set a session limit (e.g. 2 hours) • Grab a buddy (optional or record the session) • Test the hypothesis • Create bugs • Example: Persona based exploratory testing

  43. What We Will Cover • Microsoft Solutions Framework • Team Model • Working with Customers • Iteration Planning • Shadow Architecture • Exploratory Testing

  44. Most Importantly • MSF for Agile Software Development and MSF for CMMI Process Improvement is now available at: http://www.microsoft.com/msf

  45. VSIP Partners 46

  46. What’s Next • DB Pro Integration • Better CI support • Better Shadow Architecture Support • CM Guidance • And More…

  47. Conclusions • MSF is a vehicle for delivering Microsoft’s contributions to the software development community • MSF version 4.0 comes in two flavors to deliver maximum flexibility • MSF updates will be delivered via MSDN • MSF can become a basis for your software development process

  48. Fill out a session evaluation on CommNet for a chance to Win an XBOX 360!

  49. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

More Related