敏捷变革过程中ETC面临的六个陷阱

敏捷从2001年被首次提出到现在已经历经了17个年头,作为一种新的思潮和软件开发方法早已跨越了鸿沟(如图1所示),并团结了大部分实用主义者,陆续掀起了不可逆的全行业敏捷精益转型。

如果你的公司或者组织正在进行或者已经经历了敏捷转型,那么作为组织变革者的你,一定在转型初期,组建了类似于“变革委员会”(或者“敏捷工作组”、“敏捷小组”、“变革小组”、“敏捷组委会”等)的团队。而在这个行业中应运而生的关键角色之一 —— 敏捷顾问/敏捷教练,入驻客户现场以后,提的第一个建议很有可能也是成立这样的团队。

图1 技术采纳生命周期 – 跨越鸿沟 Geoffrey A.Moore《公司进化论》2006

其实这种类型的团队有一个专业的名词 —— ETC,全称为Enterprise Transition Community(企业转型社区),是由 Mike Cohn首次提出,并在《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》中做了详细的介绍。

ETC的成员不超过12个,他们来自于参与Scrum转型的最高级别人员。

ETC的存在是为了营造一种文化、一个氛围 —— 那些对企业成功饱含热情的人尝试做出改变,而这些人的成功又会使更多的人产生更大的热情。ETC不是通过强行实施企业变革,而是通过指导实施变革的小组,为成功实施Scrum排除障碍,为变革创造活力与激情。

虽然ETC刚开始是Mike Cohn为Scrum设计的,但是在实际应用过程中早已不局限在Scrum转型了。同时,ETC也并不只是为企业级别所特有,也适用于更小的规模,比如说:一个BU,一个部门,或者一个产品团队(通常人数规模在100人以上或者人数少但是跨部门)。虽然每个咨询师或者每个组织有不同的称呼,但是几乎每个咨询师或者变革组织都会在转型前期成立这么一个团队,足见其重要性。为了统一语言,本文会使用ETC这个名称做进一步的深入分析。

先来说说我在咨询现场的做法。我一般会协同高层领导、组织变革者组建专门的改进跨职能团队,比如一个研发组织,包含业务、开发、测试、运维等部门负责人,成立ETC,选择改进的Product Owner和Scrum Master,人员控制在15人以内(有的组织非常大,波及人员范围较广,需要领导层酌情取舍)。

ETC按照Scrum方式运作,让变革者在战斗中学会战斗。团队有正式的启动仪式,迭代周期为一个月(或者两周,不建议更短,后续以一个月为例)。一个月一次改进计划会议,通过改进Workshop制定改进措施,并梳理优先级,责任到人,一周两次站会跟踪,每次半小时,针对改进项具体内容设置评审时间和形式,一个月一次回顾会议。

这是组织进行敏捷转型过程中一个非常重要的改进落地机制,是组织的改进引擎。令人欣喜的是,这几年下来,有很多客户,在咨询师撤场两三年后还能够继续按照当初的机制运作,“持续改进”已经植入了组织的DNA,始终有这么一支队伍持续不断地率领组织时刻反思勇往直前。

但是,更多的是运作不好的ETC。尤其是ETC运作初期变革者缺乏经验,非常容易陷入困境,接下来我们就深入了解一下ETC的六个陷阱和应对措施。

陷阱1:没有共同的目标,ETC名不副实

ETC的成员往往都是参与敏捷转型过程中的最高级别人员,是一个管理团队。而管理团队往往会有屁股思维;以研发场景为例,可能会有开发部门领导、测试部门领导,还有产品领导,项目经理等。

因为人员角色多,大家关注的内容就各有侧重,ETC的计划会、站会或者回顾会中如果偏向于部门或者项目,那么另外的人可能参与感就不是很强。更重要的是,分散的目标很有可能会造成互相推诿抱怨,效率低,改进不明显。

作为ETC的发起人或者变革者,第一个要解决的就是ETC成员目标不一致的问题,就像造船分配任务之前要唤起团队内心对广阔无限海洋的渴望一样,我们需要找到核心问题,让ETC成员意识到问题的严重性,树立紧迫感,渴望改变现状,然后引导大家共同制定改进目标。

这只是第一步,变革者需要不断的与ETC成员沟通问题和变革愿景,适当时候对目标升维或者降维,甚至通过求同存异的方式让大家达成共识。

陷阱2:知易行难,ETC成员没有以身作则导致转型也就是一阵风

有一次,开家长会的时候,幼儿园的老师让家长跟着做动作,老师一边把手放在眼睛上,一遍嘴里喊着“请把手放在下巴上”。很多家长不知所云,最后大部分家长都会比较纠结地把手从下巴转移到眼睛上,又有点犹豫,最终还是效仿老师把手放在了眼睛上。

这是一个很好的“知行合一”的小游戏,我们的孩子是这样,我们的团队也一样。他们并不会根据管理层说的调整自己的行为,而是根据管理层做的调整自己的行为。

变革过程中,有时候领导会觉得团队改进进展缓慢,很多情况下与领导的风格大有关系,“一句话需求”或者“说一套做一套”都是最直接的罪魁祸首。

举个简单的例子,如果作为部门经理或者项目经理的你,希望在研发团队运作中增加一个Story Kickoff的环节,就需要不愿其烦地与团队讲Kickoff怎么做,为什么要加这个环节,能解决我们什么问题,并且在实际运作过程中参与到具体的Kickoff活动并给予团队指导;当团队遇到问题的时候,帮助团队一起解决问题,并且鼓励团队。如果你只是吩咐了一句:“大家做吧”,然后就静待收割,99%的概率会失望。

再举个例子,敏捷理念中非常重要的一条是:管理者转身 —— 使用“使命式指挥”替代命令控制。一起参加培训的时候,你对“使命式指挥”赞不绝口,非常认同,并启发管理层全部要向“使命式指挥”看齐,但是培训过后的日常管理中,对管理层又是直接命令来控制去,这个时候,大多干部都会潜移默化地效仿并对他的团队也使用命令控制,而不是“使命式指挥”。

这个陷阱的应对措施最简单也最难:以身作则,知行合一,有的时候,有些根深蒂固的习惯非常难改,尤其是管理风格,但是要让团队知道你是意识到自己的问题并且在尝试改正的。

如果我们要改变,首先需要定义出我们期望的行为是什么,我们希望人与人之间有怎么样的行为方式,并教会员工这种方法。

