南方的三月，乍暖还寒，我决定暂缓一下那匆匆的脚步，给自己的的心灵放个假，参加为期两天的精益研发管理培训课程。一方面可以充充电，另外也可以让心灵得到舒缓，毕竟和忙碌的工作相比，再紧张的学习生活也是“舒服和休闲”的。
写在前面的话
对待培训，我的态度是，放空身心去学习，独立思考去吸收。不管你对于某个主题有多少认知，既然决定了要去参加这个或者那个学习的过程，那么就该先放下自己的戒备，放松心态去拥抱。学习的过程当中，可以选择质疑，可以提出自己的看法，独立思考吸收自己觉得对的有用的部分。认识的牛人越多，越常常感慨自己学得不够多，也常常感慨了解这一点太晚，现在时间与我就是个稀缺资源，所以不得不像海绵一样去汲取呀。这篇作为培训后感，不会涉及太多的培训内容，更多的是个人对培训内容的一些思考。总而言之，这个课程对我有用，所以也推荐给你。但具体你该不该去参加，还是要独立思考的。吴博的风格是，温和的娓娓道来，讲的时间占比很高，对学生比较照顾，各种安排都很舒服。我原本预想着体力上会很累，其实并没有。
本课程讲了什么？
具体讲什么，有心人可以去找一下吴穹博士发的相关的朋友圈。我这里就简单地用吴博的培训大纲分享下。大纲中的很多关键字，相信各位都并不陌生，但如何将这些概念融汇在精益的理念里阐述出来，在参加培训前，我是有些小疑问的。好在，两天如行云流水般的课程结束后，我的疑虑就没有了。
为什么会参加？
培训很多，很多都想参加，时间和机会都有限的情况下，冲着讲师来的。知道吴博是在两年前，有那么一位前同事，总是在转各种看板的文章，其中就不乏来自吴博的文字。认识吴博是在一年半前的敏捷之旅，当时他谈的关于软件开发拥堵的话题，本人很有兴趣。只可惜当时的时间比较短，想要和讲师交流的人又很多，所以接触还是很有限啦。再后来，我加入了精益创新中国社区微信群，群里挺多牛人的，作为群主，吴博给我的印象是“慷慨”，特别大方的分享各种资源，特别豪气的发红包。我是个对红包不那么执着的人，但还是会为错过了吴博的红包感到心痛。哈哈。所以这次的两天课程，我不打算错过，因此我就来了。
大纲中我感触比较深的几点内容：
敏捷和精益
虽然，我们公司算得上国内实施敏捷相当早的一家公司，但我接触敏捷很晚。前面这半句话不是我自己瞎说的，是TW的XR跟我提到的，原来敏捷圈的男神也在我们这“潜伏”过相当长的一段时间。但当年因为自己在另外的项目，加上那会个人的重心不在这块，我是到了2014年才开始比较系统的接触敏捷的。这里也要特别感谢下Daniel Teng，他的三天CSM课程狠狠地帮我刷新了三观。为何说狠狠地，上过他课程的都知道，那是个相当自虐的过程。接着天时地利人和，当时的团队领导给了我们相当高的自由度去实践敏捷，因此后来很长的一段时间，我和其他小伙伴们就在组织内心甘情愿的做着推动敏捷的工作。再后来，因为工作的转变，我和敏捷的距离又远了那么一点点。直到最近，我的感受是，走到哪里，都有人在说敏捷，这个词从IT圈火到了各个领域。已经有好几拨人在跟我打听敏捷相关的培训，看到的各种咨询机构的预测性文章，也是反复强调Agile。
敏捷是一种价值观，我个人很认同这个说法。就像吴博说的，这个词大概和健康一样，单独看都很正确，放哪都挺合适的。人人都想要健康，人人通往健康的路却不一样，毕竟每个人的体质差别很大。所以为了更好地实施敏捷，又产生了各种给予具体指导的框架。要采用哪一种，或者哪几种，那么就要去挑选或者剪裁。拿来主义在软件开发的场景是不适用的。因为这个领域要解决的问题很复杂，很多不确定因素，很多人的因素。关于人的因素，我倾向于带着更开放的态度去看这件问题，毕竟每个人生而不同，即使每一个人的出发点是好的，要在一起合作也不简单。
至于精益，它强调快速试错，其实软件开发过程就该是如此，对于不确定的需求，除了试，似乎也没有更好的方法。至于对精益的了解，不得不提到本人闹的一次笑话。前同事跟我提不如咱们也试试kanban吧，我说是丰田的kanban吗？他。。。我仅有的精益知识来自于OM（Operation Management）课程，当年老师推荐了各种读物，其中不乏带着精益这个关键字的书， 比如《精益解决方案:公司与顾客共创价值与财富》。正因为如此，把精益的理念放到IT领域，对我来说是新鲜的。闹出当年的那个笑话后，我读了《The Lean Startup》，但除了精益创业，我也想更多的了解精益管理，所以这次的课程对我来说吸引力很大的。
需求不确定性管理
做了很多年的需求工作，我的一个感受是，成为好的需求工程师也是个试错的过程，因为存在太多的不确定性因素。一个好的需求工程师，就是尽量将不确定控制在一个相对小的范围，将相对确定的内容传达给后续的团队。没法去界定这个小到底该多小，但这个范围有多大，确实和需求分析师的能力有很大的关系。这个能力的建立过程可能很艰辛，也可能很漫长，可能是你自己跌跌撞撞摸索出来的，可能你从他人失败的教训中学习到的，当然也可能有悟性极好，你相信的就是对的，比如乔布斯。
敏捷和精益的方法，很好的将需求分析工程师从这种艰辛的工作中解脱了出来，不敢说是全部，至少是部分吧。大家放下坚信做出来的功能一定有人用的神话，回归到一个更理性的角度去看待软件过程这件事。与其苛求需求分析工程师一定要对，不如大家一起接受需求的不确定性。当然也不要因此走到了绝对的反面，觉得需求分析师的能力就不重要了，而是用一些方法来控制这个不确定性。我看到的各种敏捷方法无一不是在为此而努力的。比如用户故事，产生的前提就是用冗长的需求文档来界定到底该做什么并不科学。User Story够简短，可以在人们的思考和记忆力更容易接纳的范围内阐述需求。比如各种Scrum会议，可以让团队充分沟通，明白短期，中期和长期的目标是什么，将理解差异的不确定性尽量减少。当然，敏捷从来不是说有用户故事就够了，如果你对此有疑问，课程中会就此展开探讨。
这次的课程前，我对实例化需求的作用是有些疑问的。很早就看完了《Specification by Example》这本书，并尝试在工作中应用，但我发现加了一些实例后，相对于用文字展现需求，例子在某些时候更便于和用户达成共识，便于测试人员了解某些情况的expected result，甚至可以帮到程序员理清实现的逻辑关系，但却无法做到替代需求文档。对于实例多大程度上可以帮到自动化测试，我的疑问更大。我的理解是，例子可以帮助复杂业务逻辑的阐述，但需求本身并不只有复杂的业务逻辑，所以实例更多的只能是一个好的补充吧。课程中，吴博对此的阐述，让我的疑问释然了。下图来自课件，版权不归我 :-).
测试
对这个话题的感触是很深的，不少人都说，测试这个环节就是一个necessary waste，这么多年大家都接受并允许的一个存在。可是当前的趋势似乎是，减少专门测试人员，让开发人员自动自觉保证质量。这个愿望是美好的，道路却显然是曲折的。下面几个观点，来自我的笔记：
- 与其谈自动化测试，不如谈分层自动化。
- 先了解团队的成熟度情况，再看如何应用自动化测试。
- 自动化测试是防弹衣，不是解决所有质量问题的灵丹妙药。
- Pre-production的成本越来越高，难以负荷，与其追求流程上的完美防止出错，不如多考虑灰度测试。
协作不确定性
为了更好地协作，所以需要可视化。可视化可以把问题透明化，可以触发共情。怎么说呢，做了需求工作这么多年，我常常发现，即使是一个需求的重要性，从用户传导到需求分析师，再传达到团队的相关人员，这都不是一件容易的事情。将所有信息写在邮件里，不管你写的多么直白，后续的各种相关人士也可能是不知道的，因为他们可能根本就不看邮件。开发人员不爱看文档，也不爱看邮件。因为改变总是突然发生，我以前的一个常用的做法是，会集体沟通，也会分别去和各个party沟通，确保大家都明确了需求的优先级或者需求的变更。这种方法的好处立竿见影，但沟通成本巨大，一个字累，而且无法适应scale up，因为一个人的时间是有限的。好在Kanban可以很好地可视化这些东西。我觉得Scrum中的站会强调的也是相同的作用，创造一个好的可视化环境。
精益看板方法是可视化的重要武器。但也不要把看板做成任务板，因为那不是价值的有效流动。鉴于本人并没有kanban的实践经验，这块就不赘述了，但这理念我是认同的。掩盖问题是不能解决问题的，可视化让大家看到拥堵，让LD参与排优先级，让大家回归到理性的合作方式，这才是通往成功交付的可循之路。
吴博此处有金句：互爱而不是互相伤害模式。这点，我非常认同。项目的成功才是大家所有人的共同追求，在这个前提下，互爱才能更好的包容与合作。项目成功了，是大家的Credit，项目不成功，一切的努力都是白费，即使那个过错真的和你一点关系也没有，又如何呢？
最后
两天的课程，想分享的还是很多的，比如motivation知识工作者的方式、方法。走上管理者这个岗位后，这些都是非常重要、必须要面对的问题。这篇培训后感，就当抛砖引玉，期待看到更多同学们的分享。也借此谢谢吴博的分享，学者的态度和风范，令人印象深刻。我想从每一位讲师身上获取知识固然重要，借鉴他或者她分析研究问题的方法，也是相当重要的。
