当前访客身份：游客 [
已有文章 2067 篇
当前位置：
你不需要遵守的 7 个敏捷开发最佳实践
英文原文：
0人收藏此文章,
推荐于 2年前 (共 13 段, 翻译完成于 05-29) ()
参与翻译(4人)：
在敏捷开发中有很多好的想法和实践，这些想法和实践都非常管用：把项目分成小版本发布来进行风险管理和加速回馈；用时间盒（time-boxing)来限制WIP（Working In Process）并让所有人团结一致集中在项目中；仅依靠软件来作为进程度量；进行简单的估算并使用速度来预测团队的表现；和客户保持频繁而紧密的合作；持续集成持续发布以保证代码始终稳定可运行。
但是还有一些别的并不是那么重要但被很多人接受的想法和实践：就算你不遵守这些想法和实践你的项目依然可以圆满成功，也不会有糟糕的事情发生。但是有一些想法实践你最好不要去遵守。
&翻译的不错哦!
测试驱动的开发
做快速开发的团队需要依赖于一个快速高效测试安全网。在一个测试先行的或者是测试驱动（TDD）的敏捷开发中，没有任何借口可以不写测试用例。在你开始编码前你必须先写好测试用例，然后你就可以采用一些高效的自动测试工具来保证有一个高水平的覆盖测试和回归测试。
TDD不仅仅是一种供开发人员测试他们代码的保证手段，它更重要的一种开发技术，这种开发技术能够得到更高质量的代码和一个简单整洁的设计。
微软和IBM（通过测试驱动开发实现质量改进，微软研究院，2008）的研究团队发现，虽然TDD增加了15%-35％前期成本（TDD要求开发人员改变他们的想法和工作方式，这减缓了他们的的开发速度，至少在一开始他们的开发速度慢了很多），但是跟没有采取单元测试的团队相比缺陷密度降低了40％（IBM）或多达60%-90％（微软）。
&翻译的不错哦!
但是在软件制作第12章“测试驱动开发的有效性有多好”中，由主导的研究表明虽然TDD表面上提高了质量（根据一个或多个通过的测试用例，缺陷的数量，缺陷密度，每次测试发现缺陷数，修复缺陷的工作量，修复密度，预防性维护比例等本衡量）并且可以提高测试的质量（可以使测试错误降低，使测试变得更加容易），但TDD并不能一直提高设计质量。TDD似乎可以降低代码的复杂度，提高代码的重用率，但是它也能给耦合内聚带来负面的影响。虽然使用测试驱动的开发可以使得方法级和类级的复杂度降低，但包级和项目级却为之变得更加复杂。
喜欢TDD的人为之疯狂，如果你也热衷于TDD，那就尽管用它吧。就算你对TDD并不那么感冒，测试先行非常自然的场景也是时不时出现——尤其是当你不得不通过一种特殊的方式来解决一个特殊的问题，或者你要修正一个bug而测试用例已经为你写好的时候。但是更重要的是，你要写一组很好的测试用例不断更新并且时不时运行它们，这跟你在写代码前还写写好代码后没有关系。
&翻译的不错哦!
根据VersionOne&(敏捷开发调查状况2012)，几乎有1/3的团队采用了结对编程的开发方式——这是一个出乎意料的高数字，这显示出结对编程的良好的组织纪律性，同时表明有很多的团队使用了可以进行结对编程的XP（2%）和Scrum/XP（11%）方法。
有采用结对编程的非常好的理由：开发人员一起工作可以通过持续的非正式的审查来提高代码质量和进行信息共享。让开发人员结对或者让开发人员和测试人员结对来一起工作的情况非常常见，尤其是当你在解决一个非常困难的设计问题，或者你碰到一段以前从来都没有接触过的代码而以前开发过类似代码的人就在旁边可以请教，或者你碰到了一个高压力的问题需要解决为此你豪无头绪，或者你在测试系统的一个非常难的部分，或者你的团队又加入了新的成员而这些成员需要基础学习的时候。
&翻译的不错哦!
一些（尤其是性格外向的）人非常喜欢结对编程，喜欢它提供的非常强大的能量和非常难得的认识团队其他成员的机会。但是去强迫那些更喜欢自己单独工作的人去和自己不喜欢的人进行紧密的合作，这显然不是什么明智的作法。结对编程要花费社交成本：和一些有能力的，技术强的，有工作经验的，有自己独特方式的，有自己鲜明个性的或者是有自己职业道德的人一起结对编程你需要非常小心。而且长时间的结对编程让人精疲力竭——一项研究（Vanhanen and Lassenius 2007）发现人们通常一天只结对编程1.5至4个小时，因为成天的结对编程工作强度太大以致于无法接受。
在结对《编程或许是有害的》一文中，Jon Evans说结对编程对创造力有负面影响：
研究强烈支持这个观点：当在享受更多的不被打扰的自由和隐私空间时，人们才有最好的创意......区别表现突出的大公司的开发人员的并不是更丰厚的工作经验和更高的薪酬，而是他们可以享受的不被打扰的自由的私人空间。”一篇纽约时报的文章大骂结对编程这种所谓“新的集体思维”时这样说。
&翻译的不错哦!
另外在Pete McBreen的“依然质疑极限编程”中指出了一些结对编程的其他缺点和弱点：
不鼓励钻研思路，结对编程时开发专注编写代码，所以除非有一天的时间来钻研团队代码才能对代码有一点肤浅的理解。
开发变得过度依赖单元测试，假如测试通过了，那么代码就OK了。（这就缺乏钻研了）
没有进行详细的极端测试和边缘测试研究，特别是如果他们很难写出测试。
当结对编程时很难做到经过详细思考设计的编码，除非另外一个搭档完全控制这个编码过程。通过平时搭档间的权衡，很难建立技术复杂的设计，除非他们已经确定了一个独自会话。
结对编程时的个人风格问题，并不是所有的结对者都能像其他人一样。
和打字技能、熟练程度不同的人结对编程，往往会导致打字技能好的人完成全部的编码而其他人变得完全被动。
在分布式团队中结对编程显然也不会有效（取决于距离，不同的时区，工作方式，语言），即使这样，一些人仍然在尝试。
&翻译的不错哦!
虽然结对编程相比独自编程提高了代码质量，你也可以通过较低代价的代码复审来获得同样的代码质量提高，并且还有一些信息共享的优势。代码复审——特别轻便，离线复审——比结对编程更容易安排，代价更低点并且没有打扰。就像 即使开发们结对编程，你, 因为结对编程确实是共同解决问题，但是它并没有包含所有代码复审所涉及的全部问题。
还是乔恩埃文斯关于结对编程的老话：
真正的答案是有没有答案：独自编程，结对编程还是小组合作要根据环境用你最好的判断来动态结合才是最有效的。 结对编程的确有它存在的意义。（定律又没用了！）在某些情况下，甚至是“绝对对的”。但是坚持100%结对编程是盲目的教条主义，和所有的盲目教条主义一样，最终只会适得其反。
&翻译的不错哦!
紧急设计和隐喻
增量开发管用，而且尝试感觉起来不错，但试图。几乎没有人遵循有一个原因：它不管用。
依赖于 (系统是一条 "流水线"或 一个"物料清单"或 一箱"蜂箱的蜜蜂") ，这些隐喻被团队共享为某种
是更加荒谬的。
的研究显示
… 自然语言的隐喻，无论对技术和非技术项目成员之间增进沟通，还是在开发架构方面，相对来说都不是很有用。
&翻译的不错哦!
总之几乎无人理解 ，或者它怎样使用，或者怎样选择一个有意义的隐喻，或者如果你搞错了又怎样改变它（还有你怎么会知道你选错了），其中有人提出了这样的想法：
好吧我还是不妨公开说出来 —— 我仍然不能找到这种隐喻事情的窍门。我发现它管用，而且在C3项目中工作的很好，但这并不意味着我知道怎么做，更不要说如何解释怎样做到了。
Martin Fowler,&
敏捷开发方法促进了开发的成功率，并且展现出处理许多不同软件开发问题的更好方法——但不是架构和设计。
&翻译的不错哦!
每日站立会议
当你有了一支新的团队，而每个人都需要相互了解，并且需要更多的时间理解项目是关于什么的；或者当这个团队迫于超级压力，正在试图修复些什么或者结束些什么的紧急的状况，那么将大家聚集起来开工作例会，甚至也许一天超过一次，这是必要的且有价值的。但是每个人是站还是坐，最终他们，将由你决定。
如果你的团队已经合作一段时间也合作的很好，而他们每个人都互相了解并且知道他们在做的是什么，如果开发人员做完事情的时候，在任务板或看板上更新卡片，或者在一个电子系统里更新状态，如果他们足够成熟可以在需要的时候请求帮助，那么你不需要每个早上在房间里
&翻译的不错哦!
集中式代码所有权
让每个人的工作都涉及到所有代码并不总是有效（因为不是团队中的每个人对每个问题都有必备的知识或者经验），并且集中式代码所有权对代码质量有负面影响。
共享代码看起来似乎更有意义，但事实上却是不是每个人或者是应该为系统的每一部分工作。
&翻译的不错哦!
像写故事一样编写需求
每一个需求规格说明都能以的方式，以1到2行写到卡片上的想法，需求应该（以致开发者必须向某人解释真正的需求是什么），坚持他们应该应该以相同形式的
“作为某一类用户，我有目标期望因此某些问题…”
是非常愚蠢和没有必要的。在15年前，这同样是一类简单而又传统的想法，让每个人都用
试图去捕捉所有需求。
有更多不同的方式来有效的表达需求。有时候需求需要被规定到细节级别（当你必须满足合规性或者符合一种标准，或是与现有系统集成，或是实现特定的算法。。。）。有时候从一个测试用例或者一个具体的用例场景或一个框架或一切别的类型的模型开始会更有效，因为这样会让人知道如何推进，并且有些细节已经就绪。因此，运用格式化和细节层级能更有效也更容易开展工作。
&翻译的不错哦!
对产品所有者的依赖
，当项目失败的时候，就如客户唯一的声音和“”，无法扩展，，将团队和项目以及事实上的业务推向风险的边缘。很自然的，危险逐渐靠近正在设计的产品和管理中的开发项目，将比解决危险带来更多的问题。
一些团队意识到这一点，并试图与，因为他们必须这样做。为了成功，一个团队需要在各个层次的真实而持续的客户合同，他们，为确保他们得到他们所需要的，而不是依赖某一个人去完成所有的一切。
&翻译的不错哦!
这文章题目还是改一下吧，文章里面写的是可以不遵循的规则，题目译成了不需要遵循的。看着好像没什么区别，但是不需要遵循显得这些规则有问题，不能遵循。而文章显然写得是备用的，可以遵守也可以不遵守的规则。仅个人观点。1087人阅读
敏捷，是把利剑，用得顺手，可以披荆斩棘；用得不顺手，反倒会伤到自己。
笔者过去经历过一次敏捷开发，有一些体会，说来分享给大家，希望对于大家有所帮助，也请各位对于文章中存在的不足之处发表意见。
项目背景：
开发测试接近40人，以前习惯于传统CMM流程；
开发人员有2/3以上的新员工，开发经验较少，几乎没有设计经验；
需求较为稳定，需要2个团队跨地域合作，两边的交付件存在较强的集成关系。
个人认为，一个成熟度一般的团队，从传统的CMM流程向敏捷过渡的话， 一定要谨慎。下面介绍一些需要注意的地方。请大家参考。
一、需要审视自己的团队，是否具备敏捷能力：
1、是否具备有了足够开发、设计经验的开发团队
这点是重中之重。敏捷对于团队成员要求极高，如果不具备分析能力、设计能力，无法应对的需求变化，无法对于后续的改动进行持续的重构，即使需求没有变化，在一个一个规格被增加进来的时候，对于已有设计的冲击还是有的，起码要考验到架构、模块设计的可拓展性。另外如果产品的性能要求较高，功能正确后的持续重构，提高产品性能的能力一定要具备，否则“抱拥变化”就是空谈。
对于可靠性要求较高或者功能较为复杂的产品，开发人员对于异常流程的理解一定要到位，否则设计时间较短，没有时间考虑这些事情，那么开发的时候开发人员还不具备识别异常流程的能力，只能等待高素质的测试人员通过人工的测试手段保证，代价极为昂贵。
不要指望个别能力突出的开发成员可以起到总揽全局，带动团队完成开发。一旦项目启动，大家都在一个一个的赶工自己的Story，即使开会讨论，也是应该是相互交流性质的，否则就会将能力较强的开发人员陷入协助其他员工检视设计、编码思路的泥潭。久而久之，骨干员工会觉得很累；其他员工虽然每天干得工作不多，但是也是跟在别人后面忙忙碌碌，精神上很疲惫，个人能力方面得到的提升也不是很明显。
2、是否可以保证对于持续集成，自动测试的投入
无法保证这两点，敏捷开发、迭代开发就是在扯淡。例如，迭代2为了拓展新功能重构了一下基本功能模块，那么迭代1的功能是否需要重新测试？如果没有覆盖层面较高（覆盖了UT、IT、ST）的自动测试的话，答案就是：恭喜你，每个迭代你都需要重新手动测试所有功能。恶梦一样的测试。
持续集成还是较为容易的，关键在于自动测试的层面。我们这个项目自动测试层面仅为UT（单元测试），个人认为，远远不够。起码重要的、基础功能需要做到ST的自动覆盖。尤其是本项目的两个团的之间存在较大的耦合性，任何一个接口上的改动都会导致两边同时发布版本。如果两个团队无法保证自身基于接口能够自动测试的话，一个团队的延时会造成另一个团队的开发进度受阻。
3、是否有对于敏捷有一定认识和积累的领路人或者顾问
咨询大师温伯格说过：使用新东西总是有风险的。
是的，当一个团队向不熟悉的流程迁移的时候，最大的风险就是没有在整个团的层面形成对于该流程的全面的、一致的认识。这点相当可怕。CMM是严谨，过程化的，但是同时附带了一些枷锁（各种规定，各种文档）；对于枷锁深恶痛绝的人们看到敏捷过程后，惊呼：终于可以抛掉这些该死的枷锁了。但是同时，过于灵活的流程中，缺乏经验的人们反倒无所适从，下一步该做什么？该怎么做？甚至项目的骨干们对于当前的各种事情也没有了清晰的优先级的划分，大家对于敏捷的理解都源于书本，理解得有都不一致。
“敏捷应该这样”，“敏捷应该那样”，当发生了这种争论的时候，请注意，你的团队面临者一种失去方向的风险。有的时候先选择一个方向走下去，也许是最快捷、代价最小的选择。
在没有具备上述必备条件的时候，最好不好考虑上来就彻底的敏捷，循序渐进的向敏捷演进应该是更好的办法
二、审视一下我们需要敏捷给我们带来什么变化。
在决定彻底采用敏捷开发之前，还是请审视一下自己的团队需要敏捷开发给带来什么好处？是否现有的CMM流程中融入一些敏捷的思路和实践就可以达到？如果可以的话，建议采用稳健的方式向敏捷过渡。尽量不要有“一步跳进共产主义社会”的想法。
版权声明：本文为博主原创文章，未经博主允许不得转载。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：7683次
排名：千里之外
(1)(1)(1)(1)(2)(3)(1)‘无枚翱之敏捷,有司马之淹迟.’ ‘东隅已失,桑榆非晚.’ ‘戒骄戒躁,勿怠勿荒’几句是啥意思?_作业帮
拍照搜题，秒出答案
‘无枚翱之敏捷,有司马之淹迟.’ ‘东隅已失,桑榆非晚.’ ‘戒骄戒躁,勿怠勿荒’几句是啥意思?
‘无枚翱之敏捷,有司马之淹迟.’ ‘东隅已失,桑榆非晚.’ ‘戒骄戒躁,勿怠勿荒’几句是啥意思?
无枚翱之敏捷,有司马之淹迟.翻译：没有枚皋的敏捷,却有司马的淹迟.应该比喻是各有所长吧、 “枚皋敏捷,司马淹迟”的典故 ：就是说和相如同时代的枚皋作文章的速度就特快,当场就一挥而就,像后世的王勃等也是这种类型的,而相如却是“为文首尾温丽,但构思淹迟.控引天地,错综古今,忽然而睡,涣然而兴,几百日而后成”.天啊,“几百日”,一部书稿也就这多么多的时间吧.不过当时司马相如受到皇恩的激励,自然激情澎湃,可能速度稍快一点,相如使尽浑身解数写的这篇名作叫做《上林赋》,因为看到汉武帝特喜欢《子虚赋》,于是这篇《上林赋》可以看作是《子虚赋》的续集.东隅已逝,桑榆非晚 东隅：指日出处,表示早年.桑榆：指日落处,表示晚年.早年的时光消逝,如果珍惜时光,发愤图强,晚年并不晚.唐·王勃《滕王阁序》：“北海虽赊,扶摇可接；东隅已逝,桑榆非晚.” 例：歌德在四十岁以前,一心想成为一名画家,但他所作的努力没一点成效,一次,他去意大利看大家的作品,发现自己根本不可能在这方面有所建树,后来,他及时调整自己的发展方向,终于在文学上有所成就,成为了一位伟大的诗人.‘戒骄戒躁,勿怠勿荒’.警惕并防止产生骄傲和急躁情绪.不要怠慢和松懈下来.出自著名的革命家、教育家吴玉章81岁时写下座右铭：“我志大才疏,心雄手拙,好学问而学问无专长,喜语文而语文不成熟,无枚皋之敏捷,有司马之淹迟,是皆虚心不足钻研不深之过.年已八一,寡过未能.东隅已失桑榆非晚.必须痛改前非,力图挽救.戒骄戒躁,勿怠勿荒,谨铭.”