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

这种情况下自然就会出现经济学中的比较优势了。同样时间下总有赚点最多的项目。不过原则上讲，简单任务就会过度竞争了。呵呵。

计件工作确实在这方面有比计时更优越的地方.

SCRUM体系下对每个item的报价,应该不单是对外的,同时也是对内的.只是可能要有个调整参数罢了.

在一开始划甘特图的时候,组内小组就应该选择自己的工作量,PM对其进行调整,保证大体上每个小组的perceived value大体相等(或是不等,但大家都能认可和接受).

然后PM指导(监督)Team Leader做好本小组内的工作划分,依然是一样的流程,确保每个组员都了解

1. 要干什么

2. 有什么回报

3. 有什么惩罚

并且签字确认.

如果说一个小组的perceived value是100 point. 那么可以设置比如说,个人目标只占50%, 小组目标单独占50%.

假定组内有5个人. 如果他们都只关注自己的目标,忽视小组最后目标完成,那么他们干的再好,也不过拿10个point.

但如果他们有合作精神(那怕是非常有限的),在确保小组目标完成的前提下完成自己的目标,那么他们无论如何拿的会比单干来得多.

在这种情况下,我想多数人还是会选择有限合作吧.

个人感觉,这个报价在面对PO的时候其实开发组内分工已经完成了.对PO的报价只是讨价还价,并让PO了解一些细节的困难程度,更好的评估他自己的决定而已.

而且一个项目往往多个team，这种评估会导致过程更加复杂。另外软件管理的一个重要原则是不能同时使用奖罚措施。

agile的一个目的就是要最小化管理成本，按这样做，只会更复杂。

pg的评估只是一个相对值，是这个小组成员相对于以往工作给出的一个点数，所以不强调说这个点数是man-day。不同的小组会对同一个任务给出不同的点数，这都是可以认可的。

而且现在软件公司，说白了，大点规模的公司，奖金相对于工资都只能是个小数字。起不到本质作用。

所以奖金的数字必须有一定刺激性，我们之前曾经在项目里推广过类似的做法，最后发现，成本大幅度提高以外，项目进度和质量并未有提高，而成员之间互相嫉妒猜疑种种情况反而增加了。

至于扣钱的做法就更简单了，员工可以用脚来对你用屁股坐的决定给与回答。毕竟现在任何地方，有经验的程序员都不是太难找到工作。

