软件开发周期和IT核心竞争力的个人见解

每天都有人跟我说，敏捷了嘛，敏捷叫我们不要写文档嘛，所以我们不写文档嘛，所以沟通成问题了嘛，都是敏捷闹的嘛
对这种话的标准回答是
敏捷还叫你先写测试再写代码呢，你写测试了没？
别跟我说敏捷叫你如何如何。敏捷叫你做的事你也没做。你只是在找借口偷懒而已。

楼主再麻烦说明一下：
你们搞Scrum之前有project manager吗？如果有，搞了Scrum之后，Project Manager干什么去了。

你们的Scrum Master受过培训吗？

你们是日常都是怎么搞Scrum的？


谢谢

我们不需要纠缠在scrum上面，我只是想说明做项目能够不分优先，孰轻孰重么？
另外，我文章的意思您看懂了么？我强调的是要尽量减少迭代开发的次数，以节约人力物力和时间等成本，和迭代开发本身并无任何冲突。
如果您连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。
另外，从你们反驳的字里行间怎么看出，和文章所指出的立场基本一致？这也叫反驳么？还是众位没有仔细阅读本文？

楼主你说不就是瀑布模型吗？ 大家沿着一条大路，一路高歌猛进，直达目的地。

“瀑布模型”作为一个美好愿望，以及对外行人的忽悠得以长存。
而现实项目中“瀑布模型”已经被粉碎了无数遍。

为什么“瀑布模型”会失败？就是因为大家的脑子对于复杂的现实而言，非常得不好使。如果你们有足够智慧的脑子与无比顺畅的沟通，那么你们就去“瀑布”好了。
如果你们不具备这些条件而要去搞，那就是刻舟求剑。

在我所经历的项目中，3次以上的迭代增量开发都是很平常的。当团队与客户在看到每次增量的结果而感到赞许，进而激发出新的好点子时，怎么会感到没热情呢？

为什么会问你很多细节，那就是因为迭代开发都有严格规则和套路的，并不是随意变化需求就叫做迭代开发。你们为什么会做得如此倦怠，那是因为你们做的根本就不是“迭代开发”。

所以说，一个业内人士去鼓吹“瀑布”，不是有其特殊的目的，就是有待提高。

你举了一个例子，然后我告诉你这个例子的问题，你说这不是实际开发，然后接着说连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。

我已经告诉你那个不是迭代

我下面的话非常可能是错的，但是我只能很遗憾地告诉你，我的心里是这么认为的：
1. 不是众位没有仔细阅读你的本文而是你根本就没看到我们再说什么
2. 我和tuti的看法基本一样，你的方法是要瀑布法。而且据我观察，你们现在可能什么法也没用--这并不是什么坏事，不一定要什么法才能干事情的，有句话说得好，一百个项目一百个法，虽然指的不是你们这种情况。但不能根据你们的现状去推测毫无关系的XP或者UP的优劣、缺陷。

我很负责的说我想说明的不是瀑布法，而是尽量减少迭代次数，因为我在项目中大量使用的也非瀑布开发模式。
另外，瀑布法开发模式里也要求进行多次迭代，再说一遍，迭代并不是随着xp的产生才出现的，迭代是一个很古老的计算机术语了。

根据你最后两段的论述，可以看出是一个十足的教条主义，所以你会顽固的认为我的文章是在鼓吹瀑布开发模式。

就因为我在文章开头漏写了几个字，几位就顽固的认为我在吹捧瀑布开发模式，那现在做以下修改：

抛开软件的开发过程及那些瀑布开发模式，原型开发模式，xp开发模式等等不谈。

这篇文章不是谈开发模式，是谈思路，可以了么？

请教一下，为什么要说“尽量”减少？为什么不直接说就1个迭代，那样不就“最尽量”了吗？

那“尽量”是不是表示有些情况下，一个迭代不行的？

那么在那些情况下应该是几个迭代呢？

楼主你推荐确定迭代时间长度的规则又是什么呢？

如果这些问题太教条了，那么先抱歉一下。只是实际工作如果只有“思路”而没些“教条”，我就不知道该怎么办了。

说实话一看到某些 “支持百万访问量” 的需求我就蛋疼。。。。

各位的回帖很精彩。