东赢体育分享一个完整的敏捷项目开发流程，以及一个详细的敏捷认知到落地的知识库（文末）。

　　最近某公司负责人一直在思考这件事，“冬季如何让更多的人参加户外运动”。然后在某个下雪天，他惊讶的发现路上竟然一个雪人都看不到，这时他灵机一动，“如果现场有一些造型奇特的雪人，会不会让更多人参与户外运动呢”。

　　于是他回到公司跟核心团队交换了想法，随后经过初步的市场调研和反复的讨论，负责人决定在这一方向上投入一些研发力量进行市场验证。

　　经过产品研发部门的细化，雪人的实现路径慢慢的清晰起来，于是负责人决定投入三个敏捷团队来“堆”这个雪人，那为了保障跨团队的协作效率，相关团队有这么几个重要的工作契约：

　　从全团队的计划会议上，所有人明确了第一个开发周期的目标：一个戴帽子的雪人（MVP版本）。

　　团队一采用的是Scrum，他们第一个开发周期的目标是“实现一顶能戴的帽子”；

　　团队三采用的也是Scrum，他们第一个开发周期的目标是“实现一个结识的身体”。

　　他们约定了各自的对接时间和关键协议，然后在随后的两周时间里，每个团队开始了各自的研发任务。当然除了既定的业务目标，每个团队也把自己第一版的CI/CD搭建了出来（非功能性需求）。

　　两周后，第一版雪人在预发布环境中亮相，因为内部已经经历了验收和跨部门的联调，所以这次的预发布过程中没有遇到什么大问题。两天后，雪人被投放在指定的地点，根据数据埋点显示，当天现场有很多人围观，引起了不小的轰动，负责运营的团队在现场也收集了很多反馈。

　　后来负责人召集核心团队对第一版雪人的发布进行复盘，同时对发布后的数据进行了分析，最终负责人决定在这个方向上继续投入，随即负责人召集产品研发部门规划了下一阶段的工作。

　　第二个开发周期的目标确定后，各敏捷团队的”待办事项列表“都更新了。这三个敏捷团队根据最新的”待办事项列表“对这个周期的工作进行了规划，然后开始了新一轮的开发，接着第二版雪人如期投放，吸引了更多的人到户外参加现场活动。

　　之后是第三次迭代、第四次迭代……随着时间的推移，各个敏捷团队的交付能力越来越强。为了最大化的发挥敏捷团队的创造力，负责人做了如下要求：

　　相信通过这个故事你对敏捷开发流程已经有所了解，下面我将结合我们团队的经验，讲述一个完整敏捷流程闭环是什么样的，典型的敏捷团队是什么样？内部又有什么样的流程的？，以及我们常使用的辅助工具PingCode

　　在一个健康的互联网公司中，一个明智的决策通常要经过充分的调研和评估，然后才能成为各个部门的目标。当然定目标绝不是喊口号，它包含两部分的内容：

　　而在这个过程中，各个关键角色的目标要进行对齐，所有人的步调要保持一致，由下向上及时反馈目标进展。

　　那对于产品研发部门来说，产品的研发进度无疑是非常重要的。如果我们对一个产品目标进行分解，会形成一个产品的关键路线图（或者称为用户故事地图），在这个路线图中分布着不同的产品特性和其完成时间。

　　进入到一个Scrum团队中，他们在自己的”产品待办列表“中就可以看到按优先级排序的各类需求。

　　Scrum团队会根据综合因素（通常包含：优先级、工作量、依赖关系、非功能性需求的比例等等）安排每个开发周期的工作，他们在每个开发周期结束时都会产出一个可以交付的程序增量。随后我们将所有的Scrum团队完成的服务进行集成，形成一个全局版本，部署到生产环境中。

　　最后我们再对不同的功能点进行追踪，对各类活动数据进行分析，为后续的决策提供数据支持，这便形成了一个完整的闭环。

　　这里我之所以把”敏捷开发流程“拉的这么长，是因为今天的敏捷已经不是”团队级别“的概念了。20年前敏捷开发试图解决业务团队与开发团队之间的矛盾，而今天敏捷开发是一种思维方式，这种思维方式将为整个组织进行赋能。

