用户名 密码 联盟服务 关于我们 联系方式 收藏本站
返回网站首页 PgMP认证,美国项目管理协会高端项目管理认证!大型项目与项目群管理Program Management全球权威认证


网站登录:会员 企业 专家 服务商
企业服务:PMP培训  内训课 公开课
工 具 箱:发表文章 提问题 发案例
首页动态 | 文库 | 下载 | 书架 | 访谈 | 专栏 | 专题 | 人才 | 培训 | 软件 | PMC 互动:活动 | 案例 | 问答 | 论坛 | 博客 | 圈子 
应用:基础工程软件制造活动研发  认证:PMPNPDPACPPgMPIPMPP2ISPMPIMCP建造师MPM  特色:热点奖项

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

10月开课 | 实战课

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

4月开课 | 新闻

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

北京 | 上海 | 感受

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 杭州 | 网络

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

深圳 | 北京 | 上海

PfMP®认证

链接战略与项目
实现组织资源投资回报

2019年首期班 上海

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

敏捷项目管理ACP认证培训
国际产品经理NPDP认证

敏捷软件开发团队的26条核心原则

作者:佚名   提交人:项目管理者联盟[项目管理者联盟]   属性:提交人转载   发布时间:2019/9/27   点击:443   【收藏本文

  我收集各式各样的至理名言。最近我一直在研究敏捷软件开发;有收获吗?下面就是能够指导敏捷软件开发团队的26条核心原则。项目管理者联盟

  1、用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功。一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定);让这个用例功能完整;让相应的测试用例都能通过;相应的文稳都补齐;只有在当前的用例完全开发完成后,才做为一个整体提交到版本库,才进行下一个用例。项目管理者联盟

  2、避免提交一个半成品。这一点大家似乎都知道,但这条原则必须列入任何一个开发指导里。能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。如果系统编译失败,那一定是有人抄近道到了。项目管理论坛

  3、不要在还没有任何使用案例的情况下设计通用模块。只有在你知道有具体用例的情况下,你才可以实现一个具体的类,而且你在该类中只应该实现当前该用例需要的方法。你也许会想到将来这个类会有其它的用途,你可以用注释的方式记录一下,但不要去实现它,只有在有了具体用例后你才可以实现它。项目管理者联盟

  4、一定不要在没有使用例的情况下往类里添加成员方法。这跟上面一条极其相似,除了这里针对的是数据成员。开发人员很容易想到:一个‘客户记录’里应该有‘送货地址’的信息,但一定不要在没有任何用例要求这个属性的时候实现这个属性。项目管理者联盟

  5、不要害怕做决定;不要害怕改变以前的决定。敏捷开发的目的是应对客户需求的不确定。开发前期你不可能获到全部的信息。你应该尽可能的拖延做决定的时间,但一旦到了你该做决定的时候,你应该当机立断,让项目向前推进。你不能说一直等到有了足够的信息才做决定。相反,你要依赖现有的信息作出最正确们决定。之后,当有新的信息出现后,不要害怕对以前的决定作出更改。(老辈人有的称之为触发器,但我称之为随环境而变)项目经理圈子

  6、不断的了解如何改进系统。这项工作没有尽头,你应该做好思想准备,持续不断的寻找可以改进的地方,收集各种关于如何找到质量问题、解决质量问题的案例。项目管理者联盟

  7、审查,审查,审查。敏捷开发可以帮助我们应对需求在将来的不确定,但过去的事情也存在不确定性。测试工作永远不能停下来。程序每次运行的表现都要被评审和记录。项目管理者联盟

  8、软件的设计要以人为本,而不是系统。很多开发人员退而求其次、以技术为中心,让设计为技术服务。永远不要忘记软件的终极目标是什么,是帮助人们完成工作。pmp.mypm.net

  9、测试是产品的一部分。许多开发人员和经理都认为产品就是你打包给客户的东西,其余的都不重要。其实测试也应该看作是产品的实际一部分,应该在设计时给予相当的重视,甚至,在很多时候,测试功能也应该同产品一起提交给客户。(后面说的这部分很多人都不认可,一个内置的能自我测试软件包并不会占用多少额外的资源,但当你需要用到它时,你会发现它的巨大价值。)pmp.mypm.net

  10、先写测试用例,后写代码。测试用例可以用来精确的说明我们的设计需求。很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。想想吧,先写测试用例后编码能节省多少时间。但是:写完测试用例1,然后编写用例1,完后才开始用例2。项目经理博客

  11、清理垃圾代码。很显然,又是一个尽人皆知的道理,但它也必须写入任何的开发原则里,因为它是如此的重要。查找垃圾代码的工作永远没有尽头,找到它,消灭它。要去除掉所有的不能给实际用户带来价值的代码。如果你不能指出某段代码对用户有什么用处,那它很可能就是没用的。项目管理者联盟

  12、培养对集成失败问题立即做出反应的习惯。你要明白,当集成构建失败时,它会影响项目中的每一个人,所以没有比让核心程序能正确的集成和测试通过更重要的事情了。我曾经见到过有的团队的集成构建中断几个月都不去管它,因为他们有其他的工作要做。每个人都在忍受这种情况,但没人采取措施。我们应该明白,应该广泛的认识到,只要做出一点点工作,整个的团队会因此得到非常大的回报。PgMp.mypm.net

  13、团队的每个成员都要知道客户的需求。大型复杂的项目必须要分割到几个独立的团队去开发,然后派发到每个开发人员的手中,但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。项目管理者联盟

  14、把意义相关的东西放在一起。组织好代码,让高度相关的东西都放在一起,也就是放在一个类里。这是标准的面向对象设计原则里的封装的概念。理想情况下,类之外的程序并不需要知道类里面的工作细节。有些开发人员喜欢把代码放到好几个文件里,这样是为了按另一种方式组织它们:例如把相同的数据类型的放到一起,或按字母顺序分类。举个例子,有人会把所有的常量放在单独一个包下的一个类里,他们这样做毫无必要,增加了程序的复杂性。按照指导原则,它们应该按照相关性进行分组,从而减少复杂性。项目管理者联盟

  15、先测试后提交代码。这个准则能让你确保“永远不要让集成构建失败”的准则。项目管理者联盟文章

  16、过早优化是灾难之源 这句话是引用Don Knuth的,今天听起来一点不错。在内核里的代码应该尽力的写好来避免不要的浪费,但针对高于单个方法的级别的优化应该在整个项目测试通过、针对最终实际用户的压力测试用例通过之后才能进行。仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断往往是错误的。相反,评审整个系统的运行表现,找出真正影响性能的1%的代码,只针对这些代码做优化。项目管理者联盟

  17、最小化未完成的编码任务的工作包(backlog)。当开发人员开发一个设计用例时,有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。把未修改完成的代码保存到本地数天或数星期,这样增加了工作浪费的风险,会出现返工。想象有三个任务,每个估计都要一天。如果三个一起开发,并行起来每个都需要3天,这样一累计会有9个’单位’的风险。如果顺序的开发,一个开发完成后再开发另一个,只会有3个‘单位’的风险。这个并不符合我们的直觉。我们的直觉告诉我们,当我们在这种情况下时,我们希望三个一起完成。但是软件不像盖房子。小的、迅速的、完整的任务不仅仅会降低我们的认知负荷,也减少了进行中的开发对其他人正在进行的开发的相互影响。转自项目管理者联盟

  18、不要过度功能范化。也就是我们所说的 “YAGNI – You Aren’t Going to Need It” 。程序员在编写一个类时喜欢料想:这个类可能在其它地方其它类中会有其它用途用. 如果这些用途是被当前的用例用到,那这样思考是没错的,但常常开发人员想到的这些用途都是目前不存在的用途,实际上可能是永远不会用到的用途。(This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)转自项目管理者联盟

  19、如果两行代码能完成就不要写成三行。简洁的代码永远都会给需要阅读这段代码的人带来好处。但千万不要把代码压缩的难以理解了。精简的、书写规范的代码易于维护和查找错误,冗长的、太多修饰的代码则相反。尽可能的简化但不要过度。pmp.mypm.net

  20、永远不要按行数多少来评价代码头。编写某个任务所产生的代码行数会因程序员而异,因编码风格而异。代码的行数不会提供任何关于程序完成情况和代码质量的信息。代码质量可以相差200倍之多,这是计算代码行数的方法不能胜任的。应该计算功能性的用例数。项目管理者联盟

  21、我们应不断的再设计、再分析。应用这一条时你要非常的小心,因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。一个数据成员以前是整数型的,但现在有个用例需要它是浮点型,不要害怕去改变它,只要你按步骤:测试,写文档,布署。项目管理者联盟

  22、删除死代码。当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。比如说,我们需要往类里添加一个新方法来替换以前的旧方法,通用人们会保留老方法‘以防不测’。其实,我们应该花一些功夫去检查看看这个老方法是否还有用,如果没有证据显示它还有用,就该删掉它。更糟糕的错误做法是把这些代码注释掉,留下一堆注释码。注释掉的代码一旦发现就该被删掉,不能留到测试时还有、甚至提交到代码库。添加代码总是容易的,删除代码总是困难的。因此,一旦发现有可能没用的代码,你应该花点时去确认它、删除它,这样会让代码更加可维护。项目管理者联盟

  23、不要自创新语言。程序员喜欢使用文本文件来实现功能性的趋动,这样可以使程序变的可配置。通过配置文件来改变软件行为所产生的后果是不过控的。XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现,人们试图通过文件的配置以让最终用户‘编程’来控制软件的功能、避免重新编译。这种设计上的缺陷是:软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。所以,真正的最终用户是不可能知道软件的内部工作机理的,不可能推理出这些复杂的指令组合会产生什么样的预期结果。脚本有它的用途,也不应该被抵制,但设计人员必须以非常非常安全的方式使用它们,尽可能使用现有的语言,必免使用新发明的语言。club.mypm.net

  24、只有当准备好了实现和测试才去确定设计。我应该有一个总体的认识我们要做什么,应该有个总体架构目标,而不是详细设计、详细的具体方法的实现,只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。详细设计只应该包括当前需求用例中需要覆盖的部分。软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了,或者是你的设计一开始就建立在错误的假设上。项目管理者联盟


