[微软培训归来.pptVIP

微软培训归来 刘亮亮 2008-01-22 培训内容 培训主要讲述了软件开发过程的一些窍门和经验，包括对项目进度，项目人员，项目成本三个因素的叙述。 本演示文稿主要向你们揭露一些真实的数据，并且传达一些窍门，以促进我们的项目开发效率。 我们需要吸取其中的一些优点，当然一定要根据实际情况进行“本土化”。 花絮 软件失败了 培训上令人震惊的一个数据是成功的软件开发并不是100%，而是34%（2003年），失败的是15%，碰到各种问题的是（51%），而失败的原因更加令人瞠目：“when projects fail, it’s rarely technical”,而原因就是缺乏有效的项目管理，比如： 和需求不符 团队缺乏良好沟通 微软的团队模型 职能叠加 用户体验?产品经理?测试人员 项目经理?发布经理 开发人员 大项目如何划分小组 Lead Team 项目经理，产品经理，开发人员，测试，发布经理 小组1 项目经理，开发人员，测试，用户体验 小组2 项目经理，开发人员，测试，用户体验 注：Vista 有2000个项目经理，office有500个 如何鼓舞士气 明确目标 为项目做一些标志（比如有人喜欢用一些著名的河流，我们也可以用一些植物；比如为项目定一个logo等） 在一起 进行一对一的交流 庆祝成功（项目成功了，是该庆祝一下） 项目管理流程 立项启动流程 计划流程 执行流程 控制流程 收尾流程 三方制约 开始哪个项目？ 启动一个项目主要考虑如下因素： 功能 容易使用 利润 可实现性 成本 最主要的是哪个呢？。。。。。 项目开发计划阶段 需要计划的因素 范围（scope): 风险（Risk):项目中存在风险 成本(Cost) 时间（Schedule) 人力资源(Team Resource) 质量(Quality) 沟通(Communication) 采购(Purchase) 整合(Integration) 范围（Scope)计划 使用“远景陈述(Vision Statement)” 通过”远景陈述“来对功能(features)进行筛选 风险（Risk)计划 分类 人员 过程 技术 环境 风险陈述 风险需要清楚的描述 成本计划 问题 数据库数据太多，造成反应时间太慢 方案1 买一台新服务器，4-8核 方案2 对数据库进行优化，建立索引 方案3 建立两台数据库服务器，一台只读，一台只写，两台同时进行复制 时间计划 采用远景分割（Vision Breakdown) 评审 这是我们经常做的事情 关键路径估算时间 关键路径为？ 人力资源计划 团队关系（Tuckman model) Forming, Storming, Norming, Performing 雇用人员(Hiring) 培训(Training) 鼓舞士气(Motivation and morale) 炒鱿鱼(Removing road blocks) 质量检测计划 首先需要确定一个项目质量标准，比如微软的两个实例： SQM (Software Quality Metric) 网站响应时间0.2s 然后确定需要采取什么样的活动以达到标准，比如良好的编码。 沟通计划 如何进行有效的沟通包括以下部分： 沟通的形式（是开会还是电话还是…） 时间/频率（什么时候，多长时间） 观众 （沟通的对象是哪些人） 所有者 与客户的沟通 Persona 收集用户需求 可用性实验室 Persona 抽象客户 一个可以代表一种类型客户的个体 比如 网管：有点水平，但只是停留在表面 专家或教授：非常有水平的一个人 农业局长：不太懂计算机 这对于搜集用户需求非常有帮助 如何搜集需求 倾听来自客户的心声 观察客户 与客户就需求进行确认 对客户的反馈进行确认，比如SQM 微软的可用性实验室 用户并不能精确描述自己的需求 建立实验室，请用户过来进行实验 140个工程师 20多个实验室 什么是用户需求？ 需要(Needs)和需求(Requirements) 客户的问题隐藏了他/她的需求或难处 ”用户永远是对的” 不要把用户的需求停留在表面（用户显式指定的需求往往是片面的-不论是对于其他用户甚至他/她自己) 不要丢弃没有意义的功能请求，说不定后面还蕴含了没有挖掘出来的需求。 Customer Scenarios 需要在用户手册里面描述用户遇到的问题，然后阐述你的产品如何解决用户所碰到的问题。 采购和整合计划 培训忽略 开发过程管理 状态报告 追踪项目进度 -我们是一周一次报告 Bug管理 -mantis 利用差错状态来预测软件可发行性-没有动作 里程碑的到达标准（Milestone exit criteria)-没有动作 进