关于站立会议的一些常见问题

最近看到一些观点，关于敏捷开发各种不好用的观点，来源于水木社区，有兴趣的朋友可以自己去搜索，这里就不罗列了，仅仅记录一些目前我在一个新团队中推动时看到的问题，以及论坛中一些观点涉及到的错误的点，今后可能会发布一系列这方面的文字，随笔随写了。

1，水木上某人说在某国企应用敏捷开发，结果一个站立会议开了35分钟。

从这里就可以看到几个应用错误：

第一，该国企纯粹是形式上的站立，而内心中的传统会议形式仍然没有任何改变，不知道是哪家咨询公司如此提供咨询服务，真是无语了。当然太多的人都只懂得本本主义，知其形，而不知其本。

第二，站立会议的总时长应该是在3-5分钟内能够结束的，如果结束不了，就需要考虑一下几点：人数是否过多，内容是否应该精简，议题是否超过边界。

其他的看下面的条目吧，还有很多对应错误。

2，站立会议的记录，合并，项目组的方式是对的，但是，我不知道是否真的执行了，还是说，就是问了一下，或者让大家写个东西发给他。一定要有一个状态，不是背书，这个形式有很多积极的作用。

站立会议，必须是站立进行的，目的是为了加快进度，大家不至于拖延，另外，站立会议的内容就是说明发生了什么和即将发生什么，关于为什么发生或者有没有改进的方式等等的一切都不需要在这上面讨论。

3，每天完成的工作量，标记状态和百分比。

项目经理要去配置库中进行核查，是否说得一致，至少内容是否相类似。
比如，说添加了多少行代码，修改了多少行，通过diff来检查一下，差不多就行了。
如果说完成了百分之多少，那就标记，下一天总不能比这个少，如果少，就要说明原因，为什么会减少，是前面评估错误，还是遇到风险，或者做错了。

4，这些东西都要所有的人都看到。每个人要了解别人做的事情。

这样便于相互配合，和进度的展开。

目前的这个项目组因为刚刚开始启动，很多的新人，所以，只能从基础开始构建和习惯。

此文中部分内容将来会涉及到项目度量的基础和延展，并不是仅仅作为敏捷开发的一个实操过程来记录的。