<<上一页 1 2 下一页>>
项目管理者联盟PMP认证中心
[相关文章] [网友互动]
·教你几招,弱矩阵下项目团队该怎. (134)曾伟强10-28
·带团队,这四大原则缺一不可! (203)项目管理者联盟10-25
·让项目团队热情起来的5个杀手锏 (166)曾伟强10-14
·打造自组织团队的“六部曲” (219)项目管理者联盟10-12
·再谈项目团队合作问题 (123)曾伟强10-12
·团队管理的十条核心准则 (217)项目管理者联盟10-09
·敏捷软件开发团队的26条核心原则 (443)项目管理者联盟09-27
·掌控这50大原则,你也就掌控了敏. (306)项目管理者联盟09-27

11-12[日志] 企业如何选择项目管理软件?哪个项目管. (11)
11-11[日志] SaaS软件有未来吗?SaaS是如何为企业带. (14)
11-06[帖子] 中小型企业加工厂用哪种ERP软件比较好 (61)
11-06[日志] 中小型企业加工厂用哪种ERP软件比较好 (11)
11-04[帖子] 为什么项目不能用手工或者填表式的项目. (56)
11-04[日志] 为什么项目不能用手工或者填表式的项目. (12)
11-02[帖子] 在敏捷管理中,你对需求变化是怎样理解. (51)
11-02[日志] 在敏捷管理中,你对需求变化是怎样理解. (20)
[发表评论]
本站热点
·2020年敏捷项目管理ACP培训计划
·PgMP:项目经理到中高层经理的升级
·2020年项目集管理PgMP培训计划
·2020年国际产品经理NPDP培训计划
·PgMP考试第三季度通过率高达86.6%
·里程碑:中国PgMP认证人数超越印度
·2020年度PMP培训班招生简章
·项目集管理最佳实践与PgMP实战应用
·联合体EPC工程总承包专题实践论坛
栏目说明
    《文库》栏目为项目管理者联盟网站核心栏目,收录了十大行业项目管理文章5000余篇,囊括了项目管理五个阶段、九个知识领域的相关文章,是广大项目管理爱好者学习的知识库,欢迎大家发表原创文章、转贴文章,或直接发给编辑。须联盟会员且登陆后才能发表文章。