陷阱3:事无巨细,ETC成员沦为微管理现行犯

如果原有领导班子是命令控制性风格,这几乎是ETC成员最容易犯的毛病之首,管理太细节,改进Backlog太细节。

三年前我就见过一个领导团队,7、8个部长就一个“测试场地到底有20平方还是40平方,能不能放下测试仪器”的事情吵了起来,而这样的领导者容易犯的第二个毛病就是:没有了解清楚就给方案。

关注的内容太过于细节,但是领导往往掌握不了所有的细节,这样的矛盾就会滋生出更多的矛盾,甚至造成给底层员工添乱的尴尬局面。

而ETC的一个重要职责是营造一种环境,在该环境中里,可以逐渐形成不 同的改进社区,这些改进社区在追求改善企业产品创建过程中,自发地形成和解散。

Mike Cohn《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》

ETC最大的目标是创造这么一个环境,让改进社区确认自己的目标,并自发地组织起来达成目标。

现在你是否发现,进入ETC其实并不意味着我们自己要做很多很多的任务,比ETC实际要完成的这些工作更重要的是,传递我们的转型愿景并激发别人的兴趣。

陷阱4:将信将疑,ETC成员期待他山之石可以攻玉

例如,作为事业群的最高领导者及ETC的PO,其实对整个转型过程呈观望状态,由于其他事业群的压力所迫,不得不跟风;虽然敏捷运作开始了,但是更多是谨慎前行,你希望团队要告诉你敏捷到底行不行。

这种场景,几乎都有一个同样的结局:失败。

经历过这种转型的咨询师或者变革者都会深有感触不堪回首。我在咨询现场,对领导层提的第一个要求就是:乐观并且坚定。管理层的乐观和坚定非常重要,强调多少遍都不为过。

因为,如果管理层将信将疑,团队会从各种互动中感觉到管理层的质疑,继而团队就会质疑,觉得转型没用,然后又会反过来影响管理层对转型的信心并加剧管理层的质疑,循环往复。最终以失败告终。

这里必须要提一下“文化变革的新旧途径”,约翰·舒克是丰田城的首位美籍员工,在经历了NUMMI公司的成功精益转型之后,他对沙因的文化变革模型进行了修改,他认为:

要改变文化,首先要去改变的不是人们的思考方式,而是行动方式,即他们怎么做事。

2015年,在沙因和约翰的模型基础上,为了让变革者能够更容易操作,我提出了如下观点: 对于管理层,我们要通过改变他们的思想改变他们的行为; 对于基层员工,我们要通过改变他们的行为来改变他们的思想。

随后的几年咨询生涯中,又经历了许多案例,何尝不明白“二分法”是最危险的思想,不管对于哪个群体,让其发生改变其实都需要思想和行为的相互佐证。但是,在大多数情况下,这样看似粗暴的划分其实并无大碍。尤其对于管理者而言,思维改变是前期最重要的一环,从古至今的无数变革案例几乎都昭示了一个不争的事实:领导者没有下定决心痛定思痛,变革的路就走不长远。

图2 文化变革的新旧途径

陷阱5:缺乏与基层团队的多渠道连接,ETC更像空中楼阁难以为继

就像陷阱3中提到的,ETC成员靠自己只能完成一点任务,取得一点成果,他们更需要依靠组织中的其他人完成实践落地而走向敏捷所需要的大部分工作。因此ETC如何发动群众,辐射群众,与更广大的团队形成一对多的继承和相互促进的关系就显得尤为重要。

改进社区、各角色技能CoP(Community of Practice,实践社区)都是不错的选择。切忌管理层在ETC各种指点江山发号指令,而忘记了团队疾苦,很多改进措施难以落地,团队叫苦连天,时间长了,不仅仅是变革像空中楼阁难以为继,更有甚者倒退回比之前都不如的境地。

场景一:某企业某事业部正在进行从上至下的敏捷转型,作为部门A的基层员工,根本不知道为什么要转型,每天的事情已经够多了,为什么还要多出这么多敏捷转型的讨论和会议?

场景二:经由一些天的头脑风暴和深思熟虑,在大领导的带领下,大家终于下定决心要对现状的短瀑布流程进行彻底变革,用敏捷核心实践来改善目前的产品质量。大家成立了ETC,并建立了改进Backlog,开始跟踪各种事项。作为中层管理干部,你很幸运参与了整个过程。不过你的团队经常对你飚出的一些新词以及那片花花绿绿的改进墙充满了疑惑和好奇,最开始你还解释一下,慢慢的时间长了,你也懒得一遍遍解释,他们也就熟视无睹了。

不管是Mike Cohn提到的ADAPT模型(如图3所示)还是Kotter教授在《 LEADING CHANGE》中提到的变革八部曲(如图4所示),都着重强调了一个“真理”:

每一个成功实施变革的组织都是在多个层次上进行这些活动

这个问题是:大部分变革项目都是由许多小项目组成的,这些小项目同样也需要经过从紧迫感到融入文化这8个步骤(如图4所示),缺一不可。而这是很多变革者最容易忽视的问题之一,他们往往蓄了足够的势,在最高层级用各种手段打开了突破口,找到了同盟军,让关键者动起来了,然而忘记了在下一个层级持续蓄势,或者忘记了教会他们的ETC用同样的方法鼓动底层员工跟着动起来,这也是敏捷转型非常容易失败的一个最关键的因素。

而另一问题是:整个变革项目行至中途,一些小项目完成了,而有的小项目才刚刚开始。不同项目不同团队的状况不一样,需要我们分别对待。

针对这两个问题核心应对措施就是:变革者要不断识别团队或项目处在变革过程中的哪个步骤,在多个层次和层级上反复进行变革措施,并培养更多的变革者,在不同的范围内和层次间不厌其烦地重复变革步骤。

图3 ADAPT模型 Mike Coh

图4 John Kotter’s Change Model-8 Steps 来源:staff.napier.ac.uk

陷阱6:忽视推广和传递,最终臣服于企业重力

最近几年,越来越多的企业管理者终于明白,敏捷转型是在不同的层级上进行的,敏捷变革所取得的成效也与其所能够影响的范围有直接的关联。就像上述陷阱5所讲,如果在IT组织内部不能够持续影响并顾及到多层级效应,就很难做出大的改变取得可观的效果,转型很有可能半路夭折。如果前五个陷阱完美应对过来了,基本可以说转型成功了一半。

