微软架构师的工作实践.ppt

1、微软软件架构师的修炼之道,黄学东微软移动搜索与广告总架构师,演讲提纲,微软软件架构师的故事微软语言技术架构案例问答,微软软件架构师的故事,何谓架构师？,设计师、画图员、结构设计者与建筑类似，软件系统工程中亦然架构师不是通过学习理论修炼来的架构师胚胎：实干程序员架构师幼苗：掌握了理论，软件团队开发和管理经验软件架构师：机遇努力天赋缺一不可,微软架构师概述,资深的技术专家公司总架构师部门总架构师产品架构师杰出的领导能力影响力技术和知识的深度和广度战略思考的能力,微软架构师的特点,重要却又没有“管人的权力”靠战略视野去影响靠技术能力去协调靠对问题的理解去说服靠经验去“征服”,微软架构师的工作实践,以

2、战略问题为导向，关注战术问题以全局为主导，指导局部实施以经验为参考，注重技术创新以项目启动阶段为重点，贯穿整个产品开发周期以高层次设计为主，参与功能模块的设计以概念设计为核心，统筹实施和部署设计,微软架构师的成长,架构师胚胎：实干程序员架构师幼苗：掌握了理论，软件团队开发和管理经验软件架构师：机遇努力天赋缺一不可工作实践的积累技术的精湛与全面综合能力的训练机遇,架构设计与产品开发,架构设计与产品开发周期密切相关常见的开发周期模式瀑布模式分期渐进模式敏捷模式极限编程模式测试驱动模式,架构设计与产品开发,软件产品开发步骤确定需要解决的问题制定解决问题的方案计划设计解决方案所需要的软件实现（编程+测

3、试）所设计的软件出售或者部署开发的软件产品售后支持,架构设计与产品开发,微软的开发过程高层次的指南各组/项目有自己的理解和执行手段采用混合周期模式总体规划上采用瀑布模式具体实现时采用分期渐进模式周期可以重叠，每个周期内可以有“小周期”,架构设计与产品开发,组织模型产品单位模型（PUM）产品单位单位项目管理经理项目管理组长，组员开发经理开发组长，组员测试经理测试组长，组员,架构设计与产品开发,产品单位模型的利弊适用于比较小的项目组（200人以下）单一的项目主管职业发展的空间有限,架构设计与产品开发,功能组织模型副总裁挂帅项目管理总监部门项目管理经理项目管理组长，组员开发总监开发经理开发组长，组员

4、测试总监测试经理,架构设计与产品开发,“三驾马车”协力，问题直接通到副总裁具体功能没有明确的负责主体力量强大，适合大型复杂项目Windows, Office, SQL Server, Live Search,架构设计与产品开发,架构师的作用与影响决定产品的技术路线/方案决定产品的体系结构指导构件的设计指导界面的设计协调设计方案的冲突,架构师的典型任务,产品早期攻坚技术和创新以提升竟争力了解客户需求以提供最优产品关注业界动向以制定战略战术产品中期大量开会以影响和贯彻执行产品开发攻坚新技术难题调整战略战术产品末期总结学习以提升下一版本的竟争力制定新的战略战术度假或找工作,架构师的“角色”,架构师主

5、控的产品质量跨组协调帮助团队成长领导力以身作则,架构师的“角色”,工作方式不能只考虑编程为经理“预测”未来从长远考虑问题参与和鼓励分享参与面试面试关键人员意见得到重视影响面试的过程,架构师的“角色”,设计与质量,设计思维过程以目标用户为核心基于用户反馈的全部产品使用场景评价过程的度量标准对每一个使用场景，通过“头脑风暴”提出多种方案迭代，原型，测试，迭代,设计与质量,设计思维（续）行为通过“头脑风暴”得到可能的使用场景简述各种想法和方案，不作评价不强调精确和细节创建多种原型通过真实用户来评测想法增强对用户的理解,设计与质量,设计思维（续）心态（mindset）我不是用户第一个主意不一定是最佳的

6、最佳方案可能与现有的思维完全不同如果沉浸与某一个想法，就会产生“隧道型视野”从不同背景的人群中吸取长处做好少数几件事比一般地做许多事更好,设计与质量,设计思维（续）如何避免“隧道视野”借助团队和用户扩大自己的视野启用“头脑风暴”，不要轻易排斥任何主意在确定某一方案前，对其他方案反复探讨从没有被影响的人那里听取看法经常利用真实的用户去检测注意：当选定某一方案后，你就处于“隧道”之中了！,设计与质量,谁决定改进？工程系统组织结构质量标准和度量测试策略功能要素（feature）团队的结构和实践分支机构建造体系（build system）项目管理,设计与质量,如何提高质量明确什么是“完成了”定义度量的

7、指标Checkin系统工程工具编程检评（code review）设计检评（design review）单元测试,团队协作,影响力（无权威或有权威）团队成员会认真对待你的意见让团队成员认为想法是他自己的利用一对一的会议交流想法检评时采用成员喜欢的方式关注长远的结果，不要拘泥于短期的决定设想产品可能受到的最初评价,团队协作,如何展现自己奉行“开门”政策热衷新的想法不作过多的评价善于聆听，乐于学习保密不要热衷于“曝光”不怕被证明“出错”,团队协作,委派（delegate）学会如何激励扶持团队成员“上路”经常查看建立可以印证的体系不要抢占他人的功劳给与成员成长的时间和空间,团队协作,参加新组期望高，知

8、识有限找出关键的影响人承认你不懂了解和改进工程过程细心决策,团队协作,架构设计团队“虚拟”的团队-产品架构设计与要素专家经常开会检评使用场景和需求设计并执行产品的界面，层次，和依赖关系主导质量，可行性和技术更新鼓励委派倡导架构设计“宪章”,绩效思维,成长与发展,保持与团队的关联明了产品程序了解竞争对手的情况掌握未来的技术为团队提供新的信息清除团队的“历史”成为“连接点”,成长与发展,自我成长多看(给自己留点看书的时间)参加技术会议(听众,演讲人)读/写技术“博客”勇于担负领导角色鼓励他人学习新东西,成长与发展,创新分享想法尝试新想法发表文章建立创新“社区”激发兴趣听取反馈发表有意义的创新文章拓

9、展和保持联系,成长与发展,时间管理减少会议时间少开会,开小会只参加必须到场的会:架构设计,一对一坚持围绕会议主题，会后发会议总结减少干扰将日常会议安排在同一天限制email电话等通讯手段不要成为或者依赖“英雄”,成长与发展,架构设计的核心是整合（integration）整合的核心是协同工作（collaboration）协同工作的核心是交流（communication）交流往往占用你整天的时间要做的事总比能做的事多必须确保有时间做“应该做的事”,微软语言技术架构案例,Cloud ServicesSmart devices,The Software Evolution,Human Error Rate,Speech Recognition: Approaching Human Error Rate,Microsoft licensed CMU Sphinx-II,SAPI 1.0,SAPI 4.0,SAPI 5.0,SAPI 6.0,The New Frontier,43,