敏捷开发 效率 主要矛盾

之前和朋友聊天的时候说自己在使用敏捷开发，感觉效果挺好的，每天有新的用例就做新的用例，没有用例就改bug，总之每个迭代要完成至少4个工作量。

敏捷开发中工作量计算的方法：（其中每个用例或者bug的评估标准是是公司情况而定的，但是大致是相同的。）比如新的用例来了之后由开发人员去进行评估，这个用例是简单（一个工作量，简称一个点）还是一般（两个点）亦或是三个点（困难），如果用些用例已经超过三个工作量的范围那么就需要将这个用例进行拆分。举个简单的例子来说就是比如数据从页面收集，然后就是处理后存入数据库，最后是再次向用户展示，这其实可以拆分成两个用例收集存储是一个用例，获取展示又可以是一个用例。这仅仅是一个举个例子而已具体的情况还需要具体的分析。

下面想说的是当时朋友说的一句话让自己很有触动。我说我一个迭代能修改将近30个bug也就是将近六个工作量，然后朋友说他前天加班了，然后一天就修改了17个bug。当时自己很吃惊，但是转念一想这是不对的。

持久的高效率

一般的传统开发是不顾及员工的感受往死逼着干。这样的后果就是逼的少了员工自然就偷懒了，逼的多了时候员工做的工作多，逼的再严重一些员工就撤了（这也是为什么小公司职员的流动性大的原因）。平时开发过程中因为没有衡量的标准或者说没有一个合理的制度，所以每天的工作效率是不固定的，可能今天加班修改了十几个bug，明天不想做了就改了一两个bug，所以从宏观上来说整个效率是很低的。

还记得上学的时候老师总在说的一句话“快走赶不上慢不歇”，意思就是不要三天打鱼两天晒网、一曝十寒，要有持久性。无论是学习还是管理，不要在乎今天做了多少，明天做了多少，而要看一段时间内做了多少，要把整体的工作效率提升，而不是单纯的提高某一天或者某几天的工作效率，我们要的是持久的战斗力，不是瞬间的爆发。

抓主要矛盾

而且还有最重要的一点，员工修改的bug或者说做的用例是否是紧急的，是否是直接可以给公司带来效益的。这一点非常重要，费了半天功夫做出东西，并不是用户想要的，或者并不是用户特别需要的，用户急需的功能没有做，那样怎么能给公司带来效益呢？所以说做的多不一定就是好事，做的越多证明公司投入的资金越多，包括人力物力上投入的资源等等。换句话说就是每个月公司投入的钱是一样的，但是每个月公司的产出是不一样的。

员工每天要做的东西是有限的，但是要做的东西优先级是不一样的，要做用户急需的重要的东西，不重要的姑且要放一放，名其名曰“抓主要矛盾”！所以不能说有了bug或者有了用例不管三七二十一就去做，有些不重要的bug或者用例是不需要马上做的。先把重要的做了剩下的不重要的客户自己回去掂量需不需要再次投入资金去完善这个功能。要实事求是的去做，做客户真正需要的东西才是王道。

（蟪蛄(Platypleura kaempferi)(汉语拼音：huì gū) 又名“知了”）

不要过分的纠结于眼前，谁也不是只活一天。庄子的《逍遥游》中说“朝菌不知晦朔，蟪蛄不知春秋”我们不要做蟪蛄，更不能做朝菌，要有持久的战斗力；我们可以加班，但不能每天都加班。

不要把客户当做上帝更不要满足客户的每个要求，不同的需求要有轻重缓急之分。毛泽东的《矛盾论》中说“研究任何过程，如果是存在着两个以上矛盾的复杂过程的话，就要用全力找出它的主要矛盾”；我们什么都会做，但不能什么都做。