为什么是成功了一半呢?其实对于进行敏捷转型的企业组织,只要踏过前五个陷阱,都能够取得不错的成绩,但是还差最后一关,那就是突破IT,向组织内更大范围推广和传播。

“企业重力”是一个很有意思的说法,不同的书籍均有提到相似的概念。这也是沙因对企业文化的解读:

文化 —— 是一个群体在解决外部适应和内容整合的问题时所学到的一套被普遍认可和不言而喻的假设。这些假设在过去运作得足够好,被视为有效的,因而被作为理解、思考和感知这类问题的正确方式传授给这个群体的新成员。 —沙因 《企业文化生存指南》

曾经让这个群体成功的那些思考、感受和看待这个世界的方式就是企业重力,因此敏捷转型的影响必须推得足够远足够广,才不至于使整个转型因为“企业重力”而被拉回到原点。

最经典的例子就是IT部门内部的敏捷转型,如果不连同业务部门,甚至HR、财务、物业等部门,用不了一两年,就会发现改进乏力,这也是《精益企业》中所提倡的,我们要在更大的组织和范围内进行彻底全方位的精益转型,才能让我们在不确定的市场环境中更具有适应性。

也有很多敏捷顾问/敏捷教练或者企业转型者认为只要ETC旗帜一树,正常运作起来,就成功了大半,殊不知这才是刚刚开始,组织转型本身就是九死一生的博弈,Kotter教授也在《LEADING CHANGE》中一开篇就介绍了导致组织转型失败的8种常见错误。

而本文用敏捷转型过程中的ETC作为引子帮大家鉴别领导班子的风格会严重影响组织转型的进展,希望正在做组织转型的你能够在面对ETC团队的各种问题见招拆招。


更多精彩洞见,请关注微信公众号:思特沃克

Share

DDD的终极大招——By Experience

以DDD思想和微服务架构为代表的新的架构时代正在逐步形成,不同方法和工具的涌现让人激动不已,同时这个过程也让人感觉到些许的不安,因为没有一套方法和一套架构能够打遍天下,我们能明确告诉所有组织和团队的,也只是架构设计上应该“响应变化胜过遵循计划”!具体到采用哪一种架构设计思想和方法,仿佛都需要增加一个定语“这取决于……”。

以去年的“明星”方法Event Storming(ES)为例,今年已经开始被不少人所批判。内行已经开始调侃这就是“糊墙”(不明就里的同学可以感受下图中的ES现场)。而实际上ES创始人Alberto是一位很低调的实践者,仍然在不停地磨练着他发明的这套方法。一年里我也接到了无数类似“我们是xxx领域,有xxx系统,ES感觉好像用不上?”的问题。我的答案往往是:“没事儿,你们先试试,找到具体困难点,咱们再看为啥不好用。”

(一个ES现场,“糊”满各色纸贴的建模过程。)

我相信得到这个答案的部分团队可能真的去尝试了ES,但鲜有人再将他们遇到的具体困难反馈给我 —— 也许ES实践本身就是困难,而不是他们要解决的业务问题。但我的出发点却并非推广ES,而是让团队能够获取“经验”!这点上还是小有成就的,去年我可能还是中国区“糊墙”最多的人,今年很多人都远胜过我了。

不管是在DDD原著,还是后续不少专家的书籍中,都明示或暗示架构设计最后的终极大招还是By Experience ——靠经验吃饭。从战略角度的subdomain(子问题域的划分)到战术建模层面Entity、VO的选择,最终的决策很可能不是完全“理性”,经验这个“感性”的东西发挥着很大的作用。

对于一个顾问和教练来说这是绝望的答案,因为我们每次面对的是希望学习,但没有经验的团队,“靠经验吃饭”等于告诉团队这东西没套路、靠感悟。这就迫使我们转换视角,从教大家DDD方法,转换到帮助大家获取DDD经验。下面就让我们来看看怎么有效解决DDD经验获取这个问题。

问题、问题、问题

DDD作为一种架构方法,最大的突破应该说是非常明确地区分出了问题域和解决方案域。而认知问题这件事情绝对不是技术人员擅长的,从我们学习编程起,我们就被如设计模式(Design Pattern)这样的解决方案所包围。想当年我自己最得意的事情也是refactor to pattern,也是把解决方案当成了“终极问题”来追求。

这往往是一个痛苦的蜕变,需要有人在你身边不停念叨“你说的问题是什么?”。你必须要做到心平气和,即使你认为对方是故意挑衅,有时候挑战更能促进思考上的突破。比如我经历过下面的一段经典对话:

甲:我认为这个子问题域是客户账户管理的问题。

乙:我觉得你已经在说解决方案了。

甲:客户账户管理是问题,我并没有提怎么管理啊!

乙:谁说一定要管理客户?!我还是觉得你说的是解决方案!

甲:(受不了你了… … )不管理客户我们做这个系统干啥?

乙:我就是这个意思啊,为啥要做这个系统?我们解决了什么业务问题?

甲:这么说的话那把业务找过来,看他们怎么说。

乙:行,反正DDD里说领域专家很重要,业务来了再讨论。

某种意义上这两位技术人员的争论是卓有成效的,最终的发现是业务问题其实并不清楚,远没有达到可以进入解决方案建模讨论的时候。

跨领域合作

当然上面的对话还有另外一个有意思的核心观点,即由于问题和解决方案在整个建模过程中是不停深入和迭代的,所以我们必须鼓励,甚至要求从业务到技术跨领域的人员参与和协作。

这点是我为什么仍然认为ES是一个好方法的基础,当然与我相对的观点是,如果有了真正的领域专家,搞那么复杂的协作有必要吗?ES通过对事件(event)的利用,提供了一套业务和技术能够共同理解的协作机制。在我的辅导过程中,很容易让两边的同学都理解如何上手。

(ES的运作机制,很有效的利用了Domain Event;注意这里的event是业务事件,而非技术实现。我的同事伍斌在自己的简书中详细记录ES的采用过程,欢迎大家查阅。)

当然如果真有经验丰富的领域专家,确实事情就简单了很多。业务问题的分解首先就变得非常流畅,ES的功效也就不那么明显了。然而我个人始终认为“团队共同的学习 胜于 建模本身的正确性”,即使专家也不能完全预见未来,所以团队能够有机会通过某种手段学习专家的知识,也是很有价值的一件事情。

从需求到代码

DDD最初吸引我的地方是能够从问题分析一直拉通到代码实现,这有别于很多其它的架构方法,总是在某个链条上产生脱节。所以DDD的经验获取也需要尝试让团队端到端的拉通体验。

