04｜敏捷之道：大型Go项目的开发流程是怎样的？

思考题： 1、QA 测试应该是必须存在的一个环节，虽然开发者是应该做好测试，但是开发者也只能做好自己负责模块的测试，特别是在微服务环境下，每个开发者只关注自己负责的服务，对于系统整体的集成测试、性能测试，还是需要专门的 QA 来完成。另一方面，QA 其实也可以对开发者所交付的东西的质量进行监督，可以发现开发者疏忽的问题。 2、Scrum 框架的缺点：感觉 Scrum 框架更讲究迅速，看起来更适合小型、要求先快速交付一版的新项目，很多环节由文档转变为面对面沟通，对于长期迭代的项目来说，可能会导致一些重要材料的丢失，如果项目人员流动大，可能会对后续的长期维护埋坑。 不知道是否理解正确。 另外也有一个问题想请教老师：以上内容讲的是一个软件开发的生命周期，即便是在网上查找资料，也都是类似的内容，但是有 2 个疑惑： 1、对于长期维护和迭代的项目来说，可能一个项目做了好几年了，甚至运行了十年了，那么每一个功能需求都需要走全部流程吗，包括需求分析、设计方案的制定等等？ 2、对于一个运行很长时间的复杂项目来说，在设计方案的时候怎么去避免冗余、重复等问题，举个例子，假设项目中某个子模块存储了用户信息数据，现在来一个新需求也要这些数据，或者说，一个功能里写了一个工具包，另一个新需求也需要这方面的功能，开发者怎么在设计方案的时候就知道原本项目里已有这样的功能，从而直接使用就好，不用重复开发？当一个项目很大时，可能架构师也未必能对整个项目的方方面面都了如指掌，即便可以耐心地对方案进行细抠，但是这可能需要花费较多时间，又会影响需求完成的进展。 不知道对于上面的问题，老师有没有什么经验可以分享下，谢谢老师~

请问老师课程中的课件，是否可以提供下载

qa测试是必须的，虽然开发对项目很熟，但会思维固化，不容易发现逻辑之外的错误，当局者迷 旁观者清。以前公司试图让开发做交叉测试，去掉qa，但实际效果可以说几乎没有

1 QA测试很有必要，不能保证研发对每个功能都做了充分的测试，研发有时候对用户输入、边界条件考虑不妥，这些可能在QA阶段可以测试出来； 2 敏捷开发对需求固定，变更较小的项目必要性不大，会觉得“形式大于内容”；

讲的很好，借用郑晔老师的话，“拓宽上下文”

Scrum 最大的问题就是会议太多了，最后会流于形式。 要根据实际的情况进行改进

关于QA测试是否需要，个人觉得视情况而定，如果开发者有足够高的开发质量，完善的单元测试和自动化检查手段，不一定需要单独的QA测试。但是从个人的工作经验来看，大多数的公司并不满足该前提要求，所以QA测试的存在还是必要的

QA是需要的，开发人员更多着眼于细节，很容易着相，陷入只关注技术问题的陷阱。 个人认为敏捷和瀑布最大的区别就是需求是否确定，敏捷可以更快地产出产品，进行试错，调整自己的需求，不断适应。如果一个系统的需求是确定的，总有牛逼人可以将细节分析出来，按部就班地开发即可。 敏捷开发一个周期比较小，如果某个部门的某个环节出了问题，很可能会影响到其他部门的所有人。而瀑布的工作时间区间很大，某个方面出了问题可以自己尝试调整，而不至于阻塞太多人。

M