虽然这次所谓的实践一开始就是残缺的，但我还是希望能够从中窥探到一些敏捷的东西。

我们的首次sprint定为2周。产品经理没有，就我一个人顶了。blacklog定了一些，总觉得不是很靠谱。然后召开计划会议。下面是流程：

1. 简单介绍了一下项目和blacklog，
2. 大家把blacklog分解，
3. 进行估算，计算时间。
4. 认领。

通过看书等方式自学scrum的我对计划会议的理解差不多也就是这样，基本都是按照书上的内容来的，但是在随后的工作中却发现了一些书上没有写的问题。

blacklog准备的不够。我的想法是反正blackbog是需要变化的，何不之定义眼前的，以后的以后再说。所以就只定义了我认为的两周工作量的blacklog，导致的后果就是大家都以为没什么事情干把估计的时间都拉的很长。而且对这个sprint之后的工作很茫然。

解决的办法：要一次性把所有的blacklog都列出来，然后按照优先级选择，若有变化随时update，但决不影响当前sprint。书上其实有说按照优先级选择的问题，但是没有明确的提出一次写出整个项目的blacklog，可能这个是common sense，但我还是理解偏了。

Task是有依赖性的。按照书上的说法，我们把blacklog分成了大约1~2天的task，但是问题是这些Task是有依赖关系的。例如某一个基础的Task1需要2人天，如果task1没有完成其他所有的task都无法进行。而且task1只能一个人单独完成。那这一部分时间其他人无所事事。

解决办法：无解。我到现在也没想到很好的办法，我想这是一个任何项目和开发方法都会遇到的问题。我的临时解决方案是让其他人学习一下可能用到的知识，收效甚微。

估计时间的粒度太小。由于公司前一段时间让每个人都填写一个timelog（小时为单位）而且最近在学习GTD也是以小时为单位的。我觉得这是个精确管理自己的好方法。所以我把Task估计的时间定为人时。结果总共有400多人时，每个task估计的时间都是5的倍数，完全失去了用小时作单位的好处。

解决的方法：用人天吧……

Task没法估计时间按。当我在看到scrum方法中由developer自己估计任务时间，然后组织内讨论，最终确定一个较为准确的任务评估时间时，我兴奋不已。我觉得这个方法太好了，又科学，又高效，又有意思。然而实际应用中却发现很难。首先我们这次sprint中主要的任务是使用axure开发一个可交互的原型。之前谁也没做过，就有一个一下午的training简单介绍了基本应用而已。

解决办法：我觉得如果用有经验的开发人员，这个问题就会变小。而且粒度大一点，用人天也比较好估计。如果还是没法估计的话也不要瞎说，开会讨论吧。把具体方案讨论一下哪怕用一整天，也比sprint完不成或闲着没事干好。

时间是检验真理的唯一标准！还有很多问题，随后一一列出……