Scrum引发的思考

无论是管理、设计、开发、测试，有很多牛逼的理论都是别人弄出来的。

比如：

人文类管理，无政府管理，

XP，Scrum敏捷开发

设计模式，重构

测试驱动，自动化测试，敏捷测试

CMM

 

 

很多公司、部门喜欢看到好的方法论，就照搬来用，

用了之后，又默默抱怨觉得没什么提高和改变。

 

Scrum敏捷开发很火，

所以一下子很多公司尝试敏捷开发，根据敏捷开发模式指定了很多规则。

肯定会有很多人抱怨效率没一点上升， 反而因为制定各种规则导致效率下降很多，觉得提出这种模式的人只会扯淡。

 

还有CMM，这是最多人提及和抱怨的东西了。

很多公司是CMM3，CMM4，根据CMM弄了很多很多过程规范和要求。

我敢保证很多程序员或者搞软件的人，心里都或多或少觉得，CMM中很多东西意义不大，或者是浪费时间，挫伤人的积极性。。

 

 

其实CMM、Scrum，都承认他们是很好的方法论，指导原则。

只是很多人不知道怎么或者什么时候用它。【我也不知道，我只是谈谈我的理解】

 

重点是，我们要知道：

无论是CMM还是Scrum，需要了解他们的背景 、应用环境 、要求、目的、意义

CMM的背景关键词：美国国防部、军事工程

Scrum背景关键词：应对变化、不确定性

 

Scrum敏捷开发方法要求：

重视团队、 重视沟通

要求团队有一个平等的、自管理的环境、氛围，

大家相互熟悉，齐心

每个人都有不错的沟通能力与表达能力、素质也不错

每个人技能、知识、职责都不是单一的

 

按理说，敏捷开发是非常有价值的，就算不完全套用，

在软件开发中也应用借鉴其中的很多方法和原则。

 

但是，为什么：

很多团队，为什么没有发挥出敏捷开发的作用，提高效率呢？

我觉得是因为很多团队、环境没有达到要求

最常见的因素是，没有一个Scrum的团队环境和氛围

 

说白了：

很多好的理论或者方法，都是有其应用场景、应用范围的，

而且对其他方面有一定要求的。

你只有在符合其环境，达到了或者接近它的要求，

这些方法论 才能起到很好的作用。

 

所以，我们在实际工作中，应该：

先充分的去了解自己的项目、自己的团队

了解项目的特点、环境、要求和约束、目标、关键因素、成功条件

了解每个人的能力、性格、潜力等

然后学习别人、借鉴别人，选择适合自己的方法论。

其实，在工作中，

不要简单的就因为公司制度、规范，或者CMM，不思考就去用，就去做

又或者不是很清楚自己为什么做这件事的时候

我们都应该先去了解自己所在的环境，要求，然后了解我们为什么做，我们做的目的是什么、意义何在?

然后决定是否做，或者用其他更有效的方式。

 

比方说，

详细设计文档是否需要，或者必须先做详细设计，才能写代码？

我觉得没有一个正确的答案。

详细设计文档可以没有，

我也觉得，可以先有一个大概逻辑，然后写代码，然后立即完善详细设计。

你必须了解详细设计文档到底是为了什么，它有什么作用，然后项目当下的要求是否允许等。