敏捷开发方法.pdf

敏捷开发方法
一句话评论：复习一下敏捷的12条原则，然后看看，Marty如何理解产品经理在“敏捷团队”里的角色
定位。
Marty Cagan 发表于2009年6月1日，原文地址，译者：蒋彬 / 审校：周舜莉 徐定翔
表了所有产品的需求，在开发过程中不断的说明需求
并帮助决策
-增量开发——频敏小规模发布产品，快速推动产品进入理想状态
-做好规划——工程师只做评估，客户决定每次发布的功能和时间
-持续评审代码——基于结对编程的模式，两位开发者相互评审对方的工作
-持续测试——开发者在编码时就撰写单元测试，客户则撰写用例中规定的功能测试，这些测试均
是自动、持续地进行
-持续构建——持续开发和整合软件，这样能及早发现问题，系统也一直处于可构建的状态
-持续重构——软件开发人员不懈努力，通过重构代码来简化和改进工作，同时保证所有测试正常
运行
-代码共有——与每个开发人员“独享”自己的代码这一模式不同的是，极限编辑模式中每个开发人员
只要认为有机会有必要，就可以优化系统中任意处的任意代码
-开放的工作场所——指整个团队都在一个在房间里共同工作，其中开发人员坐在中间
-每周工作40小时——限制加班以提高工作质量
-代码即文档——最有用的文档就是软件本身，整个团队应该遵循编码规范
当然了，这种方法是从软件开发人员的角度提出来的。在他们看来，除了程序员和用户（客户），
就不需要其他工作人员了。这正是让产品经理感受担忧的地方。
产品经理的工作至少包含以下三个方面。
定义产品
首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的，目的是满足特定客户
的特定需求（比如内部员工薪资系统），它并不适用于通用产品。事实上，在描述极限编程方法的图书和文章里，几乎很少提及产品管理或是界面设计。
最让人担忧的通常产品经理能否代替现场客户的作用。只有在深入研究目标用户、理解用户需求、
使用环境以及竞争格局，产品经理才能发挥最大的作用。
更让人担心的是产品设计（界面设计）角色的缺失。对于产品来说（不同于那些签署合同后开发的
定制软件），用户界面和用户体验至关重要，需要专业设计师运用其专业技能进行设计，因此在工
作流程中引入这一重要职位非常重要。
只要把最初的迭代作为持续演进的原型并不断检验，以确保开发团队能开发出正确的产品，然后再
在接下来的迭代中实施产品执行，就能更好地利用极限编程方 法。关键是确保你开发的产品是客户
想要购买的，而且客户能搞清楚该如何使用。只有一个客户或是产品经理理解这个产品并不足够，
它应该为目标市场的广大群体 所检验。
开发产品
其次要考虑的是，这些用来开发可扩展、高性能、可靠、易维护产品的技术会带来什么样的后果。
这些担忧使人马上陷入一种近乎宗教狂热的争论，争论的重 点是，什么才是开发和测试软件的最佳
方法，而这完全在产品管理职责之外。产品经理只需要清晰地确定需求，然后让技术团队按自己认
为最合适的方式来控制 风险。
极限编程过程依靠客户来定义用例（又被称为用户故事），以此作为功能测试的基础。这用在小型
项目上或许还不错，但如果是大型、通用产品的话，有必要请 专人来负责设