看到第六章中的“搞掂”一词,很疑惑,为什么不是“搞定”呢?百度了一下,看到了这样一种结果:“这一章出现了GTD,没想到这本书的产品chandler竟然与GTD也有关系,原来这个软件的UI设计师尹咪咪受到了戴维艾伦的Get Things Done书的影响,不过这里翻译为《搞掂》,而不是《搞定》,看来如果chandler早点发布,流行于世面上的GTD工具可能不会是omnifocus,而是chandler了。”果然知识的累计是异常重要的,这样就不至于在我读书时,脑子却处于“懵”的状态。
在第9章“方法”中IBM执行强制进度纪律的成功基于两条原则:(1)计划是强制性的(2)计划必须符合现实情况 ----“从底向上”,依据那些负责按计划执行的程序员的经验和知识而来,而不是“从顶至下”,靠管理者拍脑袋或对市场的期望而来。CMM这个沉重的软件开发成熟度模型在国内完全变了味,曾看着一个软件公司为了通过CMM4,编出一堆从来无人细看的厚厚的文档,CMM果然只重过程,而国内更把这种过程流于形式,通过CMM,只为了向用户抬高价码。TSP、PSP也看过,感觉相当繁琐,在国内都难于实行。2001年17位领军人物,提出了敏捷软件开发宣言,向这种笨重的CMM宣战,从此极限编程XP和SCRUM开始流行。Google让开发者把五分之一的时间花在个人项目上。这种管理方式在国内想都不敢想。
在第10章“工程师和艺术家”中的问题:编程是工程还是文学?是科学还是艺术?
在第11章中出现了一个神奇的地方:吃自己的狗粮。这种思路确实有助于提升软件质量和用户体验,想想连自己都不屑一用的软件凭什么去折磨用户呢?真的可以说是十分有趣了。
来源:https://www.cnblogs.com/xiangyu721/p/12271564.html