目   录
    第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
· · · · · · (收起)