1 / 4
文档名称:

关于敏捷开发的26个心得.docx

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

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

分享

预览

关于敏捷开发的26个心得.docx

上传人:文库旗舰店 2019/1/13 文件大小:32 KB

下载得到文件列表

关于敏捷开发的26个心得.docx

文档介绍

文档介绍:关于敏捷开发的26个心得敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。■用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”.对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功。一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定);让这个用例功能完整;让相应的测试用例都能通过;相应的文稳都补齐;只有在当前的用例完全开发完成后,才做为一个整体提交到版本库,才进行下一个用例。■避免提交一个半成品。这一点大家似乎都知道,但这条原则必须列入任何一个开发指导里。能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。如果系统编译失败,那一定是有人抄近道到了。■不要在还没有任何使用案例的情况下设计通用模块。只有在你知道有具体用例的情况下,你才可以实现一个具体的类,而且你在该类中只应该实现当前该用例需要的方法。你也许会想到将来这个类会有其它的用途,你可以用注释的方式记录一下,但不要去实现它,只有在有了具体用例后你才可以实现它。■一定不要在没有使用例的情况下往类里添加成员方法。这跟上面一条极其相似,除了这里针对的是数据成员。开发人员很容易想到:一个‘客户记录’里应该有‘送货地址’的信息,但一定不要在没有任何用例要求这个属性的时候实现这个属性。■不要害怕做决定;不要害怕改变以前的决定。敏捷开发的目的是应对客户需求的不确定。开发前期你不可能获到全部的信息。你应该尽可能的拖延做决定的时间,但一旦到了你该做决定的时候,你应该当机立断,让项目向前推进。你不能说一直等到有了足够的信息才做决定。相反,你要依赖现有的信息作出最正确们决定。之后,当有新的信息出现后,不要害怕对以前的决定作出更改。(老辈人有的称之为触发器,但我称之为随环境而变)■不断的了解如何改进系统。这项工作没有尽头,你应该做好思想准备,持续不断的寻找可以改进的地方,收集各种关于如何找到质量问题、解决质量问题的案例。■审查,审查,审查。敏捷开发可以帮助我们应对需求在将来的不确定,但过去的事情也存在不确定性。测试工作永远不能停下来。程序每次运行的表现都要被评审和记录。■软件的设计要以人为本,而不是系统。很多开发人员退而求其次、以技术为中心,让设计为技术服务。永远不要忘记软件的终极目标是什么,是帮助人们完成工作。■测试是产品的一部分。许多开发人员和经理都认为产品就是你打包给客户的东西,其余的都不重要。其实测试也应该看作是产品的实际一部分,应该在设计时给予相当的重视,甚至,在很多时候,测试功能也应该同产品一起提交给客户。(后面说的这部分很多人都不认可,一个内置的能自我测试软件包并不会占用多少额外的资源,但当你需要用到它时,你会发现它的巨大价值。)■先写测试用例,后写代码。测试用例可以用来精确的说明我们的设计需求。很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。