2022年2022年互联网团队开发流程 .pdf

为什么需要敏捷开发。在几万年以前，软件项目的开发都是以年来计算的，这代表什么意思呢？需求设计了半年多， 方案设计做了半年多， 开发了三年多， 测试了半年多，修改 Bug 用了半年多。总计花了很长很长的时间，然后上线后发现有很多需求已经不存在了，同时又出现了很多新的需求。怎么办？继续改。这一改又是半年多的时间过去了。马丹用户的需求还再改，怎么办？这是困扰软件开发项目的最大的问题，越大的项目，参与的人越多，风险越大。文档越规范，维护起来的难度就越高，导致项目中遇到的问题越来越多。不仅仅在几万年前，就是在现在，也是经常会有团队出现这种问题。不相信，你可以看看是否遇到了以下这些问题：1.需求总是在变动，反复变动，无限拖延。2.开发工程师做出来的项目， bug 不但多，而且经常改不好。 常常是改了一个Bug ，出现另一个 Bug ，好不容易把一个Bug 改好了， 过了没多久又重现了。 原本好好的功能，反而会因为改Bug 导致出现的问题更多。3.做出来的东西完全不是产品经理想要的样子，沟通完之后才发现开发工程师的理解和产品经理的理解是完全不一样的。4.项目延期不是最坏的结果，最坏的结果是还从不知道项目倒底会延期多少，根本没办法去衡量工作量，团队的成员都在加班加点，然而完全看不出来问题出在什么地方。5.开发文档，产品文档，接口文档，测试报告和真实的代码从没有完美契合过。产品经理设计出来的原型和UI 设计出来的页面和程序员开发出来的代码完全是一种不同的体系，三位一体的故事从没有真正发生过。代码的实现和接口文档根本不一致，最后索性干脆不看接口文档，完全口头交流。出错的时候各种撕逼扯皮，谁也分不清倒底谁错了。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 8 页 - - - - - - - - - 6.Team 的战斗力和凝聚力不强，经常是对着干，对分配的任务总是各种报怨，出现问题之后第一反应是这个不关我的事，不是我的问题， 是后端前端设计QAPM 的问题。如果你遇到了这种情况，或者说你不甘于这种现状，那么恭喜你，你可以真的需要敏捷开发流程了。第二，敏捷开发包括了哪些内容敏捷开发总的流程如下：1.需求规划和分期2. 需求评审 3. 需求讲解 4. 方案评审5. 每日晨会 6. 性能测试 7. CodeReview8. Demo9. 测试阶段 10.线上 Bug 修改流程表跟我说哪些东西不应该包含在敏捷开发流程里，如果你不喜欢，跟你的观念有冲突，你可以把敏捷开发这四个字换成任意四个字。总之，如果要解决这些问题，这是我目前看到的最佳实践，每一个节点都非纸上谈兵，而是经过无数个尝试和失败总结出来的。如果你是一个IT 公司的管理者， 如果你不知道该怎么去管理自己的团队，我强烈安列你按着我说的这种标准化方式去做，放心，出了问题我保证不会负一点责任。确切的说，我说的敏捷开发流程，并不仅仅是开发团队的事情，它背后隐藏着更多的理念。我可能整理的不够清楚，毕竟这是第一版。1.产品和开发必须是一个Team ，大家只是分工不同，角色不同，并不是两个对立的团队。如果你的公司是把产品和开发分成两个部门，那么恭喜你，产品和开发之间的纠纷一定无限多。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 8 页 - - - - - - - - - 在所有我带的Team 中，自始至终强调的理念就是：出了问题，别跟我说这是产品设计出来，这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任，这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题，那么也只是为了避免下次出现同样的情况，用户只会知道是一个公司出了一款垃圾产品，没有人关心到底是产品还是开发的锅。这是做敏捷开发的大前提。或者不仅仅是产品和开发，责任共担，One Team这个理念是贯穿始终的。这并不是说，大锅饭，而是说，面对不好的结果，所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景，以避免后续会出现同样的情况。产品和开发必须是一个Team 还体现在需求分期上。这一点在讲到需求分期的流程的时候，会提高的。实际上，需求分期如果没做好，敏捷开发只能流于形式。需求分期怎么做，这是MVP 的事情，另一个话题。简单来说，每一期都要有一个提前的预测，这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。2.职责明确，每个人要负责的事情必须清晰无误，谁该做哪些事情，必须要提前讲清楚。开发团队的推荐角色应该是这样的。PM 1 个 UI 1 个 CSS/js 12 个 Java 24个 Android 12 个 iOS 12 个 QA 1 个这是一个相对平衡的模板，这样的一个810 人的小 Team ，是可以复制的。敏捷开发支持多个Team 并行开发。理论上来讲。 这种方式，可以支持五到六个小Team同时启动。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 8 页 - - - - - - - - - 在讲到最后多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 更合适。然而在真实实施的过程中，因为很少有名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 8 页 - - - - - - - - - UI 具备原型的设计能力，所以实施起来会有一些难度。这个不算特别重要，慢慢培养。PM 不需要为开发进度负任何的责任，这很重要，不要把 PM 当成项目管理来使用，如果你让 PM 去做了项目管理，恭喜你，Game 近乎 Over ，产品经理没有时间再去思考如何做功能了。PM 的职责就是把功能设计好，优先级排好，给开发团队讲清楚需求，结合Story优先级和功能实现的大概时间点去做排期。开发工期交给开发团队去做，Bug 会和 QA ，开发团队一起来定。记着要在开发团队开发项目的时间里，去做好下一个产品迭代的设计。小组 Leader ：需求评审会的成员应该包括PM 组的 Leader ，前端组的 leader, 后端组的 leader, 测试组的 Leader ，或者是其他公司的中层骨干。这应该是一个公司所有应该为这个项目负责的人的评审会，在评审会上的结论，就应该被坚定的执行下去了。不参与评审会的人，不应该再对需求指手画脚。需求评审会的目标就是确定原封不动的需求，所以在这里要格外的注意，PM 拿出来的方案设计，一定是完整的，而且必须评细节。如果说，一个公司的中层骨干经过需求评审会议，仍然需求乱成一比，那就没什么可说的了，继续努力提升自己的水准，或者是补充真正的中层。而 PM 的目标就是吸引需求评审会的意见，尽量让自己的需求和设计通过评审。各个小组的 Leader 还应该承担的角色就是各个组的方案评审。这是中层骨干必须要起到的作用。小组的 Leader 还应该负责项目中风险的调控，考虑是增加人手，安排加班，项目延期，还是调整功能。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 8 页 - - - - - - - - - 与些同时，应该去审核最后的性能报告，看看是否达到系统的期望值，遇到了疑难问题如何解决。开发组成员： 项目进入真正的开发阶段后，开发组的成员就应该是主动去控制项目的进度，和风险，以及主动去测试项目中存在的问题，在这个阶段，除了一些需求不明，或者是发生变动的情况出现，不应该去打扰产品经理。不要让产品经理做开发团队的保姆。开发组的成员的目标就是做好项目的进度控制，有风险就及时反馈给Leader ，确保自己理解的需求是明确无误的，确保自己的测试是完整和严谨的，确认自己写出来的代码是可以维护的。一定要理解清楚，一旦PM 通过 Story 讲解，将需求交付给开发组成员，那么开发组成员就应该主动而独立的为这件事情负责。当项目完工以后，开发组成员应该交叉去做CodeReview，并且出性能测试报告，以及组织 Demo 。测试组成员 ：测试级成员的职责不是做功能性的测试，也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成，除了一些特别麻烦的，需要各种极端条件才能复现的，正常的操作过程中出现的问题，都应该是有开发组承担。性能测试同样是开发组人员自行完成，各小组Leader 只需要知道一件事情，测试报告是否能够通过。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 8 页 - - - - - - - - - 所以测试组的主要做的就是准确的记录，以及 bug 的统计。 也不应该去天催促开发组的成员去改Bug 。只需要去反馈给开发组的Leader 就好了。 整个 CTO 或者是技术总监应该以此为标准去衡量每个小组Leader 的绩效。回归测试是需要做的，但是也不是完全必须要做。如果能够积累足够多的自动化测试用例，就去正常使用它，如果不能，就尽可能少的减少回归测试。这需要跟开发人员沟通的比较清楚，他们往往更清楚，什么地方容易出问题。接受线上的反馈并且记录也应该是QA 的职责，如果Team 足够细，可能会有运营或者是客服统一对外收集，然后交给QA ，QA 再负责录入 Bug 系统中。基本的敏捷开发流程中的角色的职责大致就是这样的了。这不是一件容易的事情，其中的很多小细节，都照顾到了每个角色的职责和义务。理论上来说，如果有一张图的话，可以更清楚的画出来不同角色的功能。这种职责的划分，和传统的职责会有一些不同，反正，在我带过的Team 中，这是最高效的，也是最能发挥出团队的能力的方式。你可以信，也可以不信，这中间的每一个细小的调整，都是经过无数个日日夜夜的验证而得来的，我还未曾看到过比这种职责划分方式更高效，更合理的做法，虽然我接触的Team 也不够多，爱信不信 3.每个人必须学会主动去为自己的事情负责当有了第二条，你很快就能发现团队中，谁是能够尽守职责，更主动的人。第3 条很难做到，特别在很多公司，并不注重对于团队凝聚力的培养，也不会注重和他们之间的交流，不知道他们想要什么。所以这也是我一再强调的，敏捷开发并不仅仅是一个开发流程，更是一种管理的方式，他牵涉到绩效考核，公司福利，上下班制度等等你看不到的东西。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 8 页 - - - - - - - - - 如果说你的团队成员并不能做到为自己的事情负责，那么你需要的就是，要么就是去更换团队，要么就是想办法去激励团队。这是另一个话题了，我心情好的话，可能会在这里提到， 如果心情不好， 可能会在下一个文章里， 也可能根本就不会写了。这件事情其实也不算难，第一，明确这种职责的分工是合理的，第二，Leader 都需要了解自己的团队的状况。第三，不断的去强化和培养这种做事的习惯。就够了。团队是需要打磨和改造的。这三点是敏捷开发实施的前提，而不是说，有了这三点，敏捷开发就一点能做好了。在具体的实施上，还有无数的细节是需要去整理和落地的。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 8 页 - - - - - - - - -