Presentation is loading. Please wait.

Presentation is loading. Please wait.

Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006.

Similar presentations


Presentation on theme: "Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006."— Presentation transcript:

1 Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006

2 Agenda TimeTopicSpeaker 09:00-09:15Opening Tom Lee 09:15-09:30Expectations Alignment Bobby Mak 09:30-11:00MSF for Agile Software Development 11:00-11:15Coffee Break 11:15-12:30Process run through (Part 1) 12:30-13:30Lunch Break 13:30-15:00Process run through (Part 2) 15:00-15:15Coffee Break 15:15-16:30Customizing the process 16:30-17:00Q&A Tom Lee, Wong-Tun Chou

3 Bobby Mak Senior Consultant Microsoft Technology Center Microsoft Taiwan bobbymak@microsoft.com Expectations Alignment Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006

4 Goal of this workshop Helps you to better understanding the MSF for Agile Software Development methodology Helps you to evaluate the adoption of MSF for Agile Software Development methodology

5 What will be the take-away for this workshop? Understanding the relationship between –Microsoft Solution Framework –Agile Software Development –MSF for Agile Software Development –Visual Studio Team System Run through each of the tracks and work streams –Go through each activities –Go through each work products Compares how things were done –In Microsoft Product Group –Microsoft Technology Center –MSF for Agile Software Development How you can modify the process –To better fit your needs

6 Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006 Bobby Mak Senior Consultant Microsoft Technology Center Microsoft Taiwan bobbymak@microsoft.com MSF for Agile Software Development

7 A Brief History of MSF (Microsoft Solution Framework) 1994 1995 1997 1999 2002 2005-06 MSF Offering MSF v1 Solutions Dev Discipline (SDD) MSF v2 Principles of … App Dev (PAD) Infra Deploy (PID) Ent Arch (PEA) Comp Des (PCD) MSF v2.5 MSF v3 Essentials + Exam Core Agile CMMI … MSF v4

8 Methodology Overview Agile MSF v4 Essential MSF4ASDMSF4CMMI VSTS Principle MindsetRole Project Management Process Practices Activities Work Products Tools

9 Microsoft Solutions Framework Key goals for MSF: Drive business success through business & technology alignment Ensure high quality solutions; handling the many facets of quality as defined by multiple stakeholders Accelerate delivery, reduce costs, minimize risks Improve team effectiveness MSF offers guidance in how to organize people and projects to plan, build, and deploy technology solutions successfully and effectively MSF for Agile Software Development MSF for CMMI ® Process Improvement Infrastructure MSFv4 Essentials Application Development Discipline Product(instantiated) Family MSFv3 Essentials Since 1994

10 The Origin of MSF Results from project teams and product groups are analyzed Analyzed results are contrasted with industry practices and methods Combined results are then organized and consolidated into “people and process” guidance Microsoft Products Groups Microsoft Operations & Technology Group Microsoft Services Microsoft Certified Partners Proven Practices

11 MSF v4 Principles Foster open communications –to maximize members’ individual effectiveness and optimize efficiencies in the work, information has to be readily available and actively shared. Shared vision –vision helps to clarify goals and bring conflicts and mistaken assumptions to light so they can be resolved Empower team members –MSF advocates bottom-up scheduling, a schedule that the team can support because it believes in it Clear accountability and shared responsibility –establishing well-understood lines of accountability and responsibility reduces uncertainty around the "who, what, when, and why," Focus on business value –By combining a focus on business value with shared vision, the project team and the organization can develop a clear understanding of why the project exists and how success will be measured in terms of business value to the organization.

12 MSF v4 Principles (cont.) Stay agile, expect change –MSF advises teams to expect changes from stakeholders and even the team itself Invest in quality –investment in people, as well as in processes and tools Learn from all experiences –the failure to learn from all experiences is a guarantee that we will repeat them, as well as their associated project consequences. Partner with customers –Understanding the value proposition of your solution and communicating it effectively is a key success factor. Always create shippable solutions –Each change should be done in the context of the belief that the product should be ready to ship at any time.

13 MSF v4 Mindsets Team of Peers –all roles must have ownership of the product’s quality, must act as customer advocates, and must understand the business problem they are trying to solve. Customer-focused mindset –Satisfied customers are priority number one –A customer focus throughout development includes a commitment from the team to understand and solve the customer’s business problem. Solution mindset –It is about treating the results of your labor as a solution –MSF advocates the creation of project identities so that team members see themselves less as individuals and more as members of a project team Trusting mindset –Trusting your peers Quality mindset –commitment to quality. –team goal is to perform their work at the highest quality possible, so that if they have to deliver tomorrow, they can deliver something Willingness to learn –commitment to ongoing self improvement through the gathering and sharing of knowledge

14 MSF v4 Advocacy Groups Team Model Advocacy Solution Delivery Development Test Release / Operations User Experience Product Management Program Management Architecture Solution Design Solution Definition Solution QualitySolution Usability Solution Construction Solution Deployment

15 MSF v4 Advocacy Groups Focus Operations Technology Focus Business Focus Users Solutions Architects Customer Technology Architects Operations Support Project Team User Experience Development Test Release / Operations Product Management Architecture Program Management Project Sponsor