　　那对于今天雪人的故事而言，整个组织就是在用敏捷的方式响应新的”需求“。如果只有研发部门采用敏捷开发，那今天故事的结局会不一样；如果只有一个研发团队采用敏捷开发，那故事的结局会更不一样。当然今天雪人的故事中有很多夸张的因素在，很多事情并不是一蹴而就的，基础设施也需要时间来演进。

　　首先，我认为敏捷开发绝不是一种或几种固定的开发框架，虽然我们在实施敏捷开发时确实也离不开这些框架，但敏捷最大的价值是它传达出来的价值观。

　　其次，我认为使用Scrum和看板这样成熟的框架是十分必要的，标准化的研发流程容易产生规划化效果，说人话就是容易复制。那么典型的敏捷团队是什么样？内部又有什么样的流程的？

　　这个团队在开始一个新的Sprint之前，PO会及时更新左侧的产品待办列表，他通常按照优先级进行排序，并对列表里的工作项复杂度有个大概的认知。

　　在第一周周一的早上10点，Scrum Master组织所有人参加计划会议：首先由PO说明这个Sprint的目标，再对待办列表进行讲解。然后由开发团队对用户故事的规模进行预估，在团队容量允许的情况下，将用户故事放入这个Sprint的工作列表中。之后由开发团队对Sprint的工作列表进行承诺。

　　散会后各自回去主动领任务开始干活，当开发工程师开始一项工作时，他会从主分支checkout出一个特性分支，然后基于这个分支提交新代码，当开发完成时，他会向主分支提交Pull Request（或Merge Request），这会自动触发CI流水线（执行静态检查、单元测试等），CI流水线通过后，需要另一位开发工程师手动Code Review，只有Code Review通过后代码才会合入主分支，这会自动触发CD流水线（执行集成测试、部署测试环境等）。

　　每天早上10点，Scrum Master组织所有人开站立会议，每人花2分钟同步一下工作进展。

　　第二周周五下午4点左右，Scrum Master组织所有人开评审会议，由每个任务的负责人演示其完整的工作，由PO确定Sprint目标是否完成，版本什么时候对外发布，新增bug的紧急程度等等。

　　第二周周五下午5点左右，Scrum Master组织所有人开回顾会议，每个人说一下团队做的好的和不好的地方，有哪些改进方案等。

　　第三周（新Sprint的第一周）周二的晚上，部署最新的版本到生产环境中。

　　这个团队非常注意”流动的感觉“，为了保证让工作流动起来，他们定义了5个栏：需求、设计东赢体育、开发、测试和部署，其中设计、开发和测试都有明确的“完成的定义”和在制品的限制。

　　当设计同学准备处理下一项任务时，他只需从上一栏中拉过来即可，但是当他想将任务拖到已完成时，这项工作必须满足设计栏的“完成的定义”。

　　就是说所有的方案必须通过评审，并且将影响方案告知相关方。当他不把这个任务拖到已完成的时候东赢体育，那么下游的开发同学不会继续处理这个任务，这项任务将一直卡在”设计正在做“这一栏里。

　　当开发同学准备处理下一项任务时，他只需从上一栏的已完成中拉过来即可，当他要完成一项任务时，要提交相应的代码，覆盖单元测试并通过CI，然后再通过CD部署到Test环境中。

　　当测试同学准备处理下一件工作时，他只需从上一栏的已完成中拉过来即可，为这个任务写相关的自动化测试并执行通过，然后再把任务拖到已完成中。

　　他们每天早上都会看着看板开早会，说一下当前的工作进展。在这个过程中，如果有一项工作长期被卡在某一栏中，将很容易被发现，如果有大量的工作被卡在某一栏时，这时将暴露出这个团队最大的瓶颈问题。这样的方式让他们的工作状态一目了然。

　　类似这样的Scrum和看板团队组成了一个大型的研发部门，这个部门有自己的季度目标，每个月至少会开会一次部门同步会，他们会同步所有项目的工作进展和下一步的工作计划，就像雪人的故事一样……

