项目管理知识

经验

1. 所谓慈不掌兵是有道理的，最近一个很明显的例子：一个迭代的任务本来是这个迭代是可以完成的，因为组长的发言说哪一部分是优先级低的，最终就导致这一部分没有完成，其实如果不说这部分优先级低可能还可以完成。
2. 上层管理者如果无法直接管理到实际的执行者，需要指派小组长/项目经理，这个时候一定要给足项目经理的利益，因为如果这部分人员没有付诸全力，执行者更加是一盘散沙。

wbs（工作分解结构）

任务分解标准

1. 分解后的活动结构清晰，从树根到树叶，一目了然，尽量避免盘根错节；
2. 逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里程碑和监控点，所有活动全部定义清楚，要细化到人、时间和资金投入。

工作包

WBS的最低层次的项目可交付成果称为工作包(Work Package)，具有以下特点：

• 工作包可以分配给另一位项目经理进行计划和执行。
• 工作包可以通过子项目的方式进一步分解为子项目的WBS。
• 工作包可以在制定项目进度计划时，进一步分解为活动。
• 工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(Commitment Package)。

工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。

任务分解原则

1. 将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
2. 每个任务原则上要求分解到不能再细分为止；
3. 日常活动要对应到人、时间和资金投入

任务分解方法

1. 采用树状结构进行分解；
2. 以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论，分解单项工作。

wbs实例

关键路径与里程碑

关键路径
关键路径是项目计划中最长的路线。它决定了项目的总实耗时间。项目经理必须把注意力集中于那些优先等级最高的任务，确保它们准时完成，关键路径上的任何活动的推迟将使整个项目推迟。向关键路径要时间，向非关键路径要资源。所以在进行项目操作的时候确定关键路径并进行有效的管理是至关重要的。

里程碑
在进度时间表上设立一些重要的时间检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进度进行检查和控制。这些重要的时间检查点被称作项目的里程碑

敏捷开发

增量迭代、及时交付
这种模式能最大程度地不偏离客户需求的本质

核心思想
以人为本，适应变化

个体和交互胜过过程和工具
人是软件项目获得成功最为重要的因素
合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要
方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；

可以工作的软件胜过面面俱到的文档
过多的面面俱到的文档往往比过少的文档更糟
软件开发的主要和中心活动是创建可以工作的软件
直到迫切需要并且意义重大时，才进行文档编制
编制的内部文档应尽量短小并且主题突出

客户合作胜过合同谈判
客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
为开发团队和客户的协同工作方式提供指导的合同才是最好的合同

响应变化胜过循环计划
变化是软件开发中存在的现实
计划必须有足够的灵活性与可塑性
短期的迭代的计划比中长期计划更有效

敏捷开发的12个原则
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

即使到了开发的后期，也欢迎改变需求。

经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 。

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个人来构建项目。

在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

不断地关注优秀的技能和好的设计会增强敏捷能力。

简单化是根本（不做过度设计和预测）。

最好的构架、需求和设计出自于自组织的团队。

每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。