然而事实上很多团队仍然在践行着脱节的实践,比如建模后产生的Entity仍然用传统的数据和行为分离的实现方式。这样的实践方式显然是有悖于DDD的初衷,如果不能让业务和系统模型实现绑定关系,很快就会走上各说各话的老路上去。

实践端到端也有一定的技巧,首先应该明确分层架构的原则和规范,比如是否有Application Service存在的必要,Interface的调用规则等等。在此基础上,需要明确守护Domain Model的纪律,时刻保证代码和建模的一致性。最后需要建立分层的测试机制,特别是对Domain层逻辑的守护。

和前两点相比,这真是一个需要全队刻意练习的过程,坚持信念是团队走过开始阵痛期的必要条件。

刻意“失败”

之前在辅导团队的时候,一个常见问题就是团队纠结于一个业务概念建模采用Entity,还是VO。经常会听到团队说:“从现在的需求来看,VO应该是完全够用了,但很显然接下来我们马上就需要有业务状态的变化,很可能VO就没法玩了。”

针对这样的问题,我往往会刻意引导团队从简单的VO建模入手,先不要考虑“未来”的需求,即使有时候这些需求已经相当明确。这样的刻意行为显然会造成团队在接下来的时间里改变模型,VO可能会被重新建模成Entity。短时间有可能是痛苦的,很多技术人员也会跳起来说,你这是“站着说话不腰疼”。

但DDD的核心就在于持续的演进,演进就意味着模型和实现的改变。这样的改变和上面我们刻意安排的“失败”其实是一致的。当我们通过这样的刻意练习获取了演进的经验后,业务和架构未来的变化对我们来说就真的可以by experience了。

写在最后

开篇我就提到了一个新的架构时代正在浮现,不同于之前的架构方法,没有一个组织和企业会在这个时代告诉你这就是做架构的正确方式。数字化时代的系统和应用在不停进化着,速度越来越快,想要找到进化过程中正确的元方法是非常困难的。

DDD的终极大招By Experience某种意义上是在持续探索,并要求大家接受在这个探索过程中的不确定性 —— 你的设计有可能在未来被证明是错误的。这可能是未来架构设计最大的挑战,我们必须能够让架构持续演进。

《演进式架构》已于今年问世,带给我们很多这些方面的思考,类比人类社会的演进,数字化世界的构建和发展应该有很多地方可以借鉴和学习。当然就这个问题而言,不管是DDD,还是Microservices,都只是我们探索架构演进的开始,我们还有很多的Experience需要获取!


更多精彩洞见,请关注微信公众号:思特沃克

Share

讨论微服务之前,你知道微服务的 4 个定义吗?

关于“什么是微服务”的问题,其实并没有一个统一的认识。这些年在不同的场合里和不同背景的朋友都在探讨微服务。但聊得越多,越发现大家聊的不是同一回事。和 DevOps 一样,“微服务”也是一个内涵十分广泛的词。本文从“Microservice“这个概念的源头出发,总结了 4 个常用的微服务定义。

James Lewis 原始版的微服务 6 大特征

这个版本起源于2012年,这里首先要注意年份,那时候还没有 Docker,而且 Netflix 的微服务化过程也在这个概念提出之前——2008年就开始了,那时候甚至连 DevOps 还没发明出来。James Lewis 在波兰第 33 次 Degree in Kraków 会议上分享了一个案例,名称是 “Micro Services – Java, the Unix Way”。在这个分享里, James Lewis 分享了在 2011 年中参与的一个项目中所采用的一系列实践,以 UNIX 的哲学重新看待企业级 Java 应用程序,并且把其中的一部分称之为“ Micro-Services ”。

这个时候的微服务所用的单词和我们现在所用的 Microservices 这个单词有所不同。一方面,采用 Micro 作为形容词,是和 Monolithic 相对,而不是和 Macro 相对是源于操作系统这门大学课程。我们知道,现代的操作系统课程都是以 UNIX 作为案例进行讲解的。而这两个单词来自于“微内核”(Micro-Kernel)和“宏内核”(Monolithic kernel)的比较。而非常见的“微观经济学”和“宏观经济学”中的 Micro 和 Macro 两个相对应的单词。

另一方面,服务要以复数形式出现,表示的是一个以上。由于汉语里单复数是同型的,所以我们在翻译的时候会出现问题。因此,“微服务”在作为架构的形式出现的时候,我们会用“微服务架构”称呼。单个的微服务从概念上为了和 SOA 以及其它领域的“服务”有所区分,会以“单个微服务”以示区别。而“微服务”单独拿出来是被看作为一系列技术实践的总称。

在这个分享里,James Lewis将所实践的“微服务架构”总结为 6 大特征:

  1. Small with a single responsibility —— “小到只有单一原则”在这个特征里,关于微服务有多小有两个标准:第一个标准是如果一个类复杂的超过一个开发人员的理解范围,那么它就太大了,需要被继续拆分。第二个标准是:如果它小到可以随时丢弃并重写,而不是继续维护遗留代码,那么它就足够小。这个标准有个很重要的原则就是 Rewrite over Maintain,即“重写胜于维护”。
  2. Containerless and installed as well behaved Unix services —— “去容器化并且作为 Unix Service 安装”在这个特征中,James Lewis 提倡采用 Jetty 这样的工具集成到 Maven 里,可以很方便的调试或者部署,然后打包成一个可执行的 JAR 包并以 UNIX 守护进程的方式在系统启动时执行。特别是在 AWS 这样的公有云环境下,把这样的应用程序和虚拟机实例的初始化脚本结合在一起。使得应用程序的生命周期和虚拟机的生命周期绑定成为一体,由于守护进程在所有 Unix 系统中都是通用的,因此简化整体架构的开发和运维。
  3. Located in different VCS roots ——“分布在不同的版本控制代码库里”在这个特征中,James Lewis 提到了应用程序的分离,他认为一个“微服务”应该完全和另外一个服务实现彻底的隔离,这里当然是指的从开始的代码库就开始隔离了。他同样也要求开发人员看到相似性和抽象,并采用单一的领域来指导开发团队的开发。因此接下来他继续讨论了领域驱动设计领域驱动设计和康威定律的重要性。他认为界限上下文要足够的清晰,但可以有所重合。如果没有办法做到领域之间很清晰,就通过“物理上的手段”——分离不同的团队来做到这一点。这不可避免的带来一些公共代码,但要把这些公共代码作为“库”和“基础设施即代码”来对待,就像你代码中用到的开源软件。并搭建一个 nexus 库来存储那些二进制依赖
  4. Provisioned automatically ——“自动初始化”自动初始化的要点不在于如何自动化,因为不同的应用不同的平台有不同的初始化方式。这里的重点在于管理分布式应用的复杂性。所以对于每个服务,能够采用声明出这些初始化。例如:服务 A,需要一个 负载均衡,并且可以自动扩展。服务 B,也是同样的声明方式。而这些声明可以用基础设施即代码技术很好的管理起来。
  5. Status aware and auto-scaling ——“关注状态和自动扩展”在这里,他认为这些应用应该是能够感知吞吐量的监控指标来自我进行扩展的。对于一个现代的应用而言,这是一个基本的架构性要求,但这需要团队有一定的 DevOps 能力。因为这不光要求开发人员能够让应用无状态化,而且要求基础设施可以及时捕获环境的变化。
  6. They interact via the uniform interface —— “它们通过统一格式的接口进行交互”在这里,James 建议大家采用已经成熟的 HTTP 协议以及标准的媒体类型进行接口交互,而不是采用其它的方式。并且采用HATEOAS(Hypermedia As The Engine Of Application State) 的方式构建 Restful API,使其成为一个超媒体的应用状态引擎。这样就可以将状态和执行过程隔离区分开来,更加容易进行水平扩展。此外,它也构建了一个避免架构孵化的层,可以独立于客户端持续演进。

