在上一篇文章（沟通篇）中，我们讲了有关软件研发组织“在家办公”受到的沟通方面的挑战。
可能是在一家敏捷的公司待得久了，所以我很长一段时间认为“敏捷”在中国已经是家喻户晓不需要再去谈的东西。可是直到我后来做了技术顾问，开始为客户提供架构和工程能力的咨询服务时才发现，绝大多数技术架构和持续交付实践难以落地的问题，最后都会遇到团队不够敏捷这个关键障碍，而真正敏捷的团队，在整个中国的IT行业中，则是极少的。
因为不够敏捷，所以能够用于改进的带宽就不足，因为改进的带宽不足，所以就难以应用更好的技术实践，如此反复就变成了死循环……
而在众多导致不敏捷的原因中，首当其冲的，就和软件研发组织的项目管理方法和项目管理人员的能力有直接的关系。
而本次新型冠状病毒（2019-nCoV）疫情导致的“在家办公”的要求，则瞬间放大了相关影响——尤其是那些依赖于传统项目管理方法的软件研发组织。
那么，在这一篇中，我们就聚焦“传统的项目管理方法”和“敏捷的项目管理方法”的区别，来谈谈对于在家办公的影响：
最近“新型冠状病毒（2019-nCoV）”汹汹来袭，一时间“在家办公（Working From Home，简称WFH）”成了一个非常现实和火热的话题。我心想着：“这时候理应有篇写在家办公的文章”，但是又一想：“想必一定有很多人写”，所以一直没动笔。
结果呢，各种渠道和平台的在家办公类文章铺天盖地，无奈的是，里面大量的都是在卖自家产品，没几个在认真说在家办公的挑战和问题的。似乎买了某家的在线协作平台产品，就能真正实现在家办公了一样——如果真的靠买产品就能实现在家办公，那岂不是绝大多数的软件研发团队平时都应该在家办公吗？为啥还要天天车马劳顿的赶去公司上班？
这次突如其来的疫情所带来的在家办公一事，更像是一次针对软件研发组织敏捷程度的“国考”。在家穿着睡衣披头散发的办公，还都只是大家呵呵一笑找点乐子，但是如果长时间下去，还有多少软件研发组织能够笑到最后呢？
在IT行业，在家办公一直是一个非常火热的话题。我在加入ThoughtWorks之前，有过半年时间的在家办公尝试。在加入ThoughtWorks之后，在做培训、做开发、做咨询的过程中，阴差阳错的竟然实现了相当时间比例的在家办公。在我看来：
以绝大多数软件研发组织的敏捷实践水平之低，还谈不上如何在家办公。
从这篇文章开始，我将围绕制约在家办公的一些关键挑战，以多篇文章（每篇关注一个维度的方式）来谈一谈为什么在家办公是软件研发组织的“敏捷试金石”。
本篇，我们优先说一说：沟通成本。
我在2014年入职ThoughtWorks后，做了近4年的人才培养。在2018年底，我开始从事对外咨询和培训工作，然后又带着一群新技术顾问去对顾问要求比较“严苛”的客户那里做咨询。在这个过程中，一个让我割舍不掉，并且在潜意识中也无法停止思考的问题就是：怎么培养人？
尤其是与教毕业生和Junior的员工如何写代码和做项目相比，带Senior的人做咨询工作是有非常大的不同的。
这篇文章，就围绕我所精挑细选的“新技术顾问必读的十本书”出发，来给大家分享我在培养“通用型软件技术顾问”的过程中的一些思考。
也希望能够以这篇文章开始，将“如何培养软件技术顾问”这个问题进行不断的探索和总结，来补全我们过去一直以来所进行的“软件人才培养”的研究。以期日积月累，最后成书。
你是不是和我一样，是一个会使用一大堆编程语言的软件开发工程师？例如：
Java、C#、JavaScript、Ruby、Python、Go……
你是不是和我一样，会在电脑上装一大堆以上各种语言的“版本管理器（Version Mananger）”，为了管理和切换不同项目的运行时（Runtime）版本？例如：
sdkman、nvm、rvm、pyenv、gvm……
你是不是和我一样，是一个浪费了大量时间在选择某种语言的版本管理器上的“强迫症患者”？例如：
到底应该用sdkman呢还是jabbar呢？
到底应该用nvm呢还是n呢？
到底应该用rvm呢还是rbenv呢？
……
你是不是和我一样，被各种语言的版本管理器污染了硬盘还整的精神分裂呢？
你是不是和我一样，期待能够有种能够管理所有语言的版本管理器，从而“一统江湖”呢？
你是不是和我一样，平时使用macOS或者Linux操作系统呢？
如果以上答案都和我一样，那这篇神器推荐就是写给你的，让我们隆重介绍这款“一统江湖的语言版本管理器”：asdf-vm！
（对不起，我也用Windows，只是神器不支持……囧）
在我的上一篇文章中，给大家介绍了我在实践中对于DDD设计过程进行梳理的思考。本篇则是向大家整体介绍一下我的“DDD分段式协作设计”的步骤和内容。
同时，该方法的基准化操作手册，也在曾经的一篇文章中公开提供了下载，可以作为更细化的内容进行参考和使用。
由于DDD的相关概念和设计方法极多，相比其他市场上所能见到的操作手法，我在这里向大家所介绍的方法，更加聚焦如何能够确保达到“绝大多数人的60分”， 而非“极少数人的100分”，也就是说，我更加注重的是：
为此，我尽可能的通过实战检验，在一些需要凭借经验进行综合判断的场景，尽可能的提供虽然不完美但是可以降低选择成本的唯一选项或解释，从而争取让一线实施人员避免“二选一”或“看具体情况再说”这样莫能两可的纠结。
需要说明的是，不同的咨询师在实施DDD的设计过程中手法都不一样，我仅是从我所实施过的咨询项目出发，提供了一种经反复验证可工作的方式，并不代表本方法是唯一正确的。
在这里仅供参考，也欢迎大家进行交流。
2019年，在我对DDD进行基准化的过程中，遇到过非常多的挑战，其中一个便是：
DDD的设计过程，到底应该分为多少个阶段？每个阶段做什么事情？
这个困惑来自于书本上，以及其他咨询师在咨询过程中对于DDD设计和操作的差异：
对于实际的学习者和使用者来说，这种混乱的操作手法所形成的不一致和不流畅体验，对于坚持进行DDD设计和减少吵架来说，简直是一种毁灭性的影响。
在这个过程中，最让我感触深刻的，是在于大家在落地DDD的时候，使用了大量具有“二义性”的词汇，讽刺的是，这与DDD所强调的统一语言是背道而驰的。
其中对于上述混乱影响最大的因素之一，就是大家对于DDD的“战略设计”和“战术设计”认知不一致（甚至说是混沌）的问题。
所以，这篇文章，就是围绕这两个概念，来说一说我是如何在基准化的过程中解决这个问题，统一并形成较为流畅的分段式的设计过程的。
在这一年聚焦DDD设计，尤其是DDD的协作设计工作坊的咨询工作中，我发现客户同很多咨询顾问之间总是存在以下冲突：
结合我曾经在ThoughtWorks近4年的人员培养和教学经验，和这几年来的咨询经验，我能够理解客户这样要求，是因为希望能够实现方法论的规模化落地。而在方法论规模化落地的过程中，一个很重要的问题，就是绝大多数能力一般的人，都更习惯于依据“明确的指令”进行工作，而不是依赖自己“有限的经验”和“莫能两可的方法论”。
这篇文章就是记录我是如何来解决这个问题的。
一段时间以来研究和实践契约测试，发现如过去大家对于单元测试、集成测试、端到端测试等等测试理解不一致一样，绝大多数情况下都把契约测试理解或应用错了。
为了统一认知，写了个简介，以求被拍砖和拍人。
A：“能麻烦您给我讲一讲你们的工作流程吗？”
B：“哦，这个呀，就是需求分析、设计、开发、测试、上线呗！”
A：“Hum…”
B：（心里不爽：明知故问嘛！）
B：“你不是来给我们解决技术问题的嘛？你了解这些东西对我们有什么用？”
A：“哦，但凡能用技术解决的问题都不是什么问题……不知道您听说过这句话吗？”
（陷入尴尬）
这是个我曾经在做各种调研时，为了了解对方的端到端工作流程而习惯问的问题，当然收到的回答也是如上面一样相当的一致。
后来，我逐渐发现这种问问题的方法是基本上难以收获我想要的满意答案的，尤其是在同一个团队中不同的人使用的词汇和对流程理解不一致的情况下，但是从实际来说，这种认知不一致恰恰就是最普遍甚至可以说是几乎100%存在的情况。