See Also
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,独立的开发方法学