在总结的时候,它特意提到了 UNIX 哲学。这引用自Doug McIlroy 的一篇采访

Everybody started putting forth the UNIX philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” Those ideas which add up to the tool approach, were there in some unformed way before pipes, but they really came together afterwards. Pipes became the catalyst for this UNIX philosophy. “The tool thing has turned out to be actually successful. With pipes, many programs could work together, and they could work together at a distance.”

从这段话里,我们看到了“微服务架构”和 UNIX 哲学之间的关联:

  1. 职责独立:让多个程序(注意是 Programs 不是 Program)做好一件事。
  2. 统一接口:文本流是统一的接口,每个程序都可以通过统一的接口进行消费。
  3. 公共通信:采用管道(pipe)的方式可以说,微服务架构本身是对 UNIX 哲学在企业级 Java 应用系统中的另一个案例。

可以说,虽然应用场景变了,但 UNIX 分解复杂度的方式和保持简单的理念并未改变。

最后,James Lewis 把上述六点特征变成了一个六边形的业务能力:

Hexagonal Business capabilities composed of: Micro Services that you can Rewrite rather than maintain and which form A Distributed Bounded Context. Deployed as containerless OS services With standardised application protocols and message semantics Which are auto-scaling and designed for failure

翻译过来就是:

微服务可以通过重写而非维护一个分布式的界限上下文,且作为一个无应用容器的操作系统服务部署。并以标准化的应用协议和消息语义,为失败设计且可自动扩展。

Martin Fowler & James Lewis 合作版的微服务 9 大特征

由于在 James Lewis 之后,有很多不同的项目也采用“微服务”作为它们的实践名称。然而,不同项目之间还是存在一些差异的,且每个人都按照自己的方式在实践“微服务”。因此,基于“求同存异”的原则,Jame Lewis 的同事 —— 大名鼎鼎的 Martin Fowler 采用一种归纳的方式来解决这个问题:他认为“定义”是一些“共有的特征”(Common characteristics)。Martin Fowler 继续采用了 James Lewis 对这一系列实践的命名,并且做了修改,使之成为一个单独的名词 —— Microservices。

所以,他将微服务总结为以下9大特征

  1. 通过服务组件化
  2. 围绕业务能力组织
  3. 是产品不是项目
  4. 智能端点和哑管道
  5. 去中心化治理
  6. 去中心化数据管理
  7. 基础设施自动化
  8. 为失效设计
  9. 演进式设计

这 9 大特征的中文版具体内容请参考这里,限于篇幅原因,本文不展开讨论。

我们可以从中看出,Martin Fowler 试图将 James Lewis 的微服务定义进行一般化推广,使其不光可以在不同的语言架构和技术栈上使用。又可以兼顾敏捷、DevOps 等其它技术,成为一个架构的“最佳实践”集合。但这样一组实践本质上并没有太多的创新,只是把我们本身知道的很多架构和设计的原则结合在当前的技术栈上进行了一次整体的组合和应用。

恰逢一系列互联网公司的成功事迹带来的新实践(持续交付、DevOps)和新技术(Docker)在经历了早期实践者(Early Adopter)实践积累后的结果井喷后。这样的最佳实践的集中反应固然得到了技术人员的掌声。然而,这种定义对于妄图采用“微服务架构“的人来说是一个很高的门槛。如果这样的 9 个特征的总结是对”微服务架构“的定义。那么,为了要满足以上的 9 个定义,则需要花费很大的精力来进行改造,而且已经超出了技术升级和企业 IT 部门的职责范围。此外,即便我们知道其中每个特征所带来的收益,但却很难拿出案例和数据去佐证满足这 9 个特征的改造收益。

避开这 9 个特征的概念正交性不谈,即便这 9 个特征可以从既有的结果来回答”什么(What)是微服务“,但却没有给出“为什么(Why)要满足这些特征”和”如何(How)同时满足这些特征”。

如果自己挖的坑填不了,就教给别人来填吧:

Sam Newman 版微服务的两大特征和 7 个原则

同样作为 Martin Fowler 的同事,Sam Newman 在其著作 “Building Microservice”(中文译名为“微服务设计”)的第一章就重新回答了”什么是微服务架构“并回答了”为什么要采用微服务架构“的问题。

Sam Newman 在书中是这么定义微服务的(《微服务设计》的翻译):

微服务就是一些协同工作的小而自治的服务。

Sam Newman 自述的微服务的定义更加简单,包含了两个特征:“小” 和 “自治”。

除了继承 James Lewis 关于微服务应该有多小的描述以外(当然,大小都是基于个人的主观判断),还创造性的用康威定律来约束微服务的大小,即“能否和团队结构相匹配”:如果你的团队维护单个服务很吃力,需要保持团队大小不变的情况下还对维护工作游刃有余,那么这个服务就需要继续被拆分。