16 Advocacy GroupAdvocatesQuality GoalsConstituentsFunctional Areas Product Management Solution Definition o Satisfy stakeholders o Define solution within project constraints o Stakeholders o Marketing/Corporate Communications o Business Analyst o Product Planning o Release Management Program Management Solution Delivery o Coordinate identification and optimization of project constraints o Deliver solution within project constraints o Project Sponsor(s) o Project management o Program Management o Resource Management o Process Assurance o Project Quality Management o Project Operations Architecture Solution Design Design a solution within project constraints o Solution Architecture o Technical Architecture Development Solution Construction Build solution to specifications Test Solution Quality Approve solution for release only after making sure all aspects of the solution meet or exceed their respective, defined quality levels o Functional Testing o System Testing User Experience Solution Usability Maximize/ Enhance user performance/ effectiveness o Users o Operations Support o Accessibility o Internationalization o Technical Support Communications o Training o Usability o Graphic Design Release / Operations Solution Deployment Smooth deployment and transition to operations o Operations o Delivery Infrastructure o Operations o Commercial Release Management o Build Master o Tool Administrator

17 MSF v4 Advocacy Groups Roles may be combined, but some combinations pose risks N N N N N N N N N NNN P P P P P P P P P P U U U U UU U U P Possible U Unlikely N Not Recommended Product Management Program Management Development Test User Experience Product Management Program Management Development Test User Experience Release Management

18 MSF v4 Advocacy Groups Small Team User Experience Product Management Test Program Management Release Management Development Small team, combined roles

19 MSF Sub-teams in Relation to the Lead Team Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability Program Management Release / Operations Product Management User Experience Development Test Desktop Feature Team Program Management Development Test Architecture Release / Operations Product Management File & Print Feature Team Program Management Development Test Release / Operations Messaging Feature Team Program Management Development Test Architecture Release / Operations Product Management User Experience Role Lead Function Team Feature Teams

20 Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaborationCustomer collaboration over contract negotiation Responding to change over following a plan Established 2001

21 Agile Software Development “An agile method is –Iterative –Incremental –Self-Organizing and –Emergent. It must include these attributes; otherwise it is a ‘lightened defined process’.” – Ken Schwaber, First eWorkshop on Agile Methods MSF fulfills the definition of an Agile Process

22 Agile Management Philosophy Cost Accountingvs.Throughput Accounting ClassicAgile Focus is on hours spent Focus is on value delivered Eliminate waste

23 Well known Agile Methodologies Extreme Programming (XP) Scrum Adaptive Software Development (ASD) Crystal Feature-Driven Development (FDD) DSDM RUP Unisys QuadCycle Etc.

24 Agile – Software Development Lifecycle Support VTT Agile Software Development Method - http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf

25 MSF for Agile Software Development Represent a version of MSF that –De-emphasizes formal project governances –Emphasizes agile principles within smaller collaborative teams an iterative, scenario-driven, context-based software development process for building.NET, Web, Web Service, and other object- oriented applications.

26 MSF for Agile Software Development First Microsoft-branded software development methodology Complete with –documented processes –Guidance and templates –Incorporate hooks into tools “White label” approach –Designed for adopt then customized and extend as required

27 MSF4CMMI MSF4ASD MSF for CMMI Process Improvement Help organizations operate at Capability Maturity Model ® Integration (CMMI ® ) level 3, a standard defined by the Carnegie Mellon Software Engineering Institute (SEI) Does not replace process improvement infrastructure An Agile approach to CMMI –Introduce additional formality, reviews, verification, and audit Compare to MSF4ASD –Based on the same MSF meta-model –Same set of principles –Same set of mindsets MSFEssential

28 MSF for CMMI Process Improvement Coverage of 20 out of 25 process areas Footprint only 150% bigger than MSF Agile Approximately 200 activities Only 50 documents (work products) –Typical CMMI implementation ~100 Supported by around 50 automated queries and reports –Easier certification

29 CMMI Model Level 2 Project Planning Project Monitoring & Control Measurement & Analysis Requirements Management Configuration Management Process & Product Quality Assurance Supplier Agreement Management Level 3 Integrated Project Management Risk Management Integrated Teaming Requirements Development Technical Solution Product Integration Verification Validation Decision Analysis & Resolution Organizational Process Definition Organizational Environment for Integration Organizational Process Focus Organizational Training Integrated Supplier Management Omitted Level 4 Organizational Process Performance Quantitative Project Management Level 5 Organizational Innovation and Deployment Causal Analysis & Resolution 50% coverage 20% coverage

30 When to choose MSF4ASD? … for projects with results-oriented teams who can work without lots of intermediate documentation “Stretch to Fit” instead of “Shrink to Fit” –Minimalist approach –Agile methodologies promote adaptation

31 When to choose MSF4CMMI? Choose the MSF for CMMI Process Improvement process for projects with longer lifecycles and that require a record of decisions made. Choose MSF for CMMI Process Improvement over MSF for Agile Software Development, if your organization is undertaking a broad quality assurance and process improvement initiative or your team needs the assistance of explicit process guidance rather than relying on tacit knowledge and experience.

32 MSF for Agile Software Development Tracks Cycle Roles Work Streams Activities Work Products Tracks Cycle Roles Work Streams Activities Work Products 1 n 1 n 1 n 1 n 1 n Project Management ProcessPracticesActivities Work Products

33 Tracks MSF for Agile Software Development Tracks overlap each other and are controlled by checkpoints –Envision –Plan –Build –Stabilize –Deploy –Continuous

34 Cycle Foundation of every day’s coordinated team work

