所谓敏捷的哲学，无非是个噱头，其实是因为我无力为mindset在中文世界里找到一个妥帖的词表达。心态或者思维模式，在我看来都有弱化本意的倾向。索性用哲学这样大而不当的词语替代了。
在那篇《ThoughtWorks的敏捷开发》中，肖然提纲挈领浓缩了我们认为理所当然的工作方式，并且以此为引领，和我合编了《深入核心的敏捷开发》一书，作为操作细节的补充。书里凝聚了同事们这些年来，在敏捷的领域内的实践经验，也有很多可以快速学习到手的工具和方法，
但在我个人今天看来，总是觉得缺少了点什么。
Doing Agile和Being Agile的对比由来已久。在《Accelerate》一书中，它写到：
Organizations that ‘do’ agile merely adopt agile practices. They do standups and retrospectives and paper walls with Post-its. While this can create small changes, the greatest gains in satisfaction and innovation require a mindset shift. Companies need to be willing to move away from stringent planning and control toward iterative, incremental approaches built around customers and employees. Their central belief was that software development needed to be more adaptive and responsive to change – or ‘agile’ as the group decided to call it.
而组织的mindset shift，自然需要组织中的每个个体去接受和承担，这并不难理解。但它们到底意味着什么呢？
我尝试去总结和回顾那些这几年在这里习得一些思维意识的变化。很明显它们既有来自于业界翘楚在演讲和文字中，也有来自我身边所尊敬的同事的行事方式，还有一些则来自于项目中的失败教训。在观察自己的思维模式的变化，思考它的僵硬程度以及成因，都是有趣的事情。很奇怪的是，这些思维模式已经逐渐影响到我个人的一些在生活中的决定，甚至是影响到对孩子的教育上。我想我并不是个例。
原谅我并不能用一个优雅的框架或者模式，将它们囊括其中。随着阅读和思考，它们以碎片的形态进入我的大脑。直到初具规模，我才能用不足以让我信服的方式将它们归类：关于心态上的转变，关于新的认知，关于纠正偏见，以及关于信息沟通。
下面就是这些碎片们。
迎难而上的改进，是向不确定性讨要回掌控感的本能。但一如字面意义，持续改进，难的不是改进，而是在持续。重要的是持续优化的过程，最终交付只是作为副产品之一产生，顺水推舟而已。持续二字，既是对改进这件事一如既往的执着态度，也是对不确定性和不安全感出自内心的认可。适时后退一步，并不意味着低头，在后退间反而得到片刻静默，以及观察的机遇。
我们喜欢度量，只是因为我们害怕不确定性罢了。拟定的目标，但未成为现实之前，是摸不着的空中楼阁。我们如何确保自己以及众人，做出了正确的努力。度量，是在到达那一天之前，本能之下会想到的办法。遥望远方，时不时回头看下身后的脚印，再一步一步踱往前去。只是到了一些特定的局面之中，因为我们内在的人性惯性，企业文化的重力，以及微妙的的官僚和政治，原本有着良好意愿的度量初心，就会很容易被极度简单物化成了只需遵从并实现的指标，并挤压在复杂性下做全局优先思考的空间。
如果说敏捷之于个人需要承载并弘扬的部分，不过追求极致吧。作为敏捷方法族中众多轻量级方法，为什么XP（极限编程）会少有人问津，而Scrum会显得手到擒来（事实上也只是照虎画猫）？我想我们多数人恐怕并不太情愿做疲惫的推向极致的思考。更多采用一个“差不多就行”的态度，硬件的摩尔定律足以消弭掉算法和流程上的低效。
即便至今，了解到所有正在发生的事情，仍然相当比例还是只属于领导角色的专享特权。采用信息辐射器的团队，用高透明度和自信打破了这种特权。像是撕掉了团队遮遮掩掩的最后一块遮羞布，自此一览无余。这需要莫大的勇气。毕竟害怕被指责以及害怕承认无知和失败，都是人之本性。
比起没有意识到问题的存在，意识到问题但选择闭口不言，这才是羞耻。承认自己力所不逮，普通人自然会犯普通人避不开的错误。这会是个好的开始。如果勇气是一个人需要驻扎内心的东西，那开放自己的眼睛和心态，则是一个人坚实的开拔。从这里开始，说出别人不敢言出的事实，承认作为团队整体犯了错误，然后我们一起想办法，这是更进一步。
就软件构建而言，每个人在拥有多个项目和团队经验之后，一些可以称之为模式和规律的东西呼之欲出。其中如果还有一些可以称之为不变的东西，那就是：变化的市场，变化的需求，变化的利益相关者，变化的团队，变化的技术栈。每一个变化的因素下，是更多变化的因子，动态碰撞和组合。而软件构建的动态是众因素此刻的快照，软件的复杂性也由此而生。必须承认，试图去掌控所有变化的努力必然是白费的。但放弃对复杂动态的观察和思考，又会是懒惰的表现，会时不时陷入末路穷途的境地。敏捷实践的整体性似乎加剧了这个局面，人们不自觉地从入门到放弃。
软件开发是一项艰辛的活动，需要我们面对面的信任。敏捷开发不是件易容易的事情。一些新鲜的工程和管理实践方式，当然让人耳目一新。但其他一些表面之下的心态模式，例如保持开放和信任，却在努力跟人的隐藏惰性做持久的抗争。而无疑这些从思维模式到行为准则的变化，都是作为根基对具体实践方式的拱卫。
纪律，是个绝少在敏捷的世界被表达的词汇。在引入敏捷之初，无论从哪个角度，它都不是给参与者带来的诸多震撼人心的印象之一。而有趣的是，现实恰恰相反，敏捷因为轻量实践的特质，以及开头更注重认知转变，人们得以从繁重的流程和文档桎梏中喘息甚至解脱。这股反弹势头，让人们误以为敏捷的等价词就是快速，随意，或者散漫。所以随着时间漂移，我们能见到太多浮于表面但仍然被冠之以敏捷的团队和软件行为，就不足为奇了。
越是觉着痛苦的事情，越是要尽早开始做，并且频繁地做。这是我在最早接触到敏捷的时候，经常被告知的一句话。看他们身体力行地去做，自己也学着来做。做的次数多了，会有一些心态的变化。没成想，这是一件蛮过瘾的事情。很不可思议的变化。
除了估算作为必须接受计划具有可变性的切入点，我们还看到其他一些敏捷语境的词汇，启发对这种理解的可能性。当然首当其冲的，是敏捷宣言中的拥抱变化，这不是一句空洞的口号，必然会以某些细致入微的具体体现在日常中。比如必然会变动的需求，持续不断进出的人员，自然也会引发伴随计划的调整，我们都不得不拥抱它们，别无他法。
价值交付，必然需要体现在具体的行动上。一如敏捷中各类实践作为整体的完整性，价值交付的思维也需要表现在软件构建的过程中。尽早上线，频繁上线，哪怕开始只是简陋的功能也直接交由用户使用，是最符合直觉的，因为和生产环境以及最终用户有关。而更多需要表现在日常那些细致入微的活动中。故事卡的Kickoff，开发过程中频繁的本地构建和环境部署，Desk Check，迭代Showcase和Sign off，都有尽早呈现的意味在里面游弋。
自动化必然和敏捷的本质有脱不开的干些。敏捷的增量、迭代和自适应特性，隐含了对于大量回归、验证、修正的循环的需求，以及对于人们在沟通方面的不确信。必然需要强有力的自动化手段，去简化反复确认所带来的繁复的努力。这方面显然人力显然不能胜任，我们会厌倦，愤怒以及偷懒。
现在我们知道了，缩短周期是需要采取的明确无误的方法，它服务于尽早呈现可以交付的产物，但也是持续改进和推向极致的手段之一。你看，敏捷的思维模式和具体实践，本身就是一个彼此勾连的系统，之间有千丝万缕的联系。抛开任何一方，或者只是谈论一个方面，都显得片面有失偏颇。
敏捷给了我得以观察软件构建整个周期的全局视角。就此知道自己手里的任务，和前置的客户、需求、设计有千丝万缕的联系，也决定着交付的质量，以及上线后的反馈。孤立无援的螺丝钉，也可以身处轰鸣的机器中的位置。那是一个更完备的时刻处于生动运行中的图景。有了全局视角，信任感和责任心也油然而生，填满胸间。非比寻常的体验，仿佛在这个行当就此迈入了一个新的境界。