而“自治” 则很谨慎的把 Martin Fowler 微服务定义的 9 大特征中的“去中心化”、“独立” 、”松散耦合“等字眼进行了统一。并进一步解释到“一个微服务就是一个独立的实体”。并且从外部,也就是黑盒的角度来看每个符合”自治”的单个微服务所具有的特征,即:

  1. 可以独立部署。
  2. 通过网络通信。
  3. 对消费方的透明。
  4. 尽可能降低耦合,使其自治。

此外,他还采用了更简单的“黄金法则”来判断期”自治性”。即能否修改一个服务并对其部署,且不影响其他任何服务。如果答案是否定的,说明你的微服务还不够”自治“。

从 Sam Newman 的定义中,我们可以推导出“微服务”的几个基本事实:

  1. 微服务架构是一个分布式系统架构。
  2. 微服务是微服务架构的基本单元。
  3. 网络隔离是“必要的”解耦手段。
  4. 微服务的业务功能从概念上是完整的,并符合用户角度的“独立”认知。

简而言之,以上的两个特征的表述主要是将微服务从逻辑架构上和部署架构上都看作是一个正交的原子功能单元。而要做到这一点,则需要而要把整个应用系统正确的建模到这个层次,则需要参考很多的内部外部因素。

此外,为了达到“小”和“自治”的目的,Sam Newman 还总结了 7 条原则用来在实施的时候和具体实践结合,分别是:

  1. 围绕业务概念建模
  2. 接受自动化文化
  3. 隐藏内部实现细节
  4. 让一切都去中心化
  5. 可独立部署
  6. 隔离失败
  7. 高度可观察

可以看出,Sam Newman 把 Martin Fowler 的 9 大特征用更加具体的术语来重新描述,并且从逻辑上处理了 Martin Fowler 微服务 9 大特征中概念重复和不明确的部分,使其更简单和明确并且更加可操作。例如把“去中心化的数据管理” 和 “去中心化治理”合并为“让一切都去中心化”等。

更重要的是,Sam Newman 提出了采用微服务技术的主要好处,告诉了我们“为什么要用微服务”:

  1. 技术异构性:采用更合适的技术栈灵活的处理局部问题。
  2. 弹性:这里的“弹性”是弹性工程学的概念,指的是局部失败会被隔离,使得整体不会失败。
  3. 扩展:可以根据系统的部分组件按需扩展。
  4. 简化部署:这里简化部署不是指的是部署的拓扑结构,而是通过持续的小批量、小范围的部署来降低整体失败的风险。
  5. 与组织结构相匹配:微服务架构可以让组织的团队转化为合适的大小,并采用透明的制度来进行规范和复制。避免团队的人数增长而带来更多的管理层,使组织熵的上涨。
  6. 可组合性:由于各个微服务间不存在依赖关系,所以可以根据用户界面的情况进行灵活的调整和复用,避免对单体应用进行整体的大规模调整。
  7. 对可替代性的优化:由于风险和领域更加独立和隔离。因此,抛弃一个微服务并重写的成本并就变的十分低廉。

Chris Richardson 的“微服务架构模式”

2017 年,Chris Richardson 使用 Microservices.io 域名开始推广自己的微服务理念。他是这样定义微服务的:

Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.

中文翻译过来,大意如下:

微服务,也就是微服务架构。是一种用于把一个应用程序结构化为一个实现业务功能的松散耦合的服务集合的架构风格。 微服务架构使得在大型、复杂的应用程序中实现持续交付和持续部署成为可能。它使得组织可以演进自己的技术栈。

在 Chris Richardson 采用了较为简单的架构定义和准确的目标定义相结合的方式来定义”微服务架构“:它一方面简单的把微服务架构定义成一个实现业务功能的松散耦合的服务集合,另一方面又以十分具体的目标和结果(持续交付/持续集成)来约束这样一个松散耦合系统的效果:组织可以演进自己的技术栈。

Chris Richardson 将“单体架构”和“微服务架构”看做两种架构模式。并且在同样的上下文中对二者各自的优劣进行了比较。更加重要的是,Chris Richardson 采用 AFK 扩展立方来拆分微服务从而回答了“如何做微服务”的问题。

值得注意的是,Chris Richardson 所采用的例子虽然在同样的上下文中,但由于特征不同并不具备可比较性。因此,他采用了在“单体架构模式”(Pattern: Monolithic Architecture)的基础上描述其局限性的方法引出了“微服务架构模式”(Pattern: Microservice Architecture)。严格的说,Chris Richardson 的“单体架构模式”是一种对现状的和举例,并没有给出其特征和方法的描述,因此不能称之为模式。而“微服务架构模式”则又是一系列模式的总和,如下图所示:

从这个角度看,Chris Richardson 的这些模式并没有突破 Sam Newman 在《微服务设计》中总结出的实践。但相较于我们所知道的微服务的优点。Chris Richardson 也列出了微服务的缺点:

  1. 开发者的 IDE 对分布式系统的在线开发和调试相对于单体应用架构来说并不友好。
  2. 测试更加困难。
  3. 开发者必须实现跨服务的通信机制。
  4. 不采用分布式事务来跨服务构建业务是十分困难的。
  5. 需要进行跨团队的协调工作。
  6. 部署更加复杂。
  7. 更多的内存消费,对于 Java 应用来说,独立的部署意味着无法共享 JVM 的内存管理。

相较于之前的微服务定义而言, Chris Richardson 的微服务体系比较完整,而不仅仅是总结和列举实践。Chris Richardson 的”微服务架构模式”不光回答了“什么是(What)微服务”,也回答了“为什么(Why)要用微服务”,“什么时候(When)用微服务”,“什么场景(Where)下”以及“如何(How)实现微服务”的问题。

Chris Richardson 还编写了一套微服务的指南,可以在这里查看。

比“什么是微服务”更重要的事

本文总结了微服务常见的 4 个定义。但比这些定义更重要的是你为什么要用微服务?你想从微服务中获得什么益处?你是否了解为了追求这些益处所带来的代价?如果不先明确这些问题,在不理解微服务架构或者技术所带来的的风险和成本。盲目的采用所谓的微服务,可能带来的结果并不理想。

不过,在讨论这些问题之前,坐下来统一一下对微服务的理解,会提升我们讨论和实践微服务的效率。


更多精彩洞见,请关注微信公众号:思特沃克

Share

银行组织的敏捷落地

