敏捷无敌-第8部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


该任务的状态还是In　Progress，还有一定的剩余时间。”
　　“呵呵，这好办，忘记更新的接着罚款。”阿紫这个CFO时时不忘增加收入的机会。
　　“有时候也不是故意不更新的，一忙就忘记了。”小宝好像不更新的次数最多，赶紧出来解释。
　　“要不这么着吧，我们就留三次免罚机会吧。”阿捷建议。
　　“每个人三次？总共才三个礼拜的Sprint，这样下来还是不能反映实际状况。”大民立刻表示反对。
　　“就是就是！”阿朱也表示赞同大民的意见，“要不然，咱们就给整个Team留三次免罚机会，如何？”
　　“这个方法可以，跟100米赛跑的规则差不多，虽然不太公平，但可行。”大民表示赞同，小宝、阿紫等人也都没有异议。
　　“好！这个问题也有解决方案了，看看大家，谁还有啥建议？或者还有哪里需要改进？”
　　大家一片沉默，看来都没有什么话题了。
　　“好！我们今天的成果还是挺丰富的，我下去整理一下，把我们今天讨论的这些东西跟以前的总结到一起，形成咱们自己的Scrum　Rule！那今天就到这！”
　　大家边走边聊，陆陆续续走出“桃花岛”。
　　阿紫说：“大家觉得我们下次Team　Building去哪里玩比较好？”
　　“我提议去打真人CS，非周末的时候，平均每人100多些。”阿捷这个CS迷，本性不改。
　　“我觉得去爬爬香山也不错，好久没去了！”阿朱提议。
　　“去后海吧！先划船，然后泡吧、杀人！”大民这个*分子，每次的提议都很奢侈。
　　小宝插了一句：“去打Golf吧，我都建议了好几次了！”
　　“好啊！好啊……你请客我们就去！”阿紫开始起哄。
　　大家吵吵呼呼地回到格子间，引来其他Team的一阵侧目。阿捷这个团队的传统一直就是这样，人不多，但每次开会都能听到他们的笑声。
　　回来的路上，阿捷顺路到产品经理李沙那里，讨论了一下关于Product　Backlog条目更改的问题。让阿捷没有想到的是，李沙认为这个问题根本不是问题，只要大家添加新条目的时候，利用ScrumWorks工具软件里面的主题功能，对每个新条目施加一个“Not　Reviewed”的主题即可，这样李沙就知道这些新条目了。但是，李沙还是重复强调，对于其他已经存在的Backlog条目，一定不能修改，特别是先后顺序。
　　阿捷回来重新整理了一下Scrum　Rule；　然后分发给大家。
　　1．每日站立例会迟到，罚款￥5。
　　2．对于未及时更新任务状态和剩余工作量的，整个Team留三次免罚机会，以后再有人违反，则罚款￥5。
　　3．对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款￥5。
　　4．进行任务细分时，每个任务估算最大不能超过18小时（三个工作日）。
　　5．在Sprint计划会议上，认领了一项任务的人，可以对该任务估算做出不超过50％的调整。
　　6．对于复杂任务的估算和分解，采用“DELPHI”方法。
　　7．每个人都可以添加新的Product　Backlog条目；　但必须标示为“Not　Reviewed”，以方便Product　Owner审议。
　　8．为提高Sprint回顾会议的效率，在Sprint回顾会议之前，每个人应该给出“我们做得好的地方、需要改进的地方”。
　　9．在Sprint计划会议上，我们应该预留10％的估算时间作为缓冲，以应对突发事件。
　　10．在Sprint计划会议上，我们应该进行关键路径、风险、外部依赖的分析。
　　11．对于Review，发出Review的人必须给出截止日期，参与Review的人，必须在截止日期前给出答复。
　　

