案例讨论：传统项目管理 vs 敏捷项目管理

JOVI_LIFE

感谢分享

张恂

原帖由 susan_huangyong 于 2009-8-25 20:18 发表

我以为是需求中最明确最简单的部分先开始迭代呢，因为这样返工的机率会比较小。

感谢张恂老师耐心的回答，

you're welcome!


需求实现的优先级确实有很多因素需要综合考虑，没有一个固定的答案。

和你想的可能正相反，其实最明确、最简单的一般可以放到后面去做（优先级不太高），反正它们很简单，什么时候做也不容易出错，除非客户明确提出希望早点看到它们。排优先级需要分轻重缓急，最明确、最简单的通常属于轻和缓的部分，不一定是价值最高的部分。

我建议对客户价值最大的（the most valuable）最先做，还有就是技术风险最大的部分（the most risky），比方与架构有关的（architecture-significant），也要尽早做、尽早试验。价值最大、风险最大的通常属于重和急的部分，需要我们用迭代的试探、摸索和反馈来发现关键路径（critical path）。

总体上，敏捷迭代开发是价值驱动、风险驱动的结合。


另外，能否介绍一下你们项目团队的情况？

[ 本帖最后由 张恂 于 2009-8-27 10:49 编辑 ]

susan_huangyong

原帖由 张恂 于 2009-8-27 10:36 发表
另外，能否介绍一下你们项目团队的情况？

项目团队的构成也正是我所苦恼的，个人感觉这也是项目很难成功的主要原因之一。
我们项目团队组成基本如下：
1、发起人sponsor：在我们公司，项目都会在年初时做预算，业务部门会提出实施业务系统的要求来申请预算。申请书是会有项目目标这一内容，但实是太粗了，一般来说只有一句话，似乎更像是目的而不是目标。所有IT项目都会邀请最上层的领导（如副总经理）作为发起人，相当于拿到尚方宝剑，发起人基本不过问项目的进展，只是项目汇报时邮件会抄送给他。
2、PM：项目经理一般由业务部门的部长来担任，基本也只是一个挂名，不过会偶尔关注一下进度情况。
3、key user：由项目经理指派相关业务的部门经理来做为项目管理层用户，而真正参与项目时间最多的是由部门经理指派的项目执行层关键业务人员。在项目需求阶段时，需求获取的对象就是这些关键业务人员。由于层面不同，关键业务人员只会对自己所从事的部分业务非常熟悉。缺少的是对整个业务都精通的人，他可以迅速找出当前状况下最需要改进的点，也能够规划出借助IT系统来改进管理。因此，获得的需求就像一块块的砖头，没人知道也不关心要搭成什么样的房子，关键业务人员认为这个砖头的样子我已经描述清楚了，其他不关我的事。而房子的设计图纸没人能够给出。业务经理就像是一个审核的人，只会对已经设计完成的图纸提出意见，虽然他完全有能力设计这房子。
4、项目联系人：IT部门拿到批准的立项报告，指定一名IT项目管理人员着手准备（看清楚了，只有一名），我们称为IT项目负责人。我就是这个角色。承担部分BA任务，承担QA角色，承担配置管理任务，承担QC任务，碰到项目实施能力弱的乙方团队，还要承担部分SA的任务。自问没这个能力。

看到这些，不知您有何建议？

张恂

原帖由 susan_huangyong 于 2009-8-28 19:59 发表


项目团队的构成也正是我所苦恼的，个人感觉这也是项目很难成功的主要原因之一。我们项目团队组成基本如下：

...

看到这些，不知您有何建议？

我新开了主题：http://www.itpub.net/thread-1210673-1-1.html

qiaodong01sina

敏捷与瀑布，不要把两者对立起来，从项目角度来看，两者没有本质区别，只是在不同情况下对WBS、资源组织方式的不用运用而已。

nirvanv

有点蒙 学习

Williamzhao1979

原帖由 张恂 于 2009-8-19 21:46 发表


客气了

建议你先读 Craig Larman 的 Agile & Iterative Development: A Manager's Guide（原版）。这本书很好，非常综合，可以速成。

谢谢推荐了一本好书，找来读一读，呵呵。

张恂

原帖由 qiaodong01sina 于 2009-9-19 19:05 发表

敏捷与瀑布，不要把两者对立起来，从项目角度来看，两者没有本质区别，只是在不同情况下对WBS、资源组织方式的不用运用而已。

不对，waterfall 与 iterative，两者有着本质的区别。

瀑布反映的是一种线性的、确定的、sequential 的项目观。

IID 反映的是一种非线性的、不确定的、adaptive、evolutionary 的开发方式。

很多人以为迭代里面是套一个小瀑布，这其实是一种误解，高级的迭代是并行或并发的。

过去 40 年的软件工程实践、成千上万的项目数据表明，瀑布式对于大多数的项目来说，是一种糟糕的开发方式，一个导致项目失败的主因。

所以，我们说对于大多数软件项目，尤其那些复杂的，要用迭代取代瀑布，这是一个现代软件工艺的重大变革。

其实大家把 PMBOK 或传统项目管理，与 Scrum 比较一下，就能发现显著区别。PMBOK 中有敏捷的因素，比如 Rolling Wave Planning、Progressive Elaboration，但还不彻底。



[ 本帖最后由 张恂 于 2010-1-12 17:17 编辑 ]

如风入夜

张恂 发表于 2009-8-25 14:37
好家伙，一口气 4 个问题  

我先简单问答一下：

    我使用传统的项目管理管理、实施项目多年，也不排斥敏捷。但觉得楼主似乎对传统的瀑布批判过多。我同样关心第4个问题，我经历过太多的项目由于前期设计考虑不足导致设计反复带来的噩梦了，但这不是敏捷可以解决的问题。敏捷确实可以减缓新产品新业务带来的需求不稳定，变更过多给系统实现带来的噩梦，但也同时带来了新问题，需求掌握片面的时候，不要对设计的前瞻性期望有多高，后续肯定是较多的设计变更，只是在敏捷前期，设计变更的成本会相对小。
    楼主也忽视了详细设计文档的意义，对于一个后续需要不停的更新需求的系统而言，在后续两年、三年、甚至十年后你会发现文档是一个多么美妙的东西。这才是传承。对于一个快速淘汰的产品而已，那可以忽视详细设计文档。

    我觉得，追求的应该是传统和敏捷的一个结合点，还是会有不少项目适合传统的项目管理模式的。

    希望看到大项目采用敏捷，设计上的体会交流。

quhp1978

项目， 管理艺术 靠中国式智慧