为什么需要敏捷开发

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

怎么办？继续改。这一改又是半年多的时间过去了。用户的需求还再改，怎么办？

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

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

需求总是在变动，反复变动，无限拖延。

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

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

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

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

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

如果遇到了这种情况，那就代表真的需要敏捷开发流程了。

敏捷开发包括了哪些内容

敏捷开发总的流程如下：

​ 需求规划和分期 ​

​ 需求评审 ​

​ 需求讲解 ​

​ 方案评审 ​

​ 每日晨会 ​

​ 性能测试 ​

​ CodeReview ​

​ Demo ​

​ 测试阶段 ​

​ 线上Bug修改流程 ​

如果要解决这些问题，这是我目前看到的最佳实践，每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的

1.One Team

​ 产品和开发必须是一个Team，大家只是分工不同，角色不同，并不是两个对立的团队。 ​

绝大部分公司的产品和开发都是分开的，那么产品和开发之间的纠纷一定无限多。

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

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

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

需求分期怎么做，这是​ MVP（​Minimum Viable Product：最小化可行产品​） ​的事情，简单来说，每一期都要有一个提前的预测，这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。

2.职责明确

​ 每个人要负责的事情必须清晰无误，谁该做哪些事情，必须要提前讲清楚。 ​

开发团队的推荐角色应该是这样的。

PM 1个

UI 1个

web前端 1~2个

后端开发 2~4个

终端开发 1~2个

QA 1个

这是一个相对平衡的模板，这样的一个7~10人的小Team，是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式，可以支持五到六个小Team同时启动。

多Team并发写作的时候，除了这些项目小组的角色，还有各个Team的Leader。我比较推荐小组分成如下几种：

产品Team 产品团队

用户体验 Team 传统的UI团队升级为UE，升级为整个系统甚至是公司的用户体验师。

后端Team 苦逼的后端

前端Team Android/IOS/JS 一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入，但是普通的项目上手还是应该没有问题的。

QATeam QA 需要做功能测试，回归测试，边界测试，性能测试。

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

​ PM ​ ： PM的职责并不是画原型，而是去分产品的分期，确定产品要做的功能和优先级。对于产品来说，最大的职责并不是将原型画出来，而是要证明自己要做的功能是合理的。如果你证明不了自己要做的功能是合理的，是值的尝试的，就是产品经理的失职。

可以参考MVP，有无数的办法可以提前验证，如果不能够提前验证，那么就证明这是有风险。做为PM，一定要有这种风险的意识，要知道自己身上担负的责任，PM花了两周时间设计的原型，8人的开发团队要折腾近三周左右的时间。

原型和产品文档都是辅助的东西，我甚至不推荐产品经理去做原型设计，只拆分Story。原型设计交给传统的UI更合适。然而在真实实施的过程中，因为很少有UI具备原型的设计能力，所以实施起来会有一些难度。这个不算特别重要，慢慢培养。

PM不需要为开发进度负任何的责任，这很重要，不要把PM当成项目管理来使用，如果你让PM去做了项目管理，恭喜你，Game 近乎 Over，产品经理没有时间再去思考如何做功能了。PM的职责就是把功能设计好，优先级排好，给开发团队讲清楚需求，结合Story优先级和功能实现的大概时间点去做排期。

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

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

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

吸引需求评审会的意见，尽量让自己的需求和设计通过评审。

各个小组的Leader还应该承担的角色就是各个组的方案评审。这是中层骨干必须要起到的作用。小组的Leader还应该负责项目中风险的调控，考虑是增加人手，安排加班，项目延期，还是调整功能。

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

​ 开发组成员： ​项目进入真正的开发阶段后，开发组的成员就应该是主动去控制项目的进度，和风险，以及主动去测试项目中存在的问题，在这个阶段，除了一些需求不明，或者是发生变动的情况出现，不应该去打扰产品经理。不要让产品经理做开发团队的保姆。

开发组的成员的目标就是做好项目的进度控制，有风险就及时反馈给Leader，确保自己理解的需求是明确无误的，确保自己的测试是完整和严谨的，确认自己写出来的代码是可以维护的。

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

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

​ 测试组成员 ​：测试级成员的职责不是做功能性的测试，也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成，除了一些特别麻烦的，需要各种极端条件才能复现的，正常的操作过程中出现的问题，都应该是有开发组承担。性能测试同样是开发组人员自行完成，各小组Leader只需要知道一件事情，测试报告是否能够通过。

所以测试组的主要做的就是准确的记录，以及bug的统计。也不应该去天催促开发组的成员去改Bug。只需要去反馈给开发组的Leader就好了。整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效。

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

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

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

这种职责的划分，和传统的职责会有一些不同，目前来看应该算最高效的，也是最能发挥出团队的能力的方式。

3.主动承担

​ 每个人必须学会主动去为自己的事情负责 ​

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

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

如果说团队成员并不能做到为自己的事情负责，那么需要的做就是，要么就是去更换团队，要么就是想办法去激励团队。

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

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

在具体的实施上，还有无数的细节是需要去整理和落地的。

SCRUM工作流

在讲述流程之前，先介绍一下Scrum中的几个角色：

产品经理。分析用户需求、提出产品方案，为客户负责。

Scrum Master。负责协调整个Scrum过程，还要负责Scrum的各类会议

Scrum 团队。包括研发、测试等。

Scrum的主要步骤

创建产品需求列表（Product backlog）

一个产品的需求可能来自客户、团队或者产品经理的想法，这些需求的描述必须符合：

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

产品经理需要将需求初步筛选，并准备进入下一个步骤---Sprint（开发冲刺阶段）

创建开发需求列表和制定开发计划

首先，你需要确定每次Sprint的周期，短的周期可以更频繁的发布产品版本，因此可以从客户那里更迅速地收到反馈，修正错误。当然，你也可以让周期变得长一些，比如2周的时间。这样可以让开发人员更投入地工作。

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

执行Sprint（开发冲刺）

所谓Sprint，就是在一定时间内全身心投入开发。这个阶段通常用看板来管理需求，每个卡片就是一个开发任务，工作完成后，可以将卡片移到下一个阶段，用看板管理需求长这个样子：

你也可以使用专门的软件来管理看板，例如国外的Jira，国内的禅道。

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

我昨天已经做了什么

我接下来准备做什么

现在遇到什么阻碍和问题

此外，你还需要一个燃尽图还帮助了解还有多少任务没有完成，每次开完会更新一下就行了

测试和产品演示

因为每次的Sprint目标就是交付一个可以用的产品特性，所以测试工作非常重要。有不少方法可以减少测试周期，比如，你可以减少需求数量，或者让开发参与测试。

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

项目反思会和下一个Sprint计划

项目反思会的目的是讨论交付的成果和下一步如何改进工作，哪里做得好、哪里不好都可以提出。确定了改进方向，就可以专注于下一次Sprint了。

Scrum的最大特色是灵活和增量交付，要求团队之间有开放的沟通和协作。首先是由产品经理收集和整理需求，然后和开发团队确定开发列表，接着进入Sprint（开发冲刺状态），后面就是日常开会、后期改善。