第10章　持续集成（1）
Nothing　in　the　world　is　difficult　for　one　who　sets　his　mind　to　it。
　　世上无难事，只怕有心人。
　　——吴承恩《西游记》
　　“目标管理（MBO）”的概念是管理专家德鲁克（Peter　Drucker）1954年在其名著《管理实践》中最先提出的，其后他又提出“目标管理和自我控制”的主张。德鲁克认为，并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以“企业的使命和任务，必须转化为目标”，如果一个领域没有目标，这个领域的工作必然被忽视。因此管理者应该通过目标对下级进行管理，当组织最高层管理者确定了组织目标后，必须对其进行有效分解，转变成各个部门及各个人的分目标，管理者根据分目标的完成情况对下级进行考核、评价和奖惩。
　　目标管理提出以后，便在美国迅速流传。时值第二次世界大战后西方经济由恢复转向迅速发展的时期，企业急需采用新的方法调动员工积极性以提高竞争能力，目标管理的出现可谓应运而生，遂被广泛应用，并很快为日本、西欧国家的企业所仿效，在世界管理界大行其道。Agile公司作为美国最大的通信公司之一，也毫不例外地采用了这一管理实践。
　　目标管理指导思想上是以Y理论为基础的，即认为在目标明确的条件下，人们能够对自己负责。具体方法上是泰勒科学管理的进一步发展。它与传统管理方式相比有鲜明的特点，可概括为如下所述。
　　1．重视人的因素
　　目标管理是一种参与的、*的、自我控制的管理制度，也是一种把个人需求与组织目标结合起来的管理制度。在这一制度下，上级与下级的关系是平等、尊重、依赖、支持的，下级在承诺目标和被授权之后是自觉、自主和自治的。
　　2．建立目标锁链与目标体系
　　目标管理通过专门设计的过程，将组织的整体目标逐级分解，转换为各单位、各员工的分目标。从组织目标到经营单位目标，再到部门目标，最后到个人目标。在目标分解过程中，权、责、利三者已经明确，而且相互对称。这些目标方向一致，环环相扣，相互配合，形成协调统一的目标体系。只有每个人员完成了自己的分目标，整个企业的总目标才有完成的希望。
　　3．重视成果
　　目标管理以制订目标为起点，以目标完成情况的考核为终结。工作成果是评定目标完成程度的标准，也是人事考核和奖评的依据，成为评价管理工作绩效的唯一标志。至于完成目标的具体过程、途径和方法，上级并不过多干预。所以，在目标管理制度下，监督的成分很少，而控制目标实现的能力却很强。
　　阿捷觉得MBO跟Scrum在思想上是相通的，所以对这个管理方法具有无比的好感。在Agile公司，目标管理有固定的一套程序或过程。它要求组织中的上级和下级一起协商，根据组织的使命确定一定时期内组织的总目标，由此决定上、下级的责任和分目标，并把这些目标作为组织经营、评估和奖励每个单位和个人贡献的标准。为了更好地检查目标完成情况，上级和下级要定期会晤，讨论进展和问题，在Agile公司，这种定期会晤称为“One　to　One　Meeting”，是经理跟员工一对一的会议。
　　阿捷自从接管TD这个团队后，跟员工制定并讨论MBO，已成了他每个季度的必修课。因为团队正在实施Scrum，阿捷给阿朱设定的目标之一就是“如何做到测试的敏捷化”。

第10章　持续集成（2）
阿捷率先开头：“我们之前也做过几轮MBO的One　to　One了，你对这个会议本身有什么建议吗？”
　　“嗯”，阿朱略微沉思了一下，“Review要及时，目标设定要随时调整。其实我对以年为跨度的Objective　Setting和Performance　Review的最大困惑就在于两者的严重脱节。”
　　“哦？”阿捷示意阿朱继续。
　　“实际上，这样长跨度的目标设定，更倾向于一个Career　Plan而不是Objective　Plan。而拿一个Career　Plan作为年终Performance　Review的依据，似乎不怎么合理。”
　　“嗯”，其实阿捷也有同感，之前几年，都是袁朗跟阿捷One　to　One的，最终都沦为了形式，阿捷也准备做些改变。不过阿捷还是鼓励阿朱说下去，“你觉得应该怎么变化更好些？”
　　“我是这么想的，我们实施敏捷开发有一段时间了，一个Sprint的周期基本是3个礼拜左右，那么我们每人的短期目标完全可以跟每个Sprint结合起来。因为每个Sprint的目标都很明确，再落实到每个人头上就会非常实际。但这样，就得加强Review的频率，以及时调整目标。”
　　“你的意思是说我们把每个季度一次的One　to　One，改成每个月一次？”
　　“对！”
　　“嗯，你说得非常有道理，我也有同感。可以把每年的Objective　Setting，作为员工个人的Development　Plan。怎么样？”
　　“不知道别的员工怎么想，我觉得这样做，会更有价值。只不过，你就得多花些时间在这上面了。”阿朱笑着说。
　　“这倒没关系！关心并帮助每个员工向前发展，本来就是我的责任。我会再做一个调查，了解一下其他人的看法。你今天提出来，非常好！”阿捷抬头看了一下墙上的表，还有半个小时的时间，得赶紧讨论这次的主题了。“我们接下来看看我们上次提到的敏捷测试，你有什么最新进展吗？”
　　“我这几天思考了一下，我觉得我们的项目有必要采用XP的持续集成。”阿朱针对自己的“敏捷测试”目标，提出了自己的想法。
　　“为什么要持续集成？”阿捷问。
　　“你看，我们现在的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式的弊端也越来越明显，由于很多　Bug　在项目的早期就存在，到最后集成的时候才发现问题，我们测试人员需要在集成阶段帮助开发人员花费大量的时间来寻找Bug　的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况！”
　　“是啊，所以好多团队在这个阶段的除虫会议（Bug　Meeting）特别多，会议的内容基本上都是讨论Bug　是怎么产生的，最后往往发展为不同模块的负责人互相推诿责任。”
　　“通过持续集成，可以有效地解决这个问题。”
　　“具体该怎么做呢？”阿捷拿起笔，准备记录。
　　“你看我们的开发、测试流程：当任何一个人修改代码后，首先运行单元测试；通过后，提交代码；构建产品；把它放在模拟的产品运行环境下，进行测试；遇到问题，进行修正并重复上述过程。我们需要首先让上述过程自动化。”
　　“嗯，这样肯定可以大幅提高开发测试效率。”阿捷表示赞同，并示意她继续讲下去。　txt小说上传分享

