| 词条 | 敏捷无敌 |
| 释义 | 全书描述了工程师阿捷从求职到得到知名外企的Offer，通过坚韧的努力，在“敏捷圣贤”帮助下，在项目开发中从无到有学习并应用“敏捷”，经历次次冲刺攻克重重壁垒，最终顺利完成“不可能完成任务”的故事。书中既有紧张的项目进度，又有绝妙的总结（“敏捷精灵日记”），特别是结合实际给出大量解决方案和宝贵经验的方式，让读者身临其境，在享受阅读乐趣的同时，不知不觉间吸收技术知识。另外，书中关于职场现实的一些描写，也有一定的启发意义，引人深思。读者对象：技术开发、管理人员、业务分析师，以及对敏捷开发感兴趣的所有人员。 图书信息作 者：王立杰 许舟平 著 出 版 社：电子工业出版社 出版时间： 2009-6-1 页 数：348页 开 本： 16开 ISBN 9787121086601 定价：39.00元 宣传语用小说体的形式来讲述敏捷开发的故事，让复杂的概念变得通俗易懂。 不用高深的术语蒙人，在最大程度地帮助喜欢敏捷开发的读者了解到什么是敏捷开发的同时，增加阅读的快感。 作者简介王立杰，目前就职于一家美国公司，从事电信移动网络监测系统的开发与维护。在互联网、电信、电子和铁路等行业，在敏捷开发和项目管理等方面，具备多年实践经验。 2006年开始将Scrum应用到项目管理实践，致力于在中国的软件开发业界推广Agile理念和方法论，笃信以人为本，关注敏捷，专注Scrum和XP。 作者自序敏捷是怎样炼成的 很早之前，就有了写小说的冲动，写一本给程序员看的小说，写一本能够反映中国程序员生活的小说。曾几何时，“沉默寡言”、“喜欢独自思考”，甚至“木讷”成为程序员的标签。其实在每个程序员心中，除了对技术的痴迷，他们也热爱生活。他们改变着技术，同时也被技术改变着。他们是一群普通的人，也是自己心中的英雄。 之所以选择敏捷开发的主题作为《软件英雄传》的第一部，不仅仅是因为敏捷开发在这两年被炒得火热，其实更多的还是在于在今天这样一个软件工业化开发的时代，团队合作和项目管理已经成为每一个程序员不可缺少的必修课。而目前，有关敏捷软件开发方面的书籍95%来自于国外，或者中文翻译，或者影印，还没有一本真正写给中国程序员自己看的书。选择用小说体的形式来讲述敏捷开发的故事，让复杂的概念变得通俗易懂，不用高深的术语蒙人，可以最大程度地帮助喜欢敏捷开发的读者在了解什么是敏捷开发的同时，增加阅读的快感。 王立杰是我多年的好友和同事，在敏捷开发方面有着丰富的实践经验。我们一起努力将自己对敏捷开发的理解和开发过程中的所见所闻所想所忧结合起来，尽可能地用深入浅出的方法把理论和实践通过小说里的人物和故事讲给读者。有意思的是，由于之前我们都没有太多写作小说的经验，在《敏捷无敌》这部小说的早期策划阶段，我们首先将想要纳入这部小说的知识点、方法论、涉及的敏捷工具等像列Backlog一样罗列出来，而后在MSN和gTalk的闲聊中，在麻辣诱惑的福寿螺和毛血旺的飘香中，阿捷、大民、阿朱、阿紫、Charles李等个性鲜明的人物就诞生了。出现在主人公阿捷身边的爱情故事，则是希望每一个热爱技术的程序员都可以在忙碌的工作之余，找到自己生活的另一半。 由于交稿的时间相对有限，我们像组织敏捷软件开发一样将所有的章节分成若干个Sprint来完成，几个快跑下来，《敏捷无敌》的书稿就这样炼成了。目前《软件英雄传》的第二部——《安全至上》也已经在我们的策划中，在《安全至上》中，您不仅可以更深入地了解到软件开发中软件安全的重要性，而且会对现有软件开发模式中一些习以为常的做法产生新的认识。希望我们的《软件英雄传》能让每一个程序员在自己的“程序人生”中都成为英雄。 许舟平 2009年3月底 Richard和敏捷Richard是我接触最多的一个老外，因为大家一直一起做事，无论E-mail，MSN还是Conference Call，每天都要交流上几次。他们一帮老外负责做一个供内部其他Team用的测试工具，我们一拨国内兄弟负责做该工具所需的Library，有点像Visual Studio与MSDN Lib的关系，两者互为补充，缺一不可。本属于一条绳上的蚂蚱，但从未一荣俱荣过，更多的是一损俱损。Richard们是非常有创新精神的，一个本地使用的工具，为了更好地分层，不仅仅分成Server和Client，还创造性地使用了CORBA和ORB，融合了C和Java两大主流开发语言，进而带来了性能和维护上的N多问题。现在想想，一下子就能接触到这么多技术，应该说这是公司提供给我们所有人的一次宝贵练手机会。 给内部客户服务从来不是什么简单的事情。首先人家是客户，是直接给公司创造Revenue价值的，他们说的话永远是对的，虽然大多时候我们从未认同过，却没有任何理由来反驳人家；其次，因为客户离得太近（就在公司内部），可以随时跑过来冲你咆哮，或者给你一个Escalation。时间久了，出的问题多了，我们跟Richard们再也不能和睦共处了。因为内部客户提出的任何一个Issue，我们都必须做一个Root Cause Analysis，找出最初的罪魁祸首，当然最终源头无非是他们还是我们，万万不能往客户身上赖的。为此Richard们还专门发明了一个IMF（Issue Management Form）。 终于有一天，大家发现，这样内耗不行，还得一致对外才是正道，因为无论是我们问题多些，还是Richard们问题多些，对于那些难缠的内部客户而言，他们是根本不Care的。于是Richard们决定实行SLA（Service Level Agreement），逼迫用户签订城下之盟。简单讲，我们把需求按照容易程度分成A/B/C/D/E五类，为每类需求给出一个响应时间，Release之后可能会存在的Defect数目。同时，对于需求文档，客户自己要签字画押，即使错误，我们也会绝对忠实于原始需求来实现，出现任何问题客户自己负责。譬如A类需求需要4周的开发测试时间，一旦客户提出来，我们说这个需要四周的时间才能Release，回去耐心等待好了，中间不可以变更，如果要变更，那得走一个Requirement Change Management流程，然后我们再重新估算，Release时间再定。 这样实行几个月后，大家都欢欣鼓舞，因为内部用户的责难和Escalation骤降，大家的压力减轻了很多。一方面是一些内部客户觉得等不及我们的实现，就不再提需求；另一方面，在出现问题时，我们总会调出他们曾经自己签字画押的需求文档，让他们三缄其口。不过，大家都知道这样虽然可以保护自己，但对公司的利益来讲是一种伤害，但苦于找不到更合适的办法。 直到2005年底，在一次Conference Call上，Richard非常兴奋地跟我们讲用Scrum流程，足以解决跟内部客户的冲突。虽然Richard解释得很细，但大家还是听了个云山雾罩，约略记住了几个关键词：Agile，Scrum，Sprint，Backlog，Iterative development，Quick Response，Small Release。会后，下去恶补了两三个礼拜的Scrum知识后，就跟Richard们一起开始了跌跌撞撞的Scrum 之路，并渐渐地把SLA抛在了脑后。不过也奇怪，我们跟内部客户的关系居然变得越来越融洽了。 好景不长，在公司的一次WFM（Work Force Management）运动中，我们负责的内部工具成为首要目标，Richard们被迫离开了公司，而我们国内的这拨兄弟也被瓜分到了其他Team，开始真的为公司创造Revenue。没想到的是，Scrum的种子却从此在国内团队开始孕育、发芽，乃至开花。 短短两年过去了，一次又一次的WFM，让越来越多的天才Richard们离开了公司，虽然国内的兄弟们不用担心WFM，毕竟低成本的优势几年内还不至于让WFM烧到中国，但还是有兄弟因为各种原因，或者加入销售，或者四处走路，以寻求更好的发展。 渐渐地，中午一起吃饭的“饭协”日渐衰落，终于在一次“摸错门”后，曾经红极一时的“饭协”正式作鸟兽散，留下为数不多的几个人还在“深度套牢”中。 直到有一天开会，遇一新人，进来坐到偶旁边，怯怯地问：“你也是新来的吧？”当场狂晕！这时才发现，自己已经真的沉寂很久了，或许我应该把这些都记录下来，而且不能仅仅就是Scrum。 几年来，曾经看过很多书，但留下印象的不多，其中印象最深的无非是Perter F . Drucker的《旁观者》、Tom . Demarco的《最后期限》、Eliyahu . Goldratt的《目标》、《绝不是靠运气》、《关键链》、《仍然不足够》TOC系列。突然有一天，跟许舟平谈起写一本关于Scrum的书时，小说体的念头立刻就蹦了出来，并一拍即合，于是你就看到了《敏捷无敌》。 写书其实是一件很辛苦的事情，感谢这期间各个朋友的帮助、特别是博文视点的李雨来、胡辛征，以及尚未谋面的责编高老师。还有我的爱人和即将满两岁的豆豆。她们是我的动力，让我发现了幸福生活的真谛；她们带给了我无限的欢乐，是我的幸福源泉；她们让我明白了世界上无条件的爱和付出的存在。每每劳累时，想到这些，就又会动力充沛起来。 或许你看了，会觉得这不就是谁谁嘛、这不就是某某公司啊。呵呵，对号入座可不是我的本意，如果你能发现某个人或者自己的影子，就当是看了一场大戏好了，毕竟《敏捷无敌》也是虚构的。不是经常可以看到听到“本故事纯属虚构，如有雷同，概不负责”嘛，请享受这个故事吧。 王立杰 2009年3月底 目 录第1章 末日帝国——Agile公司的困境 1 国际上的竞争对手在技术上紧紧追赶，国内的厂商在客户关系和产品价格上已经屡次让Agile中国吃了苦头。如果说当年的Agile独霸天下，那现在的Agile已经日薄西山，而Agile中国研发中心更像是“最后的武士”，在努力维护着Agile中国的产品开发和质量的尊严。 第2章 重任在肩 22 阿捷知道，Agile公司的Project Manager实际是一个只有在中国才有的Title，并不在Agile公司正式的Manager序列里，在Manager Mail Group里也看不到你的名字。如果你干得好，可以从Project Manager升为Manager里最低一档的Line 1 Manager，也就是经常被人们简称的PM，不过这里PM是指People Manager，因为只有一线以上的经理才会具有人事权。如果你没讨大老板喜欢，那么这个项目结束，你也就会从Project Manager打回到Engineer的原形。 第3章 橄榄球与软件开发 29 敏捷圣贤：嗯！差不多！你知道在橄榄球中这个术语叫什么吗？ 阿捷：国内都叫司克兰。 敏捷圣贤：嗯，英文就是Scrum！意思是密集争球！实际上，我想说的Scrum这个敏捷项目管理方式，寓意就来自于“密集争球（scrum）”，寓指整个团队攒足力量，为了一个共同的目标，一起向前快跑！ 第4章 兵不厌诈——我们的第一次快跑 42 软件开发根本就没有什么灵丹妙药可言。虽然敏捷编程技术可以很快开发出优秀的应用软件，但不是说这项技术适合每个项目。在实施敏捷之前，一定对现有项目做好分析，要对症下药。 第5章 成长的烦恼 54 阿捷这几天一直很苦恼，再加上7月的北京已经开始变得炎热起来，阿捷就有点着急上火，不仅仅睡觉不踏实，连嘴边都起了大泡。从感觉上讲，Scrum应该是一个很好的项目管理模式，不然敏捷圣贤也不会推荐给自己，而且要不然像Google、Microsoft等大公司也早就放弃了。可能只是自己实践的方式不对吧，但却又不知道到底该怎么去改善，看来只能靠敏捷圣贤的帮助了。阿捷每天都上网，并待到很晚才下去，希望能碰到敏捷圣贤。 第6章 不仅仅是站立 69 敏捷圣贤：这个“立会”不仅能让所有人了解其他人在做什么，当前项目计划进展如何，还可以帮助大家解决那些阻碍做事情的问题，以及共享承诺。其实，这些都是非常有利于提高团队合作精神的。 阿捷：噢，可我们每天花这么长的时间开会，影响工作效率。有什么可以使会议保持紧凑有效的小窍门吗？ 敏捷圣贤：窍门和经验有很多，我自己总结了8条，想听吗？ 第7章 镜子反射 81 从前，有个古老的传说，讲的是当印第安人在赶了3天路后，就会停下来小憩一天，因为他要等着自己的灵魂跟上来。这跟敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，是一个意思。我们也需要等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。如果将项目开发比作一次征途，那么在项目中期进行短期休整是很有必要的。 第8章 我烧，我烧，我烧烧 91 “每天下班前，要求大家对自己负责的任务，给出一个还需要多长时间才能完成的估算。然后，把所的任务的最新估算值，累加起来，就是每天的剩余多少工作量了。譬如，截至今天，我们还需要170小时，那我们就在这个图上170左右的位置标注了一个点，用直线跟昨天的剩余多少工作量点连起来。时间一久，这个实际烧制曲线就出来了。” 第9章 没有规矩，不成方圆 99 在“冲刺”和“冲刺”之间，留几天缓冲时间很重要。团队需要一段时间做一下调整，干一些非Sprint计划中的事情。这段时间是一个很好的用来解决一些技术或者工具问题的机会。你会发现你慢一下后，会变得更有效率。这就是为什么叫“Sprint”的一个理由，你不可能无休止地冲刺。 没有规矩，不成方圆。由团队共同制定出来的Scrum团队规则，可以更好地保证Scrum的顺利实施。 第10章 持续集成 107 持续集成最大的优点是可以避免传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁地将他们对源码的修改提交（Check In）到一个单一的源码库，并验证这些改变是否给项目带来了破坏 第11章 你开车，我导航 118 就像Scrum一样，并不是所有的Team都有能力实行XP，也不是所有的项目都适合实行XP，要看实际情况而定。 XP中，多数实践方法是互相加强甚至是互相保证的，不能单单拿出某一个实践来单独实施，譬如结对编程，缺乏TDD/重构/简单递增设计等实践的有效补充，结对编程的效果可能会大打折扣。 第12章 背水一战 133 其实，不说阿捷也知道这个单子的重要性，可是关键是如何出奇兵制胜呢？阿捷对Agile公司的产品和技术实力都是有充分信心的。中国研发中心经过这几年的技术沉淀，已经完全有实力可以独自完成大部分OSS模块的设计、开发、测试和发布工作了。只是传统上还一直由美国那边来控制。阿捷有一个大胆的想法：那就是能不能利用敏捷开发的方法让中国Team第一次可以完成从模块设计、软件编码、系统测试到客户安装发布这一整套流程？ 第13章 纸牌、下午茶与软件发布 139 使用计划纸牌可以极大地提高估算速度。一次估算中，如果任何两个人的估算值相差过大，一定要停下来澄清后，再重新估算。 给团队配置两倍的人，并不能得到两倍的生产力。人越多，交流的成本越大，效率就越低。如果希望靠增加人员来提高软件团队的生产力，无疑是南辕北辙。 第14章 精益求精 153 在敏捷软件开发中，可以把当前Sprint要做的每个任务，通过这种可视化看板管理起来，每个任务只能处于这三个状态，当所有的任务都移动到了Done状态时，这个Sprint才能结束。这样应该更能让所有人清楚当前的项目状态，以及当前的项目瓶颈出现在哪个任务上。这样，就可以避免Burndown Chart所带来的假象了。 第15章 柳暗花明又一村 171 在一个Sprint执行过程中，如果遇到一些问题导致Sprint的原始目标不能实现，此时需要及时地调整目标。如果不愿意调整目标，任意延长Sprint的时间，就严重违反了Sprint的Time-Box特性，以后大家再遇到问题时，会自然而然地想再延长Sprint，那么Sprint快跑的意义也就不存在了。 第16章 滑雪、工作量与生产力 178 好的管理人员会想办法鼓励团队去创新，会选择预留一定时间让团队去思考如何创新，而不会压榨员工的每一分钟。 第17章 瓶颈再现 193 对于一个敏捷团队而言，再单纯地以测试人员发现的Bug数量，作为衡量其绩效的唯一标准，是非常没有意义的。 如果有一个核心测试集，能够覆盖用户使用一个产品的常用情形，会更有价值。对所有用户使用情形都做自动化测试是没有必要的。 第18章 决不是靠运气 207 大家对于敏捷软件开发的实质认识得更加清楚了。在这个过程中，不能为了短期生产力的提高，而做一些杀鸡取卵的事情。一切回归自然，按照事物本身的发展规律去做，一切也就会按部就班地进行：开发团队也不会为了追赶进度，而牺牲软件的内在质量；Product Marketing会重新认识客户需求的价值所在，做好优先级排序，而不会不明就里地要求全部完成。 第19章 羊群效应 220 羊群是一种很散乱的组织，平时在一起也是盲目地左冲右撞，但一旦有一只头羊动起来，其他的羊也会不假思索地一哄而上，全然不顾前面可能有狼或者不远处有更好的草。这就是“羊群效应”，也称“从众心理”。在一个组织中，特别对具有决策能力的管理者而言，“共同承担责备效应”（Blame Sharing Effect）的存在是导致了“羊群效应”的根本原因。 第20章 分布式开发的喜与忧 239 “最高指导原则就是沟通、沟通、再沟通。对于一个分布式团队，最重要的就是解决沟通的问题。因为缺乏面对面的沟通，由于时间、文化、语言的不同，需要付出更多的人力和财力才能获得预期的结果，而且小的误解也会迅速变成大问题。这需要在建立团队之初，就考虑好这个问题。沟通不要怕多，一定要充分才行。对这个问题，还有一个非常著名的康威定律（Conway's Law）”。 第21章 大地震 256 人才的流动是非常正常的事情，否则，社会也无法前进。但对于一个企业或者一个团队而言，人才的流失会是一种损失。流失人才并不可怕，最可怕的是领导人没有从中学到什么，没有搞清楚人才为什么会流失，没有采取亡羊补牢的措施。长此以往，招到的人才，还会不断地流失。 第22章 英雄已无用武之地 275 阿捷突然感觉到自己很累，从未有过的累。当阿捷刚加入Agile公司时，Charles就像一座山，高高在上。当阿捷第一次晋升Manager的时候，Charles就像在前面的领路者，自己这一年多来取得的成绩与Charles的支持和大度是分不开的。在心中，阿捷曾经偷偷想过自己40岁、50岁的时候会是怎样，会成为一个像Charles李那样的高级经理吗？会带领着自己的部门在这个瞬息万变的市场上乘风破浪吗？ 附录A 敏捷无敌人物介绍 285 附录B 敏捷无敌大事记 286 附录C Scrum名词列表 289 附录D 流行Scrum工具简单比较 294 附录E ScrumWorks,让Scrum更敏捷 300 附录F 从美式Scrum说起——一家美国公司的Scrum敏捷 项目纪要与思考 309 附录G 软件工程的进化论 314 附录H 精益生产 321 附录I X/Y/Z理论 323 附录J 约束理论(Theory of Constraints,TOC) 327 后记 331 |
| 随便看 |
|
百科全书收录4421916条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。