主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

因为我现在这个项目是个内部客户项目，最大的领导已经下了死命令必须在年底完成，但并没有说具体要完成哪些需求。所以PO有恃无恐，知道最后的验收只能由他来决定是否通过，所以他只管不停地提出各种需求变更，至于开发团队能否完成不是他考虑的事，就算完不成，最后的板子也不会打在他的屁股上，所以连Poker-plan都开不起来，不过这种恶劣的项目环境恐怕就不是软件工程所能解决的了。

因为他的出价永远低于其他人啊，那其他人还干什么。

当然这个所谓水平的定义本身就有二义性。

1. 我经历过不少项目，团队成员能力比较强的，整体生产率反而不高。因为想法比较多，大量的时间都花在讨论和控制上去了。

2. 团队成员个人能力比较弱的，有1，2个核心人员能力比较强的情况下，整体生产率反而比较高。每个人反而都可以发挥最大价值。

我个人觉得agile的目的还不是为了解决生产率的问题，而是为了适应软件开发环境已经发生大规模变化的情况下进行的适应性调整。agile更强调人性，说白了也就是要把软件开发回归到一种正常的普通人的工作状态，打破以往过于神话的地方或者非常个性化的方式。agile更强调团队的节奏感。强调团队工作，所以考核单个人的生产率，意义不大。

从这个角度看，agile不适合所有项目。

比如牛人出价5POINT，但他没空做，另一个人有空，但他的出价是10POINT，SM就必须给PO报价10POINT了，显然这对PO是不公平的。

团队和个人的评价恐怕不能算是敏捷的问题域，也就是敏捷本来就不是用来解决这个问题的。这是另一个层面的事情，比如HR。

通常我们会把最有价值的东西让牛人去做，或负责大部分。另外SM决定的估价通常也是一个平均值，而不是做这个Story的人的估值。牛人报5点的东西，也许估出来是8点。

公平问题一直是存在的，只能做到相对公平。我觉得需要强调一点，客户面临的是一个团队，而不是一个个单独的程序员。这是敏捷的一个核心价值。

另外，楼主还没讲完，这个问题也是有其他机制平衡的。

报价是平均值，而不是最低值， 牛人报价比较低的情况，要向大家做出解释，为什么会这么低，别人也会做出解释，比如这个技术我不熟悉，我估计一般人要多花多少时间云云。自然就把这个价格抬上去了。 而且有些agile的做法，这个报价是谁做谁报的，就算我觉得100天做完一个helloword，只要我坚持，别人也不有异议。

另外在planning game上选择task是整个团队的任务，而不是某个牛人的事。scrum不以个人的velocity作为考核标准，所以有些牛人在这种agile过程中要么转变，要么就很难生存。

传统开发模式中，往往是以1，2个牛人为核心的金字塔结构，然后带着一般小的打杂，强调发挥牛人的工作能力，不是太注重菜鸟们的感觉，这和agile团队是不一样的。agile强调参与感，所以这方面考虑，效率确实不咋地，但是人际关系会比较容易相处，团队气氛会比较好。

打个比方，不做agile的时候，做不完任务，你要是不自觉加班，老大就会鄙视你。 做agile了，要是你完不成任务，你做不完在那加班，老大还要过来劝你。然后还不可避免分析一下，是不是任务分配的不合适，是不是评估工作量过重等等。或者你个菜鸟选了个超难任务，也不可以说，哦，你搞不定，谁谁更好。要让你去搞，你搞不定的时候团队其他人还要想办法来帮你。这样其实某方面是牺牲了强人的利益来帮衬弱者。 但是长远的看，这种工作环境又容易造就机会，大家都没什么压力，可以随着自己喜好做事。

另外这方面老外和中国人差别很大，我接触老外的牛人性格方面都还比较好，对白痴程序员一般都比较耐心，不想中国人，解释第二遍就不高兴搭理你了。agile背后其实真正难以操作的是这种程序员文化的差异。

不考虑需求变更的时候，用传统方式往往有更高的效率（不要讨论文档，测试那些问题）。 在非agile项目里，我们接到一个任务一般是这样做。

1.招募一个核心牛人，以其为核心组建团队

