主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷
家园 这是一个统筹问题 通常我们会把最有价值的东西让牛人去做，或负责大部分。另外SM决定的估价通常也是一个平均值，而不是做这个Story的人的估值。牛人报5点的东西，也许估出来是8点。
公平问题一直是存在的，只能做到相对公平。我觉得需要强调一点，客户面临的是一个团队，而不是一个个单独的程序员。这是敏捷的一个核心价值。
另外，楼主还没讲完，这个问题也是有其他机制平衡的。
家园 这点我到不太同意了 Scrum应该更强调团队合作，要考核也是团队的velocity，对个人是不做计件工资的，否则pp什么的都够呛，成员之间关系也会比较紧张。
家园 个人觉得没什么 事实上在组内使用甘特图来控制流程的时候，也是会把工作量放到每个人头上的啊。
你说的情况解决方案也是现成的。在个人的KPI之上加一个集体KPI。 单独完成个人部分，可以拿到一部分奖励。完成集体目标，拿到更多奖励。
只要把个人奖励目标定的低于集体目标，就问题不大。
- 复 个人觉得没什么
家园 个人奖励不好评估 以前有个简单的方法，划分个若干登记，让程序员不记名自己投票。基本还是公正的，就是看到某pm很无耻的把自己列为第一等，反正谁也不知道票是怎么记得了。
- 复 个人奖励不好评估
家园 别啊,干嘛那么干呢 计件工作确实在这方面有比计时更优越的地方.
SCRUM体系下对每个item的报价,应该不单是对外的,同时也是对内的.只是可能要有个调整参数罢了.
在一开始划甘特图的时候,组内小组就应该选择自己的工作量,PM对其进行调整,保证大体上每个小组的perceived value大体相等(或是不等,但大家都能认可和接受).
然后PM指导(监督)Team Leader做好本小组内的工作划分,依然是一样的流程,确保每个组员都了解
1. 要干什么
2. 有什么回报
3. 有什么惩罚
并且签字确认.
如果说一个小组的perceived value是100 point. 那么可以设置比如说,个人目标只占50%, 小组目标单独占50%.
假定组内有5个人. 如果他们都只关注自己的目标,忽视小组最后目标完成,那么他们干的再好,也不过拿10个point.
但如果他们有合作精神(那怕是非常有限的),在确保小组目标完成的前提下完成自己的目标,那么他们无论如何拿的会比单干来得多.
在这种情况下,我想多数人还是会选择有限合作吧.
家园 问题是，谁来做这个评估做到公平公正合理？ 而且一个项目往往多个team，这种评估会导致过程更加复杂。另外软件管理的一个重要原则是不能同时使用奖罚措施。
agile的一个目的就是要最小化管理成本，按这样做，只会更复杂。
pg的评估只是一个相对值，是这个小组成员相对于以往工作给出的一个点数，所以不强调说这个点数是man-day。不同的小组会对同一个任务给出不同的点数，这都是可以认可的。
而且现在软件公司，说白了，大点规模的公司，奖金相对于工资都只能是个小数字。起不到本质作用。
所以奖金的数字必须有一定刺激性，我们之前曾经在项目里推广过类似的做法，最后发现，成本大幅度提高以外，项目进度和质量并未有提高，而成员之间互相嫉妒猜疑种种情况反而增加了。
至于扣钱的做法就更简单了，员工可以用脚来对你用屁股坐的决定给与回答。毕竟现在任何地方，有经验的程序员都不是太难找到工作。
家园 如果不复杂的话,PM不就不值那么多钱了么,嘿嘿 其实也没那么复杂啦,按照55方式分小组的话,team leader和PM都只要面对五个人(Team Leader有个人KPI指标，也算一个人）就好了.可以做到在一天内都谈完,算不上很大的工作量.26人的开发小组,应该不算很小了吧.
当然我得承认,我说的这些并不是特定于SCRUM的,这些都是Balanced Score Card里关于划分个人KPI和集体KPI的东西.
公平性问题是这样解决的.PM没有个人KPI,他的职责就是确保集体KPI完成.这样,他不会有个人优先还是集体优先的问题.
点数的问题就不多说了,其实就是个内部招投标+搭配销售,在我所供职的企业运行良好,HP的培训师讲在其他一些公司里运行也相当良好,不过似乎都不是软件公司.
工资奖金比例...看来确实有行业差别,我之前奖金是要占到40%左右的,而且工资发放也是跟KPI完成情况密切相关的.
最后一个离职的问题...就不太好回答了,呵呵.
家园 呵呵，你貌似不是在做scrum吧 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，或者说平衡记分卡当然不是万能的，不过也还是有效的。