35 Iterative Approach Cycle Minimize risks by breaking large projects into multiple versions Time Envision Plan Develop Stabilize Deploy Version 3 Envision Plan Develop Stabilize Deploy Version 2 Envision Plan Develop Stabilize Deploy Version 1

36 Iterations Cycle Achievement of a pre-determined level of quality Based on planning of feature-sets Mechanism to correct project plan deviations

37 Team Roles

38 Work Streams Work streams are groups of activities that flow logically together and are often associated with a particular role

39 Activities 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

40 Work Products Work products are files, documents, specifications, binaries, parts, and other tangible items that are necessary to complete activities and build the product.

41 Visual Studio Team System Version ControlWork Item TrackingTeam ReportingProject Portal Visual Studio Team Foundation Integration ServicesProject Management Process and Architecture Guidance Dynamic Code Analyzer Visual Studio Team Architect Static Code AnalyzerCode ProfilerUnit TestingCode CoverageVisio and UML ModelingTeam Foundation Client (includes CAL)Microsoft ® Visual Studio ® Professional EditionLoad/Web TestingManual TestingTest Case ManagementApplication Designer Logical Datacenter Designer Deployment Designer Visual Studio Team Developer Visual Studio Team Test Visual Studio Industry Partners Team BuildClass Designer

42 Work Items A work item is a record uses to track the assignment and state of work. The MSF for Agile Software Development process defines five work items to assign and track work. –Scenario –Quality of service requirement –Task –Bug –Risk

43 Reports Aggregates –Work Items –Source Controls –Test Results Work Streams Work Products Work Items Source Control Test Results Reports Team System

44 Bobby Mak Senior Consultant Microsoft Technology Center Microsoft Taiwan bobbymak@microsoft.com Process Run Through Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006

45 Capture Project Vision Write Vision Statement Capture Project Vision Define Personas Plan an Iteration Determine Iteration Length Guide Project Access Progress Create a Scenario Brain Storm Scenario Create a Scenario Prioritize Scenario List Plan an Iteration Estimate a scenario/QoSWrite Scenario Description Create a Scenario Write QoS Requirement Create a QoS Plan an Iteration Divide Scenario to Tasks Refine Personas Capture Project Vision Brain Storm QoS Create a QoS Prioritize QoS Requirement Create a QoS Dev. Lifestyle Snapshot Create a QoS/Scenario Storyboard a scenario Create a Scenario Identify Security Objectives Create a QoS Plan an Iteration Schedule scenario Plan an Iteration Schedule QoS Plan an Iteration Divide QoS to Tasks Create Solution Architect Partition the System Create Solution Architect Determine Interface Create Solution Architect Dev. Threat Model Create Solution Architect Develop Performance Model Create Solution Architect Create Infrastructure Arch. Create Solution Architect Create Architecture Phototype Implement a Dev Task Cost a Dev Task Test a Scenario Define Test Approach Test a Scenario Write Validation Test Test a QoS Write QoS Test Implement a Dev Task Create of Update Unit Test Implement a Dev Task Write Code for Dev Task Fix a Bug Reassign the bug Fix a Bug Decide Bug Fix Strategy Fix a Bug Code the Fix Fix a Bug Create of Update Unit Test Fix a Bug Reproduce the bug Fix a Bug Locate the bug cause Imp Dev Task/Fix Bug Perform Code Analysis Imp Dev Task/Fix Bug Refector Code Imp Dev Task/Fix Bug Code Review Implement a Dev Task Integrate Code Change Imp Dev Task/Fix Bug Perform Unit Test Build a Product Start a build Build a Product Verify a build Build a Product Fix a build Build a Product Accept Build Test a Scenario Verify Fix(s) Test a Scenario/QoS Select & Run a test case Test a Scenario/QoS Conduct Exploratory Test Test a Scenario Open a Bug Test a Scenario Close Bug(s) Release a Product Execute a release plan Release a Product Validate a release Release a Product Create Release Note Release a Product Deploy the product Envision Plan Build Stable Deploy Cont. Guide Project Review Objectives Guide Project Access Progress Guide Project Identify Risk Guide Iteration Monitor Iteration Guide Iteration Mitigate a Risk Guide Iteration Conduct Retrospective Guide Project Triage Bug Iteration Check-In Accepted Build Build Complete View

46 Capture Project Vision Write Vision Statement Capture Project Vision Define Personas Plan an Iteration Determine Iteration Length Guide Project Access Progress Create a Scenario Brain Storm Scenario Create a Scenario Prioritize Scenario List Plan an Iteration Estimate a scenario/QoSWrite Scenario Description Create a Scenario Write QoS Requirement Create a QoS Plan an Iteration Divide Scenario to Tasks Refine Personas Capture Project Vision Brain Storm QoS Create a QoS Prioritize QoS Requirement Create a QoS Dev. Lifestyle Snapshot Create a QoS/Scenario Storyboard a scenario Create a Scenario Identify Security Objectives Create a QoS Plan an Iteration Schedule scenario Plan an Iteration Schedule QoS Plan an Iteration Divide QoS to Tasks Create Solution Architect Partition the System Create Solution Architect Determine Interface Create Solution Architect Dev. Threat Model Create Solution Architect Develop Performance Model Create Solution Architect Create Infrastructure Arch. Create Solution Architect Create Architecture Phototype Implement a Dev Task Cost a Dev Task Test a Scenario Define Test Approach Envision Plan Build Stable Deploy Cont. Iteration Check-In Accepted Build Build Iteration 0

