感谢道长 @qitaos 的推荐，让我了解到了敏捷之旅。并在长时间的挣扎后，把 2015 年最后一个周日奉献给了它。花了这么大时间精力来参加这个活动，不记录一下对不起我的这一天。

沙龙记录

第一个 topic 名字忘了。讲师是徐毅，来自 IBM 。早在 2005 年在诺基亚西门子中就开始接触敏捷。他的 topic 主要是在反驳一个观点：“敏捷转型要把不支持敏捷的全干掉”。要点如下：

• 敏捷转型是促进个体适应变化，从而改变组织结构的变化。如同送礼物， 重要的不是你送什么，而是你怎么送。
• 敏捷成功的关键在于搞定人，让大家达成共识
• 成功的人找原因，失败的人找借口。 关键是大家到底想不想做。
• Toc 约束理论核心之一： 人不抗拒改善。不愿改变，是因为没有看到可得的利益
• 引入一个新因素后的曲线图。首先技能水平是不变的，引入因素后开始下降（各种混乱），适应和理解后慢慢提升，最终稳定在新的高度。
• 和一个国外教练交流的结果：发现问题、确认问题、分析问题、解决问题这几个步骤在中国经常会立即跳到解决方案。大家都在想怎么解决，却没怎么考虑为什么会有这个问题。
• 僵化心态和成长心态。僵化心态认为能力是固定的，成长心态认为能力是可以增长的。举了个例子，目标是保证 100 分，僵化心态会去选择自己一定能考 100 分的容易的卷子来做，成长心态会加强学习保持 100 分。
• 态度决定一切
• 作为管理者或者驱动着，我们要赞赏付出而不是结果。结果并不那么重要，重要的是过程。
• 要用理想驱动，不要痛点驱动，否则看得不够远
• 培养问题解决领导力（Dos）。问题解决框架
  • 发现问题
  • 定义问题
  • 分析根因
  • 确定方案
  • 试行及检查
  • 关键是去掉 “我觉得”

然后第二个是来自 thoughtworks 的肖然。一直觉得 thoughtworks 是一家有很多先进理念的公司，而且听说里面人数也不多，不知道以后是否有机会和里面的人交流学习下。他的 topic 主题是 "行走的敏捷"。要点如下：

• 猴子试验（一开始放音乐后爬树就有香蕉，到放音乐没香蕉，再到把猴子都换成从来没有因为音乐得到过香蕉的，最终放音乐就爬树的习惯保留了下来）
• 猴子试验说明很多后来者只是模仿，不思其所以然。
• 敏捷没有收益的项目中， 质量内建、拥抱变更 这两个有做到吗？
• 和人沟通要有同理心
• 传统软件工程方法：需求收集->需求规格->系统设计->程序设计->程序实现
• 需要解耦需求变更与技术实现。举个例子，传统瀑布流有两个关键的地方，需求 “翻译”（规划人员出具体需求规格）、程序 “翻译”（System Engineer 把需求规格翻译成架构或者具体实现）。但很多公司实践是 System Engineer 把两个翻译都做了，规划人员去市场找需求了，所以走不顺。而且 1970 年瀑布流论文的作者当时就说了按照瀑布流图的做法来做项目风险很大，改进方案和现在的敏捷很类似。
• 软件质量衡量标准的共识：好不好改（能不能快速适应需求变更）
• 敏捷的方法：需求挖掘->初始用户故事->发布用户故事->开发用户故事->测试实现
• 敏捷的方法中，所有和用户故事相关的都是业务价值，而传统的只到达需求规格这一步。敏捷的时候开发会直接接触业务，而非经过 “翻译” 的技术文档（技术实现）
• 渐进明细。不要一开始就去设计整体的架构（数据库、中间层、应用层等），而是把需求逐渐细化后再考虑这些功能具体如何实现（类似全栈）。同一个功能的具体实现不应该局限在一种方案。
• 以前的一个例子：clean code 。代码不应有注释，通过看代码就能了解业务。现在也是类似，甚至可以通过自动化测试用例来描述业务
• 敏捷实践的几个关键的点：
  • 跨职能团队（解决一个萝卜一个坑的问题，避免翻译）
  • 高度可视化（透明才能快速响应）
  • 追求自动化（应变成文化，甚至用测试用例表示业务）
• 生活中的实践：拔掉鼠标，通过快捷键的配合来编程。
• 题外话：《麦肯锡报告》（各个职位可被自动化的程度），DDD（领域驱动开发）

第三个 topic 比较有意思，讲师是杨瑞，二次创业者。 topic 主题是你的团队是什么颜色（性格色彩）。要点：

• 性格色彩基础：
  • 红色，孔雀，典型：孙中山（外向 + 感性）
  • 黄色，老虎，典型：朱镕基（外向 + 理性，领袖型）
  • 蓝色，猫头鹰，典型：张国荣（内向 + 理性，完美主义）
  • 绿色，考拉，典型：许三多（内向 + 感性）
• 找到自己天生的颜色和后天培养出的颜色
• 识别团队里成员的颜色
• 性格无好坏，人无完人，可以互补

接下来是道长的 topic ，讲得是他的个人经历，以及一些自动化测试的感悟。因为都比较熟悉，所以没怎么记录。。。