敏捷项目管理ACP培训
项目管理活动
《PgMP:项目经理到中高层经理的升级》巡回讲座
主办单位:项目管理者联盟
时    间:2019/11/30
地    点:深圳 北京 上海·
电    话:010-82273401-18
邮    件:pgmp@mypm.net
活动QQ群:531390275
免费积累PDU,仅500人

2019年项目管理活动计划
2018年活动精彩回顾
原创排行榜
 项目管理评论杂志 170 高扬 106
 项目管理 84 乔东 78
 高国伟 61 人月神话 60
 郭致星 52 张为 48
 蒋昕炜 46 肖杨 38
 潘德有 36 周劲松 34
搜索文章
关键词:
行  业:
团 队   成 本   风 险   进 度
沟 通   采 购   质 量   合 同
更多>> 专题集锦
更多:
经理访谈
更多:
个人专栏
更多:
项目管理者联盟特刊
联盟特刊是对网站会员发行的内部刊物,刊物内容包括:案例及分析等,得到了会员好评。
电子期刊:
特刊下载:
2017合刊  2016合刊  2015合刊 
2014合刊  2010合刊  2009合刊 
2008合刊  2004合刊  2005合刊 
2006合刊  2007合刊       
施工企业管理
《施工企业管理》创刊于1986年1月,中国施工企业管理协会主办,是反映施工企业管理杂志。
浏览往期:
建造师杂志
《建造师》杂志由清华国际工程项目管理研究院主办,是中国面向建设企业管理人的高端杂志。
浏览往期:
更多>> 推荐文章
10-08·别想了!没有速成的项目经.
10-08·关于项目管理的目标,我们.
10-08·8条谁都可以在工作中践行的
10-08·项目经理如何改变命苦的魔.
10-08·在阿里,如何做好技术项目.
10-08·一张图读懂项目经理
10-08·国际高级项目经理PgMP访谈.
10-08·真正会沟通的项目经理,不.
10-08·在PDCA周期中存在的管理隐.
10-08·这10个技巧,瞬间提升项目.
10-08·项目集管理:项目经理进阶.
08-30·能让项目经理少奋斗5年的职
08-30·国际高级项目经理PgMP访谈.
08-30·项目估算全靠猜?项目经理.
08-30·项目沟通中的五大陷阱
08-30·进度计划管理的反思
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
项目管理者联盟 版权所有 京ICP证070584号 | 京公网安备110102000464号
如转载本站文章,必须于文章开头处注明转自“项目管理者联盟”,并注明原作者