七、验收测试

1. 需求的沟通 产品的设想，经不起电脑前真刀真枪的考验
   • 过早精细化： 业务没启动，开发就要精确知道最后得倒什么；开发还没有评估项目，业务就想精确知道最后要交付什么
     1. 不确定原则。观察者响应/不确定原则。看到时就会冒出更好的想法
     2. 预估焦虑。评估会存在变数，即使掌握全面准确的信息。
   • 迟来的模糊性：需求中每一点模糊指出，都对应着业务方的一点分歧
2. 验收测试

九、时间管理

1. 会议 会议是必须的 会议浪费的大量时间

• 权衡是要参加：对工作带来切实显著的成效；
• 参加后也可以离席：和会议无关一体；讨论被霸占；
• 确定议程与目标：目标是什么，讨论哪些东西
• 站会，每人1分钟
• 迭代计划会议。选定需求backlog（会议前需要评估开发时间和业务价值）建议2-3小时内
• 迭代回顾和demo展示。总结过程展示成功，1小时之内。
• 争论反对：结束不能5分钟解决的争论，依据信念，而不是事实；不要强力结束争论，依据数据；避免一言堂的会议室，如果有就避免参加；
  1. 注意力点数 编程需要持续投入精力和注意力，注意力是稀缺资源。 睡眠；咖啡因；恢复，换脑子，运动、做其他事情；输入输出，培养创造性思维；
  2. 时间拆分和番茄工作法：固定时间段免打扰
  3. 要避免的行为 优先级错乱
  4. 死胡同：一条路不通时，试试其他路
  5. 泥潭：比死胡同更卡帕，明知能看到目标，但又遥不可及。 身处泥潭还要固执前进，是最严重的优先级错乱。继续前进无异于欺骗自己，欺骗团队，欺骗公司，欺骗客户。一边走向大家共同的炼狱，一边告诉其他人，所有问题都会解决。