近期看到一些观点。关于敏捷开发各种不好用的观点，来源于水木社区，有兴趣的朋友能够自己去搜索。这里就不罗列了，只记录一些眼下我在一个新团队中推动时看到的问题。以及论坛中一些观点涉及到的错误的点。今后可能会公布一系列这方面的文字。随笔随写了。
1，水木上某人说在某国企应用敏捷开发，结果一个站立会议开了35分钟。
从这里就能够看到几个应用错误：
第一，该国企纯粹是形式上的站立，而内心中的传统会议形式仍然没有不论什么改变。不知道是哪家咨询公司如此提供咨询服务，真是无语了。当然太多的人都只懂得本本主义，知其形。而不知其本。
第二。站立会议的总时长应该是在3-5分钟内能够结束的。假设结束不了，就须要考虑一下几点：人数是否过多。内容是否应该精简，议题是否超过边界。
其它的看以下的条目吧，还有非常多相应错误。
2，站立会议的记录。合并，项目组的方式是对的，可是，我不知道是否真的运行了，还是说。就是问了一下，或者让大家写个东西发给他。一定要有一个状态，不是背书，这个形式有非常多积极的作用。
站立会议。必须是站立进行的。目的是为了加快进度，大家不至于迟延，另外。站立会议的内容就是说明发生了什么和即将发生什么，关于为什么发生或者有没有改进的方式等等的一切都不须要在这上面讨论。
3，每天完毕的工作量。标记状态和百分比。
项目经理要去配置库中进行核查，是否说得一致。至少内容是否相相似。
比方，说加入了多少行代码。改动了多少行。通过diff来检查一下，几乎相同即可了。
假设说完毕了百分之多少，那就标记，下一天总不能比这个少。假设少，就要说明原因，为什么会降低，是前面评估错误。还是遇到风险。或者做错了。
4。这些东西都要全部的人都看到。每一个人要了解别人做的事情。
这样便于相互配合。和进度的展开。
眼下的这个项目组由于刚刚開始启动，非常多的新人，所以，只能从基础開始构建和习惯。
此文中部分内容将来会涉及到项目度量的基础和延展。并非只作为敏捷开发的一个实操过程来记录的。