在一个一心向着CMMI前进的公司中,如何利用敏捷来提高开发的效率啊?

公司推RUP,用的是rational全套 为的是过CMMI
可是实际情况是 由于对RUP推行的并不是很好 而且员工对RUP的理解认识也不够
导致的项目进度受阻,RUP成了为 RUP而RUP,开发 设计 需求 QA 测试 一切的一切都没有在统一的过程下进行.
而且开发的实际模式近似于传统模式:来个需求,领导把需求规划成若干模块 把各个模块的开发任务分给各个组,各个组的组长带头去干.
各种文档 uml图都是后补的,是先有设计的思想,有了思想大家就讨论,讨论后就动手写代码
当然在这过程中也会写些文档来纪录一些想法和事情,但那种文档的作用几乎就是备忘,根本不是严谨正式的文档.

于是,想寻求一种快速而又不失规范的开发方法与模式.自然敏捷是首选.

可是公司一心向着CMMI,坚决排斥初RUP之外的一切.怎么办呢?
该怎么将敏捷和RUP结合起来呢?

评论

23 楼 basicbest 2007-03-05  

只要有语言存在，就会有歧义存在。当我再回头看上面的内容的时候，我发现我没有办法彻底说明产品和功能的某些关系。
但是无论如何这个结论应该是相同的，就是在实际当中，“品牌”“产品”“功能”都是重要的。

22 楼 ozzzzzz 2007-03-03  

basicbest 写道

ozzzzzz 写道

basicbest 写道

呵呵，既然o6z提到，我就开始翻以前的帖子。

有个不同观点。作为我是用户而言，我还是关心谁提供的产品的。这个就是所谓的“品牌”的作用。

你又提到了一个很关键的问题，所谓的“品牌”。实际上类似“品牌”的很多东西，都是产品的各个部分。其实客户购买的是产品，而不是产品的功能。体会其中的区别。

你又把东西分裂了，别忘了，分析完之后要合起来。
说品牌是产品的“部分”，这个是以单独的产品为研究对象做出的结论，但是任何一件产品对品牌都没有决定性的影响，而是产品的集合对品牌有影响。你先给定了一个结论的范围，然后绕了一个圈子证明一个结论，那么这个结论始终逃不出给定的结论的范围。

还有，先不考虑品牌问题，客户购买的是产品的功能而不是产品。另外，心理满足也算作功能。

这个东西我就不仔细讲了，毕竟是质量学上的东西，而不是同软件开发的关系不大，我就只说相关的部分。
为什么说客户购买的是产品，而不是产品的功能。当然客户需要的满足是需要依靠功能，于是他们试图去购买具有此功能的某些产品。但是这些产品并非只具有他们需要的功能，其次也并非所有时候这些产品所具有的功能能完全满足他们的需求。同时从另外一个方面看，客户想要的和他们需要的还是有所不同。这些是同我们软件开发的需求工程相关的部分。
另外一个方面，质量的理论概念是对于需求的满足程度。但是在实际上来说，产品不被使用就无法说明其理论质量。因此上现实中我们说的质量，是基于对客户需要的判断建立的一个产品指标系统的满足程度。这里其实也就是造成人们对于质量概念容易混淆的根本点。当然不管如何，质量依旧是一个产品相关的概念，而不是一个活动相关概念。

确实我的讨论经常有些跳跃性的论述，那是因为我相信在共同的概念基础上，推导出的结论是统一的，我没有必要展现一个完成的推理过程，毕竟这里我不是做学术论文。我只需要展示我推理的主要要素就可以了，我相信大家的智商可以完成这个推理过程。

21 楼 basicbest 2007-03-02  

ozzzzzz 写道

basicbest 写道

呵呵，既然o6z提到，我就开始翻以前的帖子。

有个不同观点。作为我是用户而言，我还是关心谁提供的产品的。这个就是所谓的“品牌”的作用。

你又提到了一个很关键的问题，所谓的“品牌”。实际上类似“品牌”的很多东西，都是产品的各个部分。其实客户购买的是产品，而不是产品的功能。体会其中的区别。