　　敏捷开发的流程就是这样的，PingCode提供的标准化研发流程也是这样的。

　　Keep 的开发流程是基于 Scrum ，该流程要求在特定的一段时间内，输出确定的需求，在开发中需求尽量不要变更，开发人员快速完成开发。当前，Keep 的迭代和发版周期为两周，保持两周一更新，这样能让用户一直对产品保持新鲜感，也使团队的开发更有节奏。 Keep 技术开发的迭代周期和流程如下图所示：

　　为了在两周时间内完成高质量产品，我们需要尽最大努力去执行 Scrum 中的每一步，同时在 Scrum 流程上做了一些适合团队的调整和优化。

　　产品经理会使用 Keep 的数据平台分析往期功能的数据来确定是否要做调整和改进，以及结合用户反馈系统的反馈来确定是否要添加某一项新功能。在产品内部评审和优化之后，产品经理会和各个业务的技术负责人再一起去做需求的评审，确保需求的合理性和重要程度。接下来我们会将需求拆分到各个开发人员，通过估时来确定每一个 Sprint 具体完成的任务。另外我们将 Phabricator 中的需求任务和我们的聊天工具 BearyChat 做了关联，之后当需求发生改变的时候，都会自动的发一条变更消息给这个需求群组中的同事，节省了需求变更后的沟通成本。

　　任务拆分是整个流程中重要的一环，在 Scrum 中我们是这样进行任务拆分和评估的。首先在技术组内会花半天时间讨论，将产品 Task 再次拆分为子任务，对应的开发 Owner 会提前准备好需求设计方案和评估时间点，然后组内同事对开发 Owner 提出的设计方案进行建议和二次评估，得出拆解完的子任务和对应的估点时间表。

　　我们使用 Phabricator 的 Workboard 进行排列和展示，把所有拆解后的 Task 放到 Workboard 的一列中，同时在子 Task 中填写评估的时间和设置 Task 的优先级。如下图所示，Workboard 可以非常清晰的划分出每个任务，同时可以清楚的看出 Task 的完成程度。在右上角可以看到整个需求被拆成了多少个子 Task，以及需要消耗的开发时间。使用 WorkBoard 让我们的任务划分更加清晰，根据任务状态来跟进目前整体的进度，有助于整体项目的把控。

　　任务拆分和评估完成后，进入开发阶段。在正式迭代开始之前，会确定一名产品同事作为 Scrum Master 来推动整个项目。除此之外，当涉及到需要多个技术团队支持的需求，我们会指定一名技术同事来负责沟通和协调。这样既解决了产品同事不了解技术协调技术沟通的难题，也提高了技术同事的沟通能力。

　　在开发过程中，必要的沟通会议是不可或缺的。如何减少不必要的会议，提高会议的效率是我们一直努力的方向。目前 Keep 的会议采用 Google Calendar 邀约的方式，被邀请者可以根据自己的时间和会议的重要性来选择要不要参加，同时会议的组织者也可以清楚的查看其他人的时间防止安排冲突。

　　此外我们通过一系列消息自动推送服务来减少开发人员之间的沟通成本，比如 Server 服务上线、有新的测试包、Bug 状态变更、新的用户反馈等等各种通知都采用 BearyChat 的 Robot (聊天机器人) 来通知，极大降低了沟通成本。Keep 技术团队内部还使用了如 Seafile, Google 企业套件、Alfred、ResuceTime 等各种工具来提升团队和个人的开发效率。

　　项目质量也是在开发过程中不可忽视的一环。Keep 代码使用 Phabricator 来托管和 Code Review。我们设置了主要项目的代码提交前必须做 CodeReview，同时每个项目设置2 - 3位资深的工程师作为Block Reviewer，合入主干必须得到 Block Reviewer 的同意。对于比较重要、大型的 Diff ，我们会单独拉会议室邀请多位工程师来共同 Review 以保证代码质量，并要求代码作者在每次提交之前都应该自己过一遍代码，走一遍冒烟测试，确保基本的功能是完整的。

