公司历次培训的摘要

项目实施敏捷过程的摸底

1. 落实敏捷教练培训和QA检查，帮助项目经理和成员熟悉敏捷流程。

     我希望各位经理，能够跟我讲讲各自项目的具体情况，包括：

1. 为什么我们要实施敏捷（目的）。（不是所有的项目都适合做敏捷开发，更换软件的生命周期模型就能实现管理目标）
2. 目前是否有敏捷实施的流程。
3. 是否确定了敏捷的角色。
4. 是否确定了敏捷过程需要留存的文档和记录。
5. 现在敏捷过程用到了哪些工具。

站会？看板？ Story分割和估算？ Story的优先级决策技术？敏捷信息化管理系统（redmine、禅道）？迭代开发模型？集成构建工具？回顾会议？需求跟踪矩阵？多产品版本管理技术？

各位实施敏捷开发工作的困难，需要的帮助（希望各位经理能够畅所欲言）。

我问各位的目的是想做一份敏捷过程检查表，望大家配合。

二、敏捷配置管理

1. SVN代码库trunk、branches、tags的作用和用法。（10分钟）
2. 产品版本的规划和版本命名规则。（15分钟）
3. 代码分支发布和主干发布的原理和实战应用。（20分钟）
4. 高频集成方式下的版本发布解决方案。（15分钟）

休息5分钟。

1. 敏捷项目的文档目录库。（10分钟）
2. 最小要求的文档集合。（10分钟）
3. 文档版本和产品基线的管理。（10分钟）
4. 讨论。（30分钟）

三、敏捷开发

      传统项目管理是一个重型管理过程，本来蓝图设计是由我们说的甲方完成，然后发包招标，但是现在我们在蓝图设计这个阶段就已经介入了项目，我们实际上在做产品的规划和初步设计，必要情况下还要完成客户管理流程上的咨询服务，最后要出具整体的产品技术解决方案和项目实施管理解决方案。这和传统意义的瀑布开发还是不一样的，因此我们需要尽快掌握敏捷的开发方法推动项目成功。

针对项目组来说，完成敏捷实践的目标如下：

1. 能够使用禅道系统把项目过程的信息和数据管理起来。[基础阶段，必须完成]
2. 掌握必要的管理方法支撑项目的决策与分析。（某些公司敏捷做不起来，缺失的管理技术）[中级阶段，完成部分即可]
3. 掌握数据报表的分析与预测技术。[高级阶段，不必须，可选完成]

       为了加快敏捷管理在项目中的落实，特将工作分成几个主题进行展开，大家可以按照项目管理的需要挑出哪个主题先做分享，然后反馈给我。

1. 敏捷的产品需求开发优先级的规划方法。（2小时）

• 头脑风暴和亲和图为什么让需求越来越乱？
• 干系人需求的产品价值分析技术。
• 你考虑过需求的来源和变更成本吗？
• 百里挑一。净现值和多标准决策分析的应用。
• 去伪存真。干系人需求的优先矩阵排列技术。
• 你敢和客户的需求说“不”吗？

    敏捷冲刺计划的编排要点。（3小时）

1. 有了“禅道”，我们是否可以不要project编排项目进度计划，敏捷的项目管理如何跟传统项目管理进行融合？
2. 为什么计划做的不好，可以把团队做垮？
3. 为什么领导总说我做的项目一直是笔糊涂账？
4. 项目工作情况不明，怎么才能进行进度和成本的估算？
5. 怎么排计划才能提前暴露出项目风险，让我们在早期有时间解决它们。
6. 估算任务完成的诀窍有哪些？
7. 时间有限，我们能完成哪些工作。
8. 要求太高，我们到底能做出什么质量。

    产品发布的要点。（2.5小时）

1. 为什么我们要管理产品的发布，管理好发布能够给我们带来什么？
2. 为什么我们已经开发的够快了，客户还是觉得我们发布的不够快？
3. 为什么产品发布后，没能达到我们预期的效果？
4. 如何进入新版本的产品规划？

   敏捷的研发和测试。（2.5小时）

1. 为什么开发和测试衔接不上，测试人员总是对开发人员的工作提出质疑？
2. 为什么敏捷开发和测试的环境要求非常高？
3. 敏捷开发为什么注重的是产品集成的过程，为什么对接口的要求这么高？
4. 为什么测试过的产品还有很多问题不能发现？

 

