入职ringcentral两周左右，团队的模式与之前在百度和美团时有蛮大的不同。整个团队按照比较纯粹的scrum的方式在跑。少文档，重交流。组织结构上也将测试和研发放到一块，也是为了减少沟通成本以提升交付速度。但是有时会想，团队目前的方式会不会有【为了敏捷而敏捷】之嫌。该如何衡量一套敏捷方案行之有效，或者用更大的视角来看，如何衡量一个方案的引入对团队带来的收益是值得思考的。

不仅仅是工作流程上，在是技术架构上也是一样，所谓的架构，要做的并不是技术上最优秀的方案，而是在现实情况中做了各种适配甚至是妥协之后的最合适的方案。在现实情况中，你可能受限于时间的压力，上下游协作人员的压力，团队自身水平的压力等，在各种限制因素中寻求最合适的方案才是架构需要做的事。引入一套新的技术方案或者自建一种技术方案，在考虑完成业务需求的同时，也需要考虑维护的成本和新人融入和接受的成本，毕竟从软件的生命周期来看，维护的时间占了整个生命周期的极大一段。

在研发一款产品的过程中，如果产品方向正确，那么如何提升交付速度和交付质量是一个工程师团队要考虑的事，基于此来进行团队技术方向和工作流程甚至是组织架构的选型、调整和调研。而所要做的事也需要和团队自身的情况做相互的妥协，这应该是更大层面上的一种架构。不论是传统的瀑布模型还是现在流行的敏捷模型，其目的都是为了交付一个产品，只是其方式不同，但最终都是殊途同归。所以没有必要为了瀑布而瀑布，也不要为了敏捷而敏捷，最终都是需要找到一种能【快速交付高质量产品】的方案。软件工程里没有银弹，复杂度摆在那，不管用何种方案都绕不开，需要做的是减少解决这些问题是的资源浪费。譬如scrum团队中推崇的【少文档，重交流】，目的是为了各方能对同个需求理解一致，减少后期返工，但是如果【多文档，少交流】能否做到呢？如果有了文档，在一个软件的生命周期里，它的作用有多大呢？所以，根据现实情况做合适的权衡才是做架构的正确方式。