要解耦，尽量避免一个人在多个项目团队。
信息透明，尽量让团队成员能基于已有的信息自己做出决策，而不是询问上级。
建立跨领域团队，并对团队进行敏捷开发知识的宣导和指导。
引入持续集成。
限制在制品，避免一个人同时开展多项工作，原则上不能超过2个未完成的任务。
等等……
我们不再纠结于是否一定执行了敏捷里面规定的活动，又或者说我们现在的项目过程，也谈不上是完整意义的敏捷开发，我们更注重什么样的招式能有效解决我们当下的问题。
3. 我们的绊脚石
开篇讲到了组织架构导致我们并不能完整的引入敏捷开发的各项机制——做过敏捷转型的人应该都遇到了这样的问题。
以下是我们在敏捷转型中遇到的一些实际问题，当你遇到这些问题时，不要惊讶，对于一个传统的成熟组织来说很难改变，尤其在没有上层领导积极推动的情况下：
3.1 没有产品经理，敏捷团队只关注开发与发布，不管开始，不管结果。
在我们公司的组织架构采用了弱矩阵形式，敏捷团队更多的起到协作开发前端需求的作用，他们不需要对产品直接负责，也不会关注产品在市场上的反馈。
3.2 测试与开发职责界限清晰。
在理想的敏捷中，在开发过程中就开始做测试，而我们还是需要开发完成后再进入测试，走上了“小瀑布模式”之路。
3.3 无法进行短周期迭代，放弃迭代。
由于走上了“小瀑布模式”之路，根本没办法做到较短周期的迭代，对于一个月一个版本来说，超过2周的迭代周期已经失去了实际的意义。
3.4 做好的功能都会发出去，基本没有功能灰度验证，功能越堆越多，维护越来越难。
需求人员都会认为自己想法是完美的，能有效提高产品的价值，他们更关注自己提的需求，而不是这个产品。
3.5 没有项目经理，只有项目负责人，项目负责人不专注，不专业。
由于公司项目是弱矩阵形式，项目更多的是协作作用，项目负责人更多的是起到拉通团队协作的作用，由于项目负责人往往身兼多职，并不能有效的持续投入精力优化项目过程。
等等……
二、成功的每一小步
固然，我们在转型中问题众多，还有很大的优化空间，但是和以前比起来我们还是取得了不小的进步，以下招式在实际项目开展过程中具有明显的实际意义，并不受传统组织架构排挤：
2.1. 跨职能团队
对于传统企业来说，一般根据职能属性进行部门划分，各部门互相协作完成项目。
然而，跨部门的协作成本明显过高，当产品需要频繁的跨部门协作时，这样的模式明显无法胜任。
而在这时，公司必然也会暴露出由于这样的缺陷，导致的开发效率低下的问题。
此时，以事业部或核心部门主导，建立虚拟的跨职能团队，也就顺理成章，一气呵成。
跨职能团队能有效解决产品在开发时，频繁协作沟通的问题。
在这样的团队里，沟通由实际的开发、测试、需求人员直接当面沟通，频率更高，信息失真也比较少，也避免了部门之间扯皮的问题。
2.2. 每日晨会
晨会，是跨职能团队进行沟通的标准活动，每天在固定的地点、固定时间花10分钟左右举行，是一种很有效的团队同步机制。
然而晨会看上去简单，但是要开好，却没有那么容易。敏捷里面的推荐晨会内容主要包括以下三方面。
昨天做了什么？
今天要做什么？
有什么问题？
对于敏捷小白的我们，刚开始照本宣科的组织晨会，但是采用标准的模式，我们却始终都开不好这样的晨会。
下面会详细的说
