2011-08-21 08:56:43 cheny_com 阅读数 11823
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

这是敏捷开发绩效管理的第一篇。(之一之二之三之四之五之六之七

“敏捷开发绩效管理”本身是个伪命题,因为敏捷开发本身不想涉及绩效管理,这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发作为管理方法是有原因的:更高的交付保障,更高的生产率,更高的质量……这和人们选择C++(而不是C)的原因还是很接近的:都是为了更高的绩效。在下面的所有文章中,“敏捷开发绩效管理”都将不再是“敏捷开发中如何做绩效管理”,而是“如何利用敏捷开发提高绩效”。

 


何为绩效管理

绩效管理常常被片面理解为绩效考核,即如何确定个人的绩效,如何提工资和发奖金的问题。实际上绩效管理还包含制定绩效目标制定绩效计划制定配套的制度推动绩效等等,当然也包括最后的绩效考核,以最终达到绩效持续提升的目的

上述内容在本系列中都有考虑,并根据笔者以往的经验和经历给出一些实际的案例供研讨使用。

 

从一个经典问题看绩效管理的出发点

绩效管理不是敏捷开发的要求——如果能理解敏捷开发也不是瀑布模型的要求,敏捷开发爱好者们或许就会释然了——绩效管理是企业管理的要求,是企业为了持续提升自己的绩效而采取的措施。

从这个角度我们来看一个由来已久的问题:“敏捷开发是否考核个人?”很多人会脱口而出:“敏捷开发不考核个人。”但是如果再问“企业管理要求必须考核个人怎么办?毕竟工资和奖金不是发到团队总账户上的”估计再下去的回答,就只能说是闪烁其辞了。

其实这也是一个伪命题,所以才导致很难回答。下面一点点分析。

企业绩效管理的目的不是为了考核个人,而是为了提升企业绩效,所以尝试考核个人的企业实际上在“利用考核个人提升企业绩效”(尽管提升个人绩效会提升企业绩效,但勿入此牛角,因为前面有个尖)。因此这个问题从原始出发点来看,应该是:“企业是否应该通过考核个人来提升绩效?”,那么答案就是:“敏捷开发有比考核个人更能提升绩效的方法”。不是因为用了敏捷开发就不能考核个人,而是选择了敏捷开发,就意味着已经选择了比考核个人更有效的提升绩效的方法,因此没有必要让企业管理和敏捷开发较劲,它们打不起来的。

不过这个或者这些更有效的方法是什么呢?这就是本系列博文的主要内容。

本系列博文将较多涉及团队级别的绩效管理,内容包括团队管理的策略,个体管理,团队的外部目标设定,如何分解到个人,不同团队绩效管理的差异,非物质激励等。

另外一个高级话题则是产品级别的绩效管理,包括产品发布计划,产品版本计划,产品线管理,产品负责人及产品负责人团队,不同产品类型的搭配等等。但这个话题以另外一个主线组织会更顺畅:敏捷开发产品管理,因此会形成另外一个系列,但其核心内容仍是“如何通过敏捷开发管理产品提高绩效”,如果您觉得本系列所涉及的范围太窄,敬请关注 http://blog.csdn.net/column/details/productmanagement.html

 

(有读者反映每篇文章太长了,本系列会以较多的短篇文章形式发布,以便于选择关心的内容分别阅读。)

 

本人正在参加CSDN博客之星评选,如果读完并喜欢这篇文章,欢迎投票:http://vote.blog.csdn.net/item/blogstar/cheny_com

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2013-11-05 16:33:20 u012730075 阅读数 920
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

近期公司要求各部门必须要制定详尽的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

2018-10-26 21:44:16 magic_jiayu 阅读数 186
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

敏捷开发修炼之道

  • 态度决定一切
  • 学无止境
  • 交付用户想要的团建
  • 敏捷反馈
  • 敏捷编码
  • 敏捷调试
  • 敏捷协作

态度决定一切

  • 最高优先级是解决问题而不是抱怨出了问题。
  • 欲速则不达
    • 拙劣的代码工人会不假思索的改完代码然后快速转向下一个问题,优秀的程序员会挖掘更深一层,理解这里为什么要这么做,更重要的是会向想明白会产生什么其他影响。
    • 要理解开发过程,你必须理解团队采用的开发方法,理解如何恰如其分的使用这种方法,为什么它是这样的,以及如何成为它这样的。
    • 使用单元测试:使代码分层。
  • 对待明显错误的反应:询问你的队友并提出你的顾虑。
  • 特殊技术
    • 讨论前设定一个最终期限:防止进入无休止的争辩
    • 逆向思维:权衡的重要性。客观对待问题的办法:先积极看到它的正面,然后努力的从反面认识它。
    • 设立仲裁人做决策者:防止明星员工操纵会议,及时打断假大空发言
    • 支持已经做出的决定:客户目标是让项目满足用户需求并不关心这是谁的主意,结果最重要。
    • 对事不对人:我们骄傲的应该是解决了问题而不是比较谁的主意更好。
    • 寻找最好的解决方案前大家应该对“最好”的含义达成共识。开发者眼中的最好,不一定就是用户认为最好的。
  • 做正确的事:要诚实,有勇气说出实情,即使这很困难。

学无止境

  • 跟踪变化
    • 迭代和增量式的学习:每天一段时间学新技术。记下你想学的东西——当你听到一些不熟悉的术语或者短语,简要的记录下来,在计划的时间中深入研究。
    • 了解最新行情:社区讨论,邮件列表,优秀技术博客
    • 参加研讨会议
    • 如饥似渴的阅读:软件开发和非技术主题的好书,专业期刊和商业杂志
  • 对团队投资
    • 一个学习型的团队才是较好的团队
    • “午餐会议”是团队中分享知识很好的方式
    • 每周要求团队中的一个人主持讲座。向大家介绍一些概念,演示工具,或者做团队感兴趣的人讷河一件事情。可以挑一本书和大家说说其中特别内容、项目或者实践。
    • 讲座后进行开放式讨论
    • 不要局限于纯技术的图书和主题,相关的非技术主题(项目估算,沟通技巧等)也会对团队有帮助
  • 学习新的东西,更少被旧习惯所牵绊。
  • “为什么”是一个非常好的问题,而且要问到点子上。
  • 把握开发节奏。编译,运行测试,代码复审,一致的迭代,然后发布。

交付用户想要的软件

  • 让客户做决定
    • 让企业主决定业务上的关键问题
    • 和客户讨论问题的时候,准备好集中可选择的方案。不是从技术的角度而是从业务的角度,介绍每种方案的优缺点,潜在成本和利益,讨论每个选择对时间和预算的影响,以及如何权衡。
  • 让设计指导而不是操纵开发
    • 前期的设计属于战略,通常只有在没有深入了解需求的时候需要这样的设计。具体来说,它只应该描述总体战略,不应该深入具体细节。
    • 战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的字节,这应该留到战术设计阶段。战术设计的重点是集中在单个的方法或数据类型上。CRC(类-职责-协作)卡片。
  • 合理使用技术
    • 这个技术框架真的可以解决问题吗?如果有需要先做一个原型
    • 你将被它拴住吗?缺乏可取消性
    • 维护成本是多少
    • 根据需要选择技术
  • 保证你的系统随时可以编译、运行、测试并立即部署
  • 提早集成,频繁集成:早起集成会看到子系统之间的交互影响,可以估算之间的通信和共享的信息数据。
  • 提早实现自动化部署:从第一天起就进行交付,项目没有开始就有了单元测试、持续集成和基于窗口的安装程序。
  • 使用演示获得频繁反馈
  • 使用短迭代,增量发布。
    • 迭代开发:在小且重复的时间周期里完成各种开发任务:分析、设计、实现、测试和获得反馈。
    • 大部分用户希望现在就有一个可以用的软件,而不是一年后得到一个超级好的软件。确定产品可用的核心功能,把它发那个到生产环境中,越早交到用户手里越好。
    • 询问用户,哪些是使产品可用且不可缺少的核心功能。不要为华丽功能而分心,不要沉迷想象做华而不实的用户界面。
  • 固定的价格意味背叛承诺
    • 主动提议先构建系统最初的、小的和有用的部分。这是要足够一次交付并让用户真正使用。
    • 第一次迭代结束时用户有两个选择:选择一系列新的功能,继续进入下一个迭代;或者取消合同,仅需支付第一个迭代的几周费用。
    • 如果用户继续前进,这个时候应该很好地预测下一个迭代工作,在下一个迭代工作结束的时候,用户仍然有同样的选择机会。

敏捷反馈

  • 单元测试
    • 确保测试是可重复的。
    • 测试你的边界条件。
    • 不要放过任何一个失败的调试。
  • 编程之前,先写测试:
    • 使用测试驱动开发(TDD)技术。
    • 只有在具体理由的时候才开始编码,你可以专注于设计接口,而不会被很多实现的细节所干扰。
  • 持续集成:使用自动化会节省时间
  • 集成测试框架(FIT):更容易使用HTML表格定义测试用例,并比较测试结果数据。
  • 清楚项目真实进度
    • 不应该去计算工作量完成的百分比,而应该测定还剩下多少工作量没有完成。
    • 使用待办事项
  • 倾听用户的声音
    • 每个抱怨的背后都隐藏了一个事实。找出真相修复真正的问题。

敏捷编码

  • 代码要清晰地表达意图。可读性
  • 使用细心、有意义的命名,用注释描述代码意图和约束
  • 动态评估权衡:考虑性能、便利性、生产力、成本和上市时间。
  • 增量式编程:在很短的编辑/构建/测试循环中编写代码。
  • 保持简单:不要使用模式、原则和高难度技术之类的东西。
  • 编写内聚的代码:让类的功能尽量集中,让组件尽量小。
  • 命令与查询相分离模式。
  • 根据契约进行替换:通过替换遵循借口契约的类,来添加并改进功能特性。多用委托而不是继承。

敏捷调试

  • 维护一个问题及其解决方案的日志
  • 将警告视为错误
  • 对问题彼此隔离各个击破(以二分查找的方式来定位问题是很有用的)
  • 处理或是向上传播所有的异常。
  • 提供有用的错误信息(没有必要等待抛出异常来发现问题。在代码关键点使用断言来保证一切正常,断言失败时,要提供与异常同样详细的信息。

敏捷协作

  • 使用立会
  • 架构师必须写代码:新系统的设计者必须要亲自投入到实现中去。
  • 强调代码的集体所有制:让开发人员轮换完成系统不同领域中不同模块的不同任务。
  • 成为指导者:不要吝啬分享自己的知识。
  • 给别人解决问题的机会。
  • 准备好后再共享代码
  • 做代码复查(能否读懂、理解?错误?重复?重构?)
  • 及时通报进展与问题
2008-10-17 10:51:21 heweiyabeijing 阅读数 221
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

       我曾经管理和经历过使用所谓“敏捷开发”的两个相对比较大的项目。之所以是“所谓的敏捷开发”,掺杂了不少了自己的实现和理解,见笑了。

       第一个所谓的敏捷开发的项目是迫不得已的,因为项目前期投入大而且人事变卦(其它公司挖墙角),后期没有足够的时间来完成项目,所以我自告奋勇承接这个项目,CALL,其实就是为了年底能够领到更多的奖金。这个项目总价是100W,其中30多W是硬件,30多W是公关(灰色)费用,老板给我的成本价是15W,而且很认真的给我算出这个数。当时老板给我的条件是:公司资源随便支配,其中开发资源计在成本之内,三个月交付,这个时期内最少有三个重要的里程碑,每个里程碑必须完成工作的35%,包括质量检查。

        我的做事方法,一个能力跟我相当的程序员,一个能力一般且很仔细的程序员,一个测试工程师,另外还有一个是美工,还有客户方至少有一个到现场帮助测试或者业务讲解。然后在中关村某公寓封闭开发。

         我们挤在一个不大的会议室里,都在一张桌子上办公,开发程序有点像流水线,第一个是我,我写程序快,经验多,i当然BUG也多。因为是J2EE程序,我在前一周都是在写所有表的增删改查,其中MODEL和DAO这一层自动生成,controller这一块写了通用的增删改查,页面也是简单的增删改查。然后就是其它两个程序员帮助我修改一下错误和BUG。测试人员在写测试用例,美工在和客户方交流用户的操作体验。总之,我想要说的话是:敏捷开发当中,敏捷的生产过程非常非常重要

         。我们经常交流,且有一种努力创业的想法。

         。有能力的程序员,让他写一些通用的方法和JS。(随便是google或者baidu上去抄)

         。客户方帮助我们不少。每个人都了解业务,有的想去卖仪器(哈哈,客户是做仪器的)

         。我们没有单元测试,每个人做完既定的功能后就提交功能测试,我们每个人的BUG很多,但是后面就很少。

         。我们完成一个相对独立的模块后,就提交给实用户,到现场进行试用。

         当然也少不了零食,看板,使用xplaner做管理。

          结果:我们不到两个月完成项目的85%以上,如果不算BUG的话,应该是在90%以上,然后退回到公司过着朝九晚五的生活。年终我也领到了两个多月工资的奖金。一个字爽。客户如期上线。

         黑五总结:跟着我的几个哥们,很讨厌我,他们最希望加薪,我只给他们的福利是每天120元/所有人的消费标准,每天工作10个小时左右,工资每天加100元,星期六星期天加200元(可以选择过星期天)。经过这个事后,他们很疲惫,虽然他们的技术提高很快,但是对公司的不满也每天增加,终于不出半年走掉一个,不出半年,又走掉一个。

         个人感想:敏捷开发的方法是老板喜欢看到的,因为敏捷开发方法节约成本,快速交付。但是对于员工来说,这种管理让人感觉压力很大,有点变态的感觉。我想如果一个人长期处于这种敏捷的开发当中,而自己没有自由的空间时,员工的不满会与日俱增的。尤其我们IT程序员跟现在的小姐一样,青春就哪么几年还在变态中渡过,所以从员工角度来说敏捷开发不是很好。

          我同时又想到了“计件工资”,又扩大了思维想到了“联产责任承包制”,又想到了“事业部”。感觉敏捷开发应该和员工的利益直接关联。于是我又想到了长得漂亮“出台率”巨高,美妓李师师......

          可能,敏捷开发的路可能还很远,对企业的管理方式也会不断的变化。这家伙,搞的天天跟考试一样。

          至今,找到的新工作也在敏捷的氛围当中进行,看看我的BLOG的更新时间你就知道我有多忙,为了生存,奉献身体,奉献青春。

          个人想法,仅供参考,不要人身攻击。

           链接:敏捷生产

2018-03-15 11:53:50 eleanoryss 阅读数 1506
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10431 人正在学习 去看看 CSDN讲师

转自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315

        敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

那么 Kanban 到底是什么呢?我们先来看看这张表格吧:


下面我们来理解一下这个表格吧!

  • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)
  • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)
  • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

好!继续我们的 Kanban,有意思的事情即将发生!


产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了 然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!


没有更多推荐了,返回首页