2.牛人对任务进行分解，自己承担核心部分， 再把其他边角料分散给食物链各级人员。

这个模式的开发效率往往都比较高，只要找对了核心人员，就基本上成功了。

但是问题也很突出

1. 高风险性，牛人变成truck number。一旦闪失，整个项目就完蛋。

（虽然有cmm，有各种重过程各种文档，但是几十年下来大家还是发现，传统模型基本还是这个调子，那些文档和过程装饰性作用比较多）

这点对小公司可能无所谓，对大公司就是个大问题。大公司运营，关键考虑的是风险。当年我在某家公司做agile的时候，老板最满意的不是生产率，而是我解决了人员流动的风险。

2. 食物链低层人士得不得足够的成长机会，时间久了，流失难免。

项目经理只会考虑进度和质量，工作安排上只能尽可能考虑效率，不会太关心个人成长。

3. 牛人不的不长期担任核心工作，压力大，和团队人员梳理感也重，资历越老，加班时间和压力也更相应增加，过了一定年纪考虑再考虑家庭原因，很难长时间持续。再考虑到项目需求不断变更带来的压力，也往往就意味着更多的加班，更多的压力。

这种模式下，虽然有少数食物链底层可以凭自己能力出头，但是也基本摆脱不了做牛人的命运。我认识很多技术强人过了30就转行，主要不是钱的问题，还是做下去已经没有什么乐趣了。

但是要说生产率，那还真是不错，当年我年轻的时候高峰期一天要写2k代码，而且错误率很低。

现在做agile就不一样了。团队里理论上是没有金字塔结构的，人人平等， 一个任务接下来，如果你还按这种模式做，其他菜鸟就不干了，每次回顾的时候就会说，没学到东西，老板也会找你谈话。所以架构也要做，任务也要分解，但是这个过程中，你必须考虑到所有人的参与感。以前做设计，2个人核心人员讨论完了就完了，再另外找个人核心人员评审，这就算完了。现在不同，团队里所有人都要参与讨论，不懂得地方你还要耐心解释。设计弄完，开发的时候也是代码共同所有，谁都可以改，谁找你要求解释，你也必须回应。这么下来，效率怎么可能高？

但是回头来说， 其他人的成长机会就多了。 长期看，效率问题可以有所缓解，更重要的是项目风险降低了，因为责任不再由单纯的1，2个人承担了。另外这个过程中，因为交流沟通比较频繁，所以团队人员之间的关系会比较流畅，工作气氛也会比较好。比如自己年轻的时候，总是一个人带着耳机干活，现在基本上都和一些小孩子做pp，一天有说有笑的就过了。

而且这个过程，加班是不ok的，老板不能因为项目进度要求你加班。你说这么玩法，程序员能不喜欢么。所以现在搞agile的，叫的最欢的就是一些大公司。

传统过程中这么做是无可非议的。但是agile不行，由谁做某件事是团队自己决定的。也就是说如果这事牛人不想做，或者有人想跟牛人抢，那还不一定到牛人头上，只能协商，协商无效的事也不是没有。而且pm往往基于风险控制和其他理由，可能平衡一下，鼓励其他人来做。

以前有个简单的方法，划分个若干登记，让程序员不记名自己投票。基本还是公正的，就是看到某pm很无耻的把自己列为第一等，反正谁也不知道票是怎么记得了。

项目控制一个层面和实现一个层面。当然在高层次上的讨论，如Plan game等都会对成员的水平有提高。但真正提高的还是在实现的具体操作上，也就是在代码层次上的事情。菜鸟要提高就必须动手做，而且必须掌握方法。敏捷在这两方面的帮助是非常大的。

hr说到底只是辅助性质的，解决不了根本的问题，公司要把你做牲口用，hr能说什么？

特别是通过pp这种方式，成长都比较快，当然客观上就牺牲了牛人的一部分利益了，另外扯皮啥的，实在很不咋样了。

agile不强调效率，强调的是平衡，记得看过一个报告，说一个最高效的agile团队但结局比较不好。

其实老外想的也对，毕竟你和同事带的时间要比你跟家人还久，让工作气氛好一点，这也算是一种享受生活的方式。

不过你能做的事是要让po明白现实，如果最后什么都拿不出来，大家一起倒霉。