笑谈软件工程

出版时间：2013-3  出版社：清华大学出版社  作者：陈建村  
Tag标签：无  

内容概要

《笑谈软件工程:烽烟中的敏捷》凝聚作者从事软件开发十多年来的思考与实践，从8个方面说明了如何从传统的瀑布开发过渡到敏捷开发。作者以诙谐幽默的文笔，于谈笑间揭示软件开发的现状，探讨Scrum的组成，解释何为精益，剖析软件工程的全新思维，同时还涉及软件架构、人机界面、测试等主题。

作者简介

陈建村，泰迪软件（Teddysoft）的创办人，从事敏捷开发顾问、教育训练、软件工具导入服务。毕业于台北科技大学机电科技研究所（信息组）博士班，是一位热衷于软件开发与经验分享的、实事求是的软件工程师。Teddy有超过17年开发商业软件以及参与软件研究项目的经验，曾发表30余篇国内外期刊与研讨会论文。他曾担任程序开发人员、技术总监、敏捷项目经理、软件架构师、敏捷顾问、敏捷课程讲师。对于未来，Teddy有一个梦想，希望改变人们开发软件的方法，让软件开发真正成为愉快而有趣的工作与创作过程。

书籍目录

PART 1软件工程的现状 Chapter 01.想看这本书的怨念有多深 Chapter 02.老板，软件不是这样开发的 Chapter 03.600多个bu9要怎么修 Chapter 04.软件工程不等于脏话 Chapter 05.这不是网络小说——软件项目场景 专栏A.小朋友不可以说谎喔 PART2什么是Scrum Chapter 06.Scrum到底是什么 专栏B.其实，Scrum是一种制度 Chapter 07.Scrum是很有内涵的 Chapter 08.就是这个光——Scrum+Lean+XP Chapter 09.导入Scrum？谢谢，再联络 Chapter 10.我不能采用Scrum，因为我的家人不同意 Chapter 11.导入Scrum前应该有的领悟——都市游击队 Chapter 12.100％符合Scrum精神——0与1的距离 Chapter 13.不完美的Scrum——逆练九阴真经 Chapter 14.故事要如何下笔？——啊！你练的不是九阴真经 Chapter 15.首尾相接的故事——这好比切蛋糕 Chapter 16.如何估算故事点 Chapter 17.故事点为何没有单位？——这是一种相对论 Chapter 18.故事写得好，才容易估算故事点 Chapter 19.Product Backlog长得什么模样 Chapter 20.【完成】的定义——功课写完没 Chapter 21.bugs——放下心中升起的怒气 Chapter 22.冗余——容错的基本方法 Chapter 23.代码共有制——让我们变成博格人吧 Chapter 24.结对编程的药效强不强 Chapter 25.回顾会议——有许愿池的功效 Chapter 26.ScrumMaster是个什么角色 Chapter 27.有牌的ScrumMaster 专栏C.闻过则喜 Chapter 28.导入Scrum——传福音的精神 专栏D. Teddy的初衷 PART 3精益生产，减少不必要的浪费 Chapter 29.软件也会有库存问题 Chapter 30.减少不必要的浪费——半成品 Chapter 31.减少不必要的浪费——多余的功能 Chapter 32.减少不必要的浪费——重复学习 Chapter 33.减少不必要的浪费——交接 Chapter 34.减少不必要的浪费——工作切换 Chapter 35.减少不必要的浪费——延迟 Chapter 36.减少不必要的浪费——缺陷 Chapter 37.有缺陷，就停掉生产线 PART 4开发软件一定要加班，有没有听错 Chapter 38.工程师与加班之间的爱恨情仇 Chapter 39.非加班不可——台湾经济奇迹的幕后无名英雄 Chapter 40.过劳死——软件工程无用论 ehapter 41.我可能不会在18：30下班 专栏E.秀才遇到兵 PART 5换颗脑袋——软件工程的全新思维 Chapter 42.学习犯错 Chapter 43.有问题才能解决真问题 Chapter 44.传承的风范 Chapter 45.傻到愿意相信 Chapter 46.造船的目的 Chapter 47.发语词，无义 Chapter 48.培育软件，还是组装软件 Chapter 49.对症下药 专栏F. ISO大战乖乖 Chapter 50.剽窃 Chapter 51.重复代码的力量 Chapter 52.时间日志的记录方式——这不是整人游戏 PART 6软件架构 Chapter 53.问题领域与方案领域 Chapter 54.实际案例：问题领域与方案领域 专栏G.一万个小时的练习 Chapter 55.要抄就要抄最好的——人人皆可成为架构师 …… PART 7人机界面 PART 8测试与集成 参考文献

章节摘录

版权页：   插图：   Chapter 63.为了错误而设计（1）：用户犯错 针对【人机界面】设计的议题，这一篇要谈谈【用户犯错】这个问题（大哥内心独白：我犯了全天下男人都会犯的错误）。Teddy几年前曾经在《探索》频道看到一个节目，讨论英国某航空公司发生空难的案例。内容是该航空公司的某架飞机驾驶舱前方（或侧面，有点忘了）的玻璃在飞机飞行中突然整片飞出去，导致飞机在高空中失压。事后调查结果发现，该飞机在前天晚上刚执行过一次例行的保养。为了避免】金属疲乏】，技师刚刚全部更换过用来锁住玻璃的螺丝。最后的调查结果发现，是这些螺丝出了问题，冈为它们的尺寸不合，全都小了一号（可能只差了0.01公分之类的）。 为什么螺丝会小一号？是买到【山寨版螺丝】吗？还是用到【瑕疵品】，或是原厂装货的时候搞错了尺寸？都不是，原因是技师没有依照【标准流程】拿取螺丝。标准作业流程规定，更换螺丝时，必须先翻阅技术数据，确认飞机型号与其所使用螺丝的产品编号，然后再到领料处依据个别产品编号来找出所要更换的螺丝。 如果这件事情发生在宝岛台湾，乡民们认为应该如何【处置】这位技师？人肉搜索，把他祖宗八代的数据全部公布在网络上。偷懒不按标准流程做事，危害飞安，抓起来判刑。 找一群名嘴在政论节目中连续痛骂他七天七夜，并开放【当事人澄清专线】让他在电话中为自己辩解，之后继续狠批他的辩解。 还好，这个事件是发生在英国，这位技师安然保存住性命。言归正传，为什么技师不依据【标准流程】办事？经过后续的调查，得出以下几大发现。 该技师已经有多次换过同型飞机螺丝的经验。因此，他自认为不需要再逐一确认详细的飞机型号与螺丝编号。 该技师平常的工作量相当大，而且当天已经工作超时（台湾的血汗工厂们，看到没，工作超时是很危险的）。在更换那架飞机螺丝的时候（当天最后一项工作），已经是深夜了，他想尽快完成后回家。 因此，技师就把旧的螺丝拆下，拿到库房去，用【肉眼】比对找出大小一样的螺丝。没想到这些新的螺丝从肉眼看起来虽然和旧的一样，但是实际上却小了一点点。 原本这一点点的差异并不会造成问题，巧就巧在飞机驾驶舱前方锁住玻璃的那块金属已经有一个肉眼看不到的细小裂缝，在高空因为压力及温度等因素而最后造成整片玻璃脱落。 最后，航空公司并没有特别惩罚该名技师，反而是检讨公司原本维修飞机的流程，以避免问题再次发生。

编辑推荐

《笑谈软件工程:烽烟中的敏捷》实用性强，非常适合软件工程相关专业和软件行业开发人员阅读和参考。