47 Guide Project Access Progress Create a Scenario Brain Storm Scenario Create a Scenario Prioritize Scenario List Plan an Iteration Estimate a scenario/QoSWrite Scenario Description Create a Scenario Write QoS Requirement Create a QoS Plan an Iteration Divide Scenario to Tasks Refine Personas Capture Project Vision Brain Storm QoS Create a QoS Prioritize QoS Requirement Create a QoS Dev. Lifestyle Snapshot Create a QoS/Scenario Storyboard a scenario Create a Scenario Identify Security Objectives Create a QoS Plan an Iteration Schedule scenario Plan an Iteration Schedule QoS Plan an Iteration Divide QoS to Tasks Create Solution Architect Partition the System Create Solution Architect Determine Interface Create Solution Architect Dev. Threat Model Create Solution Architect Develop Performance Model Create Solution Architect Create Infrastructure Arch. Create Solution Architect Create Architecture Phototype Implement a Dev Task Cost a Dev Task Test a Scenario Define Test Approach Test a Scenario Write Validation Test Test a QoS Write QoS Test Implement a Dev Task Create of Update Unit Test Implement a Dev Task Write Code for Dev Task Fix a Bug Reassign the bug Fix a Bug Decide Bug Fix Strategy Fix a Bug Code the Fix Fix a Bug Create of Update Unit Test Fix a Bug Reproduce the bug Fix a Bug Locate the bug cause Imp Dev Task/Fix Bug Perform Code Analysis Imp Dev Task/Fix Bug Refector Code Imp Dev Task/Fix Bug Code Review Implement a Dev Task Integrate Code Change Imp Dev Task/Fix Bug Perform Unit Test Build a Product Start a build Build a Product Verify a build Build a Product Fix a build Build a Product Accept Build Test a Scenario Verify Fix(s) Test a Scenario/QoS Select & Run a test case Test a Scenario/QoS Conduct Exploratory Test Test a Scenario Open a Bug Test a Scenario Close Bug(s) Envision Plan Build Stable Deploy Cont. Guide Project Review Objectives Guide Project Access Progress Guide Project Identify Risk Guide Iteration Monitor Iteration Guide Iteration Mitigate a Risk Guide Iteration Conduct Retrospective Guide Project Triage Bug Iteration Check-In Accepted Build Build Iteration 1 For next iteration

48 Guide Project Access Progress Test a Scenario Write Validation Test Test a QoS Write QoS Test Implement a Dev Task Create of Update Unit Test Implement a Dev Task Write Code for Dev Task Fix a Bug Reassign the bug Fix a Bug Decide Bug Fix Strategy Fix a Bug Code the Fix Fix a Bug Create of Update Unit Test Fix a Bug Reproduce the bug Fix a Bug Locate the bug cause Imp Dev Task/Fix Bug Perform Code Analysis Imp Dev Task/Fix Bug Refector Code Imp Dev Task/Fix Bug Code Review Implement a Dev Task Integrate Code Change Imp Dev Task/Fix Bug Perform Unit Test Build a Product Start a build Build a Product Verify a build Build a Product Fix a build Build a Product Accept Build Test a Scenario Verify Fix(s) Test a Scenario/QoS Select & Run a test case Test a Scenario/QoS Conduct Exploratory Test Test a Scenario Open a Bug Test a Scenario Close Bug(s) Envision Plan Build Stable Deploy Cont. Guide Project Review Objectives Guide Project Access Progress Guide Project Identify Risk Guide Iteration Monitor Iteration Guide Iteration Mitigate a Risk Guide Iteration Conduct Retrospective Guide Project Triage Bug Iteration Check-In Accepted Build Build Iteration N + 1

49 Guide Project Access Progress Fix a Bug Reassign the bug Fix a Bug Decide Bug Fix Strategy Fix a Bug Code the Fix Fix a Bug Create of Update Unit Test Fix a Bug Reproduce the bug Fix a Bug Locate the bug cause Imp Dev Task/Fix Bug Perform Code Analysis Imp Dev Task/Fix Bug Refector Code Imp Dev Task/Fix Bug Code Review Implement a Dev Task Integrate Code Change Imp Dev Task/Fix Bug Perform Unit Test Build a Product Start a build Build a Product Verify a build Build a Product Fix a build Build a Product Accept Build Test a Scenario Verify Fix(s) Test a Scenario/QoS Select & Run a test case Test a Scenario/QoS Conduct Exploratory Test Test a Scenario Open a Bug Test a Scenario Close Bug(s) Envision Plan Build Stable Deploy Cont. Guide Project Review Objectives Guide Project Access Progress Guide Project Identify Risk Guide Iteration Monitor Iteration Guide Iteration Mitigate a Risk Guide Iteration Conduct Retrospective Guide Project Triage Bug Iteration Check-In Accepted Build Build Iteration N +2

50 Envision Plan Build Deploy Cont. Guide Project Review Objectives Guide Project Access Progress Guide Project Identify Risk Guide Iteration Monitor Iteration Guide Iteration Mitigate a Risk Guide Iteration Conduct Retrospective Iteration Check-In Accepted Build Build Iteration N +3 Release a Product Execute a release plan Release a Product Validate a release Release a Product Create Release Note Release a Product Deploy the product Stable

51 What is a Vision Statement? Capture Project Vision A short, coherent statement that concisely describes the purpose of building the new or improved system. Provides the justification for building the system to the team. Ideally it should be 25 words or less. Everyone on the project team can recite it from memory and connect their daily work to it

