执其两端，用其中-敏捷思考

“执其两端，用其中”，放假看书看见这个，感觉这话很符合我现阶段学习中对“敏捷”的理解和期望状态。

在我浅薄的理解中，“敏捷”更像是一种解决问题的方式，在很多东西（客户的具体目标、要解决的问题或问题解决能力）不能确定的情况下取得尽可能好的结果的问题解决方式。那解决问题的方式，在很大程度上就没有优劣，只有适不适合。

观看“敏捷”的种种，自认比较重要的两点：1更快的交付价值2灵活地响应变化

一个面向结果，一个响应过程。为的就是更好的解决问题。

就现阶段的学习、实践而言，我还是对敏捷的某些方面保持“怀疑”的态度，我相信这种“怀疑”或多或少也是契合“敏捷”要求的。

毕竟，借鉴一种新的模式的时候，“取其精华去其糟粕”，可能是比较好的解决方式。批判性的吸收精华的部分，不照搬照抄，我想，这不仅是初高中政治题给的答案，也是我们面对很多情况应该考虑的部分。

敏捷是一个很好地开发方式，从提出到风靡，它有着远不同于传统开发的强大魅力。但，敏捷的好也有着非常明显的台阶，不可否认，它对团队内所有的角色都有比较高的要求。

对PO/PM(BA)的要求是很高的，不管是前期的目标拉通，业务梳理，中间的业务沟通，还是实施阶段，需要安排至少两个迭代的任务和规划。这都是需要强大的能力和经验支持的。但，有经验的PO/PM很多时候可遇而不可求。不管是“传声筒式”的PO/PM，（客户提的所有要求都复述给团队，不会和客户谈判，不会引导客户的需求）还是业务掌控能力差的PO/PM,对整个交付而言都是很恐怖的存在。

对TEAM内的程序员的要求也很高，要是自组织的，能分享，能自我提升，还要在当所有的任务都拆散了之后，最终做出来一个完整的产品。这就意味着，技术人员要有很强的自驱力和整体意识，而且必须一开始就熟知整个产品规划。这就需要强调PO和团队，团队自身内部的直接沟通，如果在团队人数众多，以及人员变动的情况下，使团队达成一致就要花费许多时间。

对测试团队来讲，测试资源调配会更加的紧张。

对于UI来讲，可能是需要比较长时间的跟随一个项目。

所以，可以看出敏捷开发真的不仅仅是开发团队的事情，它需要很多方面的配合。甲方、PO、PM、UI、团队成员、测试，甚至连公司氛围都可能会影响的安全度检查。

针对需求固定的项目，瀑布式开发或许更容易把控进度。瀑布的开发模型具有更可靠的工作逻辑，一个工程或项目分为多个阶段，每一个阶段都投入相应的资源，来完成本阶段的工作。但，它的冗余和不灵活，是巨大的问题，要不也不会诞生“敏捷”，不是？

敏捷开发能缩短项目时间并提高质量吗？

好的敏捷，绝对是可以达到这个目标的。

用户的参与帮助团队把功能一次性完成并做正确，缩减了返工的时间；

不断的重构和测试发布能把问题发现在早期，整体质量显著提高；

过程目标导向，使团队高度集中于项目目标，提高了生产力；

不断的发布对团队是种正向激励，使团队保持持续的激情；

如果，我们拥有超棒的团队，有经验的PO/PM，睿智的Leader,良好的工作氛围，选择“敏捷”简直不用一丝犹疑。但，如果我们面对的是比较传统的项目团队，那通过什么样的方法能去满足“更快的交付价值、灵活地响应变化”的最终目的呢？

是否可以通过，添加定期的review/showcase，或使用先进的测试方法频繁的对软件进行测试。让传统的开发也是完成一个小模块，就对一个小模块进行测试的，然后和客户进行沟通，让进度更可控？ （可扩，待定）

在明确好业务需求后，是否可以通过让大家了解整个项目的规划，增强整体感？

其实，不管是什么样开发方法的，只是做工作的形式不一样了，实质其实并没有变化。我们要达成的最终目标-交付更好的软件，这不会改变。优势与缺陷，问题的关键不在于缺陷，而在于需要什么。

了解所有的不同，两端的信息，选择有利且有用的应用。这也是在响应“敏捷变化”吧。