你又把东西分裂了，别忘了，分析完之后要合起来。
说品牌是产品的“部分”，这个是以单独的产品为研究对象做出的结论，但是任何一件产品对品牌都没有决定性的影响，而是产品的集合对品牌有影响。你先给定了一个结论的范围，然后绕了一个圈子证明一个结论，那么这个结论始终逃不出给定的结论的范围。

还有，先不考虑品牌问题，客户购买的是产品的功能而不是产品。另外，心理满足也算作功能。

20 楼 ozzzzzz 2007-03-02  

basicbest 写道

呵呵，既然o6z提到，我就开始翻以前的帖子。

有个不同观点。作为我是用户而言，我还是关心谁提供的产品的。这个就是所谓的“品牌”的作用。

你又提到了一个很关键的问题，所谓的“品牌”。实际上类似“品牌”的很多东西，都是产品的各个部分。其实客户购买的是产品，而不是产品的功能。体会其中的区别。

19 楼 basicbest 2007-03-02  

呵呵，既然o6z提到，我就开始翻以前的帖子。

有个不同观点。作为我是用户而言，我还是关心谁提供的产品的。这个就是所谓的“品牌”的作用。

18 楼 basicbest 2007-03-02  

ozzzzzz 写道

cmmi和iso原则上讲都是质量无关的，这一点在本论坛的我前面的讨论中已经充分予以证明了。
另外RUP根本就不是什么思想，而是一种商业化的软件过程方法框架。

说明一下，这里的ISO特指ISO9000 family.其他的ISO标准不一定和Quality直接相关。
和质量无关这一点不是很认同.ISO和他们都是试图通过建立一定的规则来保证及提高质量。这个质量其实是一个组织的质量而不仅是简单的产品的质量。当然，只是试图，它们既不是充分条件也不是必要条件。但这不影响他们的相关性。
http://en.wikipedia.org/wiki/Quality

17 楼 ozzzzzz 2007-03-02  

cmmi和iso原则上讲都是质量无关的，这一点在本论坛的我前面的讨论中已经充分予以证明了。
另外RUP根本就不是什么思想，而是一种商业化的软件过程方法框架。

16 楼 basicbest 2007-03-02  

CMMI主要目的还是控制质量的。
如果之前有做过ISO，可以在ISO的基础上做。

无论是敏捷还是RUP都是一种思想而已，RUP本身并不会降低什么效率，敏捷不一定会提高效率，都有自己适合或者不适合的地方。
参考一下：
http://en.wikipedia.org/wiki/Software_development_process
http://en.wikipedia.org/wiki/CMMI
wikipedia上的描述相对都比较中立些

15 楼 fins 2007-03-01  

ozzzzzz 最近正在读你以前的帖子　收获很大　感觉你真的是很资深啊　
你到底是做什么的呢？你不会就是评估CMMI的吧　　呵呵

谢谢你了　我其实还是对技术感兴趣些
最近开始关注这些东西　只是因为我觉得公司弄的这些东西影响我钻研技术了　所以想看看他们成天在搞什么　呵呵

14 楼 ozzzzzz 2007-03-01  

简单说一下，up的核心还是迭代，而如果要迭代你可以测算一下，在CMMI体系下的文档规模，和各种评审的规模。
另外统一的SCM，是要求你们必须在一个完整的SCM环境下，进行各种活动。所有的行动都必须依赖于某些文件的支持，而所有的改动都也要以某些文件来做凭证。在这样的情况下，管理者每天的工作，你可以测算一下会提高多少，市场人员每天会新增加多少工作。至于技术人员的和QA们的工作量会大多少，你就不用考虑了。
说RUP能够支持你通往CMMI，不过是IBM的宣传罢了。你们要过CMMI唯一现实的路子就是找一个好的评估团队，按照他们的要求做每一件事情。至于具体你们的成本和经营，CMMI才不管你们。

13 楼 fins 2007-03-01  

我越来越糊涂了

推UP,要先推行统一的SCM,而推行统一的SCM的话CMMI也就快泡汤了
那推UP不就无法帮助我们实现CMMI了吗?

