思步网

标题: 大家的WBS都是如何写的？ [打印本页]

作者: w7a8 时间: 2008-4-25 09:09
标题: 大家的WBS都是如何写的？
分了几层，细到什么粒度，是按照两周原则呢还是有不同？里程碑如何设置？

作者: lily_014 时间: 2008-4-25 12:54
通常情况下分三到四层这样一个粒度来分
模块
  子模块
   功能点
模块
子模块
   任务包
      任务项
基本上是每个任务项（功能点）不超过两天（16小时），不过这还是个设想，具体还没执行呢
这也是借鉴敏捷开发里面的。

我也有同样的问题，如果采用迭代的话，里程碑该怎么设呢？

作者: iamredeye 时间: 2008-4-29 17:34
粒度到managable & measurable。具体时间和项目大小特性都有关。

里程碑就是你特别想去measure的点，对迭代和瀑布来说有什么本质上的不同呢

作者: w7a8 时间: 2008-5-4 22:27
每个任务项，即最小工作包，有个2周原则，即80小时原则！
对里程碑而言，无需区分用的是什么life cycle！
同意楼上的，粒度应该视项目具体情况而定，PM觉得能管理能度量就可以了！
文无定法，符合项目实际（考虑各种约束）的才是最好的！

作者: lily_014 时间: 2008-5-6 11:06
呵呵前面我说的那个是实际的情况，之前楼主不是问各个公司是怎么做的？
任务的细分程度当然是视情况而定，前面也说了是借鉴敏捷里面的，因为要做到可视度而且如果要引入每日构建的话，通常是开发人员拿到任务后就不用再去细分了，直接可以coding。
纠正一下每个任务项，即最小工作包，有个2周原则，即80小时原则！
我理解的是，工作包里面含每个任务项，工作包2周原则，而任务项是2天。当然这是理想的状况。如果有误解欢迎大家纠正。。。。

作者: iamredeye 时间: 2008-5-6 11:43
你说的任务项大概是指schedule activity。还是要看项目特性，比如规模，对大的项目2天显然太细，也做不到。计划也是有成本的。对需要特别monitor的成员，2天却是一个好办法。只有一个原则，就是粒度让pm感到安全。

另外WBS是project scope，千万不要又变成了product功能分解

作者: lily_014 时间: 2008-5-6 13:23
对很多时间领导会质疑开发人员的工作量

作者: xixiaojing666 时间: 2008-5-7 16:45
我也很想听听迭代时里程碑的设置？

我们不管多大的项目，最后任务的粒度也会在2-3天，或更小，一般在项目开始的时候粒度会大点，当进入该阶段，进行制定阶段详细计划的时候，粒度就缩小了。

感觉在项目执行的时候，制定计划对项目经理来说很费劲，而且很多计划到最后都不能执行，也就是说计划变化很快！:(

作者: 冰封伯爵 时间: 2008-5-7 21:35
做WBS的分解前提条件是已选择了相应的软件生命周期模型，根据相应的生命周期模型做初步分解，然后在日常工作中逐步细化，没有不变的需求和计划，时时在变，如果跟不上更新的脚步，计划将无任何实施意思。

作者: iamredeye 时间: 2008-5-8 14:00

原帖由 xixiaojing666 于 2008-5-7 16:45 发表
我也很想听听迭代时里程碑的设置？

我们不管多大的项目，最后任务的粒度也会在2-3天，或更小，一般在项目开始的时候粒度会大点，当进入该阶段，进行制定阶段详细计划的时候，粒度就缩小了。

感觉在项目执行的时 ...

项目有大有小。你们不管多大的项目，最后还是2－3天或更小－－这是因为你们不管多大的项目还是很小。

另外你们的项目计划执行成问题也反应了这个计划有问题。可能的原因是：
－粒度太小
－这个计划只是PM一个人拍脑子定的吗？如果是，那就可以理解了。pragmatic？
－没有change mgmt
－没有risk mgmt
－maturity。。。

作者: Scott 时间: 2008-5-8 14:47
还是要看项目特性，比如规模，对大的项目2天显然太细，也做不到。--同意。

WBS的制定方式最好考虑交付件，按照交付件来制定会比较合理，也比较好度量。比如有需求说明书，那就制定
xx功能
需求说明书编制
评审
基线
里程碑

如果是迭代开发，可能就要以迭代为里程碑。
比如
xx需求编制
yy需求编制
评审
迭代里程碑

作者: Scott 时间: 2008-5-8 14:52
粒度要看从哪一层算起，如果是项目经理一层，建议最多3层，一层项目（包含公共任务，比如培训、会议等），二层迭代，三层活动。

作者: tongwds 时间: 2008-7-10 11:02
不过生命周期模型的WBS差别有多大？

比如迭代模型和瀑布模型的WBS相比较
瀑布模型的是按顺序不断更新累计，迭代模型的如何作？

作者: tongwds 时间: 2008-7-10 11:04
目前只接触到瀑布模型的（项目的周期都是瀑布型），不知迭代、增量模型的该如何入手，有这方面经验的请多多指点

作者: 思步 时间: 2008-7-10 11:13
个人感觉，首先要弄清楚一点：这个WBS是用于什么方面、供谁去用、那些角色关注等方面的问题。
1、如果公司高层也非常乐意去关注项目的具体进展，那么，这个WBS最好以“线性”的思维去体现；
2、如果项目管理员（公司级）要关注项目的详细情况，那么，这个WBS最好按“工程活动”、“管理活动”、“支持活动“来分开；
3、如果是该项目的PM，那么，针对与迭代开发与瀑布模型，可以将两者结合起来，可以在迭代模型中套瀑布模型，也可以在瀑布模型中套迭代模型；

这些是我的切身体验，供参考。还有部分内容，容我有时间时再放上来。

作者: lljyujie 时间: 2008-7-14 09:38
谢谢分享呵呵,没有金币了啊!

作者: loosiech 时间: 2009-3-8 15:03
好贴，借鉴一下

作者: worldfame 时间: 2009-3-11 17:17
80小时制

作者: lee_huo 时间: 2012-11-5 18:17
任务分解到2-3天，最好是1-2天就有能够交付的粒度最好。
最好是按迭代交付，2周交付。
节奏固定，2周就是一个里程碑，而这个里程碑对于用户来说是有意义的

作者: step365he 时间: 2012-12-28 17:39
分解的粒度是到工作包层次，特征是要分配给具体责任人，能明确的可测量的交付物。

作者: 大大梦想 时间: 2012-12-28 18:21

step365he 发表于 2012-12-28 17:39
分解的粒度是到工作包层次，特征是要分配给具体责任人，能明确的可测量的交付物。

是这样的。

作者: 三重门。 时间: 2014-5-6 14:25
很有见地的探讨，先收藏着~

作者: 海℡永不湮灭 时间: 2014-6-8 17:32
好帖是需要鼓励的~

作者: 万丈光芒小太阳~ 时间: 2014-8-7 09:33
这么强,支持楼主，佩服

作者: 粑粑 时间: 2014-9-4 12:42
看起来好像不错的样子

作者: 雨落青屿念雁羽 时间: 2014-11-25 12:31
以我的经验来看，楼主的想法是可以执行的~

作者: 橙子女 时间: 2015-6-29 15:56
顶不错支持下

作者: 无边雨丝 时间: 2017-11-22 15:17
好帖是需要鼓励的~

欢迎光临思步网 (http://www.step365.com/)