第10章　持续集成（3）
“我觉得需要做这样几件事情：编译自动化、单元测试自动化，再加上自动打安装包、自动部署到测试环境，并进行功能测试、性能测试！”
　　“我觉得还有必要加上一条，自动统计测试结果，并通过邮件发送给相关的人。有了这样的一个框架，你们测试人员就可以从一些烦琐的手工工作中解放出来，做真正有意义的事情了。”
　　“嗯，有道理。”
　　“看来关键是如何实现完全的自动化，从读取源代码、编译、连接、测试，整个创建过程都应该自动完成。对于一次成功的创建，我们要做到在这个自动化过程中的每一步都不能出错。”
　　“这么一来，也就不需要专人做Build　Manager了！我总算解放了　。”阿朱对这个想法的实施，肯定已经神往很久了。
　　“嗯，具体的工作是不需要你亲自动手了，但是策略性的东西，还得你把关。譬如软件配置管理（SCM）、分支/合并策略、软件发布通知（Release　Notes）等。”
　　“这些工作不需要经常做的。我会搞好的。”阿朱笑着说。
　　“不过，上述所说的持续集成过程，实际上要求开发过程也要有对应的改变，譬如自动单元测试那块，应该由开发人员负责。”
　　“对，因为这不再是传统的编译和连接那么简单，属于自测试的范畴。自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试，将所有的这些自测试代码整合到一起形成测试集，在所有的最新的源码通过编译和连接之后，还必须通过这个测试集的测试，才能算是一次成功的创建。”
　　“这好像就是McConnell　提出的‘冒烟测试’吧。”阿捷突然想起了前几天看过的一篇文章。
　　“对！这种测试的主要目的是为了验证创建的正确性。在持续集成里面，这叫做集成验收测试——Build　Verify　Test，简称　BVT。我们测试人员按理不会感受到　BVT　的存在，我们只针对成功的创建进行测试，如功能测试。”
　　“嗯，这块我会跟大民、小宝他们说的，让他们去实现。”
　　“那我和阿紫负责其他部分的测试框架。”
　　“我还有一个问题，持续集成和日创建有什么关系？二者是不是就是一个东西？”阿捷绝对不会放过任何一个学习的机会。
　　“有些不同。
　　持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前业界推荐的最佳实践是每一个小时就集成一次。
　　持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续集成强调的是集成失败之后向开发人员提供快速的反馈，当然成功创建的结果也是得到稳定的版本。
　　日创建并没有强调开发人员提交（check　in）源码的频率，而持续集成鼓励并支持开发人员尽快提交对源码的修改并得到尽快的反馈。
　　“噢，重点就是‘频率’和‘反馈’两个方面。”阿捷若有所思。
　　“对！持续集成有一个与直觉相悖的基本要点，那就是‘经常性的集成比偶尔集成要好’。对于持续集成来说，集成越频繁，效果越好　，如果集成不是经常进行的，少于每天一次，那么再集成就是一件痛苦的事情，也就是我们过去及现在一直遇到的问题。”
　　“我想，创建一个持续集成的环境技术上是比较复杂的，也需要一定的时间，但长期回报肯定是巨大的。”阿捷带着问询的眼光瞅着阿朱。
　　“没错！只要我们能够让持续集成可以‘及时’抓到足够多的Bug，从根本上消除传统模式的弊端，这就已经很值得为它所花费的开销了。”阿朱非常期望这件工作马上开工：“那我们需要赶紧开一个会议，大家统一一下认识，做一个分工，然后分步实施。”书包　网　。　想看书来

