这周进行了一周的Scrum演练，谈谈感受。
其实并不是完全意义的Scrum，只是引入了迭代的概念、迭代开始的项目会议和进度管理，等这次周期结束还打算进行回顾展示会议。
要说这次引入开始的项目会议，还是有很大作用的。会议本身是个让开发者明确产品需求的时机，两个前端能在会议上明确讨论需求的大致实现方法，同时所有人能对别人做的事情有更好的了解。
一些经验：
在会议开始前，要做好backlog的准备工作。这个是Scrum master要和产品在会前得出结论的，包括足够的需求和需求的重要度。我在这次实践还让产品经理去估计项目的时间（按照人天，最短0.5人天为单位），目的是让产品能感受到他自己的时间估计和实际时间的偏差。不过后起来看这个可能会效果不大。
为这个会议留足讨论的时间。如果输入的需求足够细致，自然时间就不会很长。但是一旦需求不够明确，没有足够的时间就会导致讨论不够细致，为之后的开发带来隐患。不过会议中间应该注意休息，大概一小时休息一次的节奏会比较合适。
会上要让全体一起估计每个需求的时间，哪怕这个需求最后只归结到某个人去做，也要让大家一起参与。一方面当大家偏差较大时，说明大家对需求的理解不一致，需要继续讨论，另一方面也是尽量阻止有人思想溜号，只关心自己的部分。
会议上要合理将需求分解为可控的任务，如果是新功能，分解的任务需要包含测试和返工的时间。对于很纠结的产品经理，一定要把任务拆的尽量细，然后争取在每个任务完成后进行反馈，这样能尽早展现做完的形象。
Scrum Master可以记录每个需求的讨论时间，用来衡量需求本身质量的高低。如果一个需求的质量还没有达到可以开发的地步，就会有大量的时间花费在这个需求，确认各种细节和实现，导致这个需求的讨论时间非常长。这次有两个需求的讨论时间超出了30分钟，最后的实现阶段这两个需求都出现了延期。
在一开始，可能还不会有很好的方式做scrum log，我现在都是自己用number来追踪项目的完成度和时间。不过另一方面的经验，scrum log的维护可能还是要有一个专人来完成，不然慢慢就没人做了。
不过现在trello的用法很奇怪。居然要求第一阶段的request尽量空，而第二阶段的plan却堆满了东西。从trello里完全看不出一个迭代内应该做的事情。反正事情我劝了，不接受我也没办法。如果以后做Scrum，需要在各种视图上都明确出迭代的阶段，一方面让产品了解什么时候该准备需求，什么时候该讨论需求，另一方面让团队有节奏感，知道什么时候应该突击功能，什么时候应该重构代码。老大现在一直不愿意让团队有喘息的机会，生怕闲下来出现偷懒摸鱼的人，唉……