敏捷开发

最新推荐文章于 2023-05-04 11:12:33 发布

为爱修行

最新推荐文章于 2023-05-04 11:12:33 发布

阅读量178

点赞数

以下文章转载自知乎,暗灭-京华九月秋近寒，浮沉半生影长单.

暗灭

京华九月秋近寒，浮沉半生影长单

366 人赞同了该回答

前言

================================================

1.本回答从属于“IT修真院”收藏夹系列第二篇，第一篇是IT职业介绍。

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

第二篇是对敏捷开发和项目管理做了一介绍，这篇贴子还没写完，其实它的价值远远大于第一篇走马观花的介绍。只是大家还没有到能够理解敏捷开发的时候，所以我想了很久，决定暂时不写了。

互联网公司的“敏捷开发”流程是怎么样的，每个职位的角色和分工是什么？ - xdyl 的回答

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

顺手推荐一下修真院的专栏，各种IT行业的真实小故事。IT修真院 - 知乎专栏

2.本回答和第一篇不同，纯属分享，并不需要有任何的广告。

3.但是，本人依然不对分享出来的任何内容的可信度负任何的责任，也根本不保证是一篇公正，客观，完美的回答。

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

5状态：未完待续

正文

========================================

首先讲为什么需要敏捷开发。

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

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

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

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

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

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

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

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

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

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

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

第二，敏捷开发包括了哪些内容

敏捷开发总的流程如下：

1.需求规划和分期

2. 需求评审

3. 需求讲解

4. 方案评审

5. 每日晨会

6. 性能测试

7. CodeReview

8. Demo

9. 测试阶段

10.线上Bug修改流程

表跟我说哪些东西不应该包含在敏捷开发流程里，如果你不喜欢，跟你的观念有冲突，你可以把敏捷开发这四个字换成任意四个字。总之，如果要解决这些问题，这是我目前看到的最佳实践，每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的。

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

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

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

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

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

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

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

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

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

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

PM 1个

UI 1个

CSS/js 1~2个

Java 2~4个

Android 1~2个

IOS 1~2个

QA 1个

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

在讲到最后多Team并发协作的时候，我也会提到的。

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

1.产品Team 产品团队

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

3.后端Team 苦逼的后端

4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起，我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入，但是普通的项目上手还是应该没有问题的。

5.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系统中。

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

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

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

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

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

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

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

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

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