　　进入测试阶段前，我们添加了 Show Case 环节。其实 Show Case 就是产品在工程师提交给 QA 之前组织开发人员、设计师、测试人员简单过一遍功能点，发现逻辑上比较明显的一些问题交给开发人员再次修改，以及确保整体流程不会被严重的 Bug Block 住。团队内部测试完毕后，会使用内部自动化发布工具发给用户升级，在一周内进行内测和灰度两次测试。我们使用微信群运营维护了一批忠实的用户粉丝作为内测用户，内部测试覆盖规模大致为 500 人，灰度测试的覆盖规模增加到 2000 人，一方面验证内测的 Bug 是否被解决，另一方面避免遗漏概率低于 0.1% 的问题。

　　最后是整个迭代末期的总结和复盘。我们会组织一场回顾会议拿出这个 Sprint 版本产品、技术功能点进行展示，同时对线上功能进行数据的同步。如下图展示了 Keep 的部分数据：

　　我们会根据这些数据进行分析和总结，验证之前的需求是否达到想要的目的，做的 A/B Test 哪一个更有效。此外回顾会议会记录下大家讨论出在这次 Sprint中有哪些做的好的地方，有哪些值得改进的地方，并在之后的 Sprint 中加以改正。

　　在开发过程中也难免会遇到线上的一些事故，比如服务器冗机、客户端出现严重质量问题。在 Phabricator 中有一个专门的 Project 叫 Post Mortem 来记录每次线上发生的事故，记录这些事件发生的原因、经过、结果以及对于整个事件的反思和总结，只有这样才能不断提升我们的能力，让团队在反思中成长。

　　以上则是 Keep 在用户高速增长过程中践行的技术开发流程。我们使用更加高效的工具来提升团队的开发效率，通过更严格的 Review 来确保证代码质量，建立灰度测试流程来提高项目的质量，在数据分析和项目复盘总结反思中调整方向和保持团队成长。相信各个公司团队都有着适合自己团队的一套开发流程，也许 Keep 目前的开发流程不是最好的，但我们一直努力去更加积极探索和优化目前的开发流程，让团队协作更加简单高效。

　　第一篇对IT职业做了一个相对深入的介绍，给了想从事互联网职业的人一个了解各个职业的机会，已经有4000+赞了，我想是真的帮助到了很多人。IT行业都有哪些职位，初学者（0基础，新人）该如何选择，才能够快速进入这个行业？ - xdyl 的回答

　　第二篇是对敏捷开发和项目管理做了一介绍，这篇贴子还没写完，其实它的价值远远大于第一篇走马观花的介绍。只是大家还没有到能够理解敏捷开发的时候，所以我想了很久，决定暂时不写了。互联网公司的“敏捷开发”流程是怎么样的，每个职位的角色和分工是什么？ - xdyl 的回答

　　这是第三篇，写这个贴子的动机是因为，在修真院有不少人在问，我要学到什么程度才能找到工作，我是零基础啊，有没有视频和教程可以教我。有哪些IT初学者（新人）成长为技术大牛的真实经历？ - xdyl 的回答

　　顺手推荐一下修真院的专栏，各种IT行业的真实小故事。IT修线.本回答和第一篇不同，纯属分享，并不需要有任何的广告。

　　4.这个回答，是任何一个初级或中级甚至是高级的程序员，产品经理，Leader都可以认真去思考和尝试的，某种程度上，这个回答比写两行代码更有效果。

　　在几万年以前，软件项目的开发都是以年来计算的，这代表什么意思呢 ？需求设计了半年多，方案设计做了半年多，开发了三年多，测试了半年多，修改Bug用了半年多。总计花了很长很长的时间，然后上线后发现有很多需求已经不存在了，同时又出现了很多新的需求。怎么办？继续改。这一改又是半年多的时间过去了。马丹用户的需求还再改，怎么办？

　　这是困扰软件开发项目的最大的问题，越大的项目，参与的人越多，风险越大。文档越规范，维护起来的难度就越高，导致项目中遇到的问题越来越多。

　　不仅仅在几万年前，就是在现在，也是经常会有团队出现这种问题。不相信，你可以看看是否遇到了以下这些问题：

