最近,我与一位开发人员就敏捷软件开发进行了交谈。虽然我理解这个原则,但不断变化的需求似乎创造了项目永远继续下去的潜力。但是,至少在我工作的地方,项目需要完成,因为这是一份合同。
也就是说,第一次迭代可能需要几个月,因为对于某些项目,客户不能使用不完整的应用程序。对于某些项目,我认为您需要首先定义已完成的项目,然后可以将其分解为迭代,并在每次迭代之后细化定义。但你必须始终有这样的定义。
如果敏捷软件开发包括不断变化的需求,你如何知道它的终点?当最终结果总是变化时,您如何为项目进行预算?
敏捷软件开发更多地是关于敏捷过程,而不是敏捷产品吗?
发布于 2011-07-14 19:16:32
从OP的评论来看,他像我一样在一家咨询店工作,在那里我们为我们的客户提供开发服务.我想是因为这种精神状态导致他/她的困惑.因此,我要陈述一个众所周知但从未陈述的事实。
定义的软件开发不兼容。
许多咨询公司声称敏捷,他们在撒谎。他们这么说只是因为敏捷已经达到了Buzz的地位。
敏捷最适合于内部开发,程序员是全职的,很少有人谈论预算。只是时间框架和特征。
发布于 2011-07-14 02:17:18
如果你首先专注于做(你认为是最重要的事情),那么这个项目就会在以下时间结束:
发布于 2011-07-14 05:03:50
当业务决定不再执行任何迭代时,您就会停止。你会希望这是在大量价值被交付之后,但在你进入收益递减的领域之前。
无论在你所处的环境中意味着什么,它都应该由“企业”来驱动。它可以是软件开发车间的高级管理人员,也可以是内部开发环境中的实际业务发起人。他们将决定下一次迭代的成本何时超过下一次迭代中交付的特性的好处。
https://softwareengineering.stackexchange.com/questions/92727
复制相似问题