敏捷过程实践[经验分享]
参与敏捷过程有一段时间了, 我们享受到很多敏捷的好处, 也遇到了很多的问题.在此将我的经验与大家分享, 希望对实施敏捷过程的同行们有一定的帮助.
文档中有争议的地方, 欢迎大家指出. 谢谢.sdlkfj2 谢谢了！ 这个所谓敏捷过程是不是就是Scrum？这种项目管理模式现在在很多地方都很流行。最最累人的实际上说白了就是“早请示晚汇报”，也就是每天的例会，这很要命的，跟催命地似的。 敏捷过程中包括很多种，Scrum也是其中的一种。 我们使用的是XP（极限编程）。
“催命”似的， 我倒是理解为，像种田一样， 每次只划分一小块，然后做完一小块就回顾一下。 至少有一点可以保证， 不会到整个项目快结束了，然后就疯狂的赶进度，疯狂的压缩测试的是时间。因为敏捷过程中开发和测试几乎示同步的。
（呵呵， 感觉大家对这个话题不是很感兴趣。。。没什么人发言哦。） 嗬嗬，可能这里参与项目管理的人还没有“露峥嵘”。我那天肯定是理解错了，你说的这个敏捷过程应该就是Agile Project Management吧。XP应该就是Extreme Programming。抱歉，我们这里通常对这些新名词直接用英语，不翻译，我只好猜测你的中文所对应的概念，便于我理解。
对于你的经验分享，我觉得挺好的。虽然我自己暂时还没有接触这种项目管理模式，但是知道一些。
你所提到的用户改需求的问题，其实我有个问题：
需求应该在项目开始阶段就基本确定才对。你这里，客户要求该需求的时候，通常你们如何同意的？是否要和用户沟通诸如产品交付时间需要推迟什么的。其实对于这种Agile模式，很多人也有批评。我们这里通常认为对于小项目这种模式应该不错，如果项目大，翻来覆去的改需求，各种成本就上去了。
谢谢分享，并欢迎继续探讨！
回复 #5 evemond 的帖子
需求管理在敏捷项目中是很重要的一块。（至少我个人是这么认为的。）需求在项目开始阶段就有了大的计划，会确定按照这个计划我们会什么时候交付产品，但这个计划不是绝对的，会根据需求的变化而变化。
但是我们给客户更多的空间，我们将整个产品分成很多个user story，（也就是是RUP意义上的user case）。开发人员来评估每个user story的时间是多少，由客户来定哪些先做，哪些后做。（当然开发人员也会对不合理的地方提出意见和建议。）
至于交付期，实际上我们每一次迭代都是一次交付期。比如说确定本次迭代会完成5个user story，（2个星期后发布） 那么完成这部分后，我们就将release. 让客户来接收测试。并确定下一次的release将包含哪些user story。
所需要保证的就是，每次release都是可用的版本。这样客户也可以及早的发现需求交流上的问题， 不至于到开发完毕以后才发现有很多是不符合自己的真正需求的。
如果客户更改了需求，那么开发人员将更改的需求列入新的user story中，估算需求修改所需的时间和经费，让客户自己选择是否修改原先的需求。
说白了就是，给你（客户）做多少东西就收多少钱。
在这其中， 和客户的交流非常的重要 对agile 稍微有一些了解，但是不知道这种过程应用于国内的情形如何，尤其对于中小企业。给人的感觉是，冒着风险在走。毕竟这种过程迭代需要双方都能适应。 ding
支持敏捷开发
但实际上我们还是原型加瀑布 顶!了解以下 sdlkfj5 thanks xiexie
回复 #1 Linda_123 的帖子
很不错啊一直想看看恩sdlkfj2 谢谢 bu mingbai sdlkfj1 3Q楼主 好东东，收下了 好，就是看不了，郁闷了。
