案例讨论：传统 vs 敏捷

张恂

一个 FAQ：传统和敏捷有何区别？有根本的区别。让我们先来看一个案例。

dearchloe（国内一家交通行业 IT 公司的项目经理）at itpub:

原文请看 http://space.itpub.net/13353915/viewspace-610417

首先说一下这个项目成员。不算其他边边角角的人员，项目组主要有4个人。这4个人里，有三个都是很强势的人。最不强势的人就是项目经理了。为什么项目经理会这样呢？因为他对业务和技术都不懂，而且他自己还很清楚这点，所以他平时就什么都不敢说也不敢管（不过我觉得他也缺乏带项目的经验）。并且，我们3个人都不是全职做这个项目。这个项目涉及的技术我们都没有人用过。

接下来说一下工作安排。由于我是项目开始后加入，所以需求分析我没有参加。然后详细设计，大家讨论，然后每个人分一块来写，项目经理收齐后合并成一份文档，交给领导审批。开发时，再打乱分下来一人开发一个模块。由于，我们部门今年内增加了很多规章制度，要求文档要齐全，格式要标准，并且要经过技术委员会审批。因此当这一切做完，已经到年中了。

然后架构师开始搭开发框架（一边摸索一边搭）。我们开始开发。开发时碰到一些问题：1）对使用的新技术我们都不熟；2）详细设计文档不够详细（文档其实就是为了应付领导），需要不断地询问；3）项目经理不统一项目开发标准和管理项目事项。4）每个人都有其他事情不断地打断开发。

作者分享的这个案例非常好，在国内还是非常典型的。感谢她的实话实说，提供了这么好的一个案例，下面我也实话实说。

从软件工程专业的角度看，这个项目失败的概率非常高，可谓又一个 death march 项目，而且正好可以作为敏捷过程的反面教材。在她的介绍中，我看到的全都是些不利因素、障碍或者风险，我没看到能使它成功（高质按时交付）的有利因素。

我觉得这家公司的问题是比较严重的（希望不是积重难返），这看上去更像是一个人浮于事的官僚机构，而不是一个有竞争力、效率至上的当代软件研发机构，当然更不是学习型组织了。所有人（包括领导、项目经理、“强势”的技术人员在内）都不知道当代软件工程已经取得了哪些进展，历史上有哪些经验教训，他们还在用农耕时代的思维和方法开发当代软件、管理当代项目。只缘身在此山中吧。

造成这些现象的原因可能有很多，我觉得最大的问题首先在于领导的管理能力和意识没有与时俱进，其次是落后的公司/组织管理制度，以及存在严重缺陷的开发过程规范。

您对这个项目有何看法和评价，是否在平时工作中也遇到过类似的情况，敏捷方法又该如何做呢？欢迎参加讨论！

[ 本帖最后由 张恂 于 2009-7-31 10:48 编辑 ]

张恂

下面，我们分析一下这个项目存在的几个明显缺陷和问题：

1）采用错误的瀑布式过程

风险大，效率低，浪费严重。

“这个项目涉及的技术我们都没有人用过”，“对使用的新技术我们都不熟”

需求分析，详细设计，文档审批，实现（一人开发一个模块）

2）用人失误

领导安排的项目经理，对业务和技术都不懂，缺乏带项目的经验，而且不敢说也不敢管。

“项目经理不统一项目开发标准和管理项目事项”

估计这个项目在领导眼里并不重要。

作者提的这些问题非常好，也是我想问的：

领导为什么要指派一个技术和业务都不熟悉，并且缺乏项目管理经验的人做项目经理？

领导为什么要指派给他的成员都是其他项目的项目经理，并且都是强势的？

领导为什么要指派我这种很久已经不写代码的人去写代码？



3）低效的兼职、并行处理

一个人同时参与、负责多个项目，每个人都有其他事情，经常被打断。

项目组的核心成员一共才 4 个人，其中 3 个都不是全职，而这 3 个人里面有 1 个是该项目的项目经理，其余 2 个人是其他项目的项目经理，临时被派过来做程序员、架构师。只有 1 个应届毕业生做全职的程序员。

这个情况也说明，这个项目不重要，领导对它不够重视。

4）沟通问题

5）命令控制（command and control）式管理

6）企业制度文化的问题

以文档为核心，文档驱动。

“我们部门今年内增加了很多规章制度，要求文档要齐全，格式要标准，并且要经过技术委员会审批”

文档重要，还是程序代码重要？文档质量的好坏并不能代表软件本身的实际质量水平。不知道该公司对软件程序本身是否有相应的质量要求？

审批文化，委员会文化。

“然后详细设计 ... 项目经理收齐后合并成一份文档，交给领导审批”

我的疑问是，这里的领导对详细设计的审批有什么实际作用？连项目组成员都对所用的技术很不熟悉，难道领导比项目组的专家更懂？

这里我发现的一个矛盾是，既然这个项目不太重要，为什么还要走这么严格的审批流程呢？难道不是浪费？

“文档其实就是为了应付领导”

dearChloe

你说的都正是我想说的，但我已经不想再批评领导的决策和部门的改革。
事实上，领导对这个项目很重视，重视的方式就是天天问PM能不能按时交付。

张恂

原帖由 dearChloe 于 2009-7-28 15:31 发表
事实上，领导对这个项目很重视，重视的方式就是天天问PM能不能按时交付。

