敏捷需求分析

还有就是如何计算成本问题(大概), 钱怎么样算?

PS> 华丽地转页 ^0^

国内大多数项目都是客户告诉你他有一笔xx万的预算，打算做个东西，然后让你出个方案，这个方案肯定要包括主要功能和工期
这种情况是不容你一点点把软件作出来，然后告诉他这就是我的方案的
不知道TW如何应对这种客户，签的又是什么样的合同？

嗯，同感，互联网项目需要更加快的发布速度。这个比较难平衡。项目做了近1年以后，快速发布会变得很难。光发布前的测试就会占用1周的时间。想在1周内发布几乎不可能。

啊哈，钱如果能按照时间算是最理想的。如果不行，就只好估算一个大概工作量了。谈一个scope不确定但是时间人数确定的合同。

写的不错，很有感受。很多理念可以融入到我们的项目管理中。

不过楼主所说的很多东西和我们实际项目操作中有些差别。

1、项目需求的不明确，导致后面很多东西无法确认，比如开发的时间，测试的时间。我们做项目时需要申请资源，包括测试人员、demo设计人员，开发人员等，这些人员不光是我们项目的参与人员，也是其他项目的参与人员，我们在项目开始的时候需要向他们的经理申请他们的资源。所以我们尽量在前期把需求确认的充分些，幸好我们是有一批专职的人员来收集需求，提炼需求，类似于产品经理的角色。我比较认同这句话：“需求分析过程是分散到整个开发的过程中”，实际操作中也是这样的，有些需求只有到了真正做的时候才能发现问题。


我想，还是一句话，适合的就是最好，别人的优点可以借鉴。

真是精彩文章，思路清晰描述到位。不过我特别对用户故事的构建感兴趣。
XP的书本上说得很多，但实践中应该有很多“想不到”。
是否能举几个例子，说说最佳实践，说说“想不到”的地方。

正常逻辑来说，敏捷开发，对基于项目的好像是很自然的事情，不知道大家对于开发一个可扩展的产品级别，有什么好意见没有。
我的感觉，做产品和做项目在好多地方的定位都是有根本差别的

敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不同的难度和风险，[b]并提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论[/b]。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选，客户可以选择这些用户故事，或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。

这里有两个疑问，请实践过敏捷的帮忙解惑：
1、“开发人员提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论”，BA和客户进一步讨论沟通后的结果是不是需要以类似需求文档的形式写下来？不可能还是以用户故事的形式书写吧？

2、某一次迭代涉及的多个用户故事要实现的功能，也许需要以某种关系进行协作以完成功能，类似于高层的设计，由谁来完成？总不能程序员挑选完用户故事后，自行协商各个类之间消息接口吧？敏捷设计是如何进行，一直是我实践中比较大的困惑。

另外还有一个疑问是QA测试的依据是什么,用户故事还是其他？仅靠用户故事足够完成验收测试吗

弱弱地问一下：敏捷开发是否可以看成是原型法的迭代过程？