　　2.开发工程师做出来的项目，bug不但多，而且经常改不好。常常是改了一个Bug，出现另一个Bug，好不容易把一个Bug改好了，过了没多久又重现了。原本好好的功能，反而会因为改Bug导致出现的问题更多。

　　3.做出来的东西完全不是产品经理想要的样子，沟通完之后才发现开发工程师的理解和产品经理的理解是完全不一样的。

　　4.项目延期不是最坏的结果，最坏的结果是还从不知道项目倒底会延期多少，根本没办法去衡量工作量，团队的成员都在加班加点，然而完全看不出来问题出在什么地方。

　　5.开发文档，产品文档，接口文档，测试报告和真实的代码从没有完美契合过。产品经理设计出来的原型和UI设计出来的页面和程序员开发出来的代码完全是一种不同的体系，三位一体的故事从没有真正发生过。代码的实现和接口文档根本不一致，最后索性干脆不看接口文档，完全口头交流。出错的时候各种撕逼扯皮，谁也分不清倒底谁错了。

　　6.Team的战斗力和凝聚力不强，经常是对着干，对分配的任务总是各种报怨，出现问题之后第一反应是这个不关我的事，不是我的问题，是后端前端设计QAPM的问题。

　　如果你遇到了这种情况，或者说你不甘于这种现状，那么恭喜你，你可以真的需要敏捷开发流程了。

　　2. 需求评审3. 需求讲解4. 方案评审5. 每日晨会6. 性能测试7. CodeReview8. Demo9. 测试阶段10.线上Bug修改流程表跟我说哪些东西不应该包含在敏捷开发流程里，如果你不喜欢，跟你的观念有冲突，你可以把敏捷开发这四个字换成任意四个字。总之，如果要解决这些问题，这是我目前看到的最佳实践，每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的。

　　如果你是一个IT公司的管理者，如果你不知道该怎么去管理自己的团队，我强烈安列你按着我说的这种标准化方式去做，放心，出了问题我保证不会负一点责任。

　　确切的说，我说的敏捷开发流程，并不仅仅是开发团队的事情，它背后隐藏着更多的理念。我可能整理的不够清楚，毕竟这是第一版。

　　如果你的公司是把产品和开发分成两个部门，那么恭喜你，产品和开发之间的纠纷一定无限多。

　　在所有我带的Team中，自始至终强调的理念就是：出了问题，别跟我说这是产品设计出来，这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任，这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题，那么也只是为了避免下次出现同样的情况，用户只会知道是一个公司出了一款垃圾产品，没有人关心到底是产品还是开发的锅。

　　这是做敏捷开发的大前提。或者不仅仅是产品和开发，责任共担，One Team这个理念是贯穿始终的。这并不是说，大锅饭，而是说，面对不好的结果，所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景，以避免后续会出现同样的情况。

　　产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候，会提高的。实际上，需求分期如果没做好，敏捷开发只能流于形式。

　　需求分期怎么做，这是MVP的事情，另一个话题。简单来说，每一期都要有一个提前的预测，这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。

　　UI 1个CSS/js 1~2个Java 2~4个Android 1~2个IOS 1~2个QA 1个这是一个相对平衡的模板，这样的一个8~10人的小Team，是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式，可以支持五到六个小Team同时启动。

　　1.产品Team 产品团队2.用户体验 Team 传统的UI团队升级为UE，升级为整个系统甚至是公司的用户体验师。3.后端Team 苦逼的后端4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起，我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入，但是普通的项目上手还是应该没有问题的。5.QATeam QA只需要做功能测试，回归测试，边界测试，并不需要做性能测试。这里也会在后面提到。

　　那么来描述一下每个角色的不同职责。这些不同的角色牵涉到团队并行开发，所以并不是简单的随便扒拉到一堆就好了的。

　　： PM的职责并不是画原型，而是去分产品的分期，确定产品要做的功能和优先级。对于产品来说，最大的职责并不是将原型画出来，而是要证明自己要做的功能是合理的。如果你证明不了自己要做的功能是合理的，是值的尝试的，就是产品经理的失职。可以参考MVP，有无数的办法可以提前验证，如果不能够提前验证，那么就证明这是有风险。做为PM，一定要有这种风险的意识，要知道自己身上担负的责任，PM花了两周时间设计的原型，8人的开发团队要折腾近三周左右的时间。

