一个非常珍贵的机会，聚集了公司很多牛人，进行了一场发人深省的讨论。有一个话题我想拿出来和他家分享一下我的看法。
越来越不舒服的站会
站会是每天都在固定的时间、地点，大概持续15分钟左右（我们的小组都比较小，Scrum精神的一部分吧）的站着开的会。参加人员一般有所有的Developer， Project Manager（简称PM）等其他人。
站会的目的是为了让组内每个人的工作更加透明，如果能发现问题互相帮助更好。所以，站会每个人说话的内容有三要素：昨天干了啥，今天准备干啥，遇到什么困难。昨天干了啥，大家一般都会从这几点开始说：做了什么，怎么做的，进展怎么样。开始大家还都集中精力适应Scrum，所以也很少有什么不舒服的感觉。
但是随着Scrum的进展，我们发现了一些不好的地方。下面是三个小故事
- 如果我前天说有一个问题我在Debug，昨天说我在继续Debug，今天我该说点什么呢，仍然在Debug？其他人，尤其PM，会怀疑我的能力，到底在不在干活儿？
- 一般Debug的过程都很曲折，如果前天我说，可能是A原因；昨天说，A可能不是最终的原因，发现B可能是；今天说，上午我在解决B问题，发现C才是根本原因。结果大家“哄”笑了，背后的意思是“你确定不会发现D才是根本原因”？
- 我们的Project非常大，才会导致了上面那个问题，这里面还有一个其他问题。当我发现B问题的时候，可能我觉得它比较浅，较深层次的原因可能在别的组的一些组件里，我需要请教其他组的人，我需要掌握他们的逻辑，我需要看看他们的代码。这些至少都需要时间，那么也就是说如果直接Fix那个浅浅的问题，我不要学习其他的东西，时间很短，1天就好。但是，当我想深层次的Fix这个问题，因为那才是根本，这样我才能成长、扩大我对Project的理解、成长为专家。但是，当我说我需要5天时，我觉得脸上火辣辣的：别人可能都觉得我只需要1天就好了，说这么多天，别人会怎么想我呢？我需要向他们解释吗？
这种情况下，公司老人都有这样的担忧，那么对新人，尤其还不了解公司文化的情况下，其实是更加不好的：“因为我需要证明我是能干活的，只需要很少的时间”。但是，其实公司希望他慢点Fix，去找到根本原因，去学习，半年后成为专家，而不是两年后还是停留在问题的表面。
需要被完善的Agile/Scrum
在读了《agile software development》 和《程序员的思维修炼-开发认知潜能的九堂课》之后我意识到公司培训了我们Agile/Scrum，但是并没有培训我们如何去思考，如何去完善Agile/Scrum。
不仅没有如何完善，更有甚者，其实我们是在往一个大家对Agile/Scrum理解的交集上靠拢着。就像这样：
而我们期待的是：
我思故我在
Agile/Scrum不是一套写死了的，你这么干就Agile/Scrum了，它也不是一种流程，规范；它更加不是老板怎么说，我们就怎么办！它是一种精神（从这一刻起，我觉得，那些书名叫敏捷方法的，都可以毙掉了）：全员，敏捷。
在《程序员的思维修炼》里提到，Andy的思考：不论遇到什么问题，感觉不对了，就思考，就要想办法改变，并且时时刻刻地在发生。
公司培训了我们Agile/Scrum，但是，没有告诉我们这不是一个固定的、完全适合我们的方法，我们需要每个人都参与其中，去适应，去按照我们具体情况地完善它。
在《agile software development》里提到了代码表现出来的几个问题，其中一个是Viscosity，粘性/粘度。从一个方面理解它就是说：当你想做一件正确的事情时，比如抽取一个函数出来，遇到了很大的难度，这个难度就是一种粘性。
之前，公司里的architect问我，是什么样的情况，导致一个Cpp文件能有10000多行的Code呢？当时，我就想起来了Viscosity，代码库工具的Viscosity。我们使用了公司内部开发的一种代码库管理工具，它有一个地方不太好用，在一个Project里添加文件，很麻烦，先是概念上的复杂，新人不容易掌握，因为用的不多，老人们用的时候，也需要回忆一下；再是，UI上操作完成了，不一定能百分之百的成功，需要去文件里确认一下，操作是成功的；最后是，命令行操作，很少人熟悉。
这是一种典型的Viscosity，Environment Viscosity。我们在站会这件事情上遇到的问题，也是Viscosity，一种不能让人踏实地、按照自己的节奏干活儿的Viscosity。
这里有几个问题：首先，大家没有识别出这种Viscosity，因为还没有要去识别它的意识；第二，即使识别了，也只能私下里讨论一下，不可能马上传播到其他组里，因为没有公司层面的支持，公司层面从文化，到流程，到条例等各个方面的支持。
为什么没有意识，一，已经说过了，公司没有培训；二，我们没有读到过这本书，太忙了，一天到晚的Debug，干不完的活儿，哪有时间；三，读到了，忘记了，为什么忘记了，没有《知道做到》。
回到，Andy的思考，以及全员，敏捷。这是要动员全民去思考，去完善这个流程。我们的一个领导曾经提过一句：你们应该多思考，去改变自己（方式，方法）。但是这一点从没有被High Light过，慢慢的，就成了一句不显眼的提醒了。但是，我觉得这句话比起，其他任何具体细节应该被强调，因为它更加重要。
现在的Scrum的流程，已经是Scrum大牛们实践了多年后的、几年前的版本。我们读到的书，开始实践Scrum都是人家几年前的“剩儿”了。现在我们Run的Scrum已经和大牛们的最新版本差了很多，如果我们不能思考，并去完善它，那么我们的Scrum会越来越与之脱节。搞不好，我们最后会得出一个结论，我们部署过Scrum，它并不适合我们。
我靠！我们从没有一天真正的Agile/Scrum过，好不好！！
鼓励大家去思考，深入的思考，从多个角度的思考，从人性，脑力，工程师文化等各个角度去思考，去创新。鼓励大家，有想法，就始终如一的坚持思考下去。哪怕最终发现是错了，也是收获，因为你知道哪里错了，为什么错了。
思考问题，提出问题，和别人去讨论，去实践，形成完整的理论体系，传达给其他需要的人，完成个人价值。
科学的方法-统计
如果做到这一点？《Code Complete》上有过关于命名的讨论，摆数据证明了变量还是要全名，全名比缩写更容易使用：自己写的时候，自己半年后读的时候，别人读的时候，新人读的时候，全部考虑进去。我想知道一件事情，那个数字是怎么来的。怎么来的过程，也就是在回答“如何做到这一点的”的过程。
我们日常工作中，也遇到过命名的问题，基本上是找一些参考资料，按照那个上面说的做。这里有一个问题，各种参考资料不统一怎么办？这就导致了，Code Review，大家各执己见。最后的结果莫不是：Case by Case；更甚者，因为谁也不接受谁的，然后就不了了之了。
我们都是在科学这面大旗下成长大的，但是关键时刻都忘记了属于科学的方法：统计。我们能不能这样，各执己见者，从发现问题就开始着手研究，各自的影响究竟是什么：全名好，怎么好，从人的阅读，到意思的表达等多个角度，举例说明！缩写好，好在哪里？能不能建立起来一个网页，让大家开始给出自己的反馈，从自己到其他人，从老人到新人，从刚写完Code到半年后回顾，每一种形式都作一个Survey，每年作一次，每当有任何新进展的时候作一次。不出三年，对我们自己非常合适的数据就出来了。50.000001%的人，认为全名好，Ok，那么我们就全名吧；或者更具体的Survey是，那种情况下全名好，哪种情况下，缩写好。这就是科学的Case by Case，不是耍流氓的那个。
有了科学的方法，一定也能出科学的结果，那么我们多年后就可以读自己写的书了，而不是多年后我们还是在读别人的书。在这个过程中，我们缺失了的是思考，方法论，和公司文化层次上的支持。
公司从文化层次上的支持太重要了，没有这个，都被压榨的去改Bug去了，哪里还有时间思考。我们有Innovation小组，也可以把这个“科研”内容放到这个小组里面啊。这不也就是官方的支持了吗？
都说软件开发过程多年来，始终没有突破一个怪圈，就是无法大幅度提高生产效率。我深深的觉得这是和人息息相关的。我们的意识，我们还没有意识到应该如何不扯皮就能成长，还能用数据说服所有人。有人又说了，如果我们得出的数据与《Code Complete》不一致怎么办？第一为什么要一致；第二，深挖“不一样”的来源。总之，我们要科学的成长，要积累。
软件开发和个人息息相关，同一本书，每个人的理解不一样，有的人理解的深，有的理解的浅，有人理解的东，有人理解的西。总之，大家不能很好的统一。这样，那些书上血泪史就不能被很少的传承。不读书的就不说了，搞不好读过书的，因为没有传承意识，一切都从解放前开始，重新摸索一遍，一直到天黑请闭眼，然后，就没有然后了。后来者，依然要从解放前重新开始。
Agile/Scrum那些牛人，努力了十多年，积累了一定的经验，又有足够好的“天时，地利，人和”，才有了今天的Visibility（但是，依然不够啊，否则，为什么大家没有像喜欢电视剧男/女主角一样喜欢他们呢？）。如果在公司文化层次上有这样的支持，我们就可以很快积累同样的经验，并比他们做的好，一方面找到了更好的软件开发的路，二方面，引领了潮流，吸引更多牛人的加入。
总结
我们学会了基本的Agile/Scrum的规则，就认为这就使一切。这个感觉有点儿和“我们什么都准备好了，就差几个Developer来实现了”的商业宣言一样，其实我们距离Agile/Scrum还很远，我们还需要思考，需要科学的方法，需要按照我们的方式去完善它。
后记
听说公司最近有些制定了一些新的规则，隐约觉得有些不妥。本着这次讨论的，哪个词汇会让人感觉更加舒服些，比如：Review->audit->discovery，这样的精神。与其 Check（performance）不如help（to setup a plan to increase the settle down speed）。因为Check带来的压力只能阻碍认知。
再说个规则的故事吧：
多年前，美国宪法制定者们，美国的国父们，曾经就总统选举问题进行过很多轮的争论。要普选还是间接选举，是其中问题之一。解决这个问题就是一句话，大意是：我们要普选，虽这样麻烦些，但是更加容易实现公平、公正。因为间接选举的话，普通老百姓可能会被一些政客忽悠，从而失去选举的意义。最重要的是，这套规则，简单明了。即使多年后，任何参与人，都可以按照其本意来操作，不会被歪解，扭曲。
我们每个制定的规则，是不是考虑了，今天你明白也知道如何操作。但是，明天新人来了，他能明白吗，知道如何具体操作吗？或者，一个瞎眼老百姓，你告诉他，他就能正确操作吗？如果不能，请慎重！或者去Help?
请思考！