敏捷开发一千零一问系列之一：序言及解决问题的心法（无我）

这是敏捷开发一千零一问系列的第一篇。（之一，之二，之三，问题总目录）

也是般若敏捷系列第十篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九，之十，之十一，之十二）

做敏捷开发时间长了，就感觉很多事情都理所当然，越发觉得“问题很可贵”，最近做培训的时候收集了一些问题，很多现场来不及解答，逐一发表在这里。

如何解决一个问题

知识多了自然可以解决问题，经历多了自然也可以积累经验，但是在一个只出现10年的领域，还有一堆只工作了10多年的年轻人中间，必然有一天会遇到从来没有人解决过的问题，这时候怎么办呢？
掌握解决问题的心法是核心。
对这个系列而言，就是要掌握用敏捷开发的方法解决问题的心法。掌握了心法就能解决所有问题，这比知道一千零一个问题的答案更加重要，因此会先用三篇来综述一下解决问题的心法，可以总结为无我、无住、共振三个词汇。
为什么不写成更通俗易懂的现代汉语？因为找不到贴切的词汇，更没有简短、容易记忆的语句，罗哩罗嗦写了一大段，保证大家关闭IE就忘光了。
估计在看完十个二十个问题和答案后，再回来看这篇序言，大家会和我一样认同这三个词汇是最佳答案。

无我

包括两个部分，无我无人 和 无现在无未来的我。

无我无人

这里的”人“是他人的意思。
原来的敏捷宣言中包括了无我无人的成分，“个体与交互胜过过程与工具”及“客户协作胜过合同谈判”说的就是这个部分。
为什么需要过程、工具、合同、谈判？因为有部门分割，有利益差异。
在传统开发过程中无形中产生了很多对立团体，比如客户负责自己的价值而我们负责编写功能（注意功能不等于价值，否则用户故事语法就不需要前面的”作为一个……“和后面的”以便……“了），程序负责编码而测试负责质量，领导负责计划而员工负责执行，产品经理负责销售市场及竞争力而项目组负责……甚至乃至在一个团队中，都有我的任务、你的任务之分，一旦这些成为事实，那就太需要过程、工具、合同、谈判了。
所以要用敏捷开发的方法解决问题，首先应该先融合不同团体的利益，比如拥抱客户价值，拥抱变化，团队工作，代码所有制，自动化测试与持续集成（开发人员参与编码的测试）、代码审查……

无现在的我和未来的我

就是千万不要以眼前利益为驱动，而要把现在和未来放在一起考虑。
这个没有出现在敏捷宣言里，因而常常被伪敏捷的人拿来作为不写文档的接口，又被反敏捷的人拿来作为攻击敏捷的漏洞。
”到底要不要写文档？“答案当然是”看着办“。但怎么看着办呢？如果一个人在”看“的时候心里想：”其实我自己开发者写代码不需把想法写出来的，现在劳心费神写文档的人是我，未来不知道便宜了哪个后来人呢“，这个时候看着办就是危险的。
但如果他在想：”这个部分代码里边表达地很不清楚，而这个产品20年后还会有人用（比如汽车电子），所以应该写成文档；那个地方呢，一看代码就很明确了，不写了。“这个时候看着办就是安全的。
差别在哪里？第一个人的想法里边有”我“有”他人“，干扰了看着办的出发点。
人有天生的惰性，习惯了”Max the undo“，就是把事情拖到最后再做，如果一旦误解了敏捷开发中的“不做不行的时候才做”，就很容易找到借口把很多应该做的事情推掉。
还有很多事情有现在和未来的差别，比如短期功能的生产率与长期架构的稳定性，短期“强分工的专家团队”的高效率与今后人员离职的困扰，现在马马虎虎提交代码与日后测试团队加班测试……这里边潜意识里都有一个概念：“现在先凑合过吧，到时候我还在不在还是个问题呢”。这都是因为区分现在的我和未来的我的原因。
无我对于运用敏捷开发方法解决问题至关重要。
如果解决问题的时候，总是想“我们应该干什么，他们应该干什么”“因为他们少干了什么，所以我们不能干什么”“这件事情没做好，是因为他……”，那么像开发人员要关心客户价值、两个人要结对编程、一个团队要每天立会这些实践，就永远用不好。