作为研发人员往往需要与多种角色打交道，产品、项管、运维等等，而与每个角色打交道的过程你是否清楚你处于需求/项目/研发里的哪个环节，不同角色做出的决策是否合理，不合理的时候怎么沟通；个人、团队、小组和部门及至公司的负荷和产出如何，是否健康高效，要从哪些点入手改善。没有对应的理论支撑的话，更多只能凭经验说话，而经验不一定就是最科学了，需要结合理论进行实践。咱们今天就来探讨一下一线研发该如何理解研发效能。
开发模式进入主题前，我们得先自我思考一下，在理解流程前，我们先得清楚我们现在用的是什么开发模式？敏捷开发？敏捷的哪一种框架？scrum?可能大多数人能回答上的是敏捷，scrum，日常迭代的大体执行流程就没了。其实现在大多数敏捷团队会结合实际情况往往用到不只一种敏捷框架。
一.敏捷开发思想
敏捷开发的四句宣言：
个体与交互胜过过程与工具
可以工作的软件胜过面面俱到的文挡
客户协作胜过合同谈判
响应变化胜过遵循计划
二.SCRUM
1.核心领域定义（人工品）
人工品是指信息传播体，用于贯穿整个流程
1)UserStory。一小部分功能是，团队将在一个被称为Sprint的时间段内工作。通常的格式是：作为[用户角色]，希望[系统做这个和那个]，以便[交付这样和这样的商业价值]。它必须有一个“完成的定义”，用来确定故事是否已经正确执行。
2)Task。它可以与用户故事相关或不相关。例如，设置新的开发环境或研究CPU内存问题是与用户故事无关的任务。
3)Backlog。用户故事和未来Sprint任务的列表。
4)Sprintbacklog。从Backlog的当前Sprint中挑选用户故事和任务列表(又名“工作项目”)。
5)Productincrement。在Sprint结束时交付的一种潜在可交付功能块。
6)Extensions。像BurndownChart、Velocity等的报告，用于跟踪团队的进展。
2.参与角色
1)开发团队。包括开发人员、QA工程师、UI/UX设计师、业务分析师以及其他需要的人员。Scrum团队通常有3到9名成员。当9个人还不够时，团队就一分为二了。
2)ScrumMaster。主持每日Scrum会议、策划/更新/回顾会议，并帮助团队成员解决沟通问题。ScrumMaster不是团队成员，所以他们可以同时与多个团队合作。
3)产品所有者。利益相关者的代表，将Scrum团队的愿景(作为用户故事的基础)传达给Scrum团队，在每个Sprint结束时优先考虑用户故事，并接受或拒绝他们。
3.倡导的价值观
1)承诺(在Sprint中实现目标)。
2)勇气(做您认为正确的事)。
3)重点(在当前Sprint中的工作项目)。
4)开放(关于面临的任何挑战)。
5)尊重(相信其他人的能力)。
三.看板(kanban)
Kanban框架是由丰田工程师TaiichiOhno发明的。在20世纪40年代后期，丰田代表们观察到超市是如何根据货架上的货物重新进货。这促使丰田建立了一个供应体系，生产计划将由实际消耗驱动。Kanban的关键思想之一是避免产生过剩。Kanban通过使用Kanban卡和Kanban板来可视化资源在生产周期中的移动。这使每个人都能够最大程度地了解流程，并帮助管理人员实时解决盈余/短缺问题。Kanban系统还引入了“pull”与“push”的概念，工人可以根据自己的能力进行工作，而不是在传送带上或在待办事项列表形式中工作。在软件工程中，Kanban意味着一次可以进行的工作量是有限的。换句话说，Kanban上的“进行中”栏内可以拥有卡片是有上限的，这样做是为了增加焦点并减少上下文切换。Kanban开发的另一个方面是，活动始终与客户需求紧密相关，并与客户保持持续的沟通。除非在经济上有利于客户，否则什么都不会产生。1.原则1）专注—减少多任务;
2）减少浪费;
3）客户的需求放在第一位(即他们的业务需求-ROI);
2.实践
1）可视化;
2）限制工作进展;
3）流程管理（可以通过管理队列或限制工作来完成）；
4）明确政策;
5）使用反馈循环;
6）实验演变;Kanban和Scrum的关键区别在于：Kanban是连续的，而Scrum是迭代的。Kanban更适合在Sprint期间有大量计划外工作(支持问题;紧急修复;紧急功能请求)的团队。通过这种方式，团队可以随时重新排序任务，不再需要等待Sprint结束。
四.精益(Lean)
Lean开发者，MaryPoppendieck在她的事业生涯中取得了巨大的成功，她带领她与TomPoppendieck共同编写了Lean软件。因为Lean大量借用了Kanban，两种方法之间有许多相似之处。就像Kanban一样，Lean尽量避免浪费，最大限度地为客户带来价值。与Kanban不同的是，Lean有一些关于工程实践的规定(例如TDD)。与此同时，Lean对交付时间的要求不那么严格，团队可能随时准备部署。精益与看板的对比五．极限编程(XP)
极限编程始于KentBeck的一个实验，他的想法是把编程实践做到极致，看看会发生什么。例如，代码审查代替代码检查。后来，随着越来越多的公司开始采用这种方法，例如日常集成测试等，某些严格的规则开始被忽略。与传统的观念相反，XP不只是简单的平等配对编程，XP还提供了一个流程管理算法。需要注意的另一点是，理想情况下，所有的XP操作都应该一起使用，否则他们将无法正常工作。XP的管理方面受到了一些项目经理批评。例如，持续存在的客户被认为是压力的来源。另外，没有任何要求和设计系统可能是无效的。1.XP与SCRUM的价值观对比就像Kanban和Lean，XP也很注重浪费问题。
2.实践
1）计划游戏;
2）测试驱动开发(“先写单元测试”);
3）配对编程;
4）团队(客户/程序的实际用户可用于反馈);
5）持续集成;
6）重构设计改进;
7）小版本;
8）编码标准;
9）集体代码所有权;
10）设计简单;
11）系统隐喻(以程序员、客户和其他人理解的方式命名事物);
12）可持续性。
六．反思
结合以上的敏捷框架的介绍，重新再回答自己的团队用到了哪些框架？我自己的话感觉团队的开发模式其实涉及多个框架的原则与实践方法，从流程的角度来看大主体还是scrum，用户故事、任务拆分估时，每日站会，结果交付，过程使用燃尽图等工具来跟进迭代。一线研发角度会涉及到极限编程的某些实践，测试驱动开发，配对编程，持续集成，重构设计改进，小版本，编码标准等，从产品和管理层面会涉及精益相关的原则及实践，比较