第10章　持续集成（4）
“嗯，很好的建议！这个任务我就交给你了，怎么样？”
　　“没问题！我很乐意做这样的事情。”
　　二人又随便聊了聊，讨论了一些其他事情。
　　这次“One　to　One”的结果来看，还是非常成功的，持续集成这个想法如果得到实施，那将是一次巨大突破，阿捷决定把这个思想记录到自己的Blog上。
　　在他人眼里，像阿捷这样高学历、高薪水，出入高档写字楼的白领单身人士，身边一定会有很多女孩子。其实阿捷的生活完全不是别人想象的那样。虽然不知道自己还有多久能告别单身生活，可是阿捷并不着急。因为他一直崇尚这样一句话，“宁愿高傲地发霉，也不要委屈地谈恋爱”，忘记这是谁的QQ留言了，但享受生活的阿Q式精神是必不可少的，要在平淡的生活中用自己的生活方式来享受人生，去品尝大千美食，去饱览世间万象。故而，阿捷的业余生活非常丰富，不仅经常去北师大踢踢野球，顺路饱饱眼福，他还是“绿野”的会员，从“香巴拉”拉练到灵山黄草梁穿越，北京周边都留下了阿捷的足迹。
　　周末，对于阿捷这种光光人士来说，既好过，又不好过。　好过的是孤家寡人，想做什么就做什么，非常自由。不好过的是偶尔感觉到一点孤独，特别当自己的狐朋狗友抛开自己，跟女朋友出去约会的时候，只有忠实的小黑安静地趴在自己的腿边，陪着阿捷打CS。
　　自从阿捷接触敏捷开发，阿捷的周末生活已经慢慢有了些变化，从原来的遛完小黑就开始无聊地打CS，到每天都泡在网上如饥似渴地学习Scrum。而敏捷圣贤的出现，则让阿捷多了一份期待。那种似师似友的感觉很奇妙，敏捷圣贤可以在全球各地Tr*el更让喜爱旅行的阿捷羡慕不已。这天在网上，阿捷又遇见正在德国做Consultant的敏捷圣贤。
　　阿捷：Hi，你好！圣贤，德国玩得怎么样？现在在哪儿呢？
　　敏捷圣贤：嘿，哪有你说得那么轻松，我这可是工作的一部分。我现在在慕尼黑。
　　阿捷：不错！我喜欢那个城市，因为有德甲最伟大的球队——拜仁慕尼黑。
　　敏捷圣贤：你喜欢哪个球星？
　　阿捷：当然是小猪了！”
　　敏捷圣贤：施魏因斯泰格？我可以帮你带一件他签名的球衣！
　　阿捷：真的？
　　敏捷圣贤：真的！
　　阿捷：我都不知道怎么感谢你好了！
　　敏捷圣贤：不用这么客气呀，举手之劳的。
　　阿捷：嗯，对你可能是，但对我却不是……无论如何，我要好好感谢你才对，不仅在这件事情上，你在项目管理上对我的帮助，也使我受益匪浅。
　　敏捷圣贤：其实，我从你们的实践中也获得了很多值得思考的东西。对了，最近你们怎么样？有没有试验一下其他敏捷实践？
　　阿捷：持续集成CI（Continue　Integration）。
　　敏捷圣贤：这是一个非常好非常有用的XP实践！它可以非常有效地降低风险，但是它对与编程相关的日常活动提出了很高的要求。你们现在做到什么程度了？
　　阿捷：才刚刚开始！有什么需要注意的吗？
　　敏捷圣贤：哦，我以前的团队实行持续集成时，遇到了很多问题。在后来，我遇到Paul　Duvall博士，才知道我们错误地采用了一些持续集成的反模式。
　　阿捷：Paul　Duvall？反模式？
　　敏捷圣贤：Paul　Duvall是　Stelligent　Incorporated　的　CTO，该公司是一家咨询公司，在帮助开发团队优化　Agile　软件产品方面被认为是同行中的翘楚。反模式（anti…pattern）这个词，表示在特定环境中不应该采用的做法。反模式最终可能产生严重影响。　txt小说上传分享

