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

我们的首次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完不成或闲着没事干好。

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

Scrum这个词从前就听过，只知道他是敏捷开发的一种。敏捷开发倒是熟悉很多，学校图书馆里关于敏捷开发的书我都看过，书中的团队与方法让人向往，尤其是那贴满贴纸的墙和分享知识的气氛。从前在学校根本没有这样的机会环境和团队，但现在貌似出现了小小的契机。

认识、了解到实践scrum其实也就2礼拜的事儿，事情的经过是这样的：周五整理公司的TFS服务器时发现了服务器上安装了一个eScrum的软件，当时感觉是个软件项目管理的东西，就在网上查了一下，发现是集成在TFS上的一个Scrum的管理软件。再进一步的搜索中找到了很多关于Scrum的资料，当时的理解是Scrum没有XP哪么极端，并已经被很多公司采用（其实这个理解是很片面的，同时eScrum也关门大吉了）。这激起了我的很大兴趣，于是乎在infoQ上下了个电子书《硝烟中的Scrume和XP》看了一下午。其实这个书跟很多外国人写的敏捷书一样，很美很幻觉，总觉得跟我相隔很远，下班之后便不再理他。

周六，娱乐ing……买了本《程序员》，地铁上翻翻，看到国人所出的书《敏捷无敌》，小有兴趣。又是等车，无聊走进了上海书城，发现书架的角落里就摆着一本《敏捷无敌》,一翻竟是以小说形式写的关于Scrume和xp的书（自从看了《小强升职记》对这种像是的书很有爱）。饶有兴趣，买了……周日基本看完。

当时对Scrum的理解：

sprint：一个固定的时间2~6周，

blacklog：一些功能的条目，偏需求和功能的条目，有重要程度和故事点。由产品经理来编写优先级（这个我做不到，没有所谓的产品经理）。

燃尽图：

站立会议：

sprint计划会议：

计划纸牌等小东西……

虽然我知之甚少，但我相信实践出真知，读多少书也不如真正搞一把来的实在。于是乎……

周一开始实践，正好我有6个实习生，与其干一些可干可不干的无聊事情，不如来吧“敏捷“的。