那公司怎么还要RUP啊

大家见笑了 我对UP CMMI这些东西实在了解太少了 :'(

12 楼 ozzzzzz 2007-02-28  

UP和QA人员的关系其上不大，特别是RUP同QA的关系更小。推行RUP的关键在于使用构建的方式进行迭代开发，应用USECASE来跟踪需求和进度，强制性的统一的SCM。作为一个大公司，首先应该推行统一的SCM，并且应该是全方位的，而不仅仅是技术上的，而应该是管理和业务也包括在内的广义的SCM。并且这个SCM必须是建立在支持迭代，而不是阻碍迭代的基础上的。而要做的这样，估计你们的CMMI也就快泡汤了。

11 楼 刑天战士 2007-02-28  

lz是东软的？你不大可能在公司内部推行XP的，不知道你在沈阳还是大连，反正大连的外包那一块，是与敏捷精神相违背的。再加上现在总在争取CMMI，所以估计可能性不大。

10 楼 basicbest 2007-02-28  

乱世出英雄，兄弟，机会呀！

9 楼 fins 2007-02-28  

其实我们属于比较糟糕的那种情况
就是上层领导要求UP 但是下层 从QA到开发人员 到测试人员
没有那个能真正明白的

我们那些QA也许明白 但是他们讲不明白 或者是其他人员太愚笨 听不明白
总之 现在是一塌糊涂啊

8 楼 ozzzzzz 2007-02-27  

那么你们就坚持实施RUP好了。但是首先你们要彻底的理解和贯彻RUP的精神和核心实践。具体的可以看我在这里的一些关于RUP的论述。
其实如果你们能够实施up，那么距离agile就不遥远了。

7 楼 basicbest 2007-02-27  

敏捷是思想，你可以以RUP为名，行敏捷之实哇。:)

而且，RUP和敏捷在我看来没啥不同。嘿嘿。

6 楼 yangzheng 2007-02-27  

fins 写道

而且开发的实际模式近似于传统模式:来个需求,领导把需求规划成若干模块 把各个模块的开发任务分给各个组,各个组的组长带头去干.

我不觉得这个过程是与敏捷有矛盾，敏捷应该关注的是细节，来了需求，我们怎么进行敏捷需求分析，如果根据用户故事，确定其商业价值和优先级，对于各个模块开发，如何实施敏捷开发的方法，根据情况采用诸如迭代，结对等方式。

fins 写道

各种文档 uml图都是后补的,是先有设计的思想,有了思想大家就讨论,讨论后就动手写代码
当然在这过程中也会写些文档来纪录一些想法和事情,但那种文档的作用几乎就是备忘,根本不是严谨正式的文档.

uml图重要吗？所有的项目都需要uml图吗？需要全部的uml图吗？还是根据情况，画出必要的uml图。
文档重要吗？所有的文档都是必须的吗？文档要达到什么程度才是严谨正式的呢？这些都是我们要根据实际情况要做的，敏捷给了我们最重要的是思想和原则。我们要学会根据具体情况裁减。

有兴趣的话可以看看我的一篇文章。
http://blog.csdn.net/yzhz/archive/2007/01/15/1483651.aspx
这是我的项目中采用的开发流程，文章的字面上虽然没有敏捷的字眼，但我觉得在具体的实施中敏捷是融入每个具体的过程中。

5 楼 david4liu 2007-02-27  

引用

开发的实际模式近似于传统模式:来个需求,领导把需求规划成若干模块

领导对RUP的认识不深，这样推行很难哟，另外就是人员责任划分、任务安排、进度安排听来都存在一定的问题。不过你们是为了过CMMI才上RUP，所以呢个人认为这种情况太正常不过了，这是因你们本次的目标而决定了的，要改变起来难度很大，所以建议不要老是想理论上的RUP，围绕你们本次的目标实施RUP，个人认为才是可取，纯个人言论。

4 楼 dengyin2000 2007-02-26  

fins 写道

问题就是如何小范围敏捷呢？

找几个同一个team的兄弟实施，农村包围城市。。 哈哈