　　原型和产品文档都是辅助的东西，我甚至不推荐产品经理去做原型设计，只拆分Story。

　　PM不需要为开发进度负任何的责任，这很重要，不要把PM当成项目管理来使用，如果你让PM去做了项目管理，恭喜你，Game 近乎 Over，产品经理没有时间再去思考如何做功能了。

　　PM的职责就是把功能设计好，优先级排好，给开发团队讲清楚需求，结合Story优先级和功能实现的大概时间点去做排期。

　　开发工期交给开发团队去做，Bug会和QA，开发团队一起来定。记着要在开发团队开发项目的时间里，去做好下一个产品迭代的设计。

　　：需求评审会的成员应该包括PM组的Leader，前端组的leader,后端组的leader,测试组的Leader，或者是其他公司的中层骨干。这应该是一个公司所有应该为这个项目负责的人的评审会，在评审会上的结论，就应该被坚定的执行下去了。不参与评审会的人，不应该再对需求指手画脚。

　　需求评审会的目标就是确定原封不动的需求，所以在这里要格外的注意，PM拿出来的方案设计，一定是完整的，而且必须评细节。如果说，一个公司的中层骨干经过需求评审会议，仍然需求乱成一比，那就没什么可说的了，继续努力提升自己的水准，或者是补充真正的中层。

　　小组的Leader还应该负责项目中风险的调控，考虑是增加人手，安排加班，项目延期，还是调整功能。

　　与些同时，应该去审核最后的性能报告，看看是否达到系统的期望值，遇到了疑难问题如何解决。

　　项目进入真正的开发阶段后，开发组的成员就应该是主动去控制项目的进度，和风险，以及主动去测试项目中存在的问题，在这个阶段，除了一些需求不明，或者是发生变动的情况出现，不应该去打扰产品经理。不要让产品经理做开发团队的保姆。开发组的成员的目标就是做好项目的进度控制，有风险就及时反馈给Leader，确保自己理解的需求是明确无误的，确保自己的测试是完整和严谨的，确认自己写出来的代码是可以维护的东赢体育。

　　一定要理解清楚，一旦PM通过Story讲解，将需求交付给开发组成员，那么开发组成员就应该主动而独立的为这件事情负责。

　　当项目完工以后，开发组成员应该交叉去做CodeReview，并且出性能测试报告，以及组织Demo。

　　：测试级成员的职责不是做功能性的测试，也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成，除了一些特别麻烦的，需要各种极端条件才能复现的，正常的操作过程中出现的问题，都应该是有开发组承担。性能测试同样是开发组人员自行完成，各小组Leader只需要知道一件事情，测试报告是否能够通过。所以测试组的主要做的就是准确的记录，以及bug的统计。也不应该去天催促开发组的成员去改Bug。只需要去反馈给开发组的Leader就好了。整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效。

　　回归测试是需要做的，但是也不是完全必须要做东赢体育。如果能够积累足够多的自动化测试用例，就去正常使用它，如果不能，就尽可能少的减少回归测试。这需要跟开发人员沟通的比较清楚，他们往往更清楚，什么地方容易出问题。

　　接受线上的反馈并且记录也应该是QA的职责，如果Team足够细，可能会有运营或者是客服统一对外收集，然后交给QA，QA再负责录入Bug系统中。

　　基本的敏捷开发流程中的角色的职责大致就是这样的了。这不是一件容易的事情，其中的很多小细节，都照顾到了每个角色的职责和义务。理论上来说，如果有一张图的话，可以更清楚的画出来不同角色的功能。

　　这种职责的划分，和传统的职责会有一些不同，反正，在我带过的Team中，这是最高效的，也是最能发挥出团队的能力的方式。你可以信，也可以不信，这中间的每一个细小的调整，都是经过无数个日日夜夜的验证而得来的，我还未曾看到过比这种职责划分方式更高效，更合理的做法，虽然我接触的Team也不够多，爱信不信~

