在写完《示人以真》读书笔记后，又进行了深刻思考。
1. 以终为始
不管做什么事情，都要有目标，并能以终为始。就好比书中说到的不要担心失去生意，那么我们去谈生意的目标是什么。谈生意最终目的还是需要能够解决客户的问题，那么我们就要怀着一颗初心，始终抱着为客户解决问题的心态。在与客户谈生意的时候，时刻想着如何能真正为客户解决问题，让客户感受到你的诚意。打个比方，比如我的3年规划是一名专业培（咨）训（询）师，那么从现在起，就要把自己当做培训师，抓住一切机会进行练习。
2. 知之为知之，不知为不知
《论语》，知之为知之，不知为不知。在客户面前也要这样。如果自己不知道的事情，一定要勇于承认自己的不知。今天在Daniel的课程上，感触最大的就是。不知道不知道的，和知道不知道的区别。如果不知道不知道，那么从何下手？Google也没有目标啊。变革艺术家就是需要让不知道不知道变成知道不知道，把新鲜的思想概念带进组织，点燃大家的求知欲。
3. 真诚诚实
为人要真诚。人之初，性本善。身在江湖，要以真面目示人。
知道这本书是非常偶然的，在阅读帕特里克 兰西奥尼的《破除团队藩篱》一书时，无意中看到书后有推荐的书目，当时就被宣传语给击中了。
一位在所在地区小有名气的大型咨询公司的项目经理，却总被一家规模远小于自己的小型咨询公司竞争对手打得焦头烂额。可就在这一年，这家小公司的管理者却意外地宣布退出了，于是这位项目经理有机会接管这家公司。在经营这家小公司，梳理“宿敌”的“遗产”时，这名项目经理却惊奇地发现，让自己对手成功的原因竟是如此简单……
怎么样？如果你心系咨询、培训并想在这个行业大展宏图的话，那么看了上述的文字一定心里老痒痒了。没错，我和你的心情是一样的，因此我迅速的下了订单买了一本。
下面我就列举该书中最最核心的思想（咱不说故事了）：
核心思想：裸式咨询
在进行咨询服务时，咨询顾问常常有如下3个担忧：
针对这3个担忧，分别有一些相应的原则可以遵守并消除担心。
担心失去生意
担心出洋相
担心露怯
看了上面的原则后，是不是还有疑问？有问题？是的，好几个原则我看了以后也不理解。没关系，买一本书细细地看一遍。我相信你会有收益的。
经理会要求收集和产生很多测量和报告，而对于经理来说，这正是一个真正的好机会，确保只有那些有益于价值创造流程的那些测量被捕获和汇报。当然这个目标也需要确保测量和回报的过程符合Scrum的核心价值和原则。
Scrum有几个重要原则，这些原则可以指导经理怎样处理测量和报告。下面是几个例子：
1. 关注闲置工作，而不是空闲员工。为了达到这个原则，要监测工作流什么时候被阻碍了，有多频繁，而不是监测你有多擅长让大家保持忙的状态。比如测量生产周期，会展现工作开始时间和结束时间的间隔。如果生产周期在增长，那么你就需要研究一下为什么了。
2. 通过可工作的、经过验证的资产衡量进度。如果你没有交付人们想要的产品，没超预算，按时交付这些事情还要紧吗？关注对交付价值（可工作的、经过验证的资产）的衡量，但也不要忽视交付价值所需要的参数（时间、范围、预算和质量）。
3. 组织快速反馈的流程机制。所以也需要考虑用你的测量方法来表征快速学习周期的进程（假设、构建、反馈、检视以及适应）。
4. 最后一种测量是**创新核算的核心。**创新核算对于任何在极端不确定条件下创建产品或服务的组织都是有效的（Ries 2011）。创新核算使用可行的指标评价我们学习的速度，并作为创造商业价值结果进度的关键测量。创新核算基于以下三个步骤：
4.1 创建一个最小化可行产品（MVP），基于组织或产品目前状况制定真实有效的衡量指标基准。
4.2 执行一系列增量式的产品改进，使指标在基准线向着理想或期望的价值进展。
4.3 如果测量指标显示产品正朝着期望的目标产生显视化的进展，那么就沿着当前的轨迹坚持下去；否则，需要转型到新的策略上，并重新开始这个过程。
========================
以上文章摘取自《Scrum精髓》中文版第13章
总结几点非常好：
1. 人要有职业，就好比猫抓老鼠，狗看大门。
2. 整洁。古人云：一屋不扫，何以扫天下。因此整洁从个人做起。
3. 友爱
4. 投桃报李
5. 路不拾遗
==========================华丽丽的分割线
本文转载自《读书文摘》
偶尔看到几册印于民国十一年（即1922年）的线装小学课本，不禁震撼!不禁为当今的中国教育汗颜，不禁为中华民族的未来深深忧虑!民国年间，兵荒马乱，人心却淡定。人有信念，下有常识，小学课本集二者于一身。老课本的编著是民间的，无关君王军阀权贵，透着民众皮肤上的冷暖，不呼口号，不居高临下，不繁文缛节。仁、义、礼、智、信，情趣，家国之源、江山之远、永恒之义，多在平白明净的故事之中。
教育的最大功能是使生命产生敏感。翻阅这几册线装小书，景深里都是天地之悠悠。 在此，我择其有图画有味道的几篇课文，配以拙文，分享于人，致敬民国童年。
第一课 职 业
【课文原文】猫捕鼠，犬守门，人无职业，不如猫犬。
一十八字，道出生命的庄重。
进化的自然选择，适己而利人，善哉。
不可无职业，也不可职业乱窜。犬捕鼠，多管闲事；猫看门，形同虚设。
世上职业千万，有需要就有职业；可世上好职业只有一种：喜爱又能谋生。
各司其职，便能各尽所能；按劳分配，或能走向按需分配。这些宏大的道理和主义，猫犬不懂，却能身体力行。
第六课 整 洁
【课文原文】屠羲时曰：凡盥面，必以巾遮护衣领，卷束两袖，勿令沾湿，栉发必使光整，勿令散乱。
教一件事，先教方法。道理在事体里，厚积薄发。据称联合国一份文件用五种官方文字打印，中文最薄。
语言也可整洁。
外看是仪表，内中透情境。
一个人，一亿人从小“勿令沾湿，勿令散乱”，蕴蓄华夏男儿的堂堂仪表。
第十一课 友 爱
【课文原文】徐湛之出行，与弟同车。车轮忽折，路人来救。湛之令先抱弟，然后自下。
寥寥数语，淡淡白描，人、事、观点都有了。
众人平素相似，不一样在非常时刻。危险、利益、困顿，最考验人。
这一课让我们看到什么呢？车与路都得适时检修；路有不平，人施于手；先救弱小，再自救。事小道理大，放之于雪灾、地震、车祸、旱涝、战乱而皆准。
道路决定车轮，车轮决定远方。
只是今夜城市车流里的广播正唱：心在远方，堵在路上。
第十五课 投 报
【课文原文】孙赵二女，同校读书。孙女得新书，持赠赵女。赵女取纸笔报之。
此册封三印有商务印书馆一段话：“教科书所言事实以家庭教育为主，兼及社会，皆日常习见习闻者。取材颇合儿童心理，书中间涉女子事，尤便男女共校之用……”
所以此课不只是讲孙赵二女的礼节，还在讲这个国度封建了几千年后另一半人的学堂梦想。她们是女童，她们是母亲。西方哲人曰：“一国之兴衰不是看一国之君，而是看一个个家庭的母亲。母亲哺乳了孩子，教育哺乳着母亲，谁哺乳教育呢？”
十年树木，木渐成林。光阴沉淀，积为年轮。
投桃报李，远古至今的绿色箴言。
第十六课 不 拾 遗
【课文原文】王华行池畔，见地有遗金，华置金于水边，守其旁，待遗金者至，指还之。
夜不闭户，路不拾遗，是俗世温度计上的一个温暖时刻。在川流不息的路上，在更深人静的夜里，站着人世的荣耀。
民国那会儿，军阀运辄大打出手，城乡多见兵荒马乱。大道阡陌之间，草莽英雄，世相奔逐。偏偏那一日静静站着个叫王华的童子，他守在池畔，守着金子等一个陌生的路人。读者看到他的等待，千万个如他的童子一起等待。这个简单的故事，复制为民国国民生长的一则信念。
不以黄金为最贵的年代，就是黄金年代。
第十七课 御 侮
【课文原文】鸠乘鹊出，占居巢中，鹊归不得入，招其群至，共逐鸠去。
鸠占鹊巢，一课藏谶。
这册课本出版十多年后，日寇军刀割裂了大半个中国，那些用胸膛死死顶住日本刺刀的汉子里，会有多少7、8岁孩儿时读了这个故事，20出头投笔从戎的血性男儿呢!
七十多年后，当我们再读这册课本，在亘古如斯的夕阳下翻到“御侮”这一页，仿佛读到了河山的密码。
这几天Ron Jeffries写了两篇《SAFe good but not good enough》和《Issues with SAFe》，引爆了敏捷社区关于大规模敏捷框架（SAFe）的讨论。
我的意见是不管SAFe好不好用，只要是解决了客户的问题就是值得认可的。另外如果真要说是不是大规模敏捷框架，那么就要回归敏捷的4条价值观：
个体和互动 高于 流程和工具
可工作的软件 高于 详尽的文档
客户合作 高于合同谈判
响应变化 高于 遵循计划
不管是SAFe也好，Scrum也好，都是声称自己是敏捷的方法，那么就要遵循敏捷的价值观。如果脱离了敏捷价值观，那么就不再是敏捷方法了。
下面是微信群里大家关于SAFe的一些讨论摘抄：
Ken Fang 下午9:03
SAFe 當然是符合敏捷的思想。而任何人的批評，往往才是最佳的學習與成長的素材。Michael James 的批評，啟發了另一种思維……如何誏团队不論是採用XP, Scrum或SAFe，都要能更加的 “擁抱变化”。而这也應該是XP, Scrum, SAFe, 所有敏捷咨询顧問所需面对的最主要挑戰。
Ken Fang 下午9:19
团队/組織敏捷的核心度量指標……团队/組織是否可擁抱由外部市場，外部使用者所引起的变化？！基本上，“擁抱变化” 不是个新話题，人類在这話题上已奮鬥，鑽研，爭論了半个多世紀……現在，終於在敏捷上找到了方向，但，各式的实踐仍再不断的演進;如:ZapThink。當然，各類的批评也不断的湧現。这就是走軟件这行，最吸引人的地方……永远不会只有一个標準答案, 永远不知道明天又有什么新鮮事，大師永远只活在昨天，永远只有創新，没有大師。
Julien 下午9:22
The value of SAFE is to make the management feel safe(the acronym can not be a coincidence) about the changes because they have a picture of where it is going. For any experienced Agile coaches, many things inside are trivial because it just puts existing stuff together and way too many others are diluted(ScrumMaster role in particular). If it enables management to buy in(and obviously it does), it has value. It does not have much more other value than that if you want serious improvements.
首先可以把技术债分3类：低级技术债、不可避免的技术债和策略技术债。
低级技术债指的是团队成员技能不足或业务不熟练、亦或是流程缺陷导致的技术债。
不可避免的技术债，通常是不可预计也不可避免的。打个比方，我们的产品使用了一个第三方的组件，在使用过程中发现该组件有缺陷，从而导致我们的产品出现故障。
策略技术债指的是组织为了快速抢占市场而有意承担的债务。
能够认识到这三类技术债后，下一步就是如何管理技术债。这里再介绍三个管理技术债的活动：管理技术债的增长，可视化技术债和偿还技术债。
管理技术债的增长：一般来说，我们会尝试用良好的技术实践来降低技术债水平，如重构，自动化测试等等。我们还需要能识别技术债的经济效果。比如为了赶工我们欠下的技术债，在经济上它到底是多少，后续会有多大的成本。
可视化技术债：可以分为业务层面和技术层面的技术债。可视化技术债的目的，是为了让所有员工都能理解技术债的影响（包括开发人员和业务人员）。业务层面的可以直接用钱来显示。而技术层面上的，可以有三种方式可视化：在缺陷跟踪系统里记录技术债；在产品backlog里记录技术债；单独一个技术债backlog。
偿还技术债：在偿还技术债时，我们要认识到不是所有技术债都需要偿还。比如即将结束的产品、一次性原型和短暂的产品是不需要偿还技术债。在开发过程中应用童子军规则（让离开时的营地比进去时更干净）。还有非常明显的一条，我们要首先偿还利息高的技术债，并且在进行开发工作时就逐步的偿还一部分技术债。
以上内容摘自《Essential Scrum》译稿第八章。
如果你正在某快餐厅排队等待点餐。就在这个时候，来了10个人加塞在你前面，你会怎么做？心里骂娘千百遍，还是大声呵斥并阻止这样的行为？
在软件开发过程当中，如果发生这样的事情，比如你的团队正在进行手头的开发工作，你的老板有个“十万火急”的需求，要2天内完成。这个时候你会怎么做？忍了，还是拒绝？亦或是其他的处理办法？
本系列文章将会从几个问题出发来描述排队的现象：
当系统的处理能力跟不上服务对象的到达率时，就会产生排队现象。（这句话也可以理解为新来的服务对象的数量要大于系统的平均处理能力）排队现象不仅仅出现在现实世界中（如开篇的例子），也出现于数字世界中。（比如软件开发，IT行业等等）那么让我们先回溯一下历史，排队理论是怎么出现的？
早在1909年，Agner Krarup Erlan就发表了一篇关于排队理论的论文。在论文中，他研究人们打电话的方式，发展出人们需要等待多久的公式。
再次发散一下，受到美国福特汽车生产的影响，许多企业认为（包括福特）大批量的生产可以降低单件的成本，从而可以降低整辆汽车的总成本。这句话的前半部分是成立的，但是单件成本的降低，不一定会带来整车成本的降低。（具体原因后面会进行分析）现在的软件行业仍然被这种思想困扰。
后来丰田汽车独创了丰田生产系统（TPS）模式，以及时生产（Just In Time）和自动化（Jidoka）为支柱，持续改善为基础。分析TPS发现，丰田是全局考虑，从而保证生产的每个环节都得到优化，并且一旦某个环节出错立刻停止生产（避免更多的浪费）；而福特的理念，属于局部优化，每个环节都做到最优化（批量生产从而降低成本），但失去了全局的集成考虑和整体优化。
回到我们的主题上，目前行业的排队现象多是受到批量生产思想影响而造成的。如果能很好的学习丰田模式（精益）的话，也会较好的解决排队现象。
在生产行业况且存在如此多的排队，那么软件开发行业是怎么样的呢？据不完全数据统计，99%的软件开发企业都存在排队现象。这是因为在软件开发当中，排队是不可见的，并且很少会有公司对此进行衡量，那么允许排队现象的存在（并且越来越严重）便是司空见惯的了。
总结一下
造成排队的原因主要有三：
说了这么多排队，排队理论、现象；那么是否排队就一定不好，排队会有什么样的后果，以及如何优化排队呢？
敬请期待本系列的第二篇，排队会产生哪些后果？
本书的两名作者是来自谷歌的Brian和Ben，也曾经是SVN的初创人员。本书是写给程序员看的，教你怎么交朋友，怎么影响团队中的其他人。让你在技术团队中过的更开心，变得更有效率，更加如鱼得水。本书想要帮助程序员改进理解他人，与人沟通以及与人合作的能力，从而在编写软件过程中更加有效率。
全书的核心是HRT三支柱，分别是：
不论做什么事情，不论个体还是团队，都应该遵循HRT的价值观。如果团队的人际关系出了问题，那么一般来说就是HRT的某个方面出现问题。
谦虚
中国有句古话叫做“谦虚使人进步”，要知道这个世界是山外有山，人外有人。只有抱着谦虚的态度（知之为知之，不知为不知），才能赢得别人的尊重。
尊重
真心实意地关心同事。他们都是活生生的人，能力和成绩都需要得到肯定。
信任
要相信别人的能力和判断力。在适当的时候懂得放权。
在本书中，还有一个团队的良好实践，我非常喜欢，摘抄如下：
- 写一份明明白白的任务宗旨，这样可以随时保持专注，知道哪些是目标，哪些不是。 - Email讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人” - 所有历史都要有记录。包含代码历史，设计决策，重要的bug修复以及过去犯下的错误 - 有效进行协作。利用版本控制，代码改动尽可能的小，方便进行代码审查，扩大公车因子，避免出现领地感 - 修复缺陷、测试，发布要有清晰的政策和流程 - 降低新人加入时的壁垒 - 共识决策
优秀团队的沟通模式：沟通的指导原则之一就是同步沟通的时候（比如开会），人越少越好。（只有相关的人参加）而在异步沟通的时候（比如Email），涉及的听众越多越好。更重要的是，必须确保项目文档里的信息尽可能让所有人看到。
顺便作者提了一个有关开会的小提示：
大海航行靠船长：优秀的团队必须有一名优秀的带头人（leader）。这一章介绍了作为带头人，进行管理的模式，反模式，一些小窍门以及激励措施。在这里作者使用了大量实例进行反模式的说明，非常值得学习。
如何对付害群之马：在这一章，作者的宗旨是对事不对人。发现有害团队的行为，立刻进行制止或采取行动。同时也有大量害群之马行为的举例。强烈建议浏览。
作者在最后指出，这些方式方法不仅仅局限于软件开发行业。只要和团队有关，比如社区建设等都能应用这些方法。所有这些的核心就是HRT（发音heart），还记得什么是HRT吗？
欢迎大家一起讨论有关团队建设方面的话题。
刚刚过去的周日，即3月9日，王立杰老师和我一起办了一场敏捷实战工作坊。这里是一个学员的总结。回来后，我也在反思究竟什么样子的工作坊是大家想要的呢？
我的观点是：有种、有趣、有料。（希望罗振宇同学不会告我侵权）
种是种子的种，因此作为一个好的工作坊，首先要有一颗好的种子，即好的话题，好的方向。你的话题要够新颖大胆，方向要够准。这样观众才会喜欢你的工作坊。
相信大家在参加培训或工作坊的时候，不愿意听长篇大论或干巴巴的数据。我也深有同感。如果一个老师在开场5分钟内不讲一个故事，我基本会走神。接下来会睡觉看手机。所以真正好的工作坊需要时刻能抓住听众的注意力，而有趣则是关键。何为有趣呢？让我们来看看维基百科是如何定义有趣的。
Fun is the enjoyment of pleasure, particularly in leisure activities. Fun is an experience - short-term, often unexpected, informal, not cerebral and generally purposeless.
有趣是一种愉悦的享受，尤其是业余活动。有趣是一种体验——短暂的、通常是出乎意料的、不理智的或无目的的。
有料，指的是有实际内容，参加的人可以真正从中有所学，有所悟。这也就达到了办工作坊的目的。比如上周日我们办的敏捷实战工作坊，就是想让大家通过一次虚拟项目真正体验一下Scrum是如何运作的。
那么办好工作坊，是不是满足“有种、有趣、有料”就够了呢？显然不是的。这只是一个前提，主要是和需要准备的内容有关，在下一期我将介绍在交付工作坊过程中需要注意哪些问题。
2014年2月22日下午，在中关村创新研修学院迎来了第一次“精益看板”活动。本次活动的发起链接请点击这里。
本次活动主要有3部分组成：
然后Julien介绍了什么是精益创业（核心是build, measure, and learn)，以及精益创业和精益之间的联系。最后是有关看板的介绍，以及看板是如何符合精益的核心价值。可以参考Julien的幻灯片。
最后第三部分，是一个有点复杂的看板游戏。不过这个游戏很好的模拟了现实工作中的各个场景。比如紧急任务、阻碍、改进任务、跨职能团队等等，而且还需要绘制累计流图、控制图、财务分析表等。真的是非常全面。详细的游戏介绍，可以参考网站：https://www.getkanban.com
