- 关于需求
a. 需求应该来自用户,不是来自于竞争对手,创意需求需要客户的沟通和小版本和小范围的验证
b. 对于我们项目用户可以很好的反馈和协作,
c. 需求需要短可交付
- 关于会议
a. 每一个人在会议之前就应该明确自己要做什么,业务是什么,重点是什么
b. 会议应该是带着解决方案开的,而不是开会的时候讨论怎么做的问题
c. 每一次的会议和评估都应该有一个具体的可执行,落地的方案是大家共识的方案
- 交付
a. 交付的东西一定是实际已经存在的东西,可以看可以点的东西,而不是形式上的工作报告
b. 工作日报可以是任务的一部分,不一定是可视化但是可以通过控制台运行,在大多数场景下交付不应该超过三天,因为三天还没有交付肯定就是方向不对或者遇到问题了
c. 每个人都是自己的Product Owner每个人都需要对自己交付,每个人都都有自己的人迭代的历程,
- 积压工作项
a. 故事要有明确交付标准,有最小交付标准
b. 故事来源于用户 反馈和市场的判断不是个人主观的看法
c. 大的说公司是一个团队,小的说每个人都是一个团队,每个人都应该对自己负责,应该积极主动去完成现有积压项
d. 积压工作项工作量应该是由完成人去评估的,不是某个旁观者去评估的,如果存在激励措施,想完成的人不止一个人会形成一种良性竞争,落选的人也可以学习别人的解决方案从而提高自己
e. 所有故事都有自己的核心流程,文档,画图,面对面等方式一定要让执行的人完全理解
- 过去,当前,将来
a. 过去的事情需要总结,当前的事情要负责,将来的事情要准备
b. 过期的事情一定要总结,问责奖励,当前做的事情有可能是自己以后一直要做的事情, 一定要认真对待,将来的事情要做准为下次迭代做好准备
- 冲刺
a. 故事燃烧过程过一定要有可交付的节点,可以定义冲刺节点,比如一个15个工作日的项目如果想不延期那么最少要定义三个冲刺节点,这样在前一个工作节点延期后在下一个工作节点才有可能补回来
b. 冲刺节点不能每个都是特别紧张和累的,我们需要有时间的紧迫感同时要需要完成任务的成就感