|
锁定老帖子 主题：Scrum，幸福来得挺突然
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-10-13
刚以项目经理身份经历完一次CMMI的评估，对项目管理中的苦可真是深有感触，以新兵的身份向LZ学习！
|
| 返回顶楼 | |
|
发表时间：2009-10-14
学习，学习！根据实际情况来说，楼主不会仅仅看过这么一个电子书就敢去实施了吧？如果有什么好的学习资料（书啊什么的），烦请分享一下！！！
|
| 返回顶楼 | |
|
发表时间：2009-10-14
zgsheng 写道 初次实施,就见效果,可见楼主本来的团队建设就很成功,团队成员也都积累了不少项目经验,不过,对于项目开发方法论的改变,能一次实施成功,我更坚信这是个各案.而更多的team在实施新的方法论的情况下,会需要时间磨合.
没有哪种方法论是万金油 嗯嗯，同意看法，我也是对新的方法的实施有恐惧感，没法对这种情况下的项目风险进行预测和控制！！ |
| 返回顶楼 | |
|
发表时间：2009-10-14
taochenpfj 写道 学习，学习！根据实际情况来说，楼主不会仅仅看过这么一个电子书就敢去实施了吧？如果有什么好的学习资料（书啊什么的），烦请分享一下！！！
根据实际情况来说，我确实是看了这么个电子书就去实施Scrum了，没有别的什么参考资料。不过如果追究起来的话，在九年软件开发经历中，待过无固定流程的开发项目组，看过别的团队实施XP，亲自参与过CMMI5和较重的瀑布式开发方法所指导的项目，对RUP也有了解（现在的公司流程就采用裁剪过的RUP，不过变味了），我相信这些经历--正面的和反面的--会让我在尝试新的方法时能把握一点分寸，有的放矢。 无论是瀑布，RUP，CMMI，还是XP，SCRUM，这些都是些实践组合而已，打个比方，是一些老中医开的经典方子而已，每个方子都有各自的对症，针对不同的团队模型，项目性质，用错了不但无益反而有害。方子固然重要，组成方子的药更重要，理解这些药的用法，原理和对症是好的管理人员必须具备的素质。粗略的划分，我把这些药分为三类：对项目进度有益的，对项目质量有益的，对团队合作有益的。简要列一下： 对项目进度有益的：
对项目质量有益的：
对团队合作有益的：
这是我的分类而已，每个人可以有自己的分类标准。这里关键的思路是：吸取每种开发方法，开发模型，开发框架中的有益实践，然后根据所在的团队结构，项目类型，存在问题进行对症下药。 大家经常在争论哪种开发方法更好，我觉得，每种方法都藏着智慧在里面，把精华部分拿出来，理解清楚，做头脑清楚的老中医，才是正道。 |
| 返回顶楼 | |
|
发表时间：2009-10-14
看到有人能够利用这本书上学到的知识，来提高交付能力、提升产品质量，真是件很快乐的事情。
这跟楼主的心态应该有很大关系，就像楼主自己所说的：“每个方子都有各自的对症，针对不同的团队模型，项目性质，用错了不但无益反而有害。方子固然重要，组成方子的药更重要，理解这些药的用法，原理和对症是好的管理人员必须具备的素质。” |
| 返回顶楼 | |
|
发表时间：2009-10-15
ohmygodlzl 写道 taochenpfj 写道 学习，学习！根据实际情况来说，楼主不会仅仅看过这么一个电子书就敢去实施了吧？如果有什么好的学习资料（书啊什么的），烦请分享一下！！！
根据实际情况来说，我确实是看了这么个电子书就去实施Scrum了，没有别的什么参考资料。不过如果追究起来的话，在九年软件开发经历中，待过无固定流程的开发项目组，看过别的团队实施XP，亲自参与过CMMI5和较重的瀑布式开发方法所指导的项目，对RUP也有了解（现在的公司流程就采用裁剪过的RUP，不过变味了），我相信这些经历--正面的和反面的--会让我在尝试新的方法时能把握一点分寸，有的放矢。 无论是瀑布，RUP，CMMI，还是XP，SCRUM，这些都是些实践组合而已，打个比方，是一些老中医开的经典方子而已，每个方子都有各自的对症，针对不同的团队模型，项目性质，用错了不但无益反而有害。方子固然重要，组成方子的药更重要，理解这些药的用法，原理和对症是好的管理人员必须具备的素质。粗略的划分，我把这些药分为三类：对项目进度有益的，对项目质量有益的，对团队合作有益的。简要列一下： 对项目进度有益的：
对项目质量有益的：
对团队合作有益的：
这是我的分类而已，每个人可以有自己的分类标准。这里关键的思路是：吸取每种开发方法，开发模型，开发框架中的有益实践，然后根据所在的团队结构，项目类型，存在问题进行对症下药。 大家经常在争论哪种开发方法更好，我觉得，每种方法都藏着智慧在里面，把精华部分拿出来，理解清楚，做头脑清楚的老中医，才是正道。 谢谢楼主的分享！！ 果然不出所料，楼主已经是非常有经验的管理人员了！前面的几位同僚的争吵没必要的，正如兄弟们讨论的很多实施方式不是放之四海而皆准的东西，任何东西都照搬书或者理论就会有项目失败的风险了！我作为一个初入管理的菜鸟劝争吵的同僚共享经验（觉得你们说的都有道理），多点和气，国人别窝里斗了，呵呵！！ 最后还是要感谢一下楼主，我也要多多学习了，总是在摸索将理论，自己的经验结合在一起实现一个成功的项目，然而本身经验不是很足，所以，总是提心吊胆，如履薄冰！！！ |
| 返回顶楼 | |
|
发表时间：2009-10-16
请教楼主：你们在团队协作过程中，是如何达到信息共享，经验共享，尤其是针对团队内部各成员水平参差不齐的状况作出调整的？
|
| 返回顶楼 | |
|
发表时间：2009-10-16
taochenpfj 写道 请教楼主：你们在团队协作过程中，是如何达到信息共享，经验共享，尤其是针对团队内部各成员水平参差不齐的状况作出调整的？
好多个实践跟信息共享有关，比如Sprint会议所有人（包括产品负责人和QA）都参加，需求信息共享；团队成员的座位安排在一起，大家彼此看得见听得到，工作信息共享；任务墙上的任务条可以实现项目进度信息共享... 经验共享也有多种实践，比如code review，设计review，还有我们自己组织的每日技术探讨等，结对编程也是实现经验共享的方法，不过我们还没尝试 |
| 返回顶楼 | |
|
发表时间：2009-10-16
楼主看这个了么？关于“敏捷计划与估计的方法”的讨论
请问你们的velocity是怎么计算的？ |
| 返回顶楼 | |
|
发表时间：2009-10-16
daquan198163 写道 楼主看这个了么？关于“敏捷计划与估计的方法”的讨论
请问你们的velocity是怎么计算的？ 翻了一下你提到的这个讨论，我们的做法基本跟其中Andy提到的做法相同，理想可用人天数是固定的，比如5人*10天=50人天，有效时间利用率我们按照70%来算的，这样一个两周的Sprint实际可用35人天； 任务size的时候采用《硝烟中的Scrum和XP》提到的任务纸牌方法来评估的，按照重要性从高到低排满35个人天； 如果过程中有需求变更，凡是影响到任务size的要考虑拆分某个backlog将不重要的feature延迟或者延迟其他未开始的backlog，除非极特殊情况不加班 |
| 返回顶楼 | |
