禅道中将近上千个bug，如果有心去看下解决的记录，大部分问题都看不出有价值的内容。问题是什么原因引起的？怎么解决的？都没有记录，唯一得到的信息是该问题已经解决了。开发人员认为问题解决的过程无需让人知道，那是我的事，其他人只要关注问题是否解决就可以了。当信息都在“我”这里时，什么东西是留给“我们”的呢？

“Courage”、“Respect”是我以前经常在强调的二个词，现在没人讲了。每个人都很忙，忙的疏忽了团队文化的建设。

测试团队这阵子一直忙于测试功能，连测试用例都省了。今天来了新的同事问起测试用例的事，提醒了我，不能再这样下去了，测试用例是测试过程不可或缺的一部分，不能因为人手不足，时间紧就忽略了。 刚好之前的债务也完成的差不多了，以后就按照用例优先的方式来执行，对测试流程也做了调整：

1. 测试从需求设计开始阶段就介入，当需求明确，原型完成后，开始着手测试用例的编写。
2. 如有可能，把优先级为1，2级的测试用例给开发，开发自测通过后，再提交给测试。
3. 实际测试过程中，需要对测试用例进行补充完善。
4. 测试完毕，提交测试报告。

今天的事也给我一点启发，平时工作中如何来对待“紧急的事”和“重要的事”，我们很容易优先处理“紧急的”而忽略了“重要的”，使得自己陷于“一直在救火”的怪圈中。 这其实也是一种“头痛医头，脚痛医脚”的思维，虽然短期会取得成效，但从长远来看，效果并不好。碰到“紧急的事”时，先不要急着去做，问问自己，它重要吗？ 如果也很重要，当然要立即去做，如果不那么重要，就要衡量下，是否还有更重要的事需要先做。

现在的博客平台很多，直接注册个账号就可以使用。如果你不想依赖他人平台，也可以自己购买服务器搭建。我的博客平台就是自己搭建的，但这两者都不符合“极简”原则。很多时候，我们只需要在网络上，有那么一块属于自己的空间，不用费很多心思去维护，也没有垃圾消息、广告的骚扰。除了自己的文字，什么都不需要有。这是我喜欢的风格。Keep It Stupid Simple。如果你也在寻找这样的一个平台，我推荐 Github.com。

我对Github.com最早的印象，它是一个开源代码托管平台，开发人员会比较热衷于使用。最近在别人的推荐下，我也玩起了 github.com。用了一段时间，完全颠覆了我之前的看法。上面除了代码，还有其他地方难以找到的工具，比如我用的翻墙软件。有很多的原创文章，有些还是涉及敏感话题的。前两天我搜一本电子书，用google搜了半天，基本都是要积分才能下载。转念一想，何不用github.com试试？一搜就搜到了，完全的免费。随着深入的使用，我相信还会有更多的惊喜等着我。 在github.com上注册了账号后，就自动获得了空间和域名，默认免费的空间好像是1G，对于博客来说也足够了。域名的格式很很好记：your_account.github.io。再配合jekyll，就可以搭建自己的博客了。五一假期在家捣腾了一下，接下来就分享下我的操作过程。 （注：因为github.com采用git作为版本管理工具，最好能了解下git的相关命令，但这不是必须的。）

1. 注册github.com账号，这一步就不具体介绍了。
2. 登录成功后，在左上角搜索框搜索“jekyll-now” 项目，进入该项目空间，如下图。点击左上角的Fork按钮，复制到自己的仓库（Repository），并把仓库名改成：xxx.github.io。这个名称就是博客的域名，浏览器输入your_account.github.io 就可直接访问。
3. 进入刚Fork过来的“xxx.github.io”的仓库，点击“Setting”，进入设置页面。
4. 启用“Github pages”功能
5. 到这里，你的个人博客已经搭建好了，直接输入域名就能看到效果。是不是很简洁？接下来再做一些个性化的配置。
6. 在仓库中找到_config.yml文件，点击打开，如下图。点击右边红框中的编辑图标，name是你的博客名称，description是博客的副标题，改成你自己的就行。然后点击“commit”按钮保存。
7. 你的文章需要放到_post文件夹下才会被自动识别并展示，。文件统一采用markdown格式，文件名的格式应遵循格式：“yyyy-m-d-file name.md”。_post文件夹下默认的文件，直接删除就可。
8. 上传博客文章，写好文章后，点击“upload files”，上传文件到_posts目录下。也可以点击“create new file”，在线创建一个md文件，然后把文章内容复制过来。文章头部必须加上以下内容：

---
layout: post
title: 你的文章标题
---

1. 再次打开首页，博客标题已经变成了你设置的标题，新上传的文章也显示在首页上了。因为是静态页面，需要清下浏览器缓存，才会看到效果。

2. 修改about页面，找到about.md这个文件，直接修改即可。

3. 默认的首页是没有分页功能的，影响使用。下面给首页加上分页功能。

