1 / 4
文档名称:

敏捷开发方法.doc

格式:doc   大小:18KB   页数:4页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

敏捷开发方法.doc

上传人:wz_198614 2017/11/19 文件大小:18 KB

下载得到文件列表

敏捷开发方法.doc

相关文档

文档介绍

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