年初在一篇文章《银行IT的敏捷转身》中谈了银行IT普遍面临的敏捷转型问题,主要聚焦于这个数字化时代,银行IT从过去的成本中心,走向科技能力中心的困惑和挑战,文中我指出了敏捷转型绝对不是IT一个部门的事情。可喜的是在这半年的时间里,我们看到越来越多的银行从数字化战略的角度开始整体规划敏捷转型,把敏捷作为迈向数字化的一个坚实基础来抓。

在经历了几家银行大刀阔斧的改革后,我希望能够把敏捷落地这个话题放到银行整个组织下来跟大家分享几点心得,借机提醒正在高歌猛进的组织不要忘了初心,也为正在规划转型的组织提供一些前车之鉴。 利用敏捷宣言的模式,我总结了四个方面:

  • 敏捷文化 over 敏捷开发
  • 实验探索 over 创新项目
  • 平台思维 over 微服务架构
  • 员工体验 over 开放办公

我们应该都意识到了排比句的右手边是这个数字化时代敏捷落地的一些核心领域,但我希望通过这样的对比,强调组织级敏捷落地中左手边领域的重要性。在下文中我将逐一展开这四个对比,帮助大家理解转型过程中的一些核心关注点。(点击此处或扫描二维码观看视频回放)

敏捷文化 over 敏捷开发

金融是一个强监管和强合规的行业,在中美贸易战和P2P暴雷遗患未除的当下,监管肯定是不会松绑的。某种意义上这是合理的,有多少客户能够接受自己在四大行买的现金理财产品出现了本金亏损(即使购买时风险已经告知)?如果这种情况出现在我父母身上,他们有可能就报警了。

这样的行业管理模式下必然驱动出统一、标准化的服务(产品)开发过程及方法,以及随之配套的企业文化。在面对不确定性市场时,这样的方法和文化的弊端被放大了,没有办法快速响应变化,更无法激发创新。这是大多数银行开始走向敏捷的原罪。

经过最近20年的演进,敏捷(软件)开发实际上已经有了一套比较体系化的方法。Scrum、Kanban及XP的实践都得到了广泛应用,在《ThoughtWorks的敏捷开发》一文中我也总结了这10多年来ThoughtWorks全球形成的敏捷开发方法的体系构建及关键实践。

那么银行作为一个组织的敏捷转型,是否就是要把过去的开发过程和方法,转变成上面提到的敏捷方法,并形成自己组织内部的统一实践呢?答案自然不是。我们要解决的原始问题是如何建立对市场变化的快速响应,并能够激发组织内部的创新。我们的目标并不是要用一套大一统的“敏捷方法”来取代过去的传统方法,我们需要的是组织文化上的敏捷性,能够持续学习和改善。

就中国的大多数银行来讲,这意味着可能有多种软件开发过程和方法,甚至于在一些传统核心应用里仍然使用瀑布过程作为流程主干。当然这里并不是预定解决方案就是“双模”,从银行自身业务发展出发,谁说不可以“三模”、“四模”呢?

经过四年多的实践,某大型国有银行软件开发中心就形成了三种敏捷开发模式(开发敏捷、全流程敏捷和端到端敏捷),为中后台团队、网络金融和互联网创新分别提供了实践的牵引。如果从教条主义出发这是值得批判的,为啥不全都是端到端敏捷?但从现实的行业和企业生存环境出发,这样的敏捷落地是务实的。四年时间里我见证了该组织员工敏捷认知上的持续进步,在强监管的约束下,通过多种模式创造了时代需要的组织灵活性。从这一点出发,这样的做法和大刀阔斧的组织变革同样值得尊敬。

我们需要拥抱变化和持续改进的敏捷文化,而不是所有产品整齐划一的“敏捷”开发模式。

实验探索 over 创新项目

由于FinTech的冲击,各大银行纷纷启动了创新机制,有的甚至成立了单独的创新中心。科技创新在银行业成了最为重要的企业战略话题,各家银行的网点里目前都已经摆满了全自助的柜员服务机,有的大堂里已经开始有服务机器人在主动迎宾。

创新同样是敏捷落地过程中一个不可避免的问题,甚至在不少银行成为发起敏捷转型的原动力。在一家致力于金融科技引领的大型股份制银行的转型过程中,敏捷开发模式成为了FinTech创新项目的必选项。但除了更“快”,大家似乎都没有找到创新和敏捷的必然联系,只是因为希望创新产品快速上市,所以认为必然是敏捷的。

在这家股份制银行的一次FinTech创新项目提案评审会议上,CIO的一个问题触动了我的思考。在各个创新团队争相汇报自己的创新产品取得的成果后,CIO停顿了几秒钟,说到:“我希望大家以后不要每次都出来讲自己的创新如何成功,取得了如何的成绩。我希望大家都讲讲自己在创新的过程中遇到了什么问题,通过用户实验验证了哪些错误的假设,并谈谈怎么改进的。”

是啊,既然是创新,那就是在实验,而实验失败应该是十之八九的事情吧。如果永远都是成功,可能如这位CIO接下来点评的:“大家都没有创新,只是在延续已有业务而已。”而接受实验失败,并把失败作为一次重要的学习机会,在目前银行业里仍然十分少见。没有这样的试错文化,可能下一个“支付宝”仍然不会出现在现有的银行体系里。

我们需要通过科学实验来验证业务想法,而不是制造一堆只能成功的“创新”项目。

平台思维 over 微服务架构

金融服务已经完全依赖于数字化渠道了,各家银行都意识到了IT系统的重要性,拼命加大科技方面的投入。由于很多互联网企业的示范作用,微服务化架构也进入了银行科技的愿景里,期待着云时代能够通过微服务构建灵活的系统架构,从而能够支撑新服务和产品的高效敏捷开发。

于是很多银行都开始拿出不同的应用进行微服务改造,希望通过试点建立自身微服务架构的能力,逐步让更多的应用“微服务化”。国内银行显然没有时间等着一个一个应用的试点,于是往往会挑选不同业务领域(如零售和对公)的应用同时进行改造。然而,完成微服务拆分后,根本没有人会跨业务的审视大家在服务层面是否有共性需求,我们希望的复用性自然也就不会发生。这些服务未来可能也仅仅是一个应用改造后的“模块”,而不是真正为多项业务持续使用的“活着”的服务。

在此基础上,不可避免的需要构建一套微服务开发框架,直接采用开源框架对于银行来说还是很难满足其监管要求的。在设计和开发这个框架的过程中,我们最常听到的就是如何能够把各种服务管理述求(从注册到安全)都植入到框架里。这是一个似曾相识的故事,结局可能是一个复杂难懂的框架,看似开发工作量(代码行数)少了,但却给开发人员带来了痛苦的体验,以至于一有机会大家都会想办法绕过框架。

