敏捷无敌-第17章
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
这样一句话，“宁愿高傲地发霉，也不要委屈地谈恋爱”，忘记这是谁的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等自动化代码美化工具，可以一次性地把所有代码整合成符合统一编码标准的形式，但这样做的风险实在太大！万一出了问题，因为所有的代码都改动了，反而没办法跟踪，不容易解决。”大民显然仔细分析过这个问题。
小宝点了点头：“我想我们可以一步一步来，只有我们需要改动哪个文件时，才对该文件按照编码标准进行一次优化。不过话又说回来，我们现在的编码标准有点乱，也有点过时了，需要重新整理一下才行。”
“要不这个任务就交给你？”阿捷问道。
“行啊！其实我已经整理了一半了。”小宝的积极主动性还是挺高的，“我们原来有一个基础版本，但有些东西已经过时了，另外还要加些新的规则进来。”
大民接过话头：“关于增量设计和重构这块我们做得还不够，当然这也是有历史原因的。咱们以前一直都是瀑布式开发，非常重设计的。仅仅针对设计，咱们以前的流程会产生概要设计文档、外部接口文档、详细设计文档、测试策略、测试计划等，从敏捷的角度来讲，我们应该做一些简化。”
“嗯，是有必要精简，但应该精简到什么程度呢？”阿朱问道。
“我觉得……”大民稍微顿了一下，似乎是故意为了强调：“够用就可以了！就是说不应该太多，但也不能没有。我们需要找出来对我们真正有用的文档，真正值得花精力的文档，然后做增量设计。”
“话虽如此！问题是咱们在大的流程上还必须按照公司的产品生命周期走，这中间会涉及很多的里程碑，而每个里程碑都要求有完备的文档，才能通过检查，进入下一阶段。”阿朱接着说。
“那我们先来看一下公司的PLC（Product Life Cycle）好了。”阿捷边说边在白板上画出公司的产品生命周期。
“虽然整个周期很长，但咱们必须通过的CheckPoint只有DEV和SHIP。咱们Team目前自己实施敏捷开发，也就是在DEV到SHIP之间。其实，这也正是敏捷软件开发跟CMMI/ISO 000等流程相互补充的最有效方式。其间的SQ虽然很重要，但不是必需的，公司强制得并不严。所以咱们只要在DEV和SHIP这两个CheckPoint上提供完备的文档就可以了。”
“DEV 在我们开发的启动之初，可以周旋的余地不多，这个念头就不用想了，该准备的文档还要准备好。不过，这个CheckPoint更多的是针对Marketing、Product Planner等除R&D以外部门的，对于我们R&D来讲，只需要给出一个
