敏捷开发文库-多团队敏捷开发的组织架构和协作模式(续).pdfVIP

刊主：袁 斌， Andy Yuan ，资深敏捷开发咨询顾问，来自－迅思威尔（ ） 迅思威尔（AgileDo）－ 企业级敏捷开发转型解决方案提供商，帮助客户“以正确的方式构建正确的产品” 多团队敏捷开发的组织架构和协作模式（续） 在微刊/con/3521290120422910 中，我介绍了在实践中多团队敏捷开发的 组织架构和协作模式。这里在补充介绍一下“技术专家”团队的一些特别做法。 这里的技术专家团队可以由内部工程师组成，但一些场合也可以考量外部的技术资源。 我们在实践中有这样的场景：系统处在试运行中，性能的问题比较突出，但客户使用后的新 需求不断提出，所有人的精力都在新需求的实现上，对性能的优化没有足够的热情，或者说 已经“疲”了，所有的头脑风暴已经不能得到有价值的反馈。 为此，我们尝试了外包。我们的目标是在本次 Sprint 使客户感受到性能的提升，我们是这 么做的： 1. 找出客户最抱怨的三种页面（登录、统计、详单）以及网站的首页作为本次优化的需求 2. 在我们以前合作的承包商中，选择技术最优的（客观的说，并不是合作最好的） 3. 和承包商沟通出一个合作模式：承包商负责找出瓶颈，提出方案，测试并提交测试报告 以证明方案的可行性。和承包商的沟通和评定，是由架构师团队来完成，换句话说，架构师 团队是承包商的 PO，负责技术需求的提出和验收。 4. 根据承包商提出的方案，结合 Sprint 的周期，选择最后的方案。我们的原则是：改动量 最小，效果相对最明显。 刊主：袁 斌， Andy Yuan ，资深敏捷开发咨询顾问，来自－迅思威尔（ ） 迅思威尔（AgileDo）－ 企业级敏捷开发转型解决方案提供商，帮助客户“以正确的方式构建正确的产品” 5. 由 Team进行代码修改，由承包商进行技术支持。承包商需要有一个人和我们一起工作。 我们发现：其实承包商不一定可以提出特别让人“眼前一亮”的方案，但却找出了一些明显 的常识性的问题，这些问题很可能就是进度紧的时候仓促写的，但再没有人进行重构，更确 切的说是没有人有热情进行重构。