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

日 本回来的一同事说给南梦宫写过游戏
问写的是哪个.....他说...不知道.
写代码的人成为了一个文档-代码生成机器
写文档的人成为了故事-文档生成机器
写故事的人成为了人物-故事生成机器
人物设计师成为了产品目标-性格生成机器.

你会发现很多种类的日本游戏中的人的总数是差不多的.
这一切由策划+监制决定的.
这个游戏的灵魂就是这两个人.
其它的要不要牛人都差不多.
画画的不好到上海北京找个外包每祯手描
故事不好就多找几个写手大量的写挑出好的用.
技术不行?什么不行.
都是if一点反射没有一样写出牛X的东西.

唯一的不足就是时间长.人力虚耗太大.....

唯一不足的就是东西没人要。

回楼主：
1. 敏捷是强调结果的
难道CMMI不是强调结果的吗？CMMI虽然号称关注流程，但是如果流程不是为了结果，整那么多流程干嘛。从这一点上来说，敏捷强调结果是没错的，但是如果只看到这一点未免管中窥豹。
2. 在最近的几个项目中，都号称用敏捷的模式进行项目管理
估计你们是自上而下的推行敏捷，不要着急一口吃成胖子。先看看当前流程哪些地方不合理，哪些地方存在坏味道，再用敏捷的实践予以改进。
举个例子，你说当前程序员的水平不足以给项目建立框架（gigix其实已经回答了）──这就是你们每日站立会议可以提出的问题啊──可以拉个牛人过来；或者拉不到，项目开始前花一定时间对技术难点进行spike。

说白了 就是

生产力 与 复杂度 的协调控制

敏捷是针对团队中都是高手的情况而言的，如果是团队中的人员结构参差不齐，敏捷真的是搞垮团队。

所以敏捷需要所有团队成员都是人精一级 至少是比较聪明的一类
并且是擅长沟通 非常熟悉自己使用的技术的(就算不熟悉 也能够在短期内 从原理上 技术哲学上 快速学习并熟悉)
然后 接着 一堆敏捷宣言 。。

我觉得不是这么简单的

别人JIT式的编程和面向信息流的架构还没说呢

敏捷不是包治百病。

小团队  小项目  高风险  需求变化频繁  。。。

几个噩梦般的经验后,我深深感觉到
实际项目上完全敏捷是危险的.不敏捷时间是不够的.
一个团队里面总会有几个菜鸟几个老鸟.老鸟一开始飞,菜鸟根本跟不上.到头来老鸟还是要回头和菜鸟一起慢慢爬.你还要小心有些菜鸟你一不注意的就把整个系统玩废了.
提供一个好点的做法.想系统设计阶段就不要搞什么敏捷了.要敏捷也不要太多人参与几个老鸟搞就好了.等把系统设计过了,大的框架搭好了,再把菜鸟们放进去.

看完LZ的帖子,个人不大同意LZ的看法,不知道LZ对重构有怎么的理解,个人觉得敏捷之所以不在早期项目设计上关注的太多,是因为敏捷提倡无时无刻,无处不在的对代码进行重构,如果在早期项目设计就已经规定了框框架架,那么如何应对以后可能发生的各种各样的需求变化呢.设计或者说框架是在代码的不断重构中完成的,而且也不应该是一成不变的.当然一些必要的大的整体上的架构还是可以在前期做好的.仁都见仁,智者见智,欢迎拍砖...