袁斌_AgileDo
- 浏览: 64338 次
- 性别:
- 来自: 北京
-
最新评论
-
windshome：
谢谢袁老师的回复。以我从事设计开发十五年的工作经历来看，因为自 ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释 -
袁斌_AgileDo：
windshome 写道袁老师，刚听过了您的课，对这一篇说点自 ...
Martin对敏捷宣言中“可工作软件胜过面面俱到文档”的解释 -
zh_harry：
微信的成功秘诀====抄袭！！
再读经典的“微软团队－成功秘诀” -
archy123：
微软的成功秘诀====抄袭
再读经典的“微软团队－成功秘诀” -
archy123：
微信的成功秘诀====抄袭！！
再读经典的“微软团队－成功秘诀”
文章列表
如何从最初的客户想法到持续维护的
Product Backlog，
大家的做法各有千秋。这里分享我们的一些做法，见下图：
第一步：独立需求。这里是从愿景开始，根据角色、行为、数据对象拆分为独立的需求
第二步：粗颗粒细化需求。这里的目的是为了分析成本考量，但并不是类似
Use Case那样的细化，只需要包含
90％的用户使用场景即可，有很多做法，其中一个是选择
3个
examples，一个
happy path，另两个是使用频率较高的异常流程。这里主要涉及的是商业规则
第三步：价值
/成本分析，这里要分析价值、成本，在此基础上再次拆分故事， ...
Kanban虽然有透明、限制WIP（在制品）和度量、提升工作流、PULL模式作为基本的特点，但这并不是说选择Kanban是因为Scrum不具备这些特点。应该说，两者都具备这些特点，只是在细节处各有侧重。Kanban和Scrum比较，在团队组织、交付频率、流程管理等方面有以下的不同之处，了解这些区别，会方便我们选择是否用Kanban：
迭代开发还是流开发（一）：迭代开发遇到的困难
基于Scrum的迭代开发已经很多年，很多团队会在2周一个迭代的周期频率下不断交付，基于跨职能的团队，同时迭代中不允许有变化的需求。但是有一些场景让这种迭代很困难，例如：
1) 紧急的技术支持
2) 临时增加的非常高的优先级的需求
3) 需求的批量小，导致无法2~4周一个迭代稳定发布
4) 估算非常难，导致不容易承诺，例如不清楚原因的bug修改，需要技术预研的任务，越来越庞大的系统导致事先未曾考量的任务出现的几率越来越大
5) 一些专家只对自己的技能擅长，导致计划扑克等团队估算形同虚设，同时他们在迭代中的任务很可能不饱满或者超值（他不能帮助其他人同时其 ...
我和大家分享的内容主要包括以下三个方面：
① 研发团队的绩效考核的方式
② 研发团队绩效考核KPI如何评估
③ 如何让绩效考核发挥作用
今天是第三部分
③ 如何让绩效考核发挥作用
如何要让绩效考核发挥作用，提高交付质量。减少学习债务和技术债务，增强团队的成熟度，我们的实践是要做到以下几点：
1) 绩效考核年度、季度来做正式的评估当然可以，最好每天的工作中都要基于这些指标发现问题和风险。每天的这些工作不是要花大量的成本来打分，而是发现偏差后及时的沟通。在每天的工作中，至少管理者（例如项目经理）要把这些指标放在心里，把项目的进度、风险等做到透明化（例如敏捷开发中的白板管理，所以项目的关键信息都放 ...
我和大家分享的内容主要包括以下三个方面：
① 研发团队的绩效考核的方式
② 研发团队绩效考核KPI如何评估
③ 如何让绩效考核发挥作用
今天是第二部分
② 研发团队绩效考核KPI如何评估
团队部分KPI指标的评估方式：
每次迭代的交付物是否可以被接受：以需求提出者对本次开发迭代交付物的评价为标准，分为“接受”和“拒绝”两种
每次迭代的生产率是否理性的增长：以每次开发迭代完成的需求工作量为评估标准，需求工作量不建议用代码行估算，而是建议用“故事点”、“理想工作日”等需求间的相对大小来评估
个人部分KPI指标的评估方式：
质量评估方式：对于开发人员，质量以“交付测试后发现的严重bug数量除以此需求 ...
我和大家分享的内容主要包括以下三个方面：
① 研发团队的绩效考核的方式
② 研发团队绩效考核KPI如何评估
③ 如何让绩效考核发挥作用
这次介绍第一部分：
① 研发团队的绩效考核的方式
很多人觉得研发团队的绩效考核很头痛，甚至不想做绩效考核，其实研发团队绩效考核我认为是需要的，因为绩效考核实际是一个“指挥棒”，它会引导研发团队朝着企业认为最佳价值的方向，通过团队/个人自己的努力达到，而不是管理者通过“管理”的方式获得，这样的效果会更好。
研发团队的绩效考核如何进行？以下是我的一些实践：研发团队的绩效考核要从团队和个人两个层面同时进行，团队的考核是为了增加团队整体对质量负责的效果，个 ...
来自“Priyanka Hasija”的经验，她认为QA在Scrum中要做到：
① 不仅仅是完成test case，还可以作为Product Owner的代理，完成Acceptance test，在PO没有时间的时候代替PO和团队沟通，甚至通过质疑各种假设等方式帮助PO明确需求
② 参加故事的评估。QA在复杂的用户场景和异常流程方面更有感觉，这些可以帮助开发人员做估算时不仅仅考量“happy path”
③ 保证团队可以清楚的了解测试目标，如果可以的话，和开发人员结对做unit test
④ 为开发人员提供快速的反馈。
我的补充：为开发人员提供快速的反馈，要做到这一点，快速的方式（例如 ...
“消除研发过程中的浪费”是我在“成本控制”领域实践中的一个原则，我们在实践中总结了超过50种实际的浪费实例，包括“未完成”、“额外的”、“转换”等多种类型。我们是这样发现和消除研发过程中的浪费：
第一步：梳理“价值流”
第二步：发现价值流中的浪费
第三步：采取措施消除发现的浪费。
我以“修改Bug“的一个典型过程介绍一下我们的具体实践：
第一步：梳理“价值流”
修改Bug的典型价值流是：基本流程为：测试人员发现Bug－>程序员修改Bug－>测试人员验证－>关闭Bug，其中“测试人员发现Bug”与“程序员修改Bug”之间的等待时间以及“程序员修改Bug”与“测试人员验证”之间的 ...
风险控制、成本控制是项目管理中非常重要的两个部分，这里我分享一下对“风险控制”的一些实践。
“发现风险越早，消除风险的成本就越低”是我在“风险控制”领域实践中最重要的一个原则。
以下是一些最常用的几个实践：
实践一：项目透明
项目透明指项目干系人对项目的重要要素一目了然。项目状态透明是把项目的发布计划完成情况、发布风险、每一次迭代的完成状态、迭代风险通过物理白板（如果是离岸开发则建议用工具代替）反映出来，如果是迭代过程则要反映每一天项目的完成状态和发现的风险，这样所有的项目干系人（这里不仅仅是研发团队）都会对项目的风险关注，而且关注每一天的风险，风险会在刚刚产生的萌芽状态得到消除和控制
实 ...