呵呵，你这么一说，出乎我的意料，这位领导的行为很矛盾，整个故事很有戏剧性。

张恂

根据常理，我猜猜看。可能性不止一种。

1. 领导为什么要指派一个技术和业务都不熟悉，并且缺乏项目管理经验的人做项目经理？

他是领导的亲信或者受到领导的亲睐，领导希望提拔、重用他，这次特意找机会让他得到锻炼。当然，也是为了培养干部。


2. 领导为什么要指派给他的成员都是其他项目的项目经理，并且都是强势的？

领导希望你们这些有经验的、强势的项目经理能够辅佐、协助缺乏经验的他获得成功。


3. 领导为什么要指派我这种很久已经不写代码的人去写代码？

领导想考验你，看看你的反应，检验你对他的忠诚度，以及学习新东西的能力。

或者不好的一面，领导有意为难你，给你出难题。

dearChloe

其实，我也不是不能理解领导这样安排的苦衷。 你说的第2点是对的。
其他是有问题的。

但问题， 一两句话是说不清楚的，主要是不够人手用，领导抓到谁就谁做。但就我个人来说，我觉得领导这种做法是错误的，就是因为人手不够，才应该仔细考量怎么分配到各个项目中。

这个项目是我们部门非常典型的一个项目。事实上，大家都不满意，但没有办法。大领导的作风左右了一个部门的风气和工作方式。

ncut_honghan

看了圈子的介绍，发现LZ十分推崇敏捷开发，然而我有几个疑问：
       1 世上没有万能的东西，只有适合和不适合，我不相信只要采用敏捷开发的项目就一定能成功。
       2 敏捷开发非常强调个人的能力，有能力就肯定有个性，那么人与人之间的磨合沟通就很重要，一方面这要求实施敏捷开发的团队一定要有默契，知根知底，惺惺相惜，我相信这是先决条件，然而要组建这样的团队并不容易；另一方面，有能力的人毕竟不多，LZ在工作中一定遇到过偏执于技术，不懂沟通，或者只会夸夸奇谈，却什么都不会做的项目成员。
        3 敏捷开发强调持续提供给客户交付品，然而我们国内的客户往往都不成熟，需求变更非常频繁，那么如果产品架构扩展性不够的话，对项目会造成非常大的影响。
        4 项目经理在敏捷开发过程中对项目的不可控性，或者无法预见结果，对项目要有准确的预测，那么反馈和收集的数据一定要准确，如果敏捷开发都通过代码来反映，总感觉不踏实。
       LZ口中的瀑布开发我认为是对项目流程管理的一种统称，我认为如果好的流程，可以解决或辅助上面提到的问题，当然敏捷开发肯定有自己的优越性，但是要根据项目来决定。
       我对敏捷开发认识还不够，希望跟LZ能有更多的交流。但是对那种明明是无序无章程的开发，却美名其曰为敏捷开发是不能容忍的。

张恂

原帖由 dearChloe 于 2009-7-29 11:24 发表

主要是不够人手用，领导抓到谁就谁做。但就我个人来说，我觉得领导这种做法是错误的，就是因为人手不够，才应该仔细考量怎么分配到各个项目中。

你的看法是对的！

这位领导至少缺乏风险意识。既然这种项目很重要，采用这种抓阄的管理方式就是错误的。没有从项目的风险和重要程度，如何提供最大的客户价值（这是终极目标）来考虑。

这样指派难道就是为了公平？我觉得可能和你们公司的绩效考核制度也有关。

张恂

原帖由 ncut_honghan 于 2009-7-29 12:30 发表
看了圈子的介绍，发现LZ十分推崇敏捷开发，然而我有几个疑问：1 世上没有万能的东西，只有适合和不适合，我不相信只要采用敏捷开发的项目就一定能成功。2 敏捷开发非常强调个人的能力，有能力就肯定有个性，那么人与人之间的磨合沟通就很重要，一方面这要求实施敏捷开发的团队一定要有默契，知根知底，惺惺相惜，我相信这是先决条件，然而要组建这样的团队并不容易；另一方面，有能力的人毕竟不多，LZ在工作中一定遇到过偏执于技术，不懂沟通，或者只会夸夸奇谈，却什么都不会做的项目成员。     
...  我对敏捷开发认识还不够，希望跟LZ能有更多的交流。但是对那种明明是无序无章程的开发，却美名其曰为敏捷开发是不能容忍的。

ncut_honghan，

我也很高兴和你交流，欢迎加入本圈或者访问我个人的网站。

你提的这些观点和问题很好，我已经开了新贴作分析：

http://www.itpub.net/viewthread.php?tid=1197393&extra=page%3D1

[ 本帖最后由 张恂 于 2009-7-30 09:57 编辑 ]

张恂

该案的问题很明显：

由于整个公司都是基于落后的瀑布式的、文档驱动的、道道审批的、机械和僵硬的过程文化，针对高风险的项目错误地采用了瀑布式生命周期模型。

解决方案也很简单：

在公司的软件工程过程规范中，加入现代国际上主流的、更先进的 IID （迭代式）模型，并要求具有高风险和高不确定性的项目采用。

当然，要做到这一点，说容易也不容易。首先要求各级部门领导、大领导意识到存在的错误和缺陷才行。

[ 本帖最后由 张恂 于 2009-7-31 10:39 编辑 ]