第10章　持续集成（5）
阿捷：看来是一位大师啊！都有哪些做法是反模式？这对于我们这样一个缺少持续集成经验的团队，应该是非常有帮助的。
　　敏捷圣贤：他主要讲到了六个反模式：第一个是代码提交不够频繁，导致集成延迟。也就是说，如果代码长期留在开发人员自己手中，没有及时提交，如果其他人对系统的其他部分做出修改，而修改可能会相互影响的话，集成就会延迟；延迟越长，消除其严重影响就越困难。
　　阿捷：那看来必须要求开发人员每天提交一次。
　　敏捷圣贤：对。把任务划分得越小，越容易完成，开发人员才能越容易地经常性提交。第二个反模式是经常性构建失败，使团队无法进行其他任务。
　　阿捷：嗯，这个问题对我们影响比较小！我们在将代码提交到存储库之前，先从存储库中更新代码，再运行私有构建（Private　Build），保证构建成功后，才能提交。万一构建失败，会专门指定开发人员并以最高优先级尽快修复。
　　敏捷圣贤：你们做得不错！第三个反模式是构建反馈太少或太迟，使开发人员不能及时采取纠正措施。我想你们也应该问题不大。
　　阿捷：对，我们对每次构建结果都会发送E…mail给全体人员。
　　敏捷圣贤：第四个反模式是垃圾构建反馈太多，这使开发人员忽视反馈消息。这一点跟前一点是相对应的。我觉得你们应该改进一下。
　　阿捷：哦？
　　敏捷圣贤：你们现在每个人都会接到反馈的电子邮件。E…mail一多，大家很快就会将持续集成反馈看做垃圾邮件，进而忽视它们。你们需要指定一个人专门负责检查关于构建的E…mail。只有构建失败时，才把邮件发给引起失败的人，这样大家才会重视。
　　阿捷：嗯，有道理，值得改进。
　　敏捷圣贤：第五个反模式是用于进行构建的机器性能太低，导致构建时间太长，严重影响频繁地执行集成。
　　阿捷：呵呵，我们有5台超强的HP…UX服务器，可以实现自动负载分担，并行构建！这样每次构建，不会超过1小时。
　　一说到这些，阿捷还是很自豪的，Agile公司财大气粗，硬件环境绝对一流。
　　敏捷圣贤：嗯，真羡慕你们公司！最后一个反模式是膨胀的构建，导致反馈延迟。
　　阿捷：膨胀的构建？
　　敏捷圣贤：譬如，把太多的任务添加到提交构建过程中，比如运行各种代码自动检查、统计工具或运行性能测试，从而导致反馈被延迟。
　　阿捷：噢，这个我们倒是应该引起足够的警惕。
　　敏捷圣贤：其实，还有其他一些反模式的，这些持续集成CI　反模式会妨碍团队从持续集成实践中获得最大的收益，所以一定要想办法限制这些反模式发生的频率。
　　阿捷：是啊！对我们没有多少持续集成经验的团队来说，持续集成像一块吊得很高的饼，看得见却摸不着。要做好持续集成并不容易，但我们可以使用持续集成的思路，来接近持续集成的目标。
　　敏捷圣贤：嗯，加油！我有点事情，先下去了。886。
　　阿捷：886。
　　