52 The one-sentence approach Capture Project Vision For(identified users) Who(narrow the scope of the problem) Our solution is (set framework) That(enumerate requirements) Unlike(differentiate from competitors / alternatives)

53 Example Capture Project Vision Foronline shoppers Whoare interested in sporting and camping equipment, but do not like shopping in brick- and-mortal shops Our solution is an AdventureWorks e-commerce Web site Thatallows them to find and purchase exactly what they need Unlikewithout having to physically visit the store

54 Personas Define Personas Descriptions of a group of typical users. –(Instances of actors) Instead of talking about the group of users in an abstract, impersonal way, a persona represents a 'proxy' for the user group, and provides a means to talk and reason about the group through the characteristics of one fictional individual, the persona.

55 Where Does Personas Fit in? Define Personas On-site Customer Actor Persona

56 What is in a Personas? Define Personas A persona describes the typical skills, abilities, needs, desires, working habits, tasks and backgrounds of a particular set of users. A persona is fictional reality, collecting together real data describing the important characteristics of a particular user group in a fictional character.

57 Favored and Disfavored Personas Define Personas Favored personas are users who will use the system “appropriately” or way that it was intended to be used. Disfavored personas are folks who will abuse the system. An example of a disfavored persona for an operating system is a hacker or virus writer.

58 Example: David Define Personas Role: Online Shopper Motivation: Get it Quick Usage: David hates to shop but wants his equipment immediately. He will place his order on Thursday night for his weekend activity. David doesn’t want to wade through a catalog. Instead, he wants things that he typically orders to show immediately.

59 Example: Judith Define Personas Role: Online Shopper Motivation: Get it Cheap Usage: Judith shops for the best bargain. She looks for the best deal on similar items. She will visit half a dozen sites to find the best deal.

60 Example: MSN Define Personas

61 Example: VSTS Personas Define Personas Jacqui Ackerman Project Manager Art Benson Architect Mort Gaines Developer Renee Davis Tester Larry Sykes Business Analyst Ian Manning Release Manager

62 Personas Resources Define Personas Personas: Practice and Theory Whitepaper http://www.research.microsoft.com/research/coet/Grudin/Personas/ Pruitt-Grudin.doc Personas book The Persona Lifecycle

63 Where do Scenario fit in? Create a Scenario User stories Use cases Scenarios

64 Brain Storm Scenario Create a Scenario For each persona, determine their goals of the system. Decompose each goal into the scenarios that are required to achieve that goal or may result from an unsuccessful attempt to achieve that goal. Add an entry (called a scenario entry) for each brainstormed scenario One scenario is one path through the system

65 Example: Purchase Product: Find Product Create a Scenario David has heard about a new lightweight frame for his mountain bike. He brings up the AdventureWorks Website and finds the search engine. He enters the text “mountain bike frame” and gets a list of the products that meet his search criteria. The list comes back sorted by the most popular (purchased most often) product but can be sorted by brand, product name, rating (number of stars by reviewers), and price. David sorts on brand and all of the “Excalibur” products are grouped together. He selects the “XJ11” which is $799.95 and has received five stars. When he presses the details button, he sees a picture of the new frame as well as links to the reviews and specification information. Note: the conclusion of adding the XJ11 to the cart has been omitted because it is described in the goal and scenario “Purchase Products: Add Product to Cart

66 Prioritize Scenario List Create a Scenario Determine the importance of the scenario Sort the Scenario list by priority Using Kano Analysis!!

67 Poor Functionality Excellent Functionality Dissatisfied Customer Satisfied Customer Indifferent Needs Linear “1 Dimensional” Needs Must Have Needs Attractive Needs “If it’s not there, I’ll never be satisfied” Ability to Print Coffee is hot Car has brakes Ability to transfer digital pictures to computer “I don’t care” MapPoint on standard tool bar Color of coffee cup Size of tires Voltage of battery “More Is Better” Speed of Internet Connection Flavor of coffee Gas Mileage Battery life on digital camera “That’s Cool” Web page editing on IE Tool Bar Free Internet Access @ Starbucks Retractable light under hood Send digital pix with your cell phone Web page editing on IE Tool Bar

68 1b. If (need 1) is poor, how do you feel? 1. I like it 2. I expect it 3. I am neutral 4, I can tolerate 5. I dislike it Customer Requirement Is A: AttractiveO: One-Dimensional M: Must HaveQ: Questionable Result R: ReverseI: Indifferent Survey Questions: 1a. If (need 1) is good, how do you feel? 1. I like it 2. I expect it 3. I am neutral 4, I can tolerate it 5. I dislike it 1. I like it 2. I expect it 3. I am neutral 4. I can tolerate it5. I dislike it 1. I like itQAAAO 2. I expect it RARA QIIM 3. I am neutralIIIM 4. I can tolerate itIIQM 5. I dislike itQ Functional Form of Question Dysfunctional Form of Question Kano Evaluation Table Functional Dysfunctional Example If the speed of the internet connection is fast, how do you feel? 1. I like it If the speed of the internet connection is slow, how do you feel? 5. I dislike it One-Dimensional Need RARA RARA RORO RMRM RMRM RMRM Functional Dysfunctional

