微软产品开发管理 张帆微软（中国）Microsoft Solution FrameworkAgendaThe development teamThe development environmentThe development processThe development managementThe development teamThe organization chartThe rolesDev managerOwn implementation of the productOverall design, keep the project on course, monitor the health, coordinate with other functional teamsDev leadsOwn featuresrequirement, design, implementation, coordinate architectural issues with leads of other dev teamDevsOwn implementation of featuresImplement, test and document features, fix bugs, support QA and UEThe virtual teamsThe architecture design teamThe performance teamThe code review teamEtc.The development environmentThe principle A standard environmentEverybody use the same environmentMandatoryProductivityPredictabilityFew exceptionsE.g., source editorThe development toolsSource code management systemCrucial for protecting company assetCrucial for parallel developmentSupport versioning, branching, locking, backup and restoreFacilitate automatic build processIntegrate with other dev toolsThe development toolsSource code management systemThe project repository Put all project related files and docs into the source code management systemSource filesCompiler, linker, libraries, build scriptsInstallation tools and scriptsTesting tools and scriptsProject specs, plans, user docs Appoint owner/admin for the systemThe development toolsIssue tracking systemAll bugs and issues are loggedRequired fieldsTitle, description, change historyOwnerOpen date, update date, close dateOpened by, changed by, fixed by, closed byStatusPrioritySeverityFix by MilestoneThe build number when the bug is foundThe build number when the bug is fixedThe development toolsIssue tracking systemUse common queries for the teamFor the dev manager and dev leadsBug open rates and close ratesBug change ratesBug fix failed countsCost to Fix a BugThe development toolsOther toolsModeling toolDebuggerPerformance analysis toolsCoverage analysis toolsTeam websitesEtc.Demo: Performance Profiling The development processThe principle -A standard processEverybody follows the same procedureMandatoryProductivityPredictabilityNo exceptionsA standard development processDesign specsCoding standardsSource code check-in proceduresBug fixing proceduresContingency proceduresBuild breaksSecurity breathThe development managementThe principle -A risk management approachThe goal: Build to spec on timeThe risk:People: Customers, personnel, organization, skillsProcessMission, budget, cost, schedule, design, build, testTechnologySecurity, dev and test environment, tools, availabilityEnvironmentCompetition, economic, regulation, legalRetired RisksRisk Assessment DocumentTop 103. Plan 5. Control2. Analyze1. IdentifyRiskStatements4. TrackRisk Management ProcessThe ongoing deliverable of this process is a living risk assessment documentResearch, evaluation and prototypingResearch projects during minor releasesMarket trends and advancesCompetitor innovations and directionsEvaluate technologiesCapability, quality, sophisticationEase of useTeam skillsPrototypeIdentify key risksDefine experimentsSimulate end resultSchedulingBalance among resource, feature set and scheduleDefine tasks and estimatesParallel developmentSchedule commitmentSchedule ownershipCredibility/PredictabilityProject ExecutionMeasuring and monitoring progressDaily builds and smoke testsThe heartbeat of your projectCrucial to maintain project consistency, integration, quality and visibilityTracing bugsWeekly bug status reportBug threshold Status meetingsHave a specific purposeInvolve PM, QA, and UE Keep it short and frequentKeep a list of outstanding issuesProject ExecutionMeasuring and monitoring progressManaging by walking around (MBWA)Shows you are involved and care about the projectSome people not comfortable speaking at meetingsRegular one-on-one with team membersSharing informationShare successShare failureProject ExecutionMaking changesChanging CourseGet the facts, but dont overanalyzeInvolves others in the discussionUse external teams to augment dev and testCut features instead of extending scheduleProject ExecutionMaking changesChanging SpeedWhen to increase pressureTo meet milestonesTo recover from a missed dateTo response to external competitive pressureHow to increase pressureDuration be clear how long overtime will lastComfort make overtime enjoyableSpirit team commitmentProgress show the team the progressAppreciation recognize teams effortBeta TestingBenefitsTest in real worldFeedback (features, performance, UI)MarketingAugmenting your stuffBeta Testing ManagementRecruiting beta sitesDistribute softwareCommunicate beta statusResults-orientedReward beta sitesStart early!Get the feedback!Build a good tool to manage informationPostmortemsFormalize the process of learning from past experiencePost-milestone review meetings Capture project learning to develop team members and improve the processBring closure to a projectFundamental to a learning organizationAction items and ownersSummaryBuild a great dev teamCreate a great dev environmentEnforce a good dev processUse a risk-oriented dev management approachQ & A 2002 Microsoft Corporation. All rights reserved. 2002 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.