第11章　你开车，我导航（1）
Among　any　three　people　walking；　I　will　find　something　to　learn　for　sure。　Their　good　qualities　are　to　be　followed；　and　their　shortings　are　to　be　*oided
　　三人行，必有我师也。择其善者而从之，其不善者而改之。
　　——孔子
　　阿朱上次跟阿捷谈过持续集成后，第二天就召集所有的人开了一次会，把自己的想法跟大家讲了一下，大家纷纷说好！并当即进行了分工，阿朱和阿紫负责产品自动安装和验收测试中的自动化，大民、小宝负责自动编译、自动UT、自动打包部分，最后再由阿朱进行总的集成。因为TD的OSS　产品很庞大，再加上历史积累下来的回归测试用例很多，大家决定将持续集成、自动测试的频率设为每天进行一次。大家还为整个过程起了一个很好听的名字　——“AutoVerify”，意指自动进行产品的验证。同时大家还讨论了一些实现细节。
　　大家晚上下班之前，把自己Check　Out出来的代码Check　In到代码库中。AutoVerify程序会在每晚8：00自动从代码库中提取最新的代码，自动进行编译，编译成功后同时启动两项任务：一个进程进行自动UT，另外一个进程进行打包并自动部署到测试环境中。这是因为UT的时间非常长，需要两个小时左右才能跑完全部的868个测试用例。这样二者并行进行，可以节省两个小时的时间，多跑一些回归测试用例。虽然也有可能UT测试用例失败，但应该是不影响产品在测试环境下运行的，可以打包并安装。安装成功后，开始自动回归测试。
　　因为历史遗留下来的测试用例太多，一个晚上不可能跑完所有的测试用例，应该只跑一些核心的最重要的测试用例，这个筛选工作由阿紫负责。只有在周末的时候，利用两个整天的时间，才把所有的测试用例全部运行一遍。AutoVerify需要自动收集统计信息，譬如运行了多少个测试用例，通过率是多少等，把这些结果汇总下来。在第二天早上　9：00，AutoVerify自动把一个晚上自动验证的结果通过邮件发给阿朱和阿捷，由阿朱负责检查。为了减少垃圾邮件，只有在任何一个环节出现问题的时候，AutoVerify才会把邮件发给大家。此时，阿朱负责把出错日志转给相应的人，收到该邮件的人要第一时间解决。
　　在讨论完AutoVerify后，大民利用剩余的时间，把XP提上了议事日程。
　　“我们这次实际上一次性地用到了XP的两个重要实践：持续集成和自动测试。其实，XP还有一些其他的很好的实践，有些已经通过Scrum这个框架体现出来，譬如小发行版（Small　Releases）等，但是XP其他一些编程实践也还是值得我们尝试的。”
　　“嗯，我赞同这个观点，Scrum本身没有规定具体的编程实践，我们正好可以用XP来补充！大民你接着说一些适合我们自己团队的XP实践吧！”阿捷说。
　　“第一个应该是结对编程，其次是编码标准、简单增量设计、重构、测试驱动开发等，还有代码集体所有权。”
　　小宝插了一句：“关于代码集体所有权，其实咱们已经做得很不错了！大家看，咱们因为模块多，代码多，一直也没有也不太可能规定具体哪块的代码归谁拥有，而是任何一个人都有权修改任何一段代码。谁破坏某个模块，谁要负责进行修补。”
　　“嗯，这点我赞同。不过我想明确提出来，强调一下，我们应该继续保持这个优良传统！同时因为代码归集体所有，所以大家就都要遵循统一的编码标准才行。”　。　想看书来

第11章　你开车，我导航（2）
“没错，我们历史遗留下来的代码太多太杂，这里面既有老美写的，还有印度人写的，再加上咱们自己写的。真够百花齐放的！”
　　“是啊！短时间内，我们是不可能吧所有的代码都统一起来的。虽然也有一些类似aStyle等自动化代码美化工具，可以一次性地把所有代码整合成符合统一编码标准的形式，但这样做的风险实在太大！万一出了问题，因为所有的代码都改动了，反而没办法跟踪，不容易解决。”大民显然仔细分析过这个问题。
　　小宝点了点头：“我想我们可以一步一步来，只有我们需要改动哪个文件时，才对该文件按照编码标准进行一次优化。不过话又说回来，我们现在的编码标准有点乱，也有点过时了，需要重新整理一下才行。”
　　“要不这个任务就交给你？”阿捷问道。
　　“行啊！其实我已经整理了一半了。”小宝的积极主动性还是挺高的，“我们原来有一个基础版本，但有些东西已经过时了，另外还要加些新的规则进来。”
　　大民接过话头：“关于增量设计和重构这块我们做得还不够，当然这也是有历史原因的。咱们以前一直都是瀑布式开发，非常重设计的。仅仅针对设计，咱们以前的流程会产生概要设计文档、外部接口文档、详细设计文档、测试策略、测试计划等，从敏捷的角度来讲，我们应该做一些简化。”
　　“嗯