这些问题的解决必须依赖于我们思想观念的转变,新的平台思维是我们需要去拥抱的。我们这谈的并非是阿里提出的中台,而是从过去软件应用框架平台到数字化能力平台的转变,这个转变带来了三个方面的显著变化:

平台的“客户”是我们的开发人员。这里的开发人员是广义的,比如在数据分析领域,未来的银行业务人员也是开发人员。这个能力平台必须要关注开发人员,即客户的体验!

平台是持续演进的“活体”。平台上每种能力都为不同的业务应用提供着支撑,并且是持续完善的。我们不会像过去应用框架开发一样集各种述求于一身,设计就需要大半年。

平台是自服务的。开发人员不需要读上百页的技术文档,或demo项目来理解怎么使用平台能力。感谢互联网,已经为我们做出了这样的表率。

我们需要一个能够持续积淀的数字化能力平台,而不是一堆各自为战的微服务。

员工体验 over 开放办公

我经常玩笑说组织转型有两个非常好的破旧立新的契机:一是组织结构的调整,二是办公室重新装修。后者毫无意外已经成为了银行组织敏捷转型过程中的常规武器,通过打造不一样的工作环境,来促进员工之间更多的沟通和交流。

在敏捷倡导的协作和信任模式下,大部分重新装修都会选择开放式办公环境,即每个员工不再有自己的小格子间,甚至不会有自己的固定工位。这样的好处自然是我们可以更方便地让一个团队的员工们坐到一起,形成更紧密的团队协作氛围。

多年的顾问工作让我习惯了“居无定所”,每次走到客户的开放办公环境自然感觉非常适应。但也有那么几次走入新装修的彩色环境时感觉莫名的不快,所谓的开放办公桌比之前的格子间更为拥挤了,桌上一个显示器挨着一个显示器。整个场地没有几个会议室,都摆满了长条桌,团队站会都显得非常局促。这让我想起了多年前一家创业企业负责人在参观了ThoughtWorks北京办公室后跟我说的一句玩笑话:“这样的开放布局不错,单位面积里能多坐不少人,还能时刻监视每个人!”搞得我忙解释,其实我们的人均员工空间是行业普遍水平的一倍多,并且也没有人会去监视别人。

(你听说的开放办公 vs 你经历的开放办公)

这样假借开放之名来“提高”场地利用率的情况现在也正在发生着。值得提醒有类似考虑的管理者,别忘了选择开放环境的初心。我们在给团队提供更紧密协作空间的同时,也需要考虑团队的私密空间,这要求不同团队之间有一定的空间隔离,也要求足够的会议室来支撑时常需要进行的小范围协作会议。开放空间的设计不是在大平桌上整齐地排列一台挨着一台的电脑和显示器,而是更加全面的思考团队沟通协作的需求,更多的可视化空间及移动办公设施。

而这一切都是为了更好的团队和员工体验,让大家能够在安全放松的环境下去思考和碰撞,从而能够激活整个组织,创建生机型文化。借用西方管理哲学里常用的一句话:只有愉快的员工,才会有愉快的客户!

我们需要一个能够让员工感到安全和放松的团队工作环境,而不是一个为了提升利用率而拥挤不堪的“开放”场地。

银行组织的敏捷落地正在发生着,文中四点显然无法涵盖转型工作的方方面面。如开篇讲到的,我希望在帮助银行数字化转型的过程中,持续把自己的经历和观察总结分享出来,促进我们的银行业在数字化的进程中变得更加开放,从而能够碰撞出真正的创新。

Share

Lightweight Architecture Decision Records | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第一篇,Blip是Lightweight Architecture Decision Records

位置

2018年5月第18期技术雷达,技术象限,建议试验

目标受众:

  • 系统架构师,技术管理者,开发设计人员

关注问题:

  • 传统的重文档编写维护量大,随着业务发展,很难保持同步
  • 在一些敏捷项目中,随着关键文档的缺失、项目Knowledge及决策丢失导致长生命周期的项目知识传递问题

解决方案:

  • 使用“ Lightweight Architecture Decision Records”(轻量级架构决策记录)来记录项目的重要决策,并将其与代码等其他项目资产一样,纳入到版本控制系统之中。

解读:

“项目要不要写文档”一直是一个很有争议的问题。在过去,项目一般都要写众多的文档,类似于需求说明书、概要设计、详细设计、数据库设计、等balabala设计……而这些文档的作用往往只是为了【过评审】或是【招投标】,写文档的形式也更多是简单的复制粘贴。

项目拿下了,过审了,一旦开动起来,文档反而就被束之高阁,再也无人过问了。

很多人没日没夜地写着千篇一律的文档、文档、文档……终于有一天,盼来了敏捷,并看到了敏捷宣言中硕大的一句:

(敏捷宣言)

唉呀妈呀,终于见到了亲人,从此高举着敏捷的大旗,与文档势不两立。

再有人敢提起写文档,就把早已准备好的“敏捷大棒”从身后掏出来,劈头就是一棒槌……

不得不说,敏捷又一次背了口黑锅。敏捷宣言所推崇的并不是简单的不写文档,而是认为之前那种写文档的方式根本没有体现出其应有的价值。还 不如代码写的漂亮些,测试写的完备些,让代码和测试成为真正有价值的活文档。

而这,相对于简单的复制粘贴攒文档,对于团队的要求反而更高了。

世间万物,物极必反。

随着时间的推移,再好的敏捷团队也会出现知识流失的问题,尽管有着完备的测试和易读的代码,但这些毕竟过于细节,无法快速还原当时设计或重构时的所有上下文。

所以技术雷达推荐使用“ Lightweight Architecture Decision Records”来记录项目的重要决策,相比于传统文档,它最大的特点就是轻量(Lightweight),关注于创造价值而不是遵循流程。 让我们看个ADR的模板:

(ADR Template)

同时技术雷达也建议我们不要将ADR束之高阁、放到Wiki或是文档库中。而是随着代码放到Git或其他版本控制工具里,这样既可以保持最大程度与代码同步,又能跟踪Decision的变更历史。

推荐的Adr-Tools工具,可以帮助我们更容易的做到这些。

相关Blip及延展阅读:

工具:

GitHub – npryce/adr-tools: Command-line tools for working with Architecture Decision Records

Share