　　当有了第二条，你很快就能发现团队中，谁是能够尽守职责，更主动的人。第3条很难做到，特别在很多公司，并不注重对于团队凝聚力的培养，也不会注重和他们之间的交流，不知道他们想要什么。

　　所以这也是我一再强调的，敏捷开发并不仅仅是一个开发流程，更是一种管理的方式，他牵涉到绩效考核，公司福利，上下班制度等等你看不到的东西。

　　如果说你的团队成员并不能做到为自己的事情负责，那么你需要的就是，要么就是去更换团队，要么就是想办法去激励团队。这是另一个话题了，我心情好的话，可能会在这里提到，如果心情不好东赢体育，可能会在下一个文章里，也可能根本就不会写了。

　　这件事情其实也不算难，第一，明确这种职责的分工是合理的，第二，Leader都需要了解自己的团队的状况。第三，不断的去强化和培养这种做事的习惯。

　　就够了。团队是需要打磨和改造的。这三点是敏捷开发实施的前提，而不是说，有了这三点，敏捷开发就一点能做好了。

　　下面是实施Scrum的主要步骤，你也可以订阅明道博客，获取更多Scrum内容：

　　我希望___,以完成____,这样的好处是让整个团队更容易理解需求，达成共识，图为一个实例：>

　　之后，Scrum可以去筛选产品需求表列，和产品经理、团队一起根据需求的重要性、开发量来制定开发优先级。开发团队一旦接受这些开发任务，就应该准时完成，不得修改交付标准。

　　其他的，还要有一个每日的Scrum会议，会议的目标是讨论当前的任务的状态，一个推荐的汇报形式是：

　　每个Sprint结束后会进行一次产品演示，由开发团队向所有人展示他们的开发成果。

　　另附上一个7分钟介绍Scrum的视频，可以帮助你和团队更容易理解Scrum。

　　等诸多问题，这些问题背后都反映了大型研发团队在项目管理中面临的普遍挑战：

　　。而大多数团队管理者在面对「为何延期」、「如何避免延期」的问题上，总是焦头烂额。>

　　。「职能墙」引发的另一个问题是，制定 KPI 的维度单一，容易造成责任推诿。尤其是在整体研发过程中，系统与系统之间存在非常多中间的灰度地带，大家都不想做中间这一块，最终影响了整体业务。

　　等，均反映了研发管理过程中的团队沟通问题。没有高效的团队协作环境，容易形成信息孤岛，影响团队士气，导致项目延期和项目质量等问题。

　　。另外，选用的数据指标是否客观、有说服力，不同团队间的数据分散在不同的系统中难以打通，这些都是导致团队效能难以度量的重要原因。

　　。这样做的好处是部门间的「职能墙」被打破，团队实现更紧密的协作配合。2.

　　，避免各自为战。另外，在团队绩效考核上，也要先考核团队，再考核个人，从而引导每个人工作的时候更多考虑业务目标。3.

　　。一旦团队价值观确定，团队的管理者、一线的执行同事都应该执行和接受，并将其时刻反馈在工作决策和工作流程当中。此外，将团队的经历沉淀为「团队故事」有利于团队文化的传播，激励团队成员。最后，管理者在团队建设上要招聘拥有相同价值观、认可团队文化的人，带领团队聚焦目标，在与团队的反复沟通协作中保证目标对齐，敏捷执行。4.

　　。在怎么做上，总是以优先级排序所有工作，保证团队目标聚焦。执行阶段，需要

　　，提升效率。同时，每日检查项目进展情况，提前发现和应对风险，保证项目按时、高质量交付。分析阶段，通过⼯作数据的结构化存储，聚合量化。利用数据

　　，如按时交付率、缺陷密度。而在做业务优化时，则选择过程数据，如技术评审通过率、故事点完成速率。最后是要做调整。

　　。这也是敏捷中推行的「迭代」，帮助团队更好地看到效果，提高项目风险营地能力。以上，希望可以为大家提供更多维度的参考与借鉴～