对敏捷的一点思考 ---- 敏捷是强调结果的

现在软件工程项目管理流行使用“敏捷”。经历了一些敏捷项目，有了些感想。
现在的项目组强制执行结对编程。我喜欢敏捷因为敏捷是山寨版的CMMI。而山寨代表着先进生产力、代表着具体问题具体分析的思想与实践。

先看看Agile 宣言与原则。你就发现敏捷其实是强调结果的。它用结果督促、指导项目的进行。
但是我觉得敏捷开发忽略了对总体架构或者系统设计的要求与指导。

在最近的几个项目中，都号称用敏捷的模式进行项目管理：每天早上的15分钟会议、结对编程、与用户的直接沟通。但这些手段都不能很好的解决在软件框架的设计问题。因为大多数程序员的经验与水平还不能够为项目建立框架（spring, struts这些现有框架确实解决了很多问题。但是一但项目需要定制自己的框架时，问题就凸显出来。）
如何根据具体的项目特点搭建适合自己业务需求的框架能够敏捷出来么？我个人觉得是不大可能的。因为这要求开发人员在对业务、技术比较了解的情况下进行更深一个层次的抽象。如何抽象？哪些可以抽象？抽象后如何向外提供服务（提供调用接口或IoC）？都是需要有比较专业的思考，同时很多也是经验。
想说的是，敏捷并不能替代全部的传统的软件工程流程，尤其是系统设计这一块。
敏捷是方法论，并不是保证。就如，设计也需要敏捷一样。

虽然我自己对敏捷有了以上负面的感觉，但我依旧喜欢敏捷，因为它思想包括：个体和交互、客户合作。

 

总体架构和系统设计，这是管理能搞定的事情么？

敏捷是不是指跑的更快.
而是指能够更透明的了解自己
像用CT看病再动手术割.
与用号脉喝汤药冶病.

要么很快成功  要么死的更快

来吧，说说看传统的软件工程流程怎么让你这帮菜鸟做出漂亮的系统设计
或者说，任何办法，能让不具备相应经验与水平的程序员突然就能够为项目建立框架了，我很想听听看这个银弹长什么样

 

这个。。。。。 无语了。 >_<

总体架构或者系统设计 真的不是管理能够解决的......

同样无语……

在我看来敏捷和CMMI简直就是“不共戴天”

我觉得敏捷不敏捷的并不重要.
重要的是从生产成本上去考虑.
采用这种方式,是否真的可以节约成本,是否真的可以提高质量.
对于cmmi之类的批评,其实很多时候都没有说到点子上.
cmmi之所以推不动,根本的原因是成本太高,而收益又太小,最后只能是走形式,不了了之.
投入可以,必须看到成果才能投入.

很高兴看到留言。：）

1) 总体架构和系统设计，这是管理能搞定的事情么？
   ===我觉得管理是多方面的、多层次的。如果仅从“管理敏捷流程”的角度讲几乎是搞不定的。系统架构、设计还是需要这方面有经验的人来做。如果从更高层次的管理来看，比如负责组建项目组这样层次的管理，它就有责任选择合适的人做合适的事。

2）能够更透明的了解自己。
   ===是。我很认同。通过每天的会议。我们了解别人，了解项目，也了解同时提醒自己在做什么。

3）传统的软件工程流程怎么让你这帮菜鸟做出漂亮的系统设计。
   ===我知道以前没有OO的时候，飞机上天了。没有敏捷的时候原子弹爆炸了，DOOM游戏诞生了。   不幸让你说中了，我也一直觉得自己是菜鸟，一直在想做出漂亮的设计。：）哈

   任何办法，能让不具备相应经验与水平的程序员突然就能够为项目建立框架了，我很想听听看这个银弹长什么样。
   === 这事肯定不能突然发生。

4） sg552。
   === 山寨在我的概念里是绝对褒义的。它最敏捷。最复合客观现实、实事求是。

5) 总体架构或者系统设计 真的不是管理能够解决的......
  我也常常这么想啊。 ：）

6） 在我看来敏捷和CMMI简直就是“不共戴天”
   ===在某正程度上，它们都讲究“流程”。不同的流程。

7）生产成本上去考虑。cmmi之所以推不动,根本的原因是成本太高,而收益又太小,最后只能是走形式,不了了之.
   ===MOTO的同事给我讲过他经历的cmmi是多么的形式化。什么东西走了形式就都违背了其原始的本意。CMMI有成本。敏捷也是有成本的。觉得还是要看自己的团队的特点，然后找出自己的“管理”方式，这也许才是真正的敏捷。
 

你说，我这儿有帮菜鸟，我就算敏捷了他们也不会做系统设计
我说，那你告诉我，你有啥办法让他们会？
你说，等二年吧

真是好回答