敏捷开发方法.pdfVIP

敏捷开发方法 一句话评论：复习一下敏捷的 12条原则，然后看看， Marty 如何理解产品经理在 敏捷团队“ ”里的角色 定位。 Marty Cagan 发表于 2009 年6月 1 日，原文地址，译者：蒋彬 / 审校：周舜莉 徐定翔 许多产品开发机构都尝试过所谓的 敏捷软件开发“ ”方法，其中最为流行的是 极限编程“ ”（XP ），此 外还有其它一些敏捷方法，比如 Crystal 、Adaptive 、Scrum 和Pragmatic Programming 等。 在使用这些敏捷方法时，产品经理常常弄不清自己的角色定位。有些产品经理甚至担心采用敏捷方 法会影响产品质量。 我打算首先总结敏捷开发的核心原则，然后以极限编程（ XP ）为例，指出极限编程的难点，以及如 何更好地发挥它的作用。 敏捷方法一览 各种敏捷方法的要求千差万别，但是它们都遵循以下 12 条原则。 1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户 —— 尽早交付有价值的软件。 2、频繁地交付可运行的软件，数周或者数月交付一次 —— 频繁发布新版本。 3、可运行的软件是衡量进展的主要标准 —— 软件比文档更重要 4 、接受需求变更，即便是在开发最后阶段 —— 倾听，并快速学习 5、项目期间业务人员与开发者共同工作 —— 紧密协作 6、找积极主动的人来开发项目 —— 为他们提供所需的环境和支持，相信他们能做好自己的工作 7、开发团队里最节省时间最有效的信息传递方式是面对面的交流 8、自发组织的团队才能做出最好的架构、和设计 —— 架构要敏捷，好主意无处不在 9、持续关注先进的技术和优秀的设计能促进敏捷性 —— 频繁地重构 10 、敏捷过程促进可持续的开发 —— 此举应能维持相对稳健的节奏 —— 而不是导致失败 11、简洁是一切的基础 —— 少即是多 12 、团队定期反思如何提高效率，并调整工作流程 —— 事后反思 极限编程概览 要阐述遵循敏捷方法到底意味着什么，不妨看看敏捷方法中最为流行的极限编程的详细规范。该方 法的发明者强调，极限编程并非万能，应该有选择性地加以使用。其主要原则如下。 -结对编程 —— 两位程序员使用同一台电脑开发同一款软件 -简单设计 —— 只设计和开发你现在就需要的东西，不考虑将来的潜在需求 -现场客户 —— 客户代表入驻开发团队，他代表了所有产品的需求，在开发过程中不断的说明需求 并帮助决策 -增量开发 —— 频敏小规模发布产品，快速推动产品进入理想状态 -做好规划 —— 工程师只做评估，客户决定每次发布的功能和时间 -持续评审代码 —— 基于结对编程的模式，两位开发者相互评审对方的工作 -持续测试 —— 开发者在编码时就撰写单元测试，客户则撰写用例中规定的功能测试，这些测试均 是自动、持续地进行 -持续构建 —— 持续开发和整合软件，这样能及早发现问题，系统也一直处于可构建的状态 -持续重构 —— 软件开发人员不懈努力，通过重构代码来简化和改进工作，同时保证所有测试正常 运行 -代码共有 —— 与每个开发人员 独享“ ”自己的代码这一模式不同的是，极限编辑模式中每个开发人员 只要认为有机会有必要，就可以优化系统中任意处的任意代码 -开放的工作场所 —— 指整个团队都在一个在房间里共同工作，其中开发人员坐在中间 -每周工作 40 小时 —— 限制加班以提高工作质量 -代码即文档 —— 最有用的文档就是软件本身，整个团队应该遵循编码规范 当然了，这种方法是从软件开发人员的角度提出来的。在他们看来，除了程序员和用户（客户）， 就不需要其他工作人员了。这正是让产品经理感受担忧的地方。 产品经理的工作至少包含以下三个方面。 定义产品 首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的，目的是满足特定客户 的特定需求（比如内部员工薪资系统），它并不适用于通用产品。事实上，在描述极限编程方法的 图书和文章里，几乎很少提及产品管理或是界面设计。 最让人担忧的通常产品经理能否