项目那点儿事(十五) ---兄弟连火力全开[团队合作]之高效的编程机器

不合群的人离开了，框架基础建好了，现在这样一个安定团结有枪有炮的军队，可以开赴前线了。

等等，我们来看看我们祖先是怎么打仗。打仗前一般会搞个仪式，说说自己多么正义，敌人多么无耻，以达到“出师有名”。

按照古人的经验，我们也来做一下。先开个誓师大会。说一下现在项目情况，同志们困难是有的，公司已经准备好庆功的美酒和奖金了，而客户也在等待我们的成功，我们现在要全力以赴了。和传销差不多——洗脑。上下同欲者，胜！

在开打前，我先说明一下，我们团队的指挥方式——任务驱动开发。

为啥要搞个什么驱动啊？直接上去打不就行了吗？

打是没问题啊，可问题是仗怎么打？我总不能像流氓群殴一样，来个街头霸王十三式，大家一起上吧。有组织有配合，退有攻进有守这才是正规军队与流氓团体不一样的地方。要做到正规军队的做法，必须要号令通行。记得孙子为了号令不通的问题还杀了两个美女（不是他的）呢。

我见过的项目（有管理流程的，野路子不算）基本上是两种号令，一种需求驱动，一种任务驱动。

需求驱动，使用这种方式的项目，项目中的人员对此项目的行业和技术（必须有成熟的开发框架）都非常熟悉，可以根据需求直接完成代码。你把需求中的一块丢给程序员，就行了。一般二次开发的团队可以使用。我也见过首次开发的团队用这种模式的，结果做得东西是你打太极我玩拳击，完全不搭界，超级的不靠谱。

任务驱动，多用于多项目或开发人员不熟悉的行业开发。由项目经理或领域专家以及架构师，提出任务，开发人员完成任务，即可。至于这个任务在整个项目中的地位，这个任务具体完成什么业务，都可以忽略。基本上就把程序员当苦大力（学名民工）来用，反正你只管在这里挖口井，至于客户本意是想建个烟囱（图纸看翻了），也与你无关。

我这个项目就是用任务驱动来做开发的，原因是我的兵不懂业务，一点都不懂。我就把需求和设计分解成任务来做。说到分解任务，在项目管理中有个专用术语——WBS（工作分解结构）。

就是把一个项目拆成多个（暴多）的任务包，来完成。每个任务包完成即项目完成。这个和人类解决疑难问题的理论是一样的，把一大问题，拆成多个小问题，每个小问题都解决完成，大问题也就解决掉了。

拆分这个理论比较简单。不知道的同志可以关注，马路上写拆字的房子，过两天去看看建筑工人是怎么来做拆分的。
拆分容易，可拆分到什么程度是个问题了？建筑工人的拆简单点，直接拆成砖头（完整或不完整）级别就行了。如果我们也学习工人阶级这种精神，那我们就要把项目拆成每行语句了。这肯定是不现实的。

前面我们有拆用例的经验，可以借鉴一下。简单点，把每个用例做为一个任务来做，复杂点，把每个用例拆成多个任务来做。拆分遵守下列原则：
1、 每个任务不要大于8个人时，就是一天的工作量
2、 一个任务安排一个资源（人）来完成
3、 保证在一个资源（人）在同一时间内只有一任务在执行。

拆好任务，我可以向团队下达号令了。可新的问题又出来了。

但项目经理可不是传令兵，发了任务要回收的；也不捡破烂的（现在叫拾荒者）收回来就不管了，我们要看看任务执行的如何、是否按要求完成。

古代击鼓鸣金（锣）这是基本号令，为了下达号令，指挥官用旗号，也有诸葛亮这类猛人用羽扇下令。我可不能在包里放个旗子或扇子，所以我们也需要个任务管理工具。

依照标准化文档，我们项目组的邮件是用OUTLOOK收的。OUTLOOK有个任务的功能，可以收发任务。

大家每天都开机启动OUTLOOK，设为每五分钟自动收发一次，现在开始我们工作的内容都可以在OUTLOOK上查到，这下要有人耍赖皮推责任，我可以欺负死他了。

用了一个月左右，感觉还不错。但是任务开始多了，程序员还好说，我想要查看某个任务的情况，或某段时期我们组做了什么，就非常麻烦了，因为OUTLOOK没有统计功能。

在这种情况下，杨威利推荐了微软的share point，这个东东倒是不错，只可惜最多5个人，原因没搞清楚，可能是服务器系统的服务数不足，也可能是share point版本不好，总之盗版的。而且share point没有自动提醒功能。看来这条路也不行。公司倒是有一套BUG管理工具，但界面太复杂，很乱，用这个系统还培训，也不行。齐猛人一狠心，直接自己做了一个任务管理，不过比较简单，功能也仅是收发任务。作为工具我的本意就是够用就行了。小齐还挺细心的，加了个客户端，可以自动提醒是否有新任务。