四、项目估算

      应部分项目经理的要求，给出一组CMMI4管理标准下（一般做到了CMMI4级才会收集到这种完整的数据）的项目管理工作量配比仅供大家参考。

注：每家公司的事业环境不同，项目管理的工作量分布比例也不相同，请一定结合自己项目的实际情况计划工作比例，或者从历史收集的工作量分布中获取数值。

生命周期模型	项目管理工作量占整个项目工作量的比例	备注
瀑布开发	7%-13%	评审和质量管理有时无专职人员情况下，也要放入项目经理的管理工作中计算
增量开发	8%-15%
迭代开发	8%-17%
敏捷开发	10%-20%

实施类项目经理工作量
项目策划	21%-28%
项目组会议	15%-25%
项目绩效报告	10%-17%
日常沟通	27%-35%
需求管理	8%-18%
风险和问题管理	7%-13%
采购管理	7%-11%
量化项目管理	7%-14%

五、风险管理

      按照上周各项目经理的提出的分享需求，本次的分享会希望各位提供项目案例（可以是自己的项目，也可以是别人的项目），将项目的问题或者风险描述出来（每人限5条），QA会在周四给出管理解决方案供与会各位进行分享，先回复案例的经理优先讲解案例。

大家提出的风险和问题限于以下范围：

1. 社会环境风险：国家政策、新技术发展、自然灾害、国际形势等。
2. 技术风险：技术的复杂性、兼容性、承受性以及与其他项目的相关性等。
3. 费用风险：成本预算准确性、任务要求明确性、进度和技术因素制约、合同类型和报价制约等。
4. 进度风险：项目人员经验、进度因素制约、计划合理性和资源充分性等。
5. 管理风险：领导素质、组织结构、研发人员的素质、各阶段的协调沟通等。

六、需求确认

1.“需求确认”专题（第一次）

1. “需求确认”为什么要分解成用户需求和产品需求两方面进行确认？合并两种确认的风险在哪里？ 【很多项目控制不住需求的根本原因】
2. 为什么一定要做需求确认？【不仅仅是预防客户提出变更，根本目的是为了项目的验收】
3. 什么时间点做需求确认？【10%的项目做砸的原因是确认时机不正确】
4. 需求确认的方式有哪些？【签字的评审报告、邮件等白纸黑字的确认是不是真的有效？你是不是忘记了假设条件和制约因素。】

10分钟讨论。

1. 客户不愿意做确认需求的原因有哪些？【避免项目陷阱】
2. 如何想方设法确认需求？【项目经理和业务专家不能毫无准备的去做需求确认。分而治之，化整为零】
3. 确认工作做到位的标准有哪些？【为什么有了需求基线还是总是改】

七、“需求变更和跟踪”专题（第二次）

A）引起“需求变更”的原因有哪些？

B）“需求变更”影响哪些文档，如何量化需求变更带来的影响，并且如何汇报需求变更。

C）需求跟踪到底要解决什么问题？【控制需求遗漏还是需求变更？】

D）需求跟踪矩阵到底是谁来跟踪？【项目经理还是项目组成员】

E）怎么使用需求跟踪最能解决问题？

八、项目计划编写

本次培训的内容包括：

1. 利用裁剪表确认项目范围，使用project制作WBS。
2. 增加培训和质量控制活动，完善任务计划。成本
3. 考虑项目风险，增加应急储备和管理储备。
4. 安排资源，估算活动历时。
5. 设置紧前活动，安排进度计划。
6. 设置项目的进度和成本基准用于项目监控。

九、项目监控培训

培训的内容包括：

1. 项目监控的层次和要素

2. 设立项目的管理基线

3. 项目周监控方式

4. 撰写有效的周报

5. 日任务监控方式

6. 项目变更的处置

7. 项目的经验总结

十、项目问题管理二期

本次研讨会共制作了5个项目案例（由于单次研讨会的时间有限制）。

5个案例是从过去经手过的失败项目中精心挑选出的，分别是：

1. 需求范围蔓延。
2. 软件产品概念定义不清。
3. 项目工期强制压缩。
4. 确认未贯穿项目周期。
5. 项目治理框架失效。