69 % Response by Category Must-Have One- Dimensional AttractiveIndifferentReverseQuestionable Need14520 10 5 Need21060255 Need3510580 Need455855 Need525302025 Need6855 10 M+OO+A 6540 7085 15 1090 5550 905 { M+O { O+A Location on Grid –Corners Strong Requirement –Center Mix of segments (respondents) Weak requirement M+O O+A Dissatisfaction if Missing Satisfaction if Included

70 Ignore Include as Differentiator s Perform slightly better than Competitors DO NOT IGNORE! Dissatisfaction if Missing Satisfaction if Included

71 Write Scenario Create a Scenario A scenario is a single path of user interaction through the system. As the user attempts to reach a goal, the scenario records the specific steps that they will in attempting to reach that goal. Some scenarios will record a successful path; others will record an unsuccessful one. When writing scenarios, be specific. Since there are an infinite number of possible scenarios for all but the most trivial systems, it is important to be discerning in deciding which scenarios to write.

72 Storyboard Scenario Create a Scenario Capture the screens that are presented to the persona. Draw out a rough sketch of the user interface called for in the scenario. Collaborate with members of the development team to ensure the user interface is consistent with the user interface metaphor. Tools that work well for storyboards include Microsoft Visio and Microsoft PowerPoint.

73 Brain Storm a QoS Create a QoS “Non-functional” requirements QSRs constrain other functionality Top 5 –Performance –Security –User Experience –Platform –Load

74 Example Create a QoS Examples –“ When the system is being used by 25,000 simultaneous users, the catalog search results response time should not exceed 5 seconds in 95% of the cases.” [Performance] –“When the catalog prices are updated, the system should log the user that has done this to the Windows Security Event Log.” [Security] –“When the user changes the text size in his Web browser, the web pages should adjust accordingly” [User Experience] Source: Carriere Stimulus Context Response

75 Define Test Approach Test a Scenario Called Test Metric Thresholds in MSF Agile –Objective definition of when the product quality is high enough to ship Context-based –Testing that is acceptable on one project may be criminal on another

76 Sample Test Thresholds Test a Scenario Planned test coverage/ release criteria for: What are we going to look at?When is it good enough? CodeUnit tests for all code70% code coverage, 100% pass rate ScenariosValidation tests for all scenariosAt least 1 test per scenario, 100% pass rate Key QSRs (enumerate) Home page load time 10,000 simultaneous users Within 2 seconds Key RisksSystem administrator not able to deploy the system in the production environment because of an incomplete/incorrect Installation Guide A person that has never deployed the system before is able to do it in our test environment by following the Installation Guide BugsBugs will be classified as follows …No Priority 1 & 2 bugs Build VerificationAll unit tests will be run as part of the daily build 100% pass rate ConfigurationsScenario validation tests executed with IE6, IE7, FireFox and Safari browsers 100% pass rate OtherBug debt per developerLess than 7

77 Agile Plan Plan an Iteration Scenario List Iteration Plan Scenario 1 Scenario 2 Scenario 3 Iteration 1 Scenario 4 Scenario 1 Scenario 2 Scenario 3 How long is an iteration? How many scenarios can I implement in an interation? How big is a scenario?

78 How Long is an Iteration? Plan an Iteration Time-boxed –2 to 6 weeks –4 weeks is a reasonable default –Planning overlaps with developing and testing (Self-organizing)

79 How Big is the Scenario? Plan an Iteration Use Rough Order of Magnitude (ROM) –~1 day -> 0 –~5 days or less -> 1 –~10 days -> 2 –> 10 days -> 3 Consider splitting

80 How many scenario per Iteration? Plan an Iteration Velocity –The number of scenario units completed in an iteration Calculating velocity –Sum of the ROM of each scenario Initial velocity –(developers * iteration weeks) / 3

81 Example: Schedule Scenario Plan an Iteration Scenario List Iteration Plan Scenario 1 – ROM 1 Scenario 2 – ROM 2 Scenario 3 – ROM 1 Iteration 1 Scenario 4 – ROM 1 Scenario 1 Scenario 2 Scenario 3 Initial velocity = (3 developers * 4 weeks) / 3 = 4

82 Using Kano Analysis Plan an Iteration MinimumAcceptanceLevel Iteration 1 Iteration 2 Iteration 3 Minimum Acceptance Level

83 Divide a Scenario/QoS to Tasks Plan an Iteration Create Sporting Good Order Split Divide Assign Browse Catalog for Products Order Products for Pickup Scenarios Dev Tasks Test Tasks Catalog UI Create Order DB Browse for Products – Catalog Provisioning Browse for Products – Product Selection

84 Cost a Dev Task Implement a Dev Task At the beginning of each iteration Developers estimate their tasks in hours –Check if SumOf(tasks) + overhead > iteration length Split or load-balance tasks if necessary Update with the actual hours when done Use velocity for estimation Use actual hours for tracking The difference between the two is the project overhead: –Meetings, code reviews, e-mail, etc.

85 ROLE: Architects Create Solution Architect Coordinate between Development and Operations –Not a Developer –Not responsible for Class Design Hands-On Architect –Limited documentation (Architectural decisions) –Setup Solution structure Responsible for Quality of Service Requirements –Architectural (evolving) prototype –Threat Modeling –Performance

86 TOOLS: Application Designer Create Solution Architect Define and visualize applications in a Visual Studio Solution and how they are connected

87 Layering Architecture Create Solution Architect

88 Shadow Architecture Create Solution Architect MSF (Agile community) has to BDUF is that –Without working software, these efforts have no feedback mechanism. Architecture must lead and reflect the structure and logic of the working code MSF utilize Shadowing –Architecture for the functionality to be completed in the iteration –A top-down approach of using System Designer System Designer in VSTS is optimized for bottom-up “composition” of systems

89 Threat Model Create Solution Architect Brainstorm threats to the system Rank the threats by risk –How serious are the consequences? –How easy is the attack? Find mitigations for the threats Decide which threats to address, and follow up

90 STRIDE-Categorize Threat Create Solution Architect TypesExample S poofing Somebody looked over your shoulder when you entered your PIN. T ampering Extra, unwanted items show up in your basket at the counter in the supermarket. R epudiation “You never lent me 1000 euros!” I nformation Disclosure Someone put your salary slip up on the wall at the office D enial of Service Someone slashed your car tyres and you can’t get to work. E levation of Privelege You use your boss’ phone to order free lunch.

91 DREAD-Rank Threats Create Solution Architect RankingsDescription D amage Potential The extend of the damage R eproducibility How easy is it to get a potential attack to work? E xploitability How much effort and expertise is required to mount an attack? A ffected Users A numeric value characterizing the ratio of installed instances of the system that would be affected if an exploit became widely available D iscoverability The likelihood that, if the vulnerability were to go unpatched, it would be found by external security researchers, hackers, etc

92 TOOLS: Threat Modeling Tool Create Solution Architect

93 Coding!! Implement a Dev Task Unit Testing –Not a choice –Rule of thumb: 70% code coverage Check-in Policy –Check as early as possible –Prevent breaking the build –Unit Tests must succeed Refactoring is not bad –Requirements change –Visions change

94 Test First or Code First? Implement a Dev Task It doesn’t matter, just do it! Create or Update Unit Tests Write Code for a Development Task Perform Unit Test Check Code against Design and Code Guidelines

95 Coding Guidelines Implement a Dev Task Full Design Guidelines can be accessed at http://msdn.microsoft.com/library/en- us/cpgenref/html/cpconNETFrameworkDesignGuidel ines.asp. http://msdn.microsoft.com/library/en- us/cpgenref/html/cpconNETFrameworkDesignGuidel ines.asp –These provide some more detail and some justifications for the guidelines described above. Community Efforts, by Lance Hunt –C# Coding Standard for.NET –http://home.comcast.net/~lancehunt/CSharp_Coding_ Standards.pdfhttp://home.comcast.net/~lancehunt/CSharp_Coding_ Standards.pdf

96 Integrate Code Change Implement a Dev Task Policies –Pass Unit Test –Pass Code Analysis –Conduct Code Review IMPORTANT: Make sure you… 1.Put a lock on to the server (source control) 2.Get latest version of the code from server 1.Integrate the differences locally 3.Compile and must PASS Check-In Suit 4.Check in only the changes 5.Release the lock

97 Coding!!! Fix a Bug Bug classification –MSF 4 Process Guidance 1 = This iteration 2 = This release 3 = May or may NOT fix –Microsoft Best Practice: Tell and Ask –Be aware: Honesty pays off Unit Test –Helps validating bug fixing –Can be used to repro a bug and check for the fix

98 Daily Build Build a Product Daily Build Vital! –Heartbeat –Keep quality near 100% Use Build Verification Tests (BVT) for validation –Scenario based Daily Integration –No surprises in the end –Saves time

99 Select and Run a Test Case Test a Scenario Involve testers during the project –Not at the end Automate tests –Where possible

100 Opening a Bug (in Microsoft) Test a Scenario

101 Select and Run a Test Case Test a QoS Performance Testing –Global performance, scenario performance –Load testing (users) –Stress testing (resources) Security Testing –Various roles, environment Exploratory Testing –Not monkey testing –Act as persona

102 Close a Bug Test a Scenario Testers decide, NOT the developers

103 Risk Guide Project Definitions –Dictionary: “Possibility of loss or injury” Webster’s Collegiate Dictionary, 10th edition –Common: A problem waiting to happen Characteristics –Inherent in every project –Neither intrinsically good nor bad –Not something to fear, but something to manage

104 Risk Guide Project Simplified risk management framework Risk is just another work item New or renamed Fields –Severity is the same as Impact –Priority replaces Exposure No Probability field Prioritization is done by customer –State Risks can be in Active or Closed states –Reason Reason a risk is in current State

105 Risk Guide Project New or renamed Fields –Iteration Iteration in which risk could be realized Risk can be made part of Iteration Backlog –Mitigation and Contingency plans are tracked in a general Description field Risks that impacts solution architecture are handled by the Architect –Architect creates an architectural prototype to validate proposed architecture

106 Access Progress Guide Project Remaining Work –How much work is left to be done, and when will it be completed?

107 Access Progress Guide Project Quality Indicator –What is the quality of the software?

108 Access Progress Guide Project Velocity –How quickly is the team completing work?

109 Access Progress Guide Project Unplanned Work –How much unplanned work is there?

110 Access Progress Guide Project Actual vs. Planned Work –How many scenarios can be completed before quality is unacceptable?

111 Access Progress Guide Project Bug Rates

112 Access Progress Guide Project Reactivations

113 Access Progress Guide Project Remaining Work –How much work is left to be done, and when will it be completed? Quality Indicator –What is the quality of the software? Velocity –How quickly is the team completing work? Unplanned Work –How much unplanned work is there? Actual vs. Planned Work –How many scenarios can be completed before quality is unacceptable? Bug Rates Reactivations

114 Stabilize Focus on delivery Feature Complete –NO new functionality will be added Bugs Fixed should exceed Bugs Found Balances stability against customer needs Can result in loss of features for the sake of stability

115 Deploy Microsoft Operations Framework Microsoft Solutions Framework Operate Deploy Build Plan

116 Deploy Goal: Release to Production or Acceptance Team focus –To facilitate the smooth transfer of the solution from the project team to the operations team –To secure customer approval that the project is complete Validate Release Deliverables –Repository of all versions of documents, load sets, configurations, scripts, and code –Release Notes

117 Deployment Best Practice Test deployment early in an environment with production characteristics Deploy multiple times during Development Lifecycle to improve the process Automate as much as possible Produce useful and up-to-date Release Notes Work closely with the Operations Team

118 Bobby Mak Senior Consultant Microsoft Technology Center Microsoft Taiwan bobbymak@microsoft.com Customizing VSTS Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006

119 Process Templates in VSTS Work Item types, workflow Check-In policy Document templates Reports Groups and permissions Integrated help

120 Extensibility Process templates can be edited Process guidance includes Microsoft ® InfoPath ® editing form Third-party tools available from Osellus

121 Method of Extension Framework – Building a process within the MSF meta-model, adopting pieces or all of MSF for Agile or Formal Software Development process Prototype – Using pieces or all of MSF for Agile Software Development or Formal as a base to build your own process without the meta-model

122 Process Guidance Architecture

123 Extending Team System Process –Process Template Customization Guide –MSF Process Guidance Customization Guide Core Service –Authoring work items –Work Item Query Language –Work Item Tracking Object Model –Check In policy extensibility –Continuous Integration –Event Subscription –Object Model Help –Linking Service Extension –Reports Extension –Security Service Guide Operation –Configure TFS to use a Remote SharePoint Server –Migrate TFS from a single to dual server –Migrate TFS to a new server –TFS Backup and Restore VSTF Extension Kit

124 Tom Lee – DPE Architect Evangelist Wong-Tun Chou – DPE ISV Evangelist Q&A Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006

125 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

126 Appendix

127 Methodology Agile MSF v4 Essential MSF4ASDMSF4CMMI VSTS Principle MindsetRole Project Management Process Practices Activities Work Products Tools Microsoft Solution Framework For Agile Software Development Workshop April 18 th & 20 th, 2006 Microsoft Solution Framework For Agile Software Development Workshop April 18 th & 20 th, 2006

128 Capture Project Vision Write Vision Statement Capture Project Vision Define Personas Plan an Iteration Determine Iteration Length Guide Project Access Progress Create a Scenario Brain Storm Scenario Create a Scenario Prioritize Scenario List Plan an Iteration Estimate a scenario/QoSWrite Scenario Description Create a Scenario Write QoS Requirement Create a QoS Plan an Iteration Divide Scenario to Tasks Refine Personas Capture Project Vision Brain Storm QoS Create a QoS Prioritize QoS Requirement Create a QoS Dev. Lifestyle Snapshot Create a QoS/Scenario Storyboard a scenario Create a Scenario Identify Security Objectives Create a QoS Plan an Iteration Schedule scenario Plan an Iteration Schedule QoS Plan an Iteration Divide QoS to Tasks Create Solution Architect Partition the System Create Solution Architect Determine Interface Create Solution Architect Dev. Threat Model Create Solution Architect Develop Performance Model Create Solution Architect Create Infrastructure Arch. Create Solution Architect Create Architecture Phototype Implement a Dev Task Cost a Dev Task Test a Scenario Define Test Approach Test a Scenario Write Validation Test Test a QoS Write QoS Test Implement a Dev Task Create of Update Unit Test Implement a Dev Task Write Code for Dev Task Fix a Bug Reassign the bug Fix a Bug Decide Bug Fix Strategy Fix a Bug Code the Fix Fix a Bug Create of Update Unit Test Fix a Bug Reproduce the bug Fix a Bug Locate the bug cause Imp Dev Task/Fix Bug Perform Code Analysis Imp Dev Task/Fix Bug Refector Code Imp Dev Task/Fix Bug Code Review Implement a Dev Task Integrate Code Change Imp Dev Task/Fix Bug Perform Unit Test Build a Product Start a build Build a Product Verify a build Build a Product Fix a build Build a Product Accept Build Test a Scenario Verify Fix(s) Test a Scenario/QoS Select & Run a test case Test a Scenario/QoS Conduct Exploratory Test Test a Scenario Open a Bug Test a Scenario Close Bug(s) Release a Product Execute a release plan Release a Product Validate a release Release a Product Create Release Note Release a Product Deploy the product Envision Plan Build Stable Deploy Cont. Guide Project Review Objectives Guide Project Access Progress Guide Project Identify Risk Guide Iteration Monitor Iteration Guide Iteration Mitigate a Risk Guide Iteration Conduct Retrospective Guide Project Triage Bug Iteration Check-In Accepted Build Build Microsoft Solution Framework For Agile Software Development Workshop April 18 th & 20 th, 2006 Microsoft Solution Framework For Agile Software Development Workshop April 18 th & 20 th, 2006


Download ppt "Microsoft Solution Framework for Agile Software Development Workshop April 18 th & 20 th, 2006."

Similar presentations


Ads by Google