敏捷开发如何考核_敏捷开发绩效考核 - CSDN
  • 遗憾的是因为时间问题两位老师对敏捷开发团队如何做绩效考核涉及不多。袁老师关于绩效考核方面主要提出了有质量的Bug和故事点比值作为关键指标;王老师主要是对团队绩效如何考核进行指导。尽管现场我向王老师请教了...
    今天上午有幸作为嘉宾参加2014World of Tech(WOT)全球软件技术峰会,听了袁斌老师和王立杰老师关于敏捷实践和敏捷团队方面的演讲,收获颇多。遗憾的是因为时间问题两位老师对敏捷开发团队如何做绩效考核涉及不多。袁老师关于绩效考核方面主要提出了有质量的Bug和故事点比值作为关键指标;王老师主要是对团队绩效如何考核进行指导。尽管现场我向王老师请教了一些问题,王老师也给予非常好的解答,但关于绩效考核仍旧存在一些问题让我疑惑。
    一、KPI制定者是谁,考核者是谁?
    敏捷团队做绩效考核,一些关键指标还是尽可能由敏捷团队给出,到底谁给出呢,CPO,PO,Scrum Master,还是Team Leader?尤其是这个敏捷团队人数达到50人甚至100人,产品又比较大,需要拆分成多个子系统的时候?另外又是谁去考核呢?对于过程可能Scrum Master比较了解,对于需求产品经理可能理解的更有深度,优于系统级别任务的拆分工作由CPO来做,所以CPO对整体的把握更强一些。这时候会出现一个问题,那就是考核变成了多层次、高纬度的一项工作。 那么这时候考核指标如何赋权重?考核如何开展?
    二、如何避免“大锅饭”现象?
    其实这个问题王老师在现场已经做了解答,不过无论如何我们无法否认,大锅饭现象的确是个不小的难缠的麻烦。 我们曾经实践过王老师所说的一个点子,团队成员之间互相打分,然而结果并不乐观,各方面原因导致团队成员之间得分很接近。如果团队达到自管理甚至是自组织的阶段时,我认为大锅饭现象就会更加难以避免,因为这时候指标更加难以制定,权重更加难以衡量,一切都松散、模糊了。
    三、故事点的粒度如何控制?
    袁老师提到一个绩效衡量指标,即有质量的Bug和故事点的比值。这时候也会出现问题,就是故事点的粒度怎么掌握,拆分的时候如何保障公平?显然一个常用故事比如登陆故事比包含复杂算法的故事解决起来轻松的多。这时候绩效考核该怎么添加辅助条件或进行怎样的调整?
    展开全文
  • 敏捷开发团队成熟度评估参考标准

    千次阅读 2015-04-17 19:00:36
    当一个产品团队采用敏捷开发模式时,如何来确认这个团队是否真的已经敏捷了呢?这个是非常重要的,在日常工作过程当中,团队的工作模式很大程度上会受团队负责人或者服务性领导的影响,有时候会因为这个负责人的一些...

    当一个产品团队采用敏捷开发模式时,如何来确认这个团队是否真的已经敏捷了呢?这个是非常重要的,在日常工作过程当中,团队的工作模式很大程度上会受团队负责人或者服务性领导的影响,有时候会因为这个负责人的一些个人工作风格,而使团队的敏捷模式偏离了方向,没有让团队真正的敏捷起来。前面一篇文章也介绍过,在敏捷开发模式团队内部,Product Owner和Scrum Master这两个角色非常重要,他们是带领整个团队前进的,下面的评估参考标准其实基本上是围绕这两个角色展开的。

    一个团队花了很多钱请来了外部的培训师和教练,同时雇佣5个员工组成“敏捷办公室”为新的Scrum团队提供建议和帮助。他们失败是因为他们认为实施Scrum仅限于开发团队。发起敏捷转型的管理层认为,只给开发人员提供培训和支持就足够了。他们没有考虑到Scrum对产品经理、测试人员、UED等人员的工作带来的影响。如果这些地方没有改变,组织惰性会把整个团队带回原点。

    Scrum简单但并不容易,原因如下:

    1、成功的变革不是完全的自上而下或者自下而上;

    2、结束状态是不可预知的,Scrum需要持续的改进;

    3、Scrum在整个组织中是无处不在的;

    4、Scrum和传统培训/教育是截然不同的;

    5、变化来的比以往更快;

    6、最佳实践是危险的,要找到适合自身的方法;

    Scrum不仅是技术层面的转型,更意味着理念的革新,整个团队都要参与进来

    1、团队要学会在没有大而全的计划的情况下开始工作;

    2、团队要学会在没有详细需求文档的情况下,通过用户故事和交流分析和理解需求,开始设计和编程;

    3、团队要习惯于频繁递交代码和持续集成;

    4、团队是在高度透明的环境下工作,每个人的进展被所有人都了如指掌;

    5、团队需要进行结对编程,需要频繁的沟通和讨论;

    初级敏捷团队

    1、Team内PO角色清楚,PO负责管理Product Backlog;

    2、PO是需求的主要来源,并负责并从各方收集需求,并对需求负责;

    3、PO负责Product Backlog优先级的确定,当变动发生时也是如此;

    4、Team中有一个人可以承担Scrum Master这个角色的工作,基本上由此人长期承担Scrum Master的工作;

    5、基本能够协调Team解决在Sprint内遇到的问题。但是对跨Domain的问题解决推动能力弱;

    6、由Scrum Master协助团队成员进行维护Sprint Backlog,并培养团队成员自行维护Sprint Backlog的习惯;

    7、Scrum Master负责主导和主持站会,站会在固定地点和固定时间,在标准时长内结束,Scrum Master对团队每个成员的工作内容都很清楚,可以通过站会发现大部分问题和风险;

    8、Scrum Master负责各种会议的如期进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master负责主导和主持plan meeting,给出工时的评估方式,给出本次sprint的计划内容和优先级别,引导大家进行sprint内容的拆分,引导大家完成工时的评估;

    10、Scrum Master负责主导和主持总结会议,主要由Scrum Master负责总结本次迭代的优点和缺点,并针对缺点制定出改进措施并进行跟进;

    11、Scrum Master负责监控风险和进度,并能知会给利益相关人;

    12、Team大部分情况下能够完成对DOD的承若;

    中级敏捷团队

    1、PO负责管理Product Backlog,Team认可Product Backlog内容;

    2、Team会协助PO收集需求,也会积极提出需求,Team认可需求并对需求负责;

    3、PO协助Team进行Product Backlog优先级的确定,当变动发生时也是如此;

    4、Team中Scrum Master这个角色的工作有Backup,当Scrum Master不在时,Backup可完全承担该角色的工作;

    5、完全能够协调Team解决在Sprint内遇到的问题。对跨Domain的问题解决推动能力较强,但对跨部门的问题解决推动能力较弱;

    6、团队成员自行维护Sprint Backlog的习惯已形成,Scrum Master只需监督和提醒;

    7、Scrum Master协助站会有效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员可以协助Scrum Master发现一些问题和风险,大部分问题和风险还是由Scrum Master发现;

    8、Scrum Master协助各种会议的有效进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master协助plan meeting有效进行,和团队成员共同商讨确定工时的评估方式、本次sprint的计划内容和优先级别,进而共同完成sprint内容的拆分和工时的评估;

    10、Scrum Master协助总结会议有效进行,和团队成员共同商讨总结本次迭代的优点和不足,能够针对不足制定出有效的改进措施并进行有效的改进,而优点能够继续保持;

    11、Scrum Master主导,团队成员参与监控风险和进度,并能定期通知给利益相关人;

    12、Team共同完成对DOD的承若;

    高级敏捷团队

    1、Product Backlog由PO发起管理,由Team共同参与讨论完善;

    2、Team共同提出和收集需求,共同对产品负责;

    3、Team共同对Product Backlog优先级进行确定并负责,当变动发生时也是如此;

    4、Team中任何一个人都可以承担Scrum Master这个角色的工作;

    5、可以帮助Team跨越Sprint中遇到的一切障碍,对跨Domain和跨部门的问题解决推动能力均较强,保障DoD按约定完成;

    6、团队成员自觉维护Sprint Backlog,Scrum Master定期检查团队成员维护Sprint Backlog的情况;

    7、团队成员积极地参加站会,站会高效地效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员积极提出问题与风险,和Scrum Master共同发现所有问题和风险;

    8、Scrum Master辅助,团队成员主导各种会议的有效进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review等等;

    9、Scrum Master辅助,团队成员主导plan meeting,Team共同对工时评估的结果,本次sprint的计划内容及拆分结果,优先级别确认结果负责;

    10、Scrum Master辅助,团队成员主导总结会议,Team共同对本次迭代的结果负责,能够共同认识到不足的根本原因所在,后期所有团队成员都积极有效的改进,将不足逐渐转变为优点,而优点能够越做越好;

    11、Team共同积极监控风险和进度,并能及时通知给利益相关人;

    12、Team从专注功能实现专为专注产品实现,Team有能力识别产品的正确路线,共同促使产品不断被完善;

    同样都是十二条参考评估标准,越成熟的敏捷团队,不光对PO和SM的要求越高,还对团队成员的要求也逐渐提高。在敏捷开发团队内部,是一个互相学习,互相进步的过程,可以促进整个团队的能力和水平的提升,因此对团队的发展是非常有好处的,特别是团队内部职场新人比较多的时候,化大成本去培训、去传帮带,还不如让他们在团队工作当中去学习和成长,这样可以更加快速的帮助他们提高,也提高了团队整体的实力。


    本文转自:《IT民工 or IT精英》

    原文链接:http://www.itfarmer.com.cn/1787.html


    展开全文
  • 敏捷团队如何进行绩效考核

    千次阅读 2013-11-05 16:30:11
    近期公司要求各部门必须要制定详尽的KPI考核方案,看了下人力下发的模版,对研发非常非常不科学,简直把研发工作当做了工厂产线,于是特别针对我们...(团队采用的敏捷开发,每一阶段会制定一个产出计划和产出目标)目

    近期公司要求各部门必须要制定详尽的KPI考核方案,看了下人力下发的模版,对研发非常非常不科学,简直把研发工作当做了工厂产线,于是特别针对我们部门的敏捷团队,制定了这么一套考核方案。
    (参考:敏捷团队的绩效考核)


    两个考核方向:团队绩效考核,个人绩效考核

    团队绩效考核

    目的:促使团队成员对整体质量负责;

    考核内容:

    1.每次迭代的交付物可否被接受。(团队采用的敏捷开发,每一阶段会制定一个产出计划和产出目标)

    • 目的:保证每次迭代的质量达到要求;

    • 考核办法:测试反馈,团队试用,团队评估;

    2.每次迭代的生产率是否理性增长。(架构是否合理,后期扩展,修改是否容易)

    • 目的:减少团队开发的债务,后期不再为前期的犯的错误买单;

    • 考核办法:团队评估;

    个人绩效考核

    目的:考察个人能力,责任心等的不同来体现出每个团队成员的差异

    考核点:

    1.工作质量(比重占个人考核的40%)

    • 目的:引导每个团队成员保证自己负责的工作交付质量;

    • 考核办法:bug数量和可接受程度;

    2.工作量(比重占个人考核的20%)

    • 目的:体现每个团队成员对交付产品的贡献程度;

    • 考核办法:完成功能点数量,技术点难度;

    3.主动性(比重占个人考核的20%)

    • 目的:引导成员个体在团队中能进行主动地交流和沟通;

    • 考核办法:团队评估;

    4.帮助团队(比重占个人考核的10%)

    • 目的:引导能够主动或乐于帮助团队的其他成员,共同对交付质量负责,避免出现“各扫门前雪”的状况;

    • 考核办法:团队评估;

    5.自身成长(比重占个人考核的10%)

    • 目的:引导团队中的每个人不断提高自己,持续改进;

    • 考核办法:团队评估;

    考核方式:

    • 考核等级:“优,良,及格,差,很差”五个等级;

    • 分数明确化:比如工作质量40分,很差0分,差30分,及格60分,良80分,优100分,舍弃中间分数,这样才可以显化差异,进行明确的利益分配。

    • 差异化考核:在上述考核点所占比例之上,还要针对个人情况进行加权评定。比如对资深员工帮助团队的加权会大,对缺乏经验的新员工自身成长的加权会大......

    360度考核

    • 由三个对象进行考核:个人,同事(项目协作者),主管(项目管理者)。

    • 保密性:考核结果交由部门负责人评定。

    争议解决

    • 主观因素的淡化:明确团队责任和产出,明确个人任务,产出;

    • 个人申诉:对考核情况由部门负责人定期进行交流,防止考核中的误解和不公平;

    奖惩措施

    考核结果与奖金分配,提薪幅度,甚至建议调离团队挂钩(中间会有主管的定期沟通,尽量避免出现不利于个人和团队的情况)


    本文出自 “永远的朋友” 博客,请务必保留此出处http://yaocoder.blog.51cto.com/2668309/1275680

    展开全文
  • #如何理解敏捷开发敏捷开发是一种过程控制论,通俗的说,就是一种做事情的方法。 1.它适用于软件,因为软件是软的,可以改。要是硬件,改起来就没那么方便了 2.它适用于客户不知道自己要啥的情况,其实,这样的...

    #如何理解敏捷开发?
    敏捷开发是一种过程控制论,通俗的说,就是一种做事情的方法。
    1.它适用于软件,因为软件是软的,可以改。要是硬件,改起来就没那么方便了
    2.它适用于客户不知道自己要啥的情况,其实,这样的客户占绝大多数。因为客户不知道
    要啥,所以你需要不断帮客户弄明白他到底想要啥。。。换句话说,你需要和客户沟通,合作,
    倾听反馈,持续改进。。。
    3.它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用
    的产品非常重要。
    4.它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,
    这就需要你能一步步的把汽车改成飞机,还能按时交付。
    5.它适用于在一个地方办公的小团队,一般10人以内。这样能使敏捷中主要的沟通方式
    “FacetoFace”是可行的。

    敏捷开发又是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个来
    提高工作效率。
    比如:
    1.站会:三个问题,简洁有效的小团队沟通方式
    2.看板:直观反映工作进度,反映流程遵守情况,反映流程缺陷
    3.演示,计划,反思会:适合于小团队的协作和优化反馈方式
    4.用户故事:站在用户的角度讲需求
    5.持续集成:随时高质量交付的基础,有利于应对变化剧烈的市场。

    敏捷开发也是一种企业管理方式
    1.一线员工可以同时是架构师,ScrumMaster,开发工程师,测试工程师,发挥了他的主
    观能动性,有利于创新和效率
    2.敏捷不专注于敏捷团队中个人的绩效考核,而更多的侧重于整个团队的绩效,更好的避
    免了KPI驱动模式。
    3.把大项目拆分成小项目去做(每个Sprint都是一个迭代,需要输出一个高质量的版本,
    相当于完成一个小项目),把bug的生存期控制在一个迭代以内,降低了风险,也减少了后
    期改bug的工作量。
    4.把数十人的大team分成几个敏捷团队,这几个敏捷团队的ScrumMaster/PO再组成
    一个更高一级的敏捷团队,利用站会,反思,看板等等敏捷元素,可以避免数十份邮件也不
    能解决一个小问题,大家互相踢皮球,沟通不畅的大企业病。
    5.老板可以是最大的PO,他给下面的高管讲idea(UserStory),定期检查Demo,把控产
    品用户体验,负责和外界的沟通合作-----比如乔布斯,360的周鸿祎等。
    #传统企业如何推广敏捷?
    1,对于传统企业推广敏捷,最重要的是建立共识,企业领导与部门领导,上级与下级,产
    品团队,研发团队之间的共识,可以不提敏捷,先着眼于当前存在的问题及企业、团队、个
    人存在的价值、愿景;
    2,提出敏捷的方式,逐步建立信任;这是一个互相调频道的过程,只有在一个频道上,才
    能依据企业的特色情况,独有文化,对敏捷方式及其它企业的成功模式进行相应的裁剪,打
    造符合企业自身业务与文化的敏捷方式,从而使敏捷能够落地;
    3,对于快速达成共识这一目标,集体参与敏捷相关培训不失为一个快速的办法,同时在日
    常工作中建立知识共享机制,从而使企业团队之间沟通能够在同一个出发点与层次进行沟通,
    迅速达成共识,对多变的业务需求进行快速且合理准确的响应。

    展开全文
  • 这是敏捷开发绩效管理的第一篇。(之一,之二,之三,之四,之五,之六,之七)“敏捷开发绩效管理”本身是个伪命题,因为敏捷开发本身不想涉及绩效管理,这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发...
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 敏捷开发中如何进行团队绩效管理

    千次阅读 2018-01-31 13:10:49
    敏捷开发中,绩效管理是管理层非常关心的问题,而敏捷(或Scrum)中没有关于绩效的定义或做法。本文是Ken Rubin基于自己20多年的敏捷开发经验总结出来的、敏捷团队中如何进行绩效管理。 几乎我教过的每堂课或辅导...
  • 敏捷开发团队考核分享

    千次阅读 2013-06-12 23:33:21
    团队怎么考核: 每sprint交付物是被接受的百分比;保证每次团队产生的价值 每sprint的生产率是增长或减缓或者倒退。 为了长期衡量团队的产生的价值和持续的改进。   不建议太严格的考核个人,如要考核,可以...
  • JAVA敏捷开发环境搭建

    千次阅读 2016-05-19 18:06:23
    整个软件项目分为四个环境 开发本地环境、开发环境、测试环境、IDC环境。和传统C++开发不一样的模式是多了第一个开发本地环境。这是为什么呢,因为目前大部分开发人员还是比较熟悉windows下开发。对于mac和linux下...
  • 敏捷开发团队中,团队成员希望达到一组目标,而经理和高管们去按传统的铁三角框架目标去考察他们。如何在敏捷开发中有效的进行成效评估?以往的软件开发团队都被认为受到软件“铁三角”的限制。三角形的三个边分别...
  • 学习使用看板进行敏捷开发

    千次阅读 2018-03-15 11:53:50
    转自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315 敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!我们可以结合 Scrum 与 Kanban...
  • 这是敏捷开发绩效管理的第五篇。(之一,之二,之三,之四,之五,之六,之七)度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容。度量...
  • 敏捷开发团队管理系列之一:序言与出发点

    千次阅读 多人点赞 2011-12-29 23:16:57
    这是敏捷开发团队管理系列的第二篇。(之一,之二,之三,之四)之前的各个系列中,已经涉及了很多团队管理相关的内容,比如松结对编程系列中提到过大型团队分拆为微观开发团队的管理,产品管理系列中提到过Product ...
  • 敏捷开发并不是一个新概念,在过去十多年里,敏捷开发方法论已成为国外开发团队的主流思想。敏捷开发真正走进中国,是从5年前开始。因为敏捷方法论中提到了一些在传统软件开发方法中没有注意到的思想,这些思想是真...
1 2 3 4 5 ... 20
收藏数 3,668
精华内容 1,467
关键字:

敏捷开发如何考核