其实也没那么复杂啦,按照55方式分小组的话,team leader和PM都只要面对五个人(Team Leader有个人KPI指标，也算一个人）就好了.可以做到在一天内都谈完,算不上很大的工作量.26人的开发小组,应该不算很小了吧.

当然我得承认,我说的这些并不是特定于SCRUM的,这些都是Balanced Score Card里关于划分个人KPI和集体KPI的东西.

公平性问题是这样解决的.PM没有个人KPI,他的职责就是确保集体KPI完成.这样,他不会有个人优先还是集体优先的问题.

点数的问题就不多说了,其实就是个内部招投标+搭配销售,在我所供职的企业运行良好,HP的培训师讲在其他一些公司里运行也相当良好,不过似乎都不是软件公司.

工资奖金比例...看来确实有行业差别,我之前奖金是要占到40%左右的,而且工资发放也是跟KPI完成情况密切相关的.

最后一个离职的问题...就不太好回答了,呵呵.

scrum里没有严格意义上pm的概念。

如果奖金可以占到40%以上，这基本都是垄断企业了吧。当然华为和少数游戏和网络公司也可以。现在一般软件公司都是惨淡经营，哪能开那么高的奖金。就算oracle，行业中利润最高的，也没那么高奖金。

平衡记分卡这套基本都是在传统企业玩的，软件公司很少玩得下去的。软件公司是以人为主运作的，程序员一般都比较有个性，太细太密的规矩不容易玩。绩效考核一直是比较困难的，因为软件本身的特点就导致工作很难量化，参加过国内一些著名讲师的培训，他们对这个也是难以一言到尽，而以KPI为核心的考核在传统企业就很普遍。所以软件公司一般弱化kpi的概念，多使用结果为导向的考核。

考核和agile是不同的问题域，只不过一般推agile的公司，在考核方面都应该比较人性化，否则对开发过程的影响是很直观的。当然不排除有这2方面同时都作的不错的公司。

另外hp的软件一直不怎么样吧，他们做培训？不会是说EDS那边的人吧？

这样考核如果是我的话，多半就会要求成立独立的开发团队，能人都在一起，多分点钱了。项目死活，管我屁事。

而且根据我的感觉，pm同样很难做到公平公正，类似的情况也不是每出现过。所谓kpi考核，考来考去，每年拿分高的都不是干活最多的人，都是和领导关系比较密切的人或者让领导觉得比较重要的人。特别项目大了，谁贡献真的多一些，不写代码的pm又怎么会特别清楚？比如我经常干的活是别人的几倍，但未必我的奖金就会有几倍吧。总之每年考核完了，大家就用脚来说话，也还是蛮公正的。

是老美程序员对那种工程可以机械细分到高中生水平的印度外包模式的反击。

首先，我说的是HP推出的平衡记分卡（Balanced Score Card）而不是单指SCRUM没错。

但是，首先，我们谈论的是一般管理困境，而且不那么正确地说，我参加过SCRUM的培训，它所讲的东西，是平衡记分卡的。。。嗯。。。一小部分。

平衡记分卡的考核方式本身就是结果导向的。或者说，我没见过什么考核方式不是结果导向的。

量化的问题，SCRUM和平衡记分卡用的方式一样，劳动力成为了计算标准（人月）。

比如说，在平衡记分卡方式下，月初team leader与PM会面，定下本月要完成的三件事。ABC，其中，A需要100小时，B需要300小时，C需要600小时。那么折算权重，A占10％，B占30％，C占60％。

或许你会说，有一些很难计算的工作，怎么办？ 其实也简单，这个过程不在于精确的描述你所干工作的权重，而在于达成一致，这个月要干什么，干成什么样。其他那些难以计算的工作要么单独作为一件事，要么并到这三件事里。但是一定要折算成工作时长，这样就有一个可比较的标准。

月末算账，看ABC完成没有，完成的怎么样。完成拿工资，完成的程度算奖金发放比例。比如说，达到85分发100％之类的。之前把规矩定好，跟大家沟通了就好。

这不就是目标导向吗？说软件公司比较特殊，可能是说这个目标由于掺杂了客户满意度而比较难以量化，但是可以在月初签KPI的时候签好几个关键评价方式，比如说，完成xxx模块，实现xxx功能。这样，就和传统公司定目标数字的方式差别不大了。。。

我不知道你说的“考核人性化”是指什么，别是说考勤把？

平衡记分卡是一种策略，不是软件。。。

如我所说，第一，你的PM可能不允许你这么做（他可是背着项目KPI呢）。第二，这是吃力不讨好的事情。（你做好你自己的事情不管项目，拿一半钱（举例）；别人做的不如你好，但是项目完成了，拿全部的钱）

PM，或者说平衡记分卡当然不是万能的，不过也还是有效的。

说白了，这个项目对PO只是个锦上添花的东西，成功了最好，不成功也无所谓，但对我们就是只能成功，不能失败，我们的痛苦就在于此。

开始poker-plan前很多人有这个疑虑。

但仔细想想，恰恰因为个别程序员了解这个模块，所以他开价应该比较低，其他人开的价是假设他们来接手的价码，自然稍高，那么平均价理论上高于那个‘个别程序员’，所以，这个个别程序员选择这个story就比较划算。

但是，如果这个个别程序员胁着‘别人不了解’而故意高开，那么就会‘暴露’。客观上，更加公平的找到了价格。

PO了解到这个层面，就OK了。

你这种恶劣的情况非常常见。

内部项目的PO是什么？无非就是另一批更高级领导雇佣的人。其实内部项目更容易用，关键在于说服最高领导。

如果牛人意识到他们干的多就拿的多，那么他自然会拼命干啊，按照我的评估体系，那是直接挂钩啊。

别的人怎么办？只能抢牛人剩下的story干。谁让你不能象牛人那样快速解决story？很残酷，但绝对促进学习热情。

楼下已经提到比较优势了。

比如报价，A1(超牛），B4,C5

平均价格3.3

虽然A报1，但是A手上在干别的story。B和C如果没有别的story可选，B相对C，选这个3.3的story不算太亏，B选了再说了，但他选完肯定会回忆一下Poker-plan会上A肯定做过的解释了，A也许指明了一条捷径，B会想不妨一试。

即使采用积点考评，看似竞争更加残酷了，实际上团队会更加合作。

因为很多story会出现合作完成情况，这种情况下积点得平分了，于是老鸟菜鸟在一起，老鸟即使处于自己利益也要帮一下菜鸟了。

而且，即使老鸟帮助菜鸟完成和他自己无关的story，那么这种帮忙也是非常明显的‘送钱’行为。事情更加上台面，菜鸟就更加珍惜和老鸟的关系。

比较优势，有想法。

STORY一旦进了sprint，无论谁接都是这个价格。

我稍后讲sprint