last sprint advantages:
32.1, save meeting time.because need to save engineers developing time.
32.2，重视dependencies, 主动push工程师进行dependency的沟通和解决。
improve:
32.3, 细分task, make sure every task can be finished by at most 2 days.
32.4, 重视ticket是否能按时完成。不能完成要说明原因。
32.5，重视risk，现在的白板上没有risk这一项，应该需要有。
scrum 要求：
（宗旨：规定一个好的流程，share一种好的工作方法。让工作降低风险，游刃有余。）
1，每人保持在两分钟以内。
2，提出dependency。在前两个task里安排解决dependency的task。（和别人商量接口，和其他team沟通都算是dependency）
3，提出risk.在前两个task里安排某些特别急待确认的risk。（提早确认ticket可行性，完成时间可控性）
2，细分task，保证每个task在两天之内完成。如果estimation time是11那起码要准备6个task条。（这样做事比较有计划性）
//************
32.2, 重视进度的掌握。重视工程师任务的完成，重视风险。我任务进度的掌握主要关注两方面，一个是dependency,一个是
risk.dependency我认为做的很好，值得发扬。risk在开发当中，我认为是工程师对于完成一个任务的技术的掌握，如果他不确定在技术
上能否实现，或者能够实现的准确时间，那么这就是一个RISK。降低RISK的方法，就是首先要明确有哪些RISK，一一列举出来，然后，
在task完成的最早开始的几天，着重去分析和验证risk，不懂的去请教别人，把risk解决以后，时间可控了，然后踏踏实实地按时去实
现代码。
*************//
scrum meeting每个人都说些什么：
1，更新任务完成情况。
2，能不能按时完成sprint plan？
不确定，就要提交risk。
确定不能，给出原因，让OL认可，重新plan。master记录下来，在review meeting上分析问题的原因。
3，有哪些dependency?状态如何？
4，有哪些risk？状态如何？team的建议是什么？
问题是：
1，不知道怎么细分task
需要与别人沟通确定的话，都提出dependency来。
出proposal的话，给出研究的阶段性计划，给出draft proposal提出的时间。
2, 不确定能不能完成？
3，确定一定不能完成？
risk包括:
1, 经验不足导致的对完成时间的不确定。
2，需求变更，或重新修改proposal.
3，各种原因导致的时间不足。