好现在这个任务管理工具开始使用。程序员每天收自己的任务，他们的工作只是完成任务（成机器人了）。

其实我们的任务内容并不太复杂，只是指定一个人去完成某个用例，或修改某个功能。任务中会说上原因和希望达到的效果，而具体实现参考技术规范，所以程序员的动脑空间还是蛮大的。

现在号令通行，大家开始做事吧！这时齐格飞是不需要做实际开发的。按说这时的齐猛人可以休闲了，但事实不是。

这一天米达麦亚遇到问题了。

米达麦亚，建国三十三年生人，出生于江西宁都，工作经验2年

米达遇到的问题是，在他的任务中，有一部分要用图表来完成，但系统基类中没有图表这一部分，根据开发规范，米达找到了齐格飞。

米达把自己遇到的困难向齐格飞说了，齐格飞决定帮助米达来搞定图表的事。说是帮助实际上米达根本不会管如何做出图表，只要小齐做好，他来调用就行了。

米达继续完成他的任务，并等待齐格飞的回复。

这下大家明白齐格飞是干什么的了吧。他是救火员（可怜的小齐，估计是个水命）。不可否认程序员在开发过程中会遇到各种各样的困难，这些困难可能会让程序员停滞很长时间不能继续工作。解决这种不可预估的困难，可能对于一个技术高手来说只要一个小时，而对于普通程序员来讲可能要想一两天。而在我的团队中程序员会把困难丢给齐格飞，齐格飞要从设计和技术两方面来解决这些问题，程序员们则继续下一个任务。我要让团队在最短的时间解决遇到的问题——好钢用在刀刃上。

看见了吧，我的程序员是工作下来不会停的，他们每天会不停的完成任务（好像很累），做不了的任务就丢给齐格飞（好像也很累），齐格飞解决后，再由程序员继续完成（都挺累的）。这种方式类似流水线工作。当流水线上发现坏品或无法加工的产品，就会丢到坏品区，由坏品区处理，处理完成后，再走到流水线中，而整条流水线是不会停止运作的。

如果你的坏品太多，齐格飞肯定不干了，那一定是在前期出了问题，就要停下来，重新设计了。

任务管理工具+救火员齐格飞+自动化代码工具，三板斧把我的团队变成一个高效的编程机器（可怜机器里的程序员），现在这部机器在开足马力工作。

附：孙武杀美妃

孙子（还是叫孙武吧，这个尊称说起来不太方便）被吴王阖闾找去，让他帮忙练兵。但这个吴王有点不相信孙武，决定让他演习一下。
估计这吴王今天心情不错，可能是后宫玩得开心了，就把后宫的宫女和爱妃都找出来了，让孙武练（恋？）一下。孙武倒是不含糊，马上把这些女同志，分成了两队，选出两个当队长，孙武也挺给吴王面子（也可能是居心叵测），让吴王心爱的两个姨太太（非正室）当队长。

刚开始这些女人就是笑，大家觉得好玩啊！孙武也挺谦虚，说自己命令下得不清楚，重新下达命令，这些女人还是笑。古代宫廷女人啊，都是卖笑的。平时向大王卖个笑，运气不好遭个冷眼，运气好的得个封赏，运气暴好的被宠幸一把（升级到卖身了），运气好到祖坟冒烟的怀个龙种。可惜这回是孙武，不是大王。

孙武发话了“不听号令者按律斩”。如果把所有的兵都杀了，那谁打仗啊，只能杀队长了。就把这两个姨太太推出来了，吴王过来苦苦求情，孙武不同意，就把这两个姨太太给杀了（和国家相比，两个女人耳）。之后这些女同志都不笑了，现在训练起来就好多了。

篇后话：

我想写了这篇，肯定会有人觉得我太不地道了，不把程序员当人使，光让他们工作不让他们学习。

“一将成名万骨枯”。因为我不是将，所以这些兵也不会成骨。我很希望在项目过程中，大家能边玩边学边干活，我也喜欢轻松的工作环境（因为这个被老板说了好多次）。不过你们放心程序员们不会太累，因为开发速度的加快，使他们每天工作时间在5-6个小时，不会满，而且工作内容较简单，1.复杂2.粘贴3.找小齐。所以不会太累。

其实真正累的是齐格飞，因为他要解决所有程序员（也就4个人）的问题，这些问题没有简单的，都是要技术攻关的，所以小齐的工作量倒是较大。说小齐是猛人就是这些问题他都解决了。

这里说到了孙武杀美妃，我们先不去想孙子是否被别的后宫妃子指使，杀了这两个姨太太，我们只说这件事中孙子的两个做法：
1、 不听号令者斩，这是保证团队稳定。这个在上一章我说过了，我也“斩”了两个。
2、 号令。是指挥的基础，所有人的生死都在这个号令是否正确中。

我们做项目，也是一样，不听话的人要严惩，下任务时要想清楚，你的任务下去了，就会有人执行，如果错了，那这个人时就浪费了。毕竟人时也是钱啊。