下一个 topic 是创新产品生态研发体系，讲师是 Bill Li 李国彪。因为此时集中力开始下降（困了。。。），记得不多，但有几个印象比较深刻：

• 只要自己足够出色，那就不需要有什么危机感（回应道长说的测试人员要有危机感）。举了个例子，一个公司招了个 6 年资深 Java 工程师，但公司的主要技术栈是 ruby 。工程师问他不大懂 ruby ，为啥招他，公司答： 我选择的是你，不是你的技术或者你的经验！
• 测试活动最终应该尽量去避免 bug 的产生，而不仅仅是发现 bug 。

最后一个 topic 是一个敏捷落地的分享，讲师是郭雪品，UC iPhone 组的项目经理（没想到原来 UC 还有项目经理，一直以为都靠产品经理推动。。。）。这个是我觉得离我比较近的一个 topic ，所以记录比较多：

• 背景：发布效率上不去；架构超扁平化，不存在自上而下；成员都有实用主义（个人觉得更像功利主义，没看得见的好处的事不干）；对于敏捷的了解是自学的，套用了一下发现不合适后对敏捷有些抗拒感。
• 思考：为何要敏捷？ 是不是你有了锤子后，看什么都是钉子？
• 自己的初心和职责：用尽一切手段，达成业务目标

• 最终落地过程：

• 切入点：

  • 可视化（痛点是管理者获取整体进度管理成本非常高，看板可以解决问题）
  • 接口人站会（各团队接口人和老大都能知道各团队现状了）
  • 规律化（迟到罚款）
  • 划分人员角色职责。
  • 先解决痛点，让团队意识到有好处

• 建立信任（频繁交付价值）：

  • 需求排序（先做顶端的，一路做下来，研发不会被需求搞死）
  • 版本 0 间隔（版本中期去做需求梳理）
  • 引入需求池（包括产品需求、bug、技术需求（技术债）。解决原来版本发布末期频繁改 bug 引起进度和质量不可控的问题，把 bug 作为需求进行管理），结合看板调整需求顺序（除下一个需求外其他都能改）
  • 开发过程优雅了。虽然没有提及 scrum，但实际做的就是这些敏捷的事情

• 抓住变化的机会做变化

  • 重大事故之后是做变化的好时机
  • 在两次重大线上事故后，推动变化，让精益技术在班车模式中借壳落地

• 留意、教导、支持

  • 拉团队成员（特别是接口人）一起培训
  • 对内传播思想，发展支持者
  • 对外多交流学习

• 有破有立（减少阻力），增加乐趣

  • 让大家不去写日报，改为只维护看板
  • 日报有啥用？停掉 3 天后没人留意到，问了老大，老大说只用于年终 kpi 时的依据
  • 取消写日报后大家很高兴
  • 看板上每个人的姓名磁铁很有趣，大家因此喜欢去维护看板
  • 要求每个人同时最多只能有 2 个 task ，通过每个人只有两个姓名磁铁就能达到
  • 通过看左侧磁铁剩余情况就知道谁有空

• 形成规则，守住成果

  • 建立契约。建立了会议基金池（对应罚款）、规划准时、发布当天的检查点

• 最终成果：

  • 业绩翻倍、奖励、发奥迪，减少 996 。

• 对推行者建议

  • 不要老想着自己的锤子，不要当自己是推行者，忘掉招式，关注业务价值，更容易被采纳
  • 多看书、交流（3-5 天一本书）
  • 让自己思维上就是以敏捷的方式思考，这样能找到更多变通方法。
  • 融入团队，做个 “有趣” 的人

推荐的书

• 《非暴力沟通》
• 《看见成长的自己》
• 《你的灯亮着吗》
• 《成为技术领导者》
• 《给经理人的第一课》（格鲁夫）

相关资料：

• 1970 年瀑布流论文
• 敏捷最初的两个论文
• DDD（领域驱动开发）
• 《麦肯锡报告》（各个职位被自动化替代的程度）

自我总结

敏捷目前对我而言还不是一个十分清晰的概念。只知道大概（敏捷宣言，scrum，xp），所以对于敏捷方面的东西不作评论，暂时听过就好。然而从今天的活动中还是有几点印象比较深刻：

• 几乎所有 topic 里面都有提到质量，都有关注质量的稳定或者提升。说明质量相关的活动不会消失，也日趋重要
• 和人交流永远是很重要的事，特别是在团队中推行一个东西的时候
• 人不抗拒改善，不愿改变，是因为没有看到可得的利益
• 性格色彩。不要试图给自己或别人染上其他颜色。
• 每天 10 分钟黄金提问，给自己的一天一个小总结
• 一件事情能不能做好的关键是 你想不想做好！

说白了，就是测试这个活动不会消失，所以只要你能找到办法，让自己的工作做到让质量提升，那么不必让自己被危机感包围。

另外，和人打交道（别人和自己）是一项必须掌握的、很有深度的技能。要抓住人性，顺着人性去做事。这样做起来才顺畅。

原文地址：http://chjvps.com/blog/?p=1054
转载（如果有的话）请注明出处，谢谢~