See Also

• Thinking Everyday
• Thinking Everyday II
• Thinking Everyday III
• Thinking Everyday IV

Shall We Talk?

如果会议中有人可以不发言,那他就没有参加会议的必要

项目经理最占便宜

传统团队项目经理最占便宜,所有人都向他单线汇报,出了事都找他,他知道所有的问题和解决方案,随着项目的进行,他的知识会被动的越来越丰富. Truck Number的一个实例

公交 vs. 地铁

说的是客户合作和开发节奏. 传统开发就像挤公交,影响路况的因素太多,这趟上不去下趟不知啥时候,所以每次发布都拼命塞feature. 好的开发节奏应该像地铁,稳定的持续的带走一批批乘客,交付一批批feature

南辕北辙

说的是提高开发效率为啥非得用敏捷,选择高效的平台,工具,库不也可以提高效率吗? 在效率上确实有很多方式. 而敏捷更关注有效性的问题. 你的平台工具和库都极端高效,就像你有最好的马最好的车最好的装备,可以一天完成十个feature或跑个一千里,可它们保证不了这是正确的feature,正确的方向. 敏捷也保证不了,但它利用一切手段让方向有所偏离的时候能尽快发现.

项目经理是个不好的暗示,Team Manager over Project Manager

Project Manager 是个不好的暗示，它或多或少的影响担当这个职责的人的行为. 如果你觉得团队建设重要,那么使用 Team Manager 这个头衔，会微妙的潜在的影响担当这个职责的人的行为. 我们说的是心理学.

天天都是新项目?　

通常刚开始一个项目,刚进入一个新团队的时候,积极性和创造力比较高. 那我们只需要创造一种环境,让大家经常有一种加入新项目的感觉

有时写文档有一种不安的感觉

可能此时应该有更好的沟通或传播方式. 文档代表的是单向的交流和较长的反馈周期,此时你的任务是否需要更及时和更频繁的反馈?

曾经的两个签名档

• IDE 不应该提供拷贝粘贴功能.
• 点穴? 画过. 我还给取了个特别好听的名字，叫葵花点穴手,后来听说一帮小混混还在那练呢… | 科幻? 写过. 我还给取了个特别好听的名字，叫极限编程,后来听说一帮小混混还在那练呢…

古典经济学与瀑布开发

犯了同样的错误: 假设知识和信息是完备的.

需求分析,是分析

不是满足用户的每一个需求,而是分析; 不是story写作,而是分析

与客户少沟通一句话,可能多写1000行代码

忘了收集证据了

兲朝夜谈

F-16坠机: 区别在于,每一次重大事故,或者事故之后,都带来了某种改变,阻止同样事故再次发生. 每次冤假错案背后,都会导致法律的修订. 在兲朝,是兲朝夜谈

站立会议最初文章的误导

不应该说昨天做了什么,今天要做什么,而是发现什么问题,需要共享什么信息等,就会好的多

测地线

空间的形状: 粒子沿着最(省力/短)的路线运动,测地线,人是不是也一样?

理论过分雕琢,意味着需要新的模型

代码设计也一样

TDD,独立的开发方法学

• TDD 最有价值的一个方面是它使得我们在同一时间只关注一件事情,要么是在编码,要么是在重构,永远也不会在同一时间做两件事情
• TDD 是一种推导设计和实现的通用方法,无论对简单情况还是复杂问题,区别在于这个推导过程时间长短的问题. 可对于复杂问题,无论什么方法都会时间相对长一点
• TDD的优势在于把 “把问题弄清楚” 和 “解决问题” 统一在一个过程中,并且在这个过程中随时可以以代码的形式验证对问题的理解
• 不能同时忽略设计和重构
• 不要掩耳盗铃,视而不见,有时设计是最简单的实现.