a. 打开_config.yml文件，在末尾加上以下两行配置：

paginate: 5   # 每页显示5篇文章
paginate_path: “/page:num”

b. 参考我的repository的index.html文件，添加相应的分页功能。

至此，您的博客系统旧搭建好了，以后定期往_posts文件里上传文章就可。

视角（perspective）一词，源自拉丁语perspicere，意思是“看透”，定义为一种考虑或者评 估事物时所处的立场。它起源于14世纪，“视角”这个词首次被使用，是用于描述某个实体， 尤其是用于那种可以改变你观看方式的光学玻璃。因此，望远镜透视其实就是望远镜里的一 个弧面的镜片，所以我们可以运用类似的概念来想一想“视角”，可以把它看作是另一个透 镜，我们正是透过它来看事物的。

“改变你看事物的方式，你看到的事物就会跟着改变。

拍照的时候，喜欢回头看。

“不断地从不同角度看问 题，不要给正前方的东西下定论，必须时刻保持角度变换”

当我们在一个改变视角的巡游当中，或是任何主动地将观察到的事物进行分类时，必须 记住的是，要把所有的资源作为收集到的信息，尤其不要仅仅用眼睛去看。《发现》 （Discover ）杂志的主编科里·S·鲍威尔写道：“我们对于自然世界的欣赏不只是由视觉来支 持，还要靠听觉、嗅觉和触觉。在林中散步的时候，如果没有鸟鸣、枯叶的泥土气味和树枝 轻拂身上的感觉，一切都会大不一样。”

•我是否忽略了什么？ •我把什么当作是理所当然的？ •当别人进入我的世界时，有哪些事情是他可能不知道的？ ———————- 优先级 三叉提问法 ———————-

发现缺失之物

站会上，我问了测试团队一个问题，对于同一个功能，为什么每个人记录的bug都不同？大家的反应很快，都提到了视角这个词。每个人看事物的角度不一样，对功能的关注点也不同，所以会导致不同的问题被发现。 我们身处在同一个物理世界中，但没有人能一模一样的描述出来。 其根本原因就是“视角”，“关注点”的选择。 当我们觉得功能测试完成时，往往需要加上“在我的视角和关注点下”这个前提。 当你忘掉自己，把自己变成另一个人，会发现这个功能又有很多可完善的地方。

周鸿祎说过，自己在电脑前开始测试时，立马就会变成一个电脑白痴，然后拿着鼠标和键盘开始胡乱的敲击。 这种测试方式一般人可能会接受不了，但确是产品测试不可缺少的一部分，因为你永远不会想到最终用户会怎么操作。早期的电脑用户甚至把光驱当成茶托来使用，最后打电话给客服说我的茶托坏了，客服花了好长劲才弄明白用户原来说的是光驱。

“不断地从不同角度看问 题，不要给正前方的东西下定论，必须时刻保持角度变换”—- 这是二战期间的飞行员想出的一句话，这样做能够帮助我们找到更多的信息，更多的背景情况、看漏的情况、正确的路径，对方的真正意图，甚至是解救我们的那条路。

我们来看下世上最有名的艺术作品——米开朗基罗的《大卫》 人们经常用这样的形容词来描述他：强壮、英勇、放松、憔悴、沉思、和平，甚至是飘逸。16世纪的历史学家乔尔乔·瓦萨里这样写道：“再没有什么作品，能够看到如此放松的姿态，也没有任何作品有他那么优雅，双脚、双手和头部之间如此协调，他在艺术性的和谐、设计和卓越感上都无可超越。”艺术评论家写到他“传达了异常的自信”，是个“完美的男人”，甚至是“评判一个美男的标准”。

再换个角度来看下 塑像的平和、放松的印象就不见了。如果能从高处俯视他的话，就像米开朗基罗雕刻他时的角度，我们会看到一张充满紧张感的脸。他的鼻孔张开，眼睛睁大，眉头微锁。靠近看，他瞪眼的时候是专注的，可能也是忧虑的。实际上，一项全角度的电脑研究表明，这全然不是放松的状态，大卫身上每一块看得见的肌肉都是绷紧的。佛罗伦萨大学解剖学的教授评论说，这座雕塑的每一个细节“都由害怕、紧张和进攻的艺术效果构成”。

即使在相同的视角下，由于关注点的不同，大家的反应也是不一样的。我在之前的文章中也提过，大脑会主动对看到的信息进行过滤，也就是说大脑会根据一定的标准，对信息做优先级排序，只有高优先级的信息才会进入大脑。为什么我们经常会有“视而不见”的情况发生，就是这部分信息被大脑认为是低优先级而自动过滤了。

