比如说吧，产品和平台之间依赖好严重啊，产品还经常要修改平台的代码；特性组和支撑组之间耦合好紧密啊，支撑组的代码都得到特性组去验证和提交。敏捷怎么解决这些问题啊？还有啊，开发人员总是几个故事一起做，做出来的故事测试人员发现没法测。敏捷怎么解决这些问题啊？

还有啊，架构思想都没有传达到开发人员啊，都做乱掉了；持续集成工具的专家他不属于开发团队啊，出问题找他支持好麻烦啊；测试工具的专家…嗯，最近的一个离我们大概有一千公里吧。敏捷怎么解决这些问题啊？

这些不是方法问题，是设计问题。设计很简单。单一职责，DRY，OCP，依赖倒置，接口隔离，就这么些东西而已。但简单不等于容易。写代码的时候不会设计，划分模块的时候同样不会，划分产品的时候同样不会，管理组织机构的时候还是同样不会。一个软件组织不让员工学会写代码，其结果就是设计问题出现在所有地方。

还有个下半句：管理问题多于能力问题。

我们很想提高工程人员的技术能力啊，应该怎么让他们学习啊？我们这些实践影响的人太少啊，怎么快速复制到成千上万人啊？──想要事情做下去，不走样，就得去关注所有的细节。拍一个任务下去，你周五之前给我完成，我只看结果。完不成怎么样？时间过去了，能力还是没提升，问题还是没解决。这就是所谓粗放式管理。一层一层都说，行，我支持，大家去学习吧──你不去手把手的教着他，他除了变成蘑菇还能变成什么？

管理细节也很简单。代码的坏味道有没有重构？每个函数有没有测试？每次提交的注释是不是符合规范？但简单不等于容易。写代码的时候不会管理细节，做管理也同样不会。一个软件组织不让员工写好代码，其结果就是管理问题出现在所有地方。