在项目外包公司（如何使用敏捷项目管理方法）

在项目外包公司（如何使用敏捷项目管理方法）

敏捷方法逐渐成软件开发行业的主流，几乎到处都是在讲敏捷，大家为什么喜欢敏捷呢？首先作为高管层，敏捷项目管理提供了两个特别吸引高管层的好处：效率以及更高更快的投资回报率。

效率

• 敏捷开发团队是富有成效的。他们组织自己的工作，专注在开发活动上，受Scrum主管的保护而不被打扰；
• 非生产性活动被最小化。敏捷方法消除没有意义的工作，专注于开发。
• 使用简洁直观的工具来显示已完成的任务、进行中的任务以及接下来的任务，项目的进展情况一目了然。
• 通过持续的测试，及早检测和纠正错误；
• 当开发了足够的功能后，敏捷项目就可以结束。

提升投资回报率的机会

• 软件能够更早交付上市。对产品特性进行分组开发和发布，而不是等到代码被100%全部开发后一次性发布。
• 产品质量更高。开发范围被分解为更小的模块，对其持续进行测试和验证。
• 收益机会加速。相比使用传统方法，产品能被更早地发布。
• 项目能够实现自我创收。在后续持续被开发的过程中，之前发布的软件版本可能已经产生收入。

产品开发和客户，客户喜欢敏捷项目是因为它可以适应不断变化的要求，并产生更高价值的产品。

提升对变更的适应

• 敏捷项目通过对变更高效的应当增加了提升客户满意度和投资回报率的机会；
• 变更通常被顺利地纳入后续的迭代中。
• 由于团队成员和冲刺周期保持不变，所以，项目变更带来的问题比传统方法少。根据优先级，将必要的变更纳入到特性列表，并将列表中较低优先级的事项排后。最终，当未来的投资不能获得足够的价值时，产品负责人将选择结束项目。
• 开发团队优先开发最高价值的任务项，产品负责人控制优先级，因此产品负责人能够确保开发活动与业务优先级的一致性。

更大的价值

• 项目团队更早交付最高优先级的产品特性；
• 项目团队可以更早地交付完成的产品；
• 项目团队可以根据市场变化和客户反馈调整需求。

管理人员喜欢敏捷项目因为它能够提供更高质量的软件，减少时间和精力的浪费，并通过清楚列表中不确定有用的特性来强调产品价值。

更高的质量

• 通过测试后驱动开发、持续集成、客户对于可工作软件的频繁反馈等技术，你可以创造更高质量的产品。

更少产品和过程的浪费

• 准时制的开发。
• 客户干系人的参与
• 对于面对面沟通的偏好
• 建立在开发上的变更
• 对软件可工作性的强调

强调价值

• 更少、更短、更专注的会议；
• 减少形式主义；
• 刚好够的文档；
• 客户和项目团队共同对产品的质量和价值负责

同时敏捷方法也可以确保开发团队在适当的条件下开发出最好的产品。由于种种好处，所以各个公司都在探索或者建立自己的项目团队，但是一个项目的建立往往资金都不会太充足。在项目前期创始人往往让一个外包团队担任自己的技术部。这样做就会存在一个根本的矛盾。项目团队形成了甲方乙方的关系。

甲方永远希望乙方多做点，减少自己后期开发的成本，而乙方相反希望需求少点，尽快结项收回款。这就形成了以各自利益为核心的不可调和的矛盾，也正是这个原因，这种合作关系很少有长时间合作的。这种出发点不同表现在具体事上就是“项目变更”。甲乙双方争论的焦点往往是对某一个功能，甲方说会站在运营的角度说自己现在开发出来的东西不能用或者没有效果，乙方会拿着需求和甲方争执，当初就是这么说的出现了变更就需要另外加钱。

如果是传统的项目管理方法，出现变更乙方就会增加成本，要求增加研发费用，无可厚非。但是站在甲方的角度说，需求是乙方分析的，功能也是乙方给的方案，当时功能没有给我们讲清楚（也许就是借口），现在让你们改都不行了吗？今后也许要改的东西多了，每次都这么斤斤计较还是不要合作了。

敏捷方法是鼓励变更的，那么甲乙双方这种关系可以使用敏捷方法管理项目吗？我认为是可以的。但是需要达成以下共识：

共识1：敏捷方法允许项目需求的增加以及变更，同时项目团队也有权取消低优先级需求的开发。

共识2：产品负责人由甲方人员担任，主要控制产品的优先级，项目负责人有乙方人员担任，主要确保项目团队不受外力干扰。

共识3：开发团队最好和乙方办公地方进行封闭开发。