我给团队分享了下面这张图，让大家讲讲看到了什么。 有人先说房子着火了，然后旁边有个农场，有人在买南瓜。也有人先描述了地上有很多南瓜，有破碎的，有完整的。然后提到小卖部，有人买南瓜，最后再提及旁边的房子着火了。有人甚至都没提到着火。接下来我提醒大家：为什么旁边的房子着火了，这个人还有心情在买南瓜？ 大伙被我问住了，赶紧拿起手机又看了起来。 “喔，这个人穿的是消防服”，有人说道。 “消防队员不去救火，却在买东西，这不是真的着火，是在演习吧。” 这位同学抓住了重点，明白了这幅图的真相。

仅仅把信息列出来并不能看清事物的真相，甚至会曲解原本的意思。图中的消防员因此被人谩骂。同样，在工作还是生活中，我们不能仅仅是毫无次序地把所有东西就这么丢给另一个人，或者放入一个报告中。我们不能假定别人有时间、有意愿、有能力去分析从多种渠道扑面而来的堆积如山的大量信息。我们需要把这些信息做优先排序，不然别人就会自己排序，而这个排序可能会是错误的。我们需要确保重要信息没有被其他人看漏。

为了更好的整理信息，保证在任何情况下发现那些最重要的要素，可以使用“三叉提问法”，就是问自己三个问题：什么是我知道的？什么是我不知道的？要是有可能得到更多的信息，我还需要知道什么？

我们带着这三个问题，再来看下上面这幅画。

什么是我知道的：

1. 远处有个房子着火了，旁边驾着消防云梯
2. 有个农场超市，门口摆放着一堆南瓜，还有其他的商品
3. 广告牌上画了个大大的苹果
4. 地上到处是南瓜，有破碎的，有完整的。
5. 有人在超市门口挑南瓜
6. 这个人带着帽子，穿着消防服。

什么是我不知道的：

1. 农场超市的老板去哪了
2. 房子为什么会着火
3. 着火的房子的人在哪呢
4. 驾着云梯，其他的消防员去哪了
5. 这个消防员怎么还有心情买东西？

我还需要知道什么？

1. 消防员为什么对火灾无动于衷？

当摄影师乔尔·斯滕菲尔德开着大众面包车驶过这个乡村的时候，碰巧看到了这情景。这幅著名的摄影作品发表在了《生活》（Life ）杂志上，标题中，告诉人们的只有时间和地点：麦克莱因，弗吉尼亚，1978年12月。观众和那些批评家模样的人只看到了这张照片的表 面，他们咒骂消防员的无能，犹如当罗马城烧起来时，尼禄还在买南瓜。斯滕菲尔德在他职业生涯的后期才告诉人们，这幅图片只是对事实的描述——一次井然有序的消防演习，有位消防队员正在中途休息。要是有任何人当时跟进了最重要的这一点（一个在闲逛的消防 员），那么，就可以更早发现真相。

当我背着相机外出旅游时，经常会有意识的回头看看，背后的风光有时比眼前的更美好。 工作遇到瓶颈了，不妨先清空自己，让大脑启动新的视角，往往会有新的转机。 之前在群里看到的11路原则，就是对切换视角的最好诠释：

11路原则： 任何时刻当你发现无法学习或作出贡献，那么坐上你的11路，去别的地方。

1. Rules are a good start, then break them when needed. 规则需要一开始就制定好，然后随时准备被打破。
2. Agile > Scrum, Principles > Practices, Servant > Master. 敏捷优于Scrum，原则优于实践，服务优于专家

3. Be autonomous, but don’t suboptimize. 自治，而不是局部最优

4. loosely coupled, tightly aligned squads. 松耦合，行动一致的小分队。

5. High aligment, High Autonomous: we need to cross the river, figure it how. 高一致、高自治团队的表现：给你一个目标，想办法实现。

6. if you need to know exactly who is making decisions, you are in the wrong place. 如果你需要清楚地知道谁是决策者，你就跑偏了。

7. Community > Structure, Focus on Motivation, Trust > Control. 社区优于结构化，聚焦动力， 信任优于控制

8. we aim to make mistakes faster than anyone else. 我们的目标是比别人更快的犯错

fail fast - learn fast - improve fast. 错的块，学的块，改进的块

1. fail-friendly environment. Failure recovery > failure avoidance 宽容的环境，修复错误优于避免错误

2. it’s not about whose fault was it,it’s about what did we learn? what will we change? 谁犯的错不重要，重要的是我们学到了什么？我们有什么改变？

3. continuous improvement: driven from below,supported from above 持续改进： 底层驱动、上层支持

4. if everything is under controll, you are going too slow. 如果一切都在掌控之中，说明前进的太慢了。

5. innovation > predictability 100% predictability = 0% innovation 创新优于可预测行， 100%的可预测等于毫无创新

6. data-driven decision, not opinion-driven, ego-driven, authority driven. 做决定采用数据驱动、而不是意见驱动，自我意思驱动，权威驱动

7. toyota improvement kata: Now, definition of awesome, next target condition, actions. 丰田改进看板： 现在的情况，最终目标，下一步目标，行动。