知行合一的敏捷实践 内容来源：敏捷+社区线上直播003期，《知行合一的敏捷实践》分享实录 分享者：道富银行敏捷教练杨贵 关注本公众号回复“知行合一”即可获取本次分享的视频回放、下载PPT。 一、原动力-你在为谁工作
在敏捷实施过程中，有几个问题很关键，包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内，今天主要聊聊人和执行力的问题。
点击阅读原文 查看回放 总结
总结来说，知行合一的敏捷实践要求做到：
价值观的认同，团队成员要有一致的价值观。 工作过程有章可循，定义好活动规则和检查规则。 团队成员积极参与。制定各项规则的owner。 反馈闭环，以数据驱动反馈闭环。 技控，用机器和工具来解决问题。
京东敏捷软件开发套路 ##开场语 京东，作为国内最大的电子商务公司，是如何进行敏捷转型的呢？在转型过程中，都碰到过哪些坑，然后又用了哪些套路，得到了什么样的结果。
我将结合自己在京东进行敏捷转型的实践，告诉大家：敏捷的核心是什么？如何进行敏捷团队转型？团队转型需要注意什么？
##背景 京东到家，2014年作为京东一个内部项目，在移动互联网的大浪潮下从一开始就注定了不平凡。京东在2015年重点打造的战略级项目，其中就包含京东到家，即基于京东强大的物流体系，整合各类O2O（线上线下）服务，主要以提供生鲜和超市产品为主。
这次分享中，我主要会介绍在2016年中，给京东到家其中一个20+的团队进行敏捷转型的案例。这个团队主要是负责京东到家的商家入驻后台，内部会和京东到家的各个团队，如业务团队、app团队、结算团队等有交集，外部与京东（包含但不限于法务、财务、审计等团队）、入驻商家、入驻商家IT团队等对接。
##如何转型 前面简单介绍了这个团队的背景，那么这个团队的转型中我们都做了什么，为什么要做这些事情呢。下面和大家一一进行拆解。 ###前提 取得信任，达成一致。
取得信任。在团队进行转型之前，一定需要得到所在团队经理或总监的认可与支持。这里的支持不是说口头说，我支持敏捷转型。而是真的会付诸行动。比如经理自身管理风格的转变，做事方法的变化等。 达成一致。达成一致需要多个层面都能统一认识。比如敏捷转型的阶段成果，比如团队的度量。一般阶段成果以3个月（季度）为单位呈现，其中每月有汇总演示。 ####度量（绩效管理） 达成一致的一个体现就是度量。下面稍微展开说一些关于敏捷度量的事情。更多的信息可以参考吴穹的“研发组织该如何设计绩效体系”
绩效管理的目标
提高个人业绩表现 改善组织结果 决定加薪或升职 1. 提高个人业绩表现
绩效管理的目标之一就是帮助个人提高，或者换个说法，个人在公司里工作的主要动力之一也是可以自我学习、提升个人价值。
反观大部分公司的绩效管理是如何做的呢？
多数公司都是等到了年底的时候，直接经理进行一次性的打分（针对这一年的表现），然后根据这样的打分来决定个人一年的总体表现。这样做，对于提高个人表现有多大的帮助呢？总之，我认为作用不会很大。
2. 改善组织结果
很多组织会有一大堆考核组织（或者团队）的度量指标——多的甚至达到20+。这么多的指标究竟有哪些可以指导组织（或团队）的改进，有哪些有负面作用？
另外，这些考核组织（或者团队）的指标往往掌握在管理者手里（团队成员并不知道）。那么这样的绩效管理对于改善组织结果的作用有多大，是值得商榷的。
3. 用于加薪或升职
正如绩效管理第一个目标（提高个人绩效）中提到的，多数公司是每年（好一点的是半年）做一次绩效评估，然后根据这次评估的结果来决定一个人的加薪或者升迁。这样的话就会导致评估结果不能真实反映实际情况，举个例子，某员工小明，在11月底的代码提交中引出一次线上事故，而在前10个月中小明表现都非常优秀。在这个情况下，小明这一年的绩效评估结果会怎么样？很不幸，估计不会太好。原因如下：1. 尽管小明之前表现非常优秀，但这次犯了错误。2. 尤为关键的是这个错误恰好在绩效评估之前，管理者记忆犹新。
前面我们列举了绩效管理的目标，以及传统按年进行绩效评估的缺陷。那么在敏捷软件开发中，如何进行绩效管理呢？
度量指标的分类
在谈及绩效管理度量指标之前，我先对度量指标做一个粗略的分类。度量指标可以分为：
内部度量指标 外部度量指标 内部度量指标
内部度量指标，指的是度量组织（或团队）内部的指标（从内部看）。举个例子，比如个人或者团队的代码行数，单元测试覆盖率，缺陷数等等。
内部度量指标主要用于提高组织（团队或个人）的效率。
外部度量指标
外部度量指标，指的是度量组织（或团队）外部表现的指标（从外部看）。举个例子，比如ROI，客户满意度，NPS等。
外部指标主要用于指导组织（团队或个人）的方向，从而组织盈利或获得成功。
敏捷软件开发的度量指标
选择度量指标的时候，有几个因素需要着重考虑：
公司的目标是什么，这个度量指标和公司目标匹配吗？ 组织（或团队）的改进方向或重点是什么？ 这个目标的数据收集工作有多大？更新周期是多久？ 最后，针对绩效管理度量，还有两个重要原则：
结果比过程重要 学习比失败重要 ###推与拉 取得信任并达成一致后，还需要考虑的问题就是推敏捷，还是拉敏捷。
推敏捷指的是推广敏捷，即团队没有真正的动力去进行组织转型而是被推着走。比如听说敏捷能提高效率，听说敏捷能解决软件开发的很多问题，等等。这种情况下进行敏捷转型，结果多半是不理想的。 拉敏捷指的是团队有意愿进行敏捷转型（内驱力），而不是上述的推。 上面分析的是敏捷转型前判断团队的状态，是推还是拉。
作者：安宝平 微信ID: abp0616
Scrum 点滴
一直想把自己使用和学习Scrum的一点心得体会写出来，因为各种原因一直没有动手，（主要原因是懒）。这次参加完“敏捷之旅2016-北京”之后正好碰见个4天的圣诞假期，再不动手就说不过去了。
在现在项目中折腾了将近4年，经历了很多很多，也和其他公司一些人讨论过Scrum，在此期间自己产生过很多疑问，也了解到别人的一些疑问，发现曾经搞清楚的问题有了答案没有记录下来，过了阵子完全忘记了，或者说那些问题的答案逐渐在自己的意识中边缘化甚至消失。自己的“组织过程资产”正在缩水，这是件恐怖的事
。趁着还没大幅缩水的时候做个文字版的记录吧。（如下内容是“现在”这个时刻的记录，半年之后会变化很多，至少现在对于Scrum的理解相比半年之前已经变化很多了。现在先记着，等研究半年后再做个记录。）
先定几个基调，嘿嘿：）
工程师如果知道这么写代码会出bug他肯定不会这么写，基本没哪个工程师故意写出有bug的代码。 工作性质决定了工程师写的代码哪怕一个单词拼写错误都可能出现bug，不是说开发工程师比其他行业的工作人员更容易犯错，而是由工作本身决定。（一个职员写一封英文邮件，有点拼写错误一般不会出现问题）。 个人或者团队的表现好与不好更多的原因在于事业环境因素。如果只抓着个人或者团队的错误不放，很有可能是在舍本逐末\缘木求鱼。 关于工程师文化：大家所谈的工程师文化都是积极的、正面的、向上的。。。我觉得吧，这有点不客观。脱离客观一般会出问题。 Scrum反对教条主义，同时反对生搬硬套Scrum的要求。不要“只是因为Scrum没有明确地提到就假定某个实践是不准许或禁止的。” 想不出来以什么形式记录这些内容，就用了模拟问答的形式，自己感觉良好。哈哈。
Q（1）: 我对于 “敏捷”粗浅的理解？
A:
a) 对于比较庞大的需求，相对于瀑布模式，在敏捷中每个迭代都交付庞大功能的小部分功能，而不是等到所有功能都开发完成之后再交付，这种更早、更快的持续交付就是敏捷，是交付层面的敏捷。
b) 为了保证每个迭代所交付的产出具有该有的质量，要对本迭代和之前迭代的所有交付做充分的测试，这些测试要在短时间内完成，人工测试难以完成，所以施行自动化测试（含单元测试、集成测试和页面交互的自动化测试）辅以人工测试。自动化测试速度比人工测试快，这是QC层面的敏捷。
引用某大咖的话“敏捷是一种心态：一种拥抱变化，拥抱学习的心态，敢于尝试，强调实战，快速反馈，适应环境和市场的变化。需要每个成员的紧密合作，需要积极融洽的团队氛围。”
Q（2）：Scrum是什么？
A: 在我看来Scrum讲的是工作流程，职责分工，如何与他人合作。是爱德华•戴明博士的管理理论在软件开发这个行业中的具体体现。是适合于软件开发这种工作的项目管理工具。
Scrum的流程是框架，文化理念才是核心。
Q（3）: 为什么要实行敏捷（Scrum）和实行时要注意什么？
A: 每个公司（团队）情况不一样，这个要看出发点或者目的是什么。就怕没有太清晰的目标，同时对于敏捷（Scrum）不甚了解的情况下引入。这种情况下引入Scrum比较容易制造出一个变形的Scrum团队：稍微问一下就会发现，其实是挂着Scrum的“羊头”卖着自己的“狗肉”，各层面问题仍然存在同时还给Scrum安了一个“徒有其名”的罪名。
想实行Scrum之前自己不妨多花些时间想想为什么要改变原来的开发模式，再找个Scrum专家（比如我，哈哈~）交流下，自己对Scrum做个深入了解，看看自己能否接受Scrum及Scrum是否适合自己。
Q（4）: Scrum Master工作的意义（产出），如何衡量？看起来Scrum Master没有做看得见的工作，凭什么要给你开薪水？
A: 这个么。。要是开发团队没有什么问题， Scrum Master确实没太大的意义，我也这么认为。但…是……，如果开发团队有很多问题，比如产出bug量很多，每个开发工程师一周之内用于修bug的时间大于等于1天。这样的情况下Scrum Master如果能把工程师每周用于修bug的时间降到1小时之内，整个团队的效率至少是20%的提升吧。一个团队年度预算如果是500W。嗯，这个产出就比较容易计算了。同时引用某大咖的话“敏捷不仅是对工作的改变，更是精神面貌的改变。”
Q（5）: 实行Scrum不需要对远期的需求做讨论（规划），只把当前几个迭代的需求讨论清楚就可以了？
A: 这个是对Scrum的误解！Scrum说的是不对远期需求做过细的讨论，但不是不讨论。比如:
l 开发的是一个全新的大项目：在开始第一个迭代之前还是要做高层次的开发规划，比如项目有12个功能模块，要在1年之内完成开发，此时要做一个年度的planning meeting。先把12个模块的流程图做出来，有了逻辑关系就有了开发顺序，再评估每个模块需要的人力。对比现有人员，就会知道是否需要补充新的人员或者评估出年度内会不会需要加班。
l 在已有项目上做新功能开发：在年度之初做planning meeting也是有必要的。只是此时可能不需要画流程图而是根据业务、市场的需求排列需求的开发优先级。
个人认为应该加入到Scrum Master培训中的内容：对于大型项目、多个Scrum团队并行开发的情形要做高层次的年度、季度planning meeting和retrospective meeting。
Scrum强调对于远期的需求不做详细的分析，只对近期要开发的内容做具体的定义，需求的细化是渐进明细的。这里要注意，低层次的、细枝末节的需求可以渐进明细，但是中高层次的需求就不能渐进明细了。反而要像瀑布开发模式那样，在最初就把中高层次的需求定义清楚。即,除了迭代的planning meeting要做，还要做季度和年度的planning meeting，要注意的是，这个年度的planning meeting比迭代中的planning meeting粒度要大的多，绝不是瀑布模型中细致入微的开发计划。对于怎么做如果加个限定词，那就是“必须”、“不遗余力”，否则容易形成需求层面的技术债务。如果在设计系统阶段没有对扩展性，耦合性，系统性能等等这些方面做充分的考虑，等问题出现时再补救会很头疼。张小龙很得意的一件事就是微信从一个小程序到现在的庞然大物没有经历过重构。
Q（6）: 实行Scrum之后不需要写文档了？
A: 这也是对Scrum的一个误解。Scrum强调面对面的沟通，避免撰写详细规格说明书，但不等于完全不写任何文档。有些文档仍然要写，并且要求还不低。我们项目组对于核心功能、重要功能和复杂功能，要求开发工程师一定要写detail design。写完的detail design通过了tech lead的审阅才能开始写代码。在此之前有时还需要工程师写出functional design（功能设计文档），所写的functional design由product owner审阅，审阅通过说明工程师对于功能需求理解到位，detail design审阅通过说明工程师在技术实现上基本没有偏差，再之后进行的开发才不会出现大的偏差。这样的QA工作做的到位再交付给QC时才不会出现过多的问题。我们这里在没有单元测试、集成测试等自动化测试的加持下做到平均每个工程师每个月产生2个bug，很大的原因在于上述QA工作。（不是说自动化测试不需要，不是我们不想做自动化测试，这些由项目组之外的管理层决定。这么大的项目目前由于缺失自动化测试导致的一些问题已经暴漏出来了。）
