软件开发中的敏捷开发适合产品，不太适合项目，因为产品开发的节奏可以控制，而项目会受客户的影响很多。
那么，软件项目开发使用敏捷开发会遇到什么问题呢？
1. 不要把最终目标带入到敏捷开发中
敏捷开发要解决的是如何逐渐准确描述用户需求和逐渐呈现产品，因为在最终产品出来之前，用户也不知道他们要的产品长什么样子。开发者的任何计划都只满足于当前迭代，迭代计划来自于前次迭代反馈做出的调整以及后续任务。反馈调整相当重要，确定好重要性和优先级后要和后续任务放在一起重新评估，后续任务并非在下次迭代中非做不可。
2. 传统开发方法，先确定目标，然后试图硬套敏捷开发
敏捷开发是一套描述过程的方法论，它有自己的适用范围。敏捷开发的精髓是风险控制，而不是必定在计划期限内完成产品，它试图在尽量早期发现问题，从而避免到后期出现重大问题时付出超额成本，这是因为每次迭代只解决几个最重要的问题，这些问题又基本来自于前次迭代的反馈（客户必需参与，这是极其重要的一点），因此基本上可以杜绝方向性错误。因此它最终可能完成产品，指达到了客户满意的最终形态，也可能完成不了，比如客户通过几次迭代了解到自己的思路不足以达到预期，因此中止了开发。
3. 敏捷开发反映的是开发者和客户的交互
对于开发者内部问题，也可以采用敏捷开发，此时技术主管成为客户。对实际客户总是要评估真实的任务周期，若周期太长，则需要划分成为子任务，并加入到任务清单，与其他任务一起评估重要性和优先级。敏捷开发要求开发者和客户保持密切的联系，最好是能和用户一起讨论应用场景并设计测试用例，这些测试用例非常重要，客户可能是不懂技术的人，但和他们讨论测试用例可以对自己的技术实现起到参考作用，同时，测试用例也是迭代目标的组成部分。
4.明确项目客户（确定裁判员）
如果是委托项目（外包），那么客户就是委托人；如果是自研项目，那么客户就是老板，如果老板没有精力，那么需要成立一个客户小组（最好不要项目经理本人担任客户角色，除非你发钱自己搞，否则又当运动员又当裁判员，基本就宣告你这个项目黄了），客户小组可以由产品部的人担任。个人认为软件项目不要把产品包含到开发团队里来，带来混乱的风险太高，他们理论上属于客户不属于实现，开发节奏由敏捷开发来把握，技术主管和核心研发分析产品需求，产生可执行任务。
5.明确软件项目经理
软件项目经理产出的是符合客户需求的软件，因此他还是属于偏输出的这么个定位。但国内一般对其定位比较模糊，上头要你全权负责，内部却权责不明。由于你是一把抓，所以你很容易深入到产品工作中，此时反倒是作为客户的产品不用负责任了，项目一旦失败，你就是冤大头。如果你一定要自己把自己摆在一个更高的位置，有一些理想，也请成立专门的产品组，和程序组分别考核。如何定位项目经理，各个公司也都不一样，国内喜欢一把抓，有权，好调动资源；国外什么样的都有，也有只做协调的，就组织开会、盯进度，不参与决策，主要看公司什么文化和流程。
