1 基本信息
1.1 时间：2005－7－12 21：00～23：00
1.2 所在：QQ群：8721636（软件项目经理网上沙龙）
1.3 关键主题
1.3.1 任务分解到何种粒度才是可以可以分配的?
1.3.2 分享你在目前项目中使用的任务分解方法
1.3.3 任务分解技巧头脑风暴
1.3.4 软件项目的任务分解从什么时候开始?
1.4 主持：camer(上半场)；飘荡（下半场）
1.5 参与人(按照进入讨论时间为序)：
1.5.1 camer;digime;槑;lance;老熊;kalevala;飘荡;有意没思;Eric_Yang;秀禾;浪子龙行天下;浪迹天涯;丑牛;风;libber;不想再IT了;黄云笑;知之;A 九头鸟;hk;陈坤;蓝色海贝;只是路过
1.5.2 共有23位朋友参加了讨论
1.5.3 最活跃
1.5.3.1 camer;digime;飘荡;Eric_Yang;丑牛;libber;陈坤;蓝色海贝
2005-07-12 17:48:11
camer
[19241702]
发帖数量:107
Re:9点档：任务分解大讨论
2 任务分解到何种粒度才是可以可以分配的?
2.1 digime
2.1.1 在设计文档中有者明确定义的粒度
2.1.2 任务分解往往是经理们的一厢情愿,往往是分配完就完成自己的任务,跟踪和引导也同时是保证进度和质量的关键部分
2.2 lance
2.2.1 计划是好的．但往往跟踪不到位
2.2.2 分配前的对任务的沟通是首要的！
2.3 camer
2.3.1 对当前里程碑做比较详细的分解；下一个里程碑会比较粗；后面的里程碑基本上是人月这样的估计值而已
2.3.2 对当前里程碑,任务分解到何种粒度是可以分配到个人的？
2.3.3 会不会分解过渡?
2.3.4 一个参考信息:微软认为任务分解到0.5~3人日的任务是最低粒度的工作包
2.3.5 任务精确到工时可能比较理想,工日为单位比较合理
2.3.5.1 飘荡：至少要工作日,太细分,反而会增加成本
2.3.5.2 digime：对的,如果项目比较小或者时间很紧分配到日可能比较合适
2.3.6 对于非当前里程碑的任务,人周\人月单位都可以用
2.3.7 人月\人年一般用于整个项目周期的估计
2.3.8 每个任务的估计都有不同程度的不确定性
2.3.9 如果任务的不确定性超过30%,你会把这个任务分配出去吗?
2.3.9.1 digime：看情况了,一般也会的,主要通过行业经验来推测
2.4 kalevala
2.4.1 每一个阶段即将开始时做详细工作分解，下一阶段暂不分解或仅进行粗略分解
2.4.2 具体的粒度，好象没有一定的标准，关键还是看PM的管理粒度、团队的默契程度
2.4.3 团队默契程度高、均具有一定的项目经验、知道如何配合PM的工作，这个粒度就可以比较粗
2.5 飘荡
2.5.1 和项目团队人员有关
2.5.1.1 digime：有道理,要根据人和环境而定
2.5.1.2 digime：飘荡对这个很有体会啊,一直在强调团队的默契
2.5.2 主要还是和企业的文化有关
2.5.2.1 Eric_Yang：企业文化很重要，没有好的企业文化，再好的方法也执行不了
2.5.3 如果一个团队是磨合很久了的,可能文档的粒度粗一点,也不紧要,因为被分配的任务人员,他能比较详细的知道要完成任务的细节,这时项目经理就不需要操心了,作这样的项目经理最舒服
2.5.4 成熟的开发人员,文档化的标明这个任务还会细分到什么程度,以及预计的时间,这个时候你就比较有把握知道完成的时间了,当然要做好缓冲的时间
2.5.5 不停的跟踪很重要,因为经常产生变更,只有这样才能控制项目
2.5.6 任务分配了,但是很难监控,因为其中的不确定因素多,主要是变更引起的,也有可能是设计不到位引起的
2.5.6.1 camer:在分配以后的变更，更增加了跟踪的难度
2.5.7 所以要不停的跟踪,排除不确定性,以保证效目受控
2.5.8 我们原来都是用经验法,就是这个项目或类似项目做过的人进行评审,以确定进度,及任务分配的合理性
2.6 老熊
2.6.1 有些任务PM有一个主观的估计或是跟团队一起沟通后估计出来的
2.7 有意没思
2.7.1 自己估计工时，细分任务，再反馈给经理
2.7.1.1 lance：这样的分配是不是太被动了？？
2.8 Eric_Yang
2.8.1 我们公司在实际工作中是分到功能点
2.8.1.1 飘荡：分到功能点,也有个粒度的问题
2.8.1.2 飘荡：功能点的统计实际上是离不开项目团队成员的磨合的,磨合很久的项目团队的生产效率是不一样的,这是功能点无法替代的
2.8.1.3 飘荡：你们是怎样在具体的历史数据上进行功能点分析的，有具体的可操作性方法吗？
2.8.1.4 飘荡：你们的功能点分析准确度有多高？
Eric_Yang：如果变更管理及时的话，准确度可达80左右
2.8.1.5 飘荡：经验法主要还是靠人,功能点法却是量化了,的确高
2.8.2 每个公司在开发一个功能点上大致要多少工作可以估计得到
2.8.3 功能点估计的准确度主要来源于实际项目的统计
2.8.4 我们一个功能点大概要0.4个人日
2.8.5 我们公司把申请CMM2的项目工时全部详细统计
2.8.6 然后，平均到每个功能点上，估计出每个FP的工时，以此做标准来定计划工时
2.8.7 做出需求后再定功能点
2.8.8 一个项目中变动是一定存在的，我们会在完成需求变更管理后再统计功能点并修改计划
2.9 丑牛
2.9.1 以前空军的高射炮部队，只有计算很准确（提前量，距离，爆炸时间等）才能发射出去。现在的制导导弹，只要大概对准方向就发出了，不断接近，不断修正轨道
2.9.1.1 camer：就像别人说XP一样"射击...瞄准,瞄准...再瞄准~"
2.9.2 大概分工就可以工作了
2005-07-12 17:48:38
camer
[19241702]
发帖数量:107
Re:9点档：任务分解大讨论
3 分享你在目前项目中使用的任务分解方法
3.1 digime
3.1.1 我在分解之前会先了解我们的同志,看那些人有灵气可以直接授权的,那些人只能干具体的活的,然后在进行具体的任务分解
3.2 飘荡
3.2.1 我一般以用例为单位,分配下去,有时结合页面进行说明和讲解,他们听完后,给我预计个完成日期,,当能他们要细分并写个文档给我,自已安排自已的时间
3.2.1.1 libber：飘荡如何控制不会有报大数的情况？
呵,如果报大数,绩效评估是做什么用的,原来基本上同样的任务,别人只做一天,你花了三天给我做出来
3.2.2 在这份文档的基础上,在进行讨论,以得到更加具体的任务分配进度
3.2.3 这样做的好处个人认为主要是开发人员参与了任务分配,而不是被动接受指令性的安排,他会为了保住自已的承诺,而按计划努力完成,有时还会自动加班
3.2.4 有变更的话还是要调整任务分配的
3.2.5 主要上根据项目的具体情况进行量体制定,可以按大家开会讨论制定,也可以由项目经理指定
3.3 丑牛
3.3.1 我的方法是：定了个大概，开工。然后要勤检查，不要布置了一个月，也不过问一次
3.3.2 检查的有效方法是“每日构建（每夜构建）”。
3.3.3 我最不相信时间计划，看了《人月神话》吗？
3.3.4 各人的方法不同，任务的分解方法差异很大
3.3.5 任务不同，工具不同，设计者的经验、技术水平不同，过程方法不同，任务分解的方法也就不同了。
3.3.6 有人喜欢直接解决问题，有人喜欢间接解决问题。有人喜欢先开发一些工具，然后成批生产，先慢后快
3.3.7 与企业文化,项目团队文化,与用户都相关
3.4 libber
3.4.1 我公司的TEAM比较小，一般是按照项目经理的经验来确定工期的
3.4.2 任务分解原自于需求，对需求的功能模块分解，然后确定各个模块所需要的时间
3.4.3 开会沟通，对需求和设计充分讨论，然后做出计划，恩，这里有个问题，我们说的计划是否是同一个计划？
3.4.4 一个是开发实施的分工，另外一个是项目整体的计划
3.5 camer
3.5.1 我们现在历史数据不多,所以用团队头脑风暴方法做任务估计和任务分配
3.5.2 我会开一个当前里程碑的计划会议...这个会议会比较长,一般要一天左右
3.6 老熊
3.6.1 分配上，还是要规范些，我们是要开发人员一起介入设计中来，来了解需求，等设计和功能说明书都出来后，再分配主体的功能点到每个开发人员。在分配上是按近似功能或近似需求的功能点尽量分到同一个员工手头上，工时和开发人员一起估算。
3.7 Eric_Yang
3.7.1 我们是由做PM任务分配，再开同行评审
3.7.2 先做小计划再合成大计划
3.7.2.1 丑牛：反过来也行？先做大计划，再分解小计划？
3.8 黄云笑
3.8.1 我们一般是先分业务，让业务经理写自己的计划，再合成，关键是把里程碑定义好，时间需求定义好。
3.8.2 计划我们使用project，把任务先罗列，再分析任务需要的时间。每周进行计划调整。
2005-07-12 17:48:58
camer
[19241702]
发帖数量:107
Re:9点档：任务分解大讨论
4 任务分解技巧头脑风暴
4.1 飘荡
4.1.1 我先说一条,让测试人员帮你盯着进度及质量
4.1.1.1 digime：测试应该在需求的时候都接入,而不能到开发完之后才介入，越早越好
4.2 老熊
4.2.1 如果公司里相应的管理部门全的话，进度是很好控制的
4.2.2 得看你们团队的结构是什么样的，项目启动时，团队成员在不包括后续系统构建 的成员，这样可以做到概要设计前面分配
4.2.3 任务分解，跟项目成员组建是分不开的，在需求调研时候和项目构建时成员成分是不一样的，分解细度也不定
4.3 libber
4.3.1 偶提出了这些问题：任务分解，任务由谁定，任务由谁来分解，任务的分解是否需要通过审核，由谁来审核？ 1任务分解需要有团队的参与，和传统的由上而下的方法不同 2任务分解的粒度要适合团队，要让团队成员接受 3任务分解基于需求分析，需求分析越准确，任务的确定度就越大 4任务分解要在变化中变化，如需求变更，干系人的关系变化
4.4 kalevala
4.4.1 任务分解、工作量估算、系统分析与设计，都需要有团队的参与、认可
4.4.2 我是先做分解、再做概要设计的
4.4.3 目前的项目，阶段划分（主要工作）： 1、前期：技术储备/可行性分析、建立功能框架（包含工作/任务分解）、项目可行性分析 2、中期：系统概要设计、系统详细设计（大半） 3、后期：系统详细设计（小半，更细节的部分）、编码、单元测试 4、尾期：系统测试、总测 5、总结：项目总结、组件库整理、文档整理
4.5 不想再IT了
4.5.1 在做概要设计时，就要考虑任务拆分了，最好能早日确定。因为我喜欢做和开发人员一起讨论方案和进度安排，这样在任务变更时，有更多的人来一起承担，比你一个人累死的好
4.5.2 工作分解，从大到小比较合适，就象绘画，先画骨架，再画模型，最后画细节、润色
4.6 知之
4.6.1 系统分析与设计、任务分解都应该有个评审确认的结果
4.7 陈坤
4.7.1 工作分解一定是在概要设计前面
4.7.2 我的工作分解在需求调研的时候就开始做了
4.7.3 用project先把大体计划做出来，以此作为一个基准
4.7.4 工作分解计划也是不断变化的，需要在实施过程中修正计划的
4.7.5 偶们开发一般都采用原型法
4.7.5.1 原型反应是开发小组对需求理解程度 偶们的原型法做出来的原型90％是以后开发产品的样子 具体要细到每个页面，页面的元素的布局
4.7.6 工作分解一定要 PM 和技术负责人一起来做
4.7.7 需求变更也是任务分解调整的一个因素 偶们应对需求变更，说老实话，没有太好的方法 偶们的客户都是强势的客户，他们提出的变更，是肯定要做的 偶们应对的，就是内部评估工作量，然后重新调整任务分解
4.8 蓝色海贝
4.8.1 我们公司一般都是先和客户一起确定需求，然后我们写方案书，他们确定了，我们报价
4.8.2 他们确认了，我们就按方案书来做，他们也会有变更，但要做到第二期第三期。。。需求变更也是按照前面的步骤来
4.8.3 任务分解可能最难应付的是应对变更
4.8.4 最怕的就是他们只是给原型的价格，而要的软件却远远超过需求
4.8.5 有个稳定、好的团队对任务分配、完成、应对变更可能也是很重要的
2005-07-12 17:49:16
camer
[19241702]
发帖数量:107
Re:9点档：任务分解大讨论
5 软件项目的任务分解从什么时候开始?
5.1 蓝色海贝
5.1.1 我觉得应该项目报价确定以后开始
5.1.2 我们一般是等方案出来后，征求不同意见，各个程序组的建议，确定后，分下任务。。。安排人员、时间。。。。
5.2 陈坤
5.2.1 任务分解，偶认为从需求调研完就应该做，也就是一个骨架，以后每个阶段完成，任务分解都需要调整的
5.3 kalevala
5.3.1 我们是在建立功能框架的时候就开始
5.3.2 需求分析完成后，建立功能框架、业务/流程模型，这个时候的工作就开始包含工作/任务分解了
5.4 丑牛
5.4.1 大家讨论的是否界定在编码任务的分解? 6 其他信息
6.1 digime
6.1.1 要求项目经理做完所有详细设计,我认为也不大现实,如果一个项目真的这样做了,他也不一定是一个好的项目经理,首先项目经理要保证的项目正常结束,怎样提高效率,一个重要的方式就是要尽可能的代出更多的小项目经理
6.1.2 比如一个项目下来,如果没有人(合适的),我们一般很少接,除非时间比较宽余
6.2 camer：Eric_Yang给我们分享关于"功能点估计"的体验
6.2.1 Eric_Yang：过几天我把公司的一些不涉及机密的东东拿出来
6.2.2 给Eric_Yang安排个"九点档".....进入计划ing
6.3 丑牛主题：分享做xp项目的体验
6.3.1 丑牛：在XP还没有提出之前，我就是采用XP了。只是俺那时不知道我的方式就是XP
6.3.2 浪子龙行天下：UP是正楷，XP是草书。先学好了UP，才能学好XP；先学XP再学UP就会乱套
6.3.3 Eric_Yang：下次再讨论XP和UP吧
6.4 一个信息,一个成熟的开发员的效率可以高过一个生手10倍
6.5 仓促做计划只能让后面更加忙乱
6.6 digime：我一般是先吧书读薄在把书读厚
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
