敏捷开发方法

　　一句话评论：复习一下敏捷的12条原则，然后看看，Marty如何理解产品经理在敏捷团队里的角色定位。
　　MartyCagan发表于2009年6月1日，原文地址，译者：蒋彬审校：周舜莉徐定翔
　　许多产品开发机构都尝试过所谓的敏捷软件开发方法，其中最为流行的是极限编程（XP），此外还有其它一些敏捷方法，比如Crystal、Adaptive、Scrum和PragmaticProgramming等。
　　在使用这些敏捷方法时，产品经理常常弄不清自己的角色定位。有些产品经理甚至担心采用敏捷方法会影响产品质量。
　　我打算首先总结敏捷开发的核心原则，然后以极限编程（XP）为例，指出极限编程的难点，以及如何更好地发挥它的作用。
　　敏捷方法一览
　　各种敏捷方法的要求千差万别，但是它们都遵循以下12条原则。
　　1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户尽早交付有价值的软件。
　　2、频繁地交付可运行的软件，数周或者数月交付一次频繁发布新版本。
　　3、可运行的软件是衡量进展的主要标准软件比文档更重要
　　4、接受需求变更，即便是在开发最后阶段倾听，并快速学习
　　5、项目期间业务人员与开发者共同工作紧密协作
　　6、找积极主动的人来开发项目为他们提供所需的环境和支持，相信他们能做好自己的工作
　　7、开发团队里最节省时间最有效的信息传递方式是面对面的交流
　　8、自发组织的团队才能做出最好的架构、和设计架构要敏捷，好主意无处不在
　　9、持续关注先进的技术和优秀的设计能促进敏捷性频繁地重构
　　10、敏捷过程促进可持续的开发此举应能维持相对稳健的节奏而不是导致失败
　　11、简洁是一切的基础少即是多
　　12、团队定期反思如何提高效率，并调整工作流程事后反思
　　极限编程概览
　　要阐述遵循敏捷方法到底意味着什么，不妨看看敏捷方法中最为流行的极限编程的详细规范。该方法的发明者强调，极限编程并非万能，应该有选择性地加以使用。其主要原则如下。
　　结对编程两位程序员使用同一台电脑开发同一款软件
　　简单设计只设计和开发你现在就需要的东西，不考虑将来的潜在需求
　　现场客户客户代表入驻开发团队，他代表了所有产品的需求，在开发过程中不断的说明需求并帮助决策
　　增量开发频敏小规模发布产品，快速推动产品进入理想状态
　　做好规划工程师只做评估，客户决定每次发布的功能和时间
　　持续评审代码基于结对编程的模式，两位开发者相互评审对方的工作
　　持续测试开发者在编码时就撰写单元测试，客户则撰写用例中规定的功能测试，这些测试均是自动、持续地进行
　　持续构建持续开发和整合软件，这样能及早发现问题，系统也一直处于可构建的状态
　　持续重构软件开发人员不懈努力，通过重构代码来简化和改进工作，同时保证所有测试正常运行
　　代码共有与每个开发人员独享自己的代码这一模式不同的是，极限编辑模式中每个开发人员只要认为有机会有必要，就可以优化系统中任意处的任意代码
　　开放的工作场所指整个团队都在一个在房间里共同工作，其中开发人员坐在中间
　　每周工作40小时限制加班以提高工作质量
　　代码即文档最有用的文档就是软件本身，整个团队应该遵循编码规范
　　当然了，这种方法是从软件开发人员的角度提出来的。在他们看来，除了程序员和用户（客户），就不需要其他工作人员了。这正是让产品经理感受担忧的地方。
　　产品经理的工作至少包含以下三个方面。
　　定义产品
　　首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的，目的是满足特定客户的特定需求（比如内部员工薪资系统），它并不适用于通用产品。事实上，在描述极限编程方法的图书和文章里，几乎很少提及产品管理或是界面设计。
　　最让人担忧的通常产品经理能否代替现场客户的作用。只有在深入研究目标用户、理解用户需求、使用环境以及竞争格局，产品经理才能发挥最大的作用。
　　更让人担心的是产品设计（界面设计）角色的缺失。对于产品来说（不同于那些签署合同后开发的定制软件），用户界面和用户体验至关重要，需要专业设计师运用其专业技能进行设计，因此在工作流程中引入这一重要职位非常重要。
　　只要把最初的迭代作为持续演进的原型并不断检验，以确保开发团队能开发出正确的产品，然后再在接下来的迭代中实施产品执行，就能更好地利用极限编程方法。关键是确保你开发的产品是客户想要购买的，而且客户能搞清楚该如何使用。只有一个客户或是产品经理理解这个产品并不足够，它应该为目标市场的广大群体所检验。
　　开发产品
　　其次要考虑的是，这些用来开发可扩展、高性能、可靠、易维护产品的技术会带来什么样的后果。这些担忧使人马上陷入一种近乎宗教狂热的争论，争论的重点是，什么才是开发和测试软件的最佳方法，而这完全在产品管理职责之外。产品经理只需要清晰地确定需求，然后让技术团队按自己认为最合适的方式来控制风险。
　　极限编程过程依靠客户来定义用例（又被称为用户故事），以此作为功能测试的基础。这用在小型项目上或许还不错，但如果是大型、通用产品的话，有必要请专人来负责设计必要的测试用例，以确保可扩展性、功能、性能、容错性和本地化特性等。这些通常都是QA的职责，极限编程的方法完全也可以借鉴。关键是让开发人员负责单元测试，QA人员负责其它测试（比如系统、集成和功能测试等）。
　　部署产品
　　最后一个为人们所关注的，是产品的发布。人们长期以来一直认为随着时间的推移，做出改变的成本也越来越高，但极限编程挑战了这一看法。换言之，只要遵循极限编程实践，你可以降低开发中系统需要变更带来的影响。这对于定制化软件来说这没错，但对于许多商业软件产品来说，变更带来的影响仍然很大，尤其是对于拥有大量活跃用户群体的互联网服务来说。
　　我曾经探讨过平滑部署的策略，这些方法有助于降低极限编程项目所提倡的频繁发布和更新策略所带来的负面影响。
　　总结