团队敏捷转型的三个阶段

在国内做咨询的这段时间里,前后帮助三个客户,在数十个团队做敏捷转型。在这个过程中,见到了不同思想的团队Leader,也遇到了能力参差不齐的团队成员,他们都面临着共同的问题:一方面有着自上而下的压力,却缺乏视野和自学能力,不知道自己究竟应该做什么;另一方面,敏捷的定义模糊且众说纷纭,自己又缺乏自主的独立思考能力,对怎么才算敏捷转型成功充满疑惑。

在国内做咨询的这段时间里,前后帮助三个客户,在数十个团队做敏捷转型。在这个过程中,见到了不同思想的团队Leader,也遇到了能力参差不齐的团队成员,他们都面临着共同的问题:一方面有着自上而下的压力,却缺乏视野和自学能力,不知道自己究竟应该做什么;另一方面,敏捷的定义模糊且众说纷纭,自己又缺乏自主的独立思考能力,对怎么才算敏捷转型成功充满疑惑。

在被客户无数次的问及以上问题后,我自己也感到疑惑,因为即使在ThoughtWorks内部,这也没有标准答案,甚至我在面对不同客户时,会根据当前的目标产生不同的答案。因此我一直在不断思考一个问题:当下一个客户再问我类似问题的时候,我能不能有一个更明确,更体系化的答案。在和工作在各业务的同事交流后,我得到了一些答案,在此先做一些整理,分享给大家,期望引发后续的讨论。

团队敏捷转型的三个阶段

我们假设,敏捷转型的开始是瀑布式开发,我把这个阶段定义为Agile 0,根据我们的敏捷成熟度模型(AMM)里提及的最终形态定义为Agile 5,期间会经历三个阶段。

阶段一(Agile 0 – 1):建立敏捷流程,缩短交付周期

这个阶段,引入迭代或者建立看板是重点,类似于下图:

(Scrum运作全景图)

这个阶段的主要目标,就是将需求的反馈、开发质量的反馈、以及改进周期缩短在一个迭代内(通常2-4周)。 为达到目的,Coach主要会做以下一些事(Actions):

  • 培训 – 给团队培训敏捷流程、各角色的职责,以及各种工具的使用(比如Jira)。
  • 现场指导 – 先带领团队走完整的敏捷流程,通常会有几个迭代;然后观察团队自己执行流程,并帮助团队改进;最后不再参与这类活动。
  • 需求梳理 – 指导PO和BA建立需求全景图(比如Story Map)、拆分Story、排优先级、和团队其他成员协作等;制定Story编写规范,Story价值流和建立Story看板。

这个阶段主要培养的目标,是Scrum Master或者类似的角色,让他们能了解敏捷流程的运作方式,并能带领团队在Coach不在场的情况下,依然按敏捷流程运作。

要走过这个阶段,有一些关键指标:

  • 交付周期 <= 3周:如果是迭代开发,则应该每个迭代小于3周,并且每个迭代都Release;如果是用Kanban,则Story的Lead Time应该小于3周。
  • 上线的已知缺陷数 = 0:有些企业会给缺陷分级,只要求把高优先级的修复,但是我们推动敏捷,要求质量不可妥协,因此需要转变客户的想法,让客户把缺陷修复放到高优先级。
  • Finish Rate / WIP:如果是迭代开发,为了改变瀑布式开发硬塞需求的习惯,一定要控制Finish Rate大于80%。如果是看板,那就要控制到WIP,让每个人专注于一件事的完成。

有些人说为什么不从技术实践开始?设想一下在瀑布式开发中,开发团队几周甚至一个月才交一次版本给测试团队,在这种情况下,开发怎么会有动力写自动化测试?运维怎么会有动力做自动部署?需求没有妥协的空间,设计没有妥协的空间,导致团队的痛点永远是按时交付,质量一定会被牺牲掉的。因此只有先强制缩短交付周期,让团队痛点转移,才能改变开发人员对质量的观念。至于这个过程中导致的交付速率降低,我们会说:

  • 在敏捷转型前期一定是有所付出的,然而你投入越多,进展就会越快,收益就会来的越早。
  • 没有质量的交付不能称为完成,只能叫半成品或者次品。

由此我们来讨论第二阶段

阶段二(Agile 1 – 3):引入技术实践,质量内建,减少返工

这个阶段的主要目标,是提升开发人员的质量意识,从而提升开发阶段产出的质量水平,减少后续环节的返工。用质量内建的话来说,在缺陷时就立刻修复。这样做的好处就是同时提高了质量和团队整体效率。 其实在软件开发中,生产过程随着开发结束而结束,随之而来的都是检查和传递,因此产品的质量实际是由开发阶段就确定的,如下图:

(Story的生命周期)

只有提升生产过程的质量,才能减少返工,提高效率,因此我们在这个阶段会引入技术实践,缩短质量验证的反馈周期,主要包括:

  • 单元测试:单元测试的反馈周期最快,也在测试金字塔的最底层。要求开发人员编写单元测试,一方面可以提升开发人员的代码设计能力,提升代码质量,另一方面可以提升开发人员的质量主人翁意识,让开发阶段的交付物质量有所提高。
  • 集成测试:包括API测试和组建测试、契约测试等。这依然是要求开发人员来编写,提高开发人员的能力和意识。
  • UI自动化测试:如果是带页面的项目,这个阶段通常都会引入UI测试,一般会要求测试人员编写,这个阶段的主要作用是帮助团队提高回归测试的效率。
  • CI:通过CI服务器,将以上测试定期运行,并可视化报告,让所有团队看到。同时要求团队第一时间修复CI。
  • CD Pipeline:建立自动部署流水线到生产环境,并集成冒烟测试,E2E测试等自动化测试,同时实现回滚。
  • Git:建立使用Git的规范,建立分支策略或者指导客户做纯主干开发,培训客户使用GIT高级功能,同时解决一些疑难杂症。
  • Operation相关技术:指导客户实践蓝绿部署、云和容器、金丝雀发布等。帮助客户设计更好的部署架构和技术架构,同时帮助客户架构师做更好的决策。

这个阶段培养的主要目标就是开发,建立开发的质量意识,帮助开发写出更好的开发,培养开发处理复杂问题的能力。同时开阔团队视野,让团队成员了解更多的技术,学习如何利用新技术提升自己效率。

除了第一阶段的指标继续改进外,这个阶段我们会重点关注的一些指标:

CI相关指标:做CI的背后其实是为了培养团队能力

  • CI触发频率 > 开发人员个数:确保开发人员每天每人有提交。
  • CI通过率 > 80%:确保开发人员在提交代码前做了本地自检。
  • 最近一周内的CI修复时长 < 8h:确定团队对CI有足够的关注,没有CI红过夜。

质量相关指标:

  • 一次通过率 > 80%(或者迭代手动Test的缺陷数接近于0):Story开发完成后,会对完成的功能做一轮手动测试。这时得到的缺陷数,代表了开发阶段的质量,缺陷数越少,说明开发人员的自动化测试和CI做的越好。一次通过率可以作为更高的要求,因为包括了后续的测试环境和生产环境中,产生问题的返工。
  • 单元测试覆盖率 > 80%(大家不要纠结为啥是80%,你也可以改成79%,或者100%):首先要确保单元测试的数量在持续增加,同时要有Code Review的机制来保证单元测试的质量。另外,如果覆盖率造假,那一次通过率一定不会得到改善。
  • 测试金字塔:收集各层测试的数据,并关注是否是一个良好的金字塔,给个参考比例1:2:7。这里需要特别关注的一点,如果发现顶层测试数量太多,通常说明开发人员对自动化测试的关注不足,需要加大对单元测试和集成测试的推广力度。

交付相关指标:

  • CD Pipeline的Cycle time < 1h:这个一定要严格控制,假设一个团队有8个开发,每人每天提交一次,那一天至少提交8次,如果Pipeline跑的太慢,就会影响到大家的代码提交。当然,你也可以把这个时间要求减少,只是我的经验里,有些部署环境复杂、UI测试写的有点多的团队中,1h完成已经是一件非常难的事了。
  • 一个月内 Product Incident <= 1:差不多就是1年小于10个的标准,这个数字可以根据不同行业有不同要求,银行业通常会更严格,而创新互联网企业对线上事故的容忍度会更高。
  • 其他SLA指标:比如服务可用率、响应速度、负载等,这些指标关系到的是部署架构和技术架构的设计和实现。

这个阶段会耗时比较长,因此会有两阶的跨度,第一阶是起步,往往会有教练带着团队做重构,写自动化测试Demo,定规范和总结最佳实践。到第二阶后,这些能力就由团队自己去传播了,教练只会偶尔参加一下Code Review来看看团队是否走在正确的路上。

小结:

总的来看,以上两阶段就是帮助客户建立流程,定义参与角色并找到适合的工具,然后通过度量追踪整个转型过程,并逐步引入敏捷实践来提升相关指标。

(敏捷转型内容示意图)

阶段三(Agile 3 – 5):提升价值交付效率和响应力

到Agile 3为止,我们一直在告诉客户你要做什么,通过改变客户团队成员的行为,来改变他们的思想,特别是开发人员的质量意识和团队成员的能力。基于已有的成果,这个阶段的目标,就是培养成员的自我提升意识,团队的自我改善能力,并帮助团队建立自我改进的习惯。

因为团队专注于自我改进,因此大家会有自己的改进线路,不过无论如何,都会专注于以下几个方面:

  • 更高级的能力建设:能进入这个阶段的团队说明已经具备了支撑快速变化业务的基本能力,因此可以推动更高级的能力建设,比如引入微服务、代码共享、特性团队等(这些能力也能在阶段三之前引入,但是只有在有了阶段二的基础后,才能真正做好)。
  • 以Coaching为主:我们Teaching的内容会变少,Coaching的内容会变多,会让客户自己组织更多的分享,鼓励客户自学,并建立学习型文化。我们会和一些关键人物定期的做交流沟通,来帮助他们解决他们所面临的问题。
  • 与业务走的更近:团队可以更好的理解业务,同时能给业务提供更有价值的建议,因此很多业务在决策早期就会引入技术团队的成员。另外团队也能更好的做出业务想要的东西。 在这个过程中,文化贯穿始末。因为团队能力变强,所以更容易建立业务和技术团队的信任,形成信任文化;因为团队养成了自我改善的习惯,所以更容易形成学习型文化;因为大家有信任、有能力,所以会打破原来的控制型文化,培育出创新型文化。这些文化的建立,能更好的帮助企业在未来保持良好增长。

这个阶段度量的内容会关注在响应力、创新上,这里给些参考:

  • 交付周期 < 5d:这是响应力的象征。
  • 假设验证率:这个指标可以用来考核PO,理论上学到的知识越多,这个数字就会越高。
  • 其他业务指标:这时团队关注的是如何帮业务走向胜利,因此在软件开发时就会大量埋点用于业务分析。

总结

整个转型的过程,其实是行为改变思想,再通过思想影响行为的过程,当团队中的人员能力慢慢提升,思想也在随之改变,所有人都能对什么是正确的事作出更好的判断,继而走向持续改进的道路。所以如果定义团队转型成功,我认为就是帮助团队建立起了一群能自己做持续改进的自组织特性团队。 团队要经历这三个阶段必然是一个漫长的过程,很多钱多气粗的企业一定想知道有没有什么捷径,我的答案是有:敏捷转型的过程就是培养大家能力的过程,既然终点是所有人都拥有很强的能力,那为什么不在一开始就找这样的人来工作呢?

PS:

2005年,作为敏捷方法实践领头羊的ThoughtWorks走入中国,并将敏捷方法论首次引进中国。今天,我们想对中国企业敏捷实施情况做个总结报告,让更多人关注并加入敏捷实施的行列。本调查针对已经实施敏捷的中国企业,了解哪些实践比较普遍,在实施过程中有哪些困难。

我们将在2017年北京TID大会(7月18日)分享第一轮结果,参与填写本调查并留下邮箱的朋友,将会优于业界其他人收到最终报告。


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

Share

敏捷团队的办公室设计

ThoughtWorks武汉办公室的装修花了三个月时间,整个办公室的装修设计体现了很多敏捷的特点,环境布置的目标就是为开展敏捷实践提供最大的方便。

ThoughtWorks旨在打造世界领先的办公环境,通过营造环境最大限度的激发人的潜能,人们可以在此获得自然光,新鲜空气,这有益于成功营造高效的工作环境。办公室内部应该实现色彩、光影、纹理、对比度,以及自然元素(如植物)的均衡,最大限度让人感到舒适——既能满足人们协同合作、专注工作的需求,同时也能让紧张的大脑得到放松。

ThoughtWorks武汉办公室的装修花了三个月时间,整个办公室的装修设计体现了很多敏捷的特点,环境布置的目标就是为开展敏捷实践提供最大的方便。

ThoughtWorks旨在打造世界领先的办公环境,通过营造环境最大限度的激发人的潜能,人们可以在此获得自然光,新鲜空气,这有益于成功营造高效的工作环境。办公室内部应该实现色彩、光影、纹理、对比度,以及自然元素(如植物)的均衡,最大限度让人感到舒适——既能满足人们协同合作、专注工作的需求,同时也能让紧张的大脑得到放松。

武汉办公室的前台包括两部分,前台办公区和前台背后的接待区。

进门右手边的地方放了两组沙发,用来招待临时的客人,比如来面试的候选人,访客。

我们会有意识地培养社区,并专门开辟这样的物理空间,以方便人们进行更多面对面的互动。从前台走进去之后就可以到达社区活动区。从这里也可以看到办公室整体的装修风格是简洁明快的。办公室的社区活动区离前台很近。这样的好处是访客来的时候直接就能到这个区域。同时这个区域也是与主办公区隔离开的,安全性特别好。在社区活动室的站立式办公区,大家可以选择站着办公,也可以选择坐高椅子。

进门是一整面的黑板墙这次的主题是回到童年还有类似拼车的生活信息。除了八卦杂志,“我想听/我想分享的海报也放在了这里供大家交流。在社区活动室也专门放置了乒乓球台和foosball,方便大家在放松的时候增进彼此之间的感情。

在进门的地方和社区活动室都会有超大显示器,展示公司最新会发生的重大事件,比如社区活动的日历、公告等。整个办公室也有几台悬挂的大电视,用于公司宣传片的播放和一些重要通知的推送。

ThoughtWorks,只要有人登高一呼就可以启动一个虚拟团队。在ThoughtWorks其实有很多虚拟团队这个大屏幕上展示的就是这个虚拟团队利用业余时间自发做的系统。团队的名字很有意思17High。大家觉得有必要做一个内部的广告系统广告什么呢比如谁有意愿分享session的时候就会在这个系统中登记登记成功后会在办公室的几个大屏幕上滚动播放这样大家就能随时知道在哪、什么时候、有什么样的session

在公司办公区的墙面上分别装饰了技术雷达和商业洞见。

ThoughtWorks在每年都会出品两期技术雷达,这是一份关于技术趋势的报告,它比起一些我们能在市面上见到的其他各种技术行情和预测报告,更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,比如人工智能和大数据,更有细致到类库和工具的推介和评论。ThoughtWorks最近发布了自己的技术战略2.0(3年前我们发布了技术战略1.0),经过三年的发展,通过我们对业界,学术界和行业的发展,我们认为现在是时候展望更长远的未来。

ThoughtWorks在践行「科技即商业」的过程中,也一直在思考、研究、学习和总结,期望把最新的思考和最有价值的案例汇集起来分享给业界。由此萌发了一个想法:搭建一个平台,能分享我们的经验,并为这一领域的实践者、作者和读者提供一个交流的纽带。这是《ThoughtWorks商业洞见》的由来。

整个办公区域是完全开放式的,方便进行可视化管理,我们设计足够长、足够大、没有挡板和隔断的办公桌,有利于每天的结对编程和code review。

敏捷团队需要很多的沟通,办公区提供随处可见的白板,很多墙壁也是玻璃的,大家有足够的空间进行每日站立会议和进行各种各样的讨论。每个项目组都会配备专用的大屏幕电视或专用显示器,来可视化持续发布和自动化的流程。

我们也会设置由电视、Mac Mini和Skype组成的无间断视频(Always On Video),不仅方便与异地的同事通过视频的形式召开每日站立式会议,而且即使大家相隔千里,也能随时就问题展开讨论。

我们并不希望大家整整八个小时都被束缚在办公桌前。因此,适当地采用分区策略(例如茶水间和放松区这样具有文化敏感性的区域),将有助于人们在需要时补充能量和恢复精力。

类似这样的公共区域,都是开放性的,比如休息区、茶水间、打印机等,没有任何物理边界,一方面是方便各个区域的人的到达,另外是形成汇聚点,成为人们的交流场所,这样大家路过的时候就能够随时打个招呼聊上几句。

会议室相对团队空间来说,私密性会强一些,因此我们特地预留了一些小的quite room。敏捷团队的会议室的白板的面积应该尽量的大,画不下要擦掉会影响思路,我们将整面墙都做成白板。

整个会议室的命名采用:区域+星系。我们之所以要给会议室起不同的名字,不是为了fancy,而是为了让我们所有人在一起工作的过程中有值得记忆的事情!当多年以后,我们依然记得在某个会议室的点滴瞬间:比如为了某段代码的争论,为了某个上线的开心,为了生日的庆祝,或者为了一些事情的伤感。

会议室的门和墙做成了透明的,同时为了兼顾隐私,在玻璃中间贴一层磨砂纸,同时保障私密和透明。很多项目也利用这块空间做成物理看板,每天的站会就在这里进行。

整个工作区域设有2个people room,以舒适沙发取代会议桌椅,大家可以在里面更加随意的聊天或者休息。另外有一个专用的母婴室,方便怀孕期和哺乳期的女性员工,武汉办公室的女性员工比例超过40%。值得一提的是ThoughtWorks凭借在全球范围利用软件技术推动社会和经济公正的多年实践,和包括Google、Facebook在内的其他24家美国组织荣登2016年最佳女性科技人员雇主领导力指数榜单,并力压群雄最终摘得“2016最佳女性科技人员雇主”桂冠。

武汉办公室欢迎大家!


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

Share

基于GitHub的敏捷学习方法之道与术

首先,让我们从需求出发,从市面上来寻找一款符合敏捷的学习软件,别想了,当然是没有的。对于一名程序猿来说,最理想的答案其实就是 GitHub,作为全球最大的程序猿(交友)网站,GitHub 本身以及围绕 GitHub 的各种插件使得其项目管理能力远比你所能想象的厉害得多。

持续行动,持续反思,持续进步。—— via. 敏捷学习宣言

前言

对时间的敬畏

需要好多年才能懂得,最好不是去震惊世界,而是要像易卜生所说的,生活在世界上。

我们都一样,渴望着建树功勋、改变世界。可是伴随着年岁的增长,却发现梦想仍旧遥远,而时间却依然残酷的流逝着,不会仅仅因为「你」而发生丝毫的改变。如《奇特的一生》当中所言,我对时间始终充满着敬畏之心,最好的方式也不过是奢求时间能够跟自己做朋友,伴随着我这也许注定朴实无华的一生,共同成长。

在我们一生所能做的事情里,睡眠占去 1/3,此生只剩 2/3,除去非做不可的基本生活维护成本之外,剩下的时间要么选择浪费而荒度此生,要么瞄准目标而奋力向前,让这一生不留遗憾。Follow your heart,你需要找到一些愿意为其付诸终身的「目标」,以这样的姿态「生活在这世界上」。

敏捷与个人成长

就像软件开发一样,一个人的成长也应该有自己的方法论。人的一生若是顺风顺水、一成不变,那未免太无趣了,正是由于世界的未知在等着我们去探索,不一样的经历才会让人感到惊喜和有趣。想做的事情永远都不会嫌多,就像柳比歇夫最开始是研究生物学的,却在科学的道路上越走越远,进而研究起了数学、物理、哲学,甚至于美学,而更关键的是,他在每一方面都做出了很大贡献并且留下了诸多著作。

时间充当着 Product Owner 的角色在不断向你提出各种各样的需求,敏捷当中最重要的一大前提就是「拥抱变化」,而在「记录时间这件小事儿」里面我提到的GTD流程便可以用于处理这源源不断的需求,即收集、整理、执行、回顾,对应到敏捷当中的几大会议,显然也可以由个人完成,自己就是自己的 IM & PM,当然也是 BA & Dev & QA(当然不用担心人格分裂)。

实践之术

我都没想到怎么写着写着就把开头写成了鸡汤文。但是咧,如果前面讲的是「道」,那么接下来就会具体到基于 GitHub 的「术」,即各种实践。

首先,让我们从需求出发,从市面上来寻找一款符合敏捷的学习软件,别想了,当然是没有的。对于一名程序猿来说,最理想的答案其实就是 GitHub,作为全球最大的程序猿(交友)网站,GitHub 本身以及围绕 GitHub 的各种插件使得其项目管理能力远比你所能想象的厉害得多。

  • 收集:需求无时无刻,无处不在,anywhere anytime
  • 整理:as BA,即分析,Elaboration & Estimation & IPM => 确定 MVP & Efforts
  • 执行:as Dev & QA,Developing & Testing & Review/Sign-Off
  • 回顾:Retrospection,Introspection,持续反思,持续进步…

通过 GitHub Issues 收集需求

首先你可以给自己建一个 GitHub 仓库作为主页,比如我的 JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues ,最开始就是从个人博客的主仓库发展而来。那么,如何快速收纳自己的想法呢?以解决问题为导向,就是有什么需求就直接给自己的 repo 建一个 issue 作为 Story Card,了却这个需求的最终形态就是 close 掉这个 Issue,比如我要写这篇文章就始于这个 issue:基于 GitHub 的敏捷学习方法总结 · Issue #36

GitHub issues 的进阶用法

与此同时,新建 issue 还有更高级的用法,也就是通过 ISSUE_TEMPLATE 这样一个模板来新建某个 issue,从而更快地定位问题所在和解析自己的想法,最主要的是能够输出更具体的 TODOs,即下一步行动的具体内容,这个还会在后面详细解释。

  • issue 和 issue 之间是可以通过 # 相互连接,甚至可以跨仓库,被 reference 的 issue 也会出现在另外一边的 issue 里面;
  • 而通过 #! 符号是可以在 comments 里面直接新建一个 issue ,这在思维爆炸的时候来得特别爽快;
  • 你还可以随意艾特你的小伙伴们,互相监督、互相学习或者给出 Constructive Feedback 之类的,😂;
  • 更甚至于,若是在 Intellij 里面关联了 GitHub,就可以在 git commit 信息里面直接看到你所要关联的 issues 列表了。

这种方式仿佛学习中的大脑,神经网络被连通了的感觉。

移动端的解决方案

而在移动端则可以通过 GitDo 这个 App 来轻松新建和管理自己的 Issues,没错,就是有人把 GitHub issues 做成了一个 Todos 类 App,还做得很漂亮功能很完善。只是不知为何这软件最近被下架了,伤感,我就又重新把滴答清单(TickTick)作为自己的万能收集箱了,之后再把比较重要的、需要进一步追踪的事项添加到 GitHub issues 里面来。

整理你的 GitHub Issues

大胆地把 issues 作为你的个人需求列表吧,需要解决的问题可以大到做一个开源项目,或者小到读一本书、写一篇文章。对于比较大的需求,你还可以将其转化为 Epic 然后把拆分过后的小 issues 们加入到这个列表里面来。

而 GitHub (with ZenHub) 强大的 issues 管理能力绝对会让你的迭代工作变得井井有条,使用 GitHub 新出的 Projects 特性或者使用 ZenHub 的 Boards 就可以让你瞬间拥有日常敏捷工作的感觉了吧!

计划与执行具体任务

制定迭代计划

首先,让我们新建一个 Milestone 来制定计划,也就是决定在一个 Iteration 里面你需要完成哪些 issues。在这里我所制定的阶段性计划周期为一个月,当然你也可以勤快一点,以2周作为一个 Iteration,享受一下自己的计划要完成不了、这个 Milestone 就要废了,没法向「时间」这个一生的朋友交付所有需求的快感吧 :)

当然咯,一般我会在月初做计划的时候给自己准备专门的时间来做 Elaboration,把 Backlog 里面的卡拖到 Rethink/Plan 这一列,经过分析和详细输出 TODOs 以及所对应的估点 points 之后便可以将其拖到 Ready For Todo 了,一般我给自己估的点数就是完成这件事情所需要的时间,一小时即对应一个 point。

这样你就可以愉快的选择 Filter Issues by Milestone 专注于当前 Iteration,专注于 In Progress 这一列所要做的事情,并且垂涎于 Ready For Todo 里面将要做的事情,每次做完还可以放到 Review/SignOff,在里面写写对这件事情的总结和感想什么的,每次挪卡都充满了敏捷的仪式感(认真脸)。

进度的把控

GitHub 在 issues 里面直接集成了 Markdown 的 TODO 语法,甚至于可以在渲染过后直接拖动某个 item 进行排序,而且可以在前面的勾选项中直接打勾 ☑️ 标记为完成。不仅如此,完成之后这个 issue 还能直接显示完成进度;前面所提到的 Epic 也能直接显示子 issues 的完成情况即 closed 比例,两者结合起来简直不能再美好。

比如说拿来作为读书列表的记录就很不错,每本书作为一个 issue,还可以把章节划分为具体的 TODOs,结合估点追踪自己看书的进度和速度,顺便在 comments 底下做个笔记也不错啊!

专注当下

ZenHub 还提供了一个基于 GitHub Issues 的 To do List,你可以只关注 Today 这一个列表,专心于当前要完成的任务。而且更有趣的是这个 list 可以加入 GitHub 的任何 issues,也就是说它是全局的,所以你可以加入很多在 GitHub 上通过 issues 写的 blog,比如徐飞的这篇文章流动的数据——使用 RxJS 构造复杂单页应用的数据逻辑 · Issue #38 · xufei/blog,被我加入到了 Reading列表当中。

与此同时我还会使用 Toggl 来记录每个 issue 具体实施的时间,以便于在时间花费上能够获得及时的反馈。这样做会让你真切地感受到时间的流逝,而在回顾记录的时候也能够进行总结分析,从而在下一次的计划当中更精确地预估时间(点数)。比方说这篇文章我估了 5 个点现在已经写了 4.5 hours 了,不过这是另外一个大话题,可以参考 记录时间这件小事儿 这个 issue。

迭代回顾与总结分析

ZenHub 也提供了 Burndown 和 Velocity tracking 图,可以得出这个迭代总体的完成情况,看看跟预期有何不同;也可以跟其他迭代进行对比,看看有何不同的地方,然后进行下一步的具体分析。

还可以根据 GitHub 和 Toggl 里面的数据进行汇总和分析,下面这个表格就是我在 11 月这个迭代完成后一部分 issues 的具体 Estimation Points 和 Time Efforts,再结合 issues 里面所记录下的各种笔记和 references,来得到一个比较直观的总结和复盘。

Number & Description Estimation Points Time Efforts
#85 记录时间这件小事儿 3 04:26:18
#96 如何对时间进行分类? 8 03:00:09
#102 建立个人 Wiki 系统 2 02:53:56
#101 技术雷达宣讲:enzyme 测试框架 5 06:11:19
#90 Working time improvement 1 33:27 min
#97 如何使用 XX 的标签系统? 1 25:21 min
其他辅助工具
  • 看板:as Jira/Trello,可视化当前进度 => GitHub Issues group by @Projects / 日历 in @滴答清单;如果你不想用 ZenHub ,可以试试 Gitlo ,可以在 GitHub issues 和 Trello 之间进行双向同步。
  • 晨间日记/每日回顾:as Stand-Up,只用关注 Timeline/Done/Todo/Blocker 以及当天的心情/天气等等,使用 @格志日记的一个特点就是可以通过问答的方式对一天进行回顾。
  • 时间记录:@时间块的优点在于记录起来非常简单、快捷,是用户评论中最省时间的时间记录工具,没有之一,推荐新手试试。但由于个人需要更加详细的记录细节和报告分析,以及多平台(包括 Chrome Extension)的支持,从而选择了 @Toggl
  • 白噪声:作为一款时间记录工具,@Toggl 本身就支持 Pomodoro 的 25 分钟提示。而作为专注力辅助的白噪声软件我在手机上用的 @潮汐,电脑上则选择了 @Noizio

后话

也许你很喜欢这个解决方案但又不太想公开自己的 issues 列表,那可以试试 GitHub 的 private repo(需要付费),免费的可以试试 GitLab,支持从 GitHub 一键导入,并且已经原生支持了 pipeline 和看板功能。当然,不限于工具或软件,这一套方法论其实是可以运用在任何地方的,甚至于我们可以来做一个结合敏捷方法论的个人学习管理软件也不错。

但是于我而言,选择在 GitHub 这样一个公开环境下记录学习的最大一个动机就在于「开源」,很喜欢一句话,大意是「在这个互联网时代,能限制住学习的只有你的求知欲」。

当你从互联网这个广阔的知识海洋当中汲取知识时,也应当有所输出,即反哺到整个互联网当中去。我会经常写博客/笔记来总结、分享自己的所学,但是一篇文章诞生的背后往往还有很多其他知识和经验的相互交融与沉淀。Issues · JimmyLv/jimmylv.github.io 这个列表里面的某个 issues 最终能否演变成一篇文章我不知道,但是基于 GitHub 开放式的学习历程都会被这些 issues 如实地记录着,任何一个想法都能追本溯源被找出最开始的缘由。

相比于软件开发这件小事儿,健康快乐地成长显然要重要得多。—— 立青


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

Share

提升业务响应力:践与行

过去8年,我们在国内外不同的金融企业里引领了敏捷转型,帮助企业有效提升了业务响应力。在此过程中我们发现,企业转型面临三大典型挑战:业务侧敏捷滞后、以项目为中心的运营结构、一刀切的治理模式。这些挑战,需要管理层深入理解敏捷适应性领导力、以价值驱动业务投资决策、以产品为中心交付、合理采纳“差异化交付模式”,才能最终带领整个组织建立一个“持续创新、高适应力、高绩效“的精益企业。

金融企业转型的三个挑战

从2009年到现在,我们在包括国有商业银行、股份制银行等传统金融企业里做敏捷转型咨询时,为了提升业务响应力,发现他们常常面临一些相似的挑战。

挑战1:业务侧敏捷的滞后

业务部门花好几个月、甚至半年的时间讨论业需求,整理出完备的SRS(软件需求规格说明书),通常是一份厚重的文档,而此时业务部门发现预算所能支撑的软件开发和测试时间已然不多,因此要求开发团队在三个月内开发完成,估计只有一个月用来测试,然后就要上线。更麻烦的是,在开发过程中业务人员发现用户需求在最近已经发生更改,他们必须修改需求规格说明书,而且还非常频繁,开发团队开始抱怨压力太大,测试团队更是热锅上的蚂蚁。

这个场景表现出的一些特征如下:

  • 需求分析过程非常长,常常是好几个月
  • 需求池(产品待办事项列表)常常处于干枯状态,或者是井喷填满
  • 开发和测试团队抱怨时间不够
  • 开发过程中大量需求变更带来很多浪费
  • 发布时间一拖再拖

这个场景中,突出的问题是超长业务决策时间压缩开发测试时间,需求变更成本高。

深入分析来看,是传统金融企业业务侧缺乏一套行之有效的方法用以提升投资决策效率,从而快速将市场需要转化为业务需求,让交付团队开发并及时上线。除此之外,业务人员缺少用户价值驱动的理念和方法,常常凭个人一厢情愿和拍脑袋规划需求,缺失了用户研究和运营数据分析环节,导致浪费。

我们咨询过的传统银行,有几款产品,做了很多功能,但是仅仅百分之几的功能被用户使用,很多功能用户从来没有用过,造成大量浪费,业务人员还要在从来没有使用过的功能上再增加新功能,犹如火上浇油。

在敏捷的浪潮下,交付侧已经有很好的方法论支撑,无论是流程还是技术实践,都可以快速响应,比如Scrum这样的敏捷方法,持续集成和持续交付这样的技术实践。

如何从业务侧改进,做到精益产品开发,快速应对市场变化是一大挑战。

挑战2:项目驱动交付的掣肘

业务侧以项目为中心立项,立项过程需要层层审批,特别是预算部分。有时立项没有及时审批通过,导致隶属于它的需要快速实现的高价值需求被延误,无法及时抓住对应用户。更糟糕的是,产品团队被打散,多个项目并行开发,没有统一的优先级,不能聚焦在高价值功能点上,等开发团队反应过来时,这个需求已经失去价值,无需再开发,延误了商机。

这个场景中,暴露的是关于项目立项的问题。常见的做法是,业务侧根据需求立项,导致项目多如山,每个交付团队同时承担多个项目开发,其后果是:

  1. 超负荷
  2. 流动性差
  3. 交付慢

每个立项还要经过层层漫长审批,特别是预算部分非常敏感。为了减少审批次数,在立项之初,项目管理人员期望把项目范围扩大,使得预算同时变大。当业务人员看到预算增大,把该有的不该有的功能都添加到交付范围内,结果导致交付更慢。更可怕的是,很多功能并没有业务价值。

我们正在负责一个大型全球跨国银行的IT研发中心,常见一个团队十来个人,同步并行的项目有三到四个,两三个人负责一个项目。在开发过程中,交付团队将注意力集中在按时交付项目划定的范围,跟业务部门分离,沟通方式局限于文档和电话,对于业务变更需求抱怨颇多。

以项目为中心交付时,如何优化治理结构和既定流程,为第二个典型挑战。

挑战3:唯“快”不破与核心安全求稳

企业在提升业务响应力过程中,受到互联网行业的冲击和影响,觉得敏捷是一颗银弹,对于后台核心业务开发也花了大量时间来尝试敏捷方式运作。然而核心系统业务需求趋于常规化和周期化,比如存款、利息重新计算等,比较稳定、可预测;其次,因为是核心业务,影响范围深而广,上线前的回归测试周期长,需要特别谨慎不能有任何失误,业务部门求稳胜过高响应力。最后发现应用敏捷方式来提升业务响应力效果并不理想。

这里暴露的问题是没有区别对待不同业务,进而采用不同开发模式。面对移动互联网的迅猛发展及互联网金融的竞争,传统金融企业纷纷提出“移动优先”、“数字优先”等IT战略,以提高响应力和适应性。对于金融行业的新兴业务或者前端系统,比如手机银行、自助服务以及渠道拓展、互联网平台接入等业务,需要对终端用户的需求快速响应,才能扩大用户群体,迅速占领市场。

然而对于金融IT传统的后台核心业务系统,却表现出如下一些特点:

  • 安全性要求极高:国家各种法律法规对于金融系统安全性有严格要求;
  • 稳定性要求极高:必须保证7X24X365的可用性;
  • 需求变更频率不高:比如银行中的存款、清算、结算等核心IT系统;
  • 受限于以上要求,功能常常是集中交付,而非迭代交付。

我们在咨询过程中客户会经常询问一个问题,“我的产品或者项目适合采用敏捷开发吗?”,如上所述的两种业务模式应该如何处理?是应该不加区分全部采用敏捷开发模式吗?这就是在传统金融企业产品研发过程中面临的“快”与“慢”并存之挑战。

以上提到的传统金融企业具备如下一些特点,决定了其业务响应力提升面临上述挑战,要想让“大象灵活的可以跳舞”,实属不易。传统金融企业特点如下:

  • 组织机构庞大,交付团队动辄上万人
  • 组织结构复杂,管理效率低下
  • 产品创新、投资决策流程复杂且低效,很难快速响应市场需求
  • 跨部门协作比较困难,业务、开发、测试、运维分离,“顽固”的职能划分,而且团队物理分散在不同地域
  • 拉通业务端敏捷阻力大,业务人员的意识转变慢
  • 企业IT表现出“慢”、“贵”、“难”等特点

正因为“大象”的特点,要提升其业务响应力困难重重,但并不是没有解决方法。

应对之策

策略1:价值驱动决策撬动业务敏捷

图1: EDGE(价值驱动产品组合管理)提升业务侧响应力

前面谈到,业务侧人员在面对敏捷的交付团队时,如何让自己变得更敏捷?其本质上是如何让业务和产品管理人员聚焦于价值,通过价值驱动决策,快速决定应该投资哪些产品功能,并创建产品待办事项列表用于交付团队开发。

EDGE是ThoughtWorks提出的一套基于组织的愿景和目标进行投资分配和监控的决策系统,立足于寻求企业投资组合管理价值最大化。它使得企业可以快速响应市场机遇,有效的将组织的战略目标与执行能力紧密的联系在一起。通过明确商业愿景、制定产品策略、专题分析和组合管理、制定最小可行产品、精益交付以及持续衡量价值来提升业务响应力。

实施策略和步骤

第一步:对业务管理机制达成共识

给业务人员、业务部门领导和业务线高层宣讲整个EDGE的业务管理机制,并达成共识。

第二步:通过精益价值树规划战略

业务人员邀请业务部门领导和业务线高层,建立精益价值树,从组织层面全局思考业务线商业愿景、目标、机会点以及行动方案。这部分非常重要,笔者在咨询过程中听到过业务人员经常猜测领导的想法,领导的话有时也被曲解,双方并没有以用户为中心。要想让业务部门从高到低所有人就战略达成一致,应当遵循精益价值树,如图2:

图2: EDGE(价值驱动产品组合管理)价值树

需要着重指出的是,精益价值树不是一成不变的。通常采用每季度组织工作坊的方式,根据市场运营的价值反馈对精益价值树进行评审,调整商业目标和后续投资。

第三步:采用可视化方法建立投资组合待办事项列表

将精益价值树中每个目标的愿景、核心价值和机会点可视化,并且对每个专题方案进行分析,输出投资组合待办事项列表,示例如下图3。

图3: 某银行专题分析示例

第四步:建立PVR(Periodic Value Review)评审与决策机制,审核及调整投资组合待办事项列表。

PVR会议由产品经理或产品负责人召集,邀请管理层、相关业务人员、市场、运营和技术专家共同参与,需要做如下事宜:

  • 回顾近期发布专题的用户反馈、运营数据,决策后续演进措施,包括是否需要调整产品策略
  • 产品经理讲解近期新的专题分析,共同讨论决策专题优先级
  • 审视和更新持续三个版本的滚动规划
  • 建议每月至少一次

第五步:通过MVP和滚动版本计划实现产品设计

滚动的版本计划将最高优先级的专题拆分为故事,分别规划到可以交付的版本中,形成持续几个迭代的滚动规划。

到此,就可以将待办事项列表中的用户故事交给交付团队开始迭代开发,进入传统的敏捷交付流程。

策略2:以产品为中心的交付

为了进一步明确这两者的区别,特对比如下:以项目为中心,其核心是以需求立项,带来的主要问题是项目周期长、需求力度大、反馈周期长、多并发项目、团队无节奏,直接结果是无法快速交付对终端用户有价值的产品;相比之下以产品为中心的交付,统筹所有需求、需求力度更小、采用持续滚动计划、团队节奏感更强,从而使得所有成员关注最有价值的高优先功能,持续交付价值。

企业创造产品的目的就是要解决用户或企业自身所面临的问题,因此以产品为中心也就是以解决问题为中心;相反,以项目为中心则是以计划、预算和职能为中心。

图4: 项目为中心交付流程 vs 产品为中心的交付流程

产品为中心的团队组建

虽然提到要“围绕产品组建跨职能团队”,但是传统金融行业的组织结构是典型的职能矩阵式, 业务部门通常在总部,开发、测试、运维部门分离,物理地理位置上也分离,很难做到理想的敏捷团队同地共置,即使是把开发和测试放在一起,也不容易;再加上外包团队,分布式团队更复杂。如何快速解决这种复杂的分布式团队的敏捷协作问题,各大银行纷纷借鉴学习了ThoughtWorks的Always-on工作模式来构建高效的分布式虚拟团队。

图5:Always-on可以帮助分布在不同地点的团队成员虚拟的面对面沟通,及时解决问题。敏捷12条原则中第四条“敏捷在整个项目开发期间,业务人员和开发人员一起工作”,这种Always-on的模式,就是为了实现这个原则。

策略3:差异化交付模式应对“快”与“慢”

差异化交付模式,是一个能够很好应对传统金融行业在“快”与“慢”的挑战下落地敏捷的一个可选方式。所谓“快”,就是变化快,需要快速响应,及时调整;所谓“慢”就是在已经非常熟悉的领域,可预测性强,需求变化慢。下面详细介绍如何使用这种模式实施交付。

差异化交付模式

差异化的交付模式如下图。模式1进行很多内部迭代,上线之前专门有个Launching阶段,与各个依赖之间进行联调测试,以免出现上线前的集成风险。模式 2结合了LSM(Lean Startup Methodology)以及Scrum,对于一个产品的研发包含:产品的Vision设置、概念剖析、MVP发布以及后续的持续迭代交付阶段。

图6: 差异化交付模式

模式1:长迭代与版本火车

不需要频繁的上线发布,而更强调稳定性。因此在每一个版本周期内以小瀑布方式完成计划、设计、开发和测试,并准备发布。开发过程以2到4周为迭代,可以在每个迭代结束时给业务和产品负责人做一次演示,尽早获得反馈;也可以更好的支持敏捷团队尽早开始联调测试。每年固定4或6个版本火车,各产品的版本节奏基于版本火车时间点对齐,利于进行跨产品间集成的协调和共同上线。某国际银行的Core Banking核心后台业务,也希望进行敏捷转型,选择了适合的模式1。

图7:版本火车

模式2:在进入迭代开发之后,就是传统的Scrum流程,迭代开发、持续交付。

差异化互相依赖的协作模式

作为前台系统,经常要与核心中后台系统做对接,差异化的两种模式进度如何匹配?具体实施方式如下:

  • 前后台Scrum团队密切合作,建立Scrum of Scrums机制,定期沟通,互相协调配合,提前规划好依赖日历,明确好先后顺序,并且避免两边需求偏离太远;
  • 从项目第一天开始进行系统集成,及时发现问题;
  • 有时候后台资源不足,这时候采用Mock服务的方式,先保证前台的功能满足业务需求,而后根据中间层的Contract ,作为接口需求,与后台系统集成;
  • 在上线前,后台会有长期的System Test、UAT 时间,这时候前台的开发计划尽量匹配后台的 ST 进行测试,以免出现上线前的集成风险。

图8:差异化交付协作方式

应对之策纵观

所有应对之策结合使用,其全局效果如下:

图9:应对之策全景图

写在最后

诚然,以上应对之策其实施流程不可谓不简单明了。然而,我们发现在过去几年的咨询过程中,企业高层在推动时却面临重重困难、层层阻挠。其本质原因在于,企业在变革过程中,推动变革的中坚力量是中层管理者,大量中间层管理者在企业响应力的提升以及责任承担方面起着举足轻重的作用。

如何撬动中层,确保以上策略落地。从组织级角度,需要提升其敏捷适应性领导力。Jim Highsmith作为敏捷宣言签署人之一提出的“适应性领导力模型”[1],要求管理者专注于如下行动:

  • 提升价值交付速度
  • 充满激情地改进质量
  • 少做:精益思考,交付客户必需的功能和稳定的产品,少即是多
  • 融入员工并持续激励他们

其核心思维转变如下:

  • 适应:从“完美计划以预防变化”转变为“接受变化”是不可避免的,唯一可控的是如何适应变化,拥抱变化
  • 探索:从传统的“计划并执行”模式,转变为设定愿景并持续探索,敢于挑战未知世界,从探索中学习并不断演进解决方案
  • 引导:从传统的“命令进而控制”思维转变为融入员工,引导建立自组织、自我约束的团队
  • 驾驭矛盾:从面临抉择时做“A或B”的选择、择其一个则牺牲其二,转变为处理好矛盾统一体,兼顾“A与B”创造性地提出新的更优解决方案

在合理采用以上策略之后,企业在不断敏捷化的道路上还将面临规模化的挑战。规模化并不是简单的从两三个小团队转到几百个团队的敏捷运作,其范畴更宽,囊括了整个企业的所有职能,包括财务预算、人力资源规划、安全与合规等,其终极目标是打造一个“持续创新的、高适应力、高绩效”的精益企业。

【作者介绍】

张岳,ThoughtWorks高级咨询师,近十年的软件行业从业经验,服务过电信、能源、金融等不同行业的客户,帮助他们交付软件产品、实施精益敏捷转型。

白玉,ThoughtWorks资深精益敏捷教练和高级咨询顾问,在金融、电信和教育行业的软件研发管理、咨询等方面有丰富的经验。

Share

让我们再聊聊TDD 续 – 人人都在做TDD

在上一篇文章里面,通过对DHH的文章以及DHH和Kent Beck等讨论的分析,我阐述了对TDD的理解和分类,现在来继续聊聊TDD的实施和分层。
现在还有非常多的软件工程师在质疑TDD的可行性,比如太难不会、成本太高无法推动、意义不是很大等,但是他们却一直都在做着TDD,只不过没有意识到而已,这便是“不识庐山真面目,只缘身在此山中”。

上一篇文章里面,通过对DHH的文章以及DHH和Kent Beck等讨论的分析,我阐述了对TDD的理解和分类,现在来继续聊聊TDD的实施和分层。

现在还有非常多的软件工程师在质疑TDD的可行性,比如太难不会、成本太高无法推动、意义不是很大等,但是他们却一直都在做着TDD,只不过没有意识到而已,这便是“不识庐山真面目,只缘身在此山中”。

TDD的实施一般分为思维层面和技术层面。一般来说,思维层面上的实施成本较低、容易接受,但是缺点很多,比如难以传递、难以持续获得快速反馈等;而技术层面上的实施一般成本较高、不容易被人接受,但是优点更多,比如可以获得快速反馈、更容易传递和协作等。而现实世界中TDD的实施一般分为三个阶段,即无意识的TDD、被动通过技术实现的TDD、以及有意识和主动通过技术实现的TDD。

第一阶段:无意识的TDD

对于软件开发人员,当他们拿到一个新的软件需求时,首先会思考如何实现,其中包括当前软件架构、业务分解、实现设计、代码分层、代码实现等。然后通过思考和设计所得到的产出物来驱动代码实现,进而在代码实现中会思考如何通过一个或多个函数或者算法来实现业务逻辑。所以软件系统的实现要先通过意识层面的思考,再进行技术层面的工作。

当开发人员思考和设计这些函数或者方法的时候,一般都会思考它们有哪些参数,然后想象将这些参数换成真实的数据后传递进去,会得到怎样的返回值。好一点的开发人员会思考如何处理异常输入和异常返回值。

这类思考其实已经是意识思维上的TDD,它帮助开发人员先在大脑里面设计并验证代码实现,甚至帮助其重构代码。所以很多开发人员都在无意识的情况下做着TDD。

比如在一个银行系统里面,开发人员拿到一个需求,需要开发一个通过手机APP转账的功能。

  1. 首先开发人员会基于当前的软件架构思考:是开发一个全新的模块来处理这个业务?还是基于当前架构中的某个模块来添加代码进行处理?
  2. 当确定架构和设计之后,就开始思考具体的代码实现,比如类的设计、方法的设计或者函数的设计等。当开发“将钱从原帐号转出”这个功能前,开发人员会思考:这个功能需要支持当钱从原帐号中转出成功后,原帐号中的余额等于原始余额减去转出金额。进一步有些程序员还会设计一些用来验证功能的实例,比如帐号中的原始余额是999.99,转出111.11,那么剩余的金额就应该是888.88。
  3. 在这样思考之后,开发人员便开始根据自己大脑中的测试逻辑和用例来驱动和辅助开发过程。在代码开发完毕之后还会想一些办法来验证一下所实现的功能是否符合预期,比如人工使用之前的或者新的测试用例再测试一下。如果验证正确,就会认为自己开发的功能正确了,并交给测试人员进行测试。

其实开发人员在开发前思考测试逻辑和用例的过程就是在做TDD了。

很多做业务分析的BA和测试分析前移的QA也同样在无意识的做着TDD(注:在前一篇文章中已说明TDD包含ATDD),比如分析验收条件、写出验收文档等。只不过这些AC和验收文档可能写得不是很明确或者不是很好,比如不是实例化需求等,但是本质上已经是TDD了。

只不过是初级的无意识的TDD,可能有的人做得好,有的人做得不好,而且没有明确的产出来协助和规范这个测试驱动开发方式,也缺乏快速反馈、度量、传递和协作等。因此从无意识到有意识将是做好TDD的一个重要过渡。

第二阶段:被动通过技术实现TDD

当有一部分软件工程师意识到了TDD的意义和普遍存在性之后,就开始准备解决思维上的TDD的缺点。而解决这些问题的方法就是在技术层面上用代码来实现TDD,用明确的代码来协助和规范开发人员的测试驱动开发行为,来度量他对业务逻辑以及代码实现的理解度。通过将他的理解传递给以后的维护人员,让他的理解能重复被使用,以及和其他人协作开发。

但是现实中很多开发人员的认识不足以及技术能力不够,就算管理层支持并且主动推动TDD,最终由于开发人员设计和选取的测试用例合理性很差,导致驱动出来的代码有效性差,测试用例无法体现出SBE(Specification by example)导致易读性差,对于自动化测试框架和测试编写不熟悉导致开发速度很慢等,往往是被动的在技术层面上去实现TDD,所以出现了各种怨言,各种抵触,进而导致技术层面上的TDD很难以大规模实施。

由于意识层面上的难易程度和工作量都比技术层面上相对较小,所以前者实施起来相对容易一些,而后者则相对较难,所以如果通过了各种手段强行实施TDD,而没有主动去摆正做TDD的意识,甚至没有足够的技术能力,那么这样的TDD就是一个倒三角,非常容易倒塌。

TDD倒三角

所以,如果不希望技术层面上的TDD随时倒塌,就需要把这个倒三角补全,才能更好的、长久的实施TDD。

第三阶段:有意识和主动通过技术实现TDD

为了大规模以及有效的实施TDD,首先要突破思维意识的局限,认识到TDD的普遍存在性和适用性,不要害怕和排斥TDD这种思维和开发模式。

其次要主动学习,并刻意练习TDD的技术实现,提升自己的技术能力,从而在技术层面能更容易的实现TDD,摆脱被动TDD的困境。其中学习的方法包括阅读TDD相关的书籍和文章,书籍包括《测试驱动开发》、《重构》、《BDD In Action》以及《系统思考》等,从而充分理解TDD优点和局限。

对于刻意练习,一定要长时间坚持去做,让其成为一种习惯。如果在项目中没有合适的环境去练习,还可以通过一些第三方的TDD练习系统去做刻意练习,比如Cyber-dojo。只有大量的刻意练习才能让你在真实的代码编写过程中去思考和理解TDD,去运用你通过学习得到的知识,最终才能做到有意识和主动的通过技术去实现TDD,TDD的倒三角才能变成一个稳定的砖块,然后哪里需要往哪里搬。

TDD砖块

总结

综上,大部分开发人员都应该在做TDD,只不过他们是无意识的或者被动的去实现的,只有少部分是有意识和主动的去实现的。既然人人都在做TDD,那么我们为什么不能和黑客帝国里面的Neo一样选择红色药丸来认清楚现实,主动拥抱TDD,并通过大量的刻意练习去改变自己的工作习惯,让TDD成为自己工作习惯的一部分,这样才能更好的提升软件质量,大大降低软件维护成本。不管你信不信,反正我信了。


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

Share

以敏捷的方式运作一所大学

2001年,敏捷宣言在美国犹他州瓦萨奇山雪鸟滑雪胜地横空出世。时至今日,敏捷软件开发流程早已经深入人心。ThoughtWorks作为敏捷实践的翘楚,一直不遗余力的向行业推广敏捷。而ThoughtWorks自身不仅在所有项目中都使用敏捷,甚至对毕业生的培养都是敏捷的。

2001年,敏捷宣言在美国犹他州瓦萨奇山雪鸟滑雪胜地横空出世。时至今日,敏捷软件开发流程早已经深入人心。ThoughtWorks作为敏捷实践的翘楚,一直不遗余力的向行业推广敏捷。而ThoughtWorks自身不仅在所有项目中都使用敏捷,甚至对毕业生的培养都是敏捷的。

1-agile-manifesto

在印度浦那有着一所很神秘的大学,叫做ThoughtWorks Univesity,简称“TWU”。每个加入ThoughtWorks的毕业生,都要接受在TWU为期5周的洗礼。笔者于2016年以讲师的身份,参加了两期ThoughtWorks University。整个经历真的是一趟奇妙的旅程,收获颇丰。在这个教授敏捷的大学,我领略到了如何以敏捷的方式来运作一所大学。

敏捷的两个先决条件

《Practices of An Agile Developer》一书讲到,一个项目适不适合敏捷有两个先决条件:第一点是项目是否以价值为导向,第二点是团队是否能够达到高度协作。

2-team

第一点也就是说整个团队有一个总体一致的目标。TWU拥有明确的目标,一切都是围绕着培养毕业生的四个方面:Customer Serivce Mindset & Skills(客户服务意识和技能), Business Understanding(ThoughtWorks业务理解), Culture/Way of Life(文化及生活方式), Global & Social Experience(国际经验及社会责任)。

只有打造一个相对扁平的组织,给予充分的信任和自由度,才有利于敏捷的实施。这反过来又要求团队中的每个人有高度的自律性。

TWU的团队主要分为核心团队和讲师团队。核心团队统筹管理所有的TWU活动,确保所有的课程和活动都是围绕着TWU的目标开展。而讲师团队则是由全球各个办公室的员工抽调而来,负责具体实施这些活动。整个TWU团队都是完全扁平的架构,没有上下级的关系。

第二点是说必须能够保证团队中的成员能够流畅的交流。我们那期的讲师来自8个国家:中国、马来西亚、澳洲、美国、印度、巴西、英国、德国。这样的国际化战队能够在组建之后立马投入运作的最大原因就是每个人在ThoughtWorks学到的深入骨髓的合作理念。TWU的核心团队和讲师团队每周都有固定的时间碰头,讨论遇到的问题并商讨解决之道。每天早上TWU的讲师也有固定时间站会,更新各自的状态。下午也有碰头会,讨论当天的工作内容、遇到的问题,并提出行动来解决。

这两个先决条件在TWU完全符合。

敏捷的基础是反馈

《Practices of An Agile Developer》中讲到敏捷的基础就是反馈。如果别人能及时指出你走错了路,那么你就会少走点弯路。只有不断的接受反馈并付出行动,才会不断的提高。反馈也是双向的,不仅自己要接受反馈,也需要主动给同事反馈。

3-feedback

在TWU,首当其冲要接受来自核心团队和讲师的反馈。每周我们有个很独特的活动,叫做Speedback Session。在这个活动上所有的讲师会进行一对一的4分钟的谈话,相互给予反馈。这种开诚布公的行为把大家都团结到了一起。

而在每期TWU的前两周,新讲师会对课程进行试讲,这是获取其他讲师反馈的好时机。笔者本人收到了很多反馈,比如说我的语速很合适、声音洪亮等,也有鞭策我提高的反馈,比如我的引导力能力不强,有的时候课堂感染力不够等。

讲师要给学生讲课,及时收集学生的反馈也相当重要。TWU团队在每个教室都专门制作了一面反馈墙,每次讲师讲完课后都会提醒学生通过贴纸的方式留下对本堂课的反馈。从这些反馈中我找到了自己的一些问题,比如有的学生说我的口音有点重,对一些技术词汇解释的不是很清楚。这会促使我下次讲课时注意解决这些问题。同时我也收到了很多鼓舞,因为很多同学都留言说学到了很多有用的新东西,很感谢我的付出。

正是这种良好的反馈文化让我在短时间内意识到了很多不足之处,也明确了改进的方向。它能使你每天都正面面对工作和生活,每天都能保持提升自己。

敏捷的精髓是拥抱变化

《Practices of An Agile Developer》一书中讲到敏捷的精髓就是拥抱变化。TWU每一期的学生来自不同的国家和地区,各自拥有完全不同的经历。这就要求我们在短短几天内充分了解团队中的学生,并且对课程进行相应的调整。

4-change

比如有一次我们要求学生团队进行一次软件发布活动,而当时他们还没有学习功能开关(Feature Toggle),正在思考如何实现只发布想要的功能,而屏蔽掉其他正在开发中的功能。为了能让他们自行思考发布策略,我们特意把介绍发布策略的课程往后挪了一天。

我们不仅会调整课程的安排,对于课程的内容我们也会经常更新。比如有一节教授HTML和CSS的课程,我们对课程进行了大幅改动,删除了一些过时的内容,加上了一些通用的最佳实践。这样的改动能够保证TWU所有教授的内容都能赶得上IT领域日新月异的变化。相比起国内大学有些课程还在使用几十年前的教材,而我们的有些课程可能每半年就会全部更新一次。

一些重大的改动会被放到一年一度的TWU年度升级中进行处理。在年度升级中我们有两个月的时间对TWU的关键活动做升级。比如今年就将TWU使用的整个技术栈全部迁移到了AWS平台,实现能够一键式创建和删除整个学期需要的资源。

TWU在课程的设置方面一直紧跟市场的变化。ThoughtWorks最近不断接收一些关于UX和XD的业务,而TWU当时并没有专门针对UX和XD的培训内容。但是短短三个月的时间TWU一群卓越的同事就创建了相关的课程,并迎来了第一批UX和XD的毕业生。

最后

在TWU当讲师的几个月,笔者一直感觉这个大学是一个充满活力的大学。在这个大学里面,没有权威,没有各种条条框框,整个团队有一股极强的凝聚力,每个人是TWU的主人。运作一所大学不易,但如果能坚持做到持续反馈、拥抱变化的话,这所大学将始终是一所紧追时代步伐的大学。

Share

敏捷实践Showcase的七宗罪

Showcase就是开发团队把开发好的功能给客户的Product Owner(以下简称PO)等业务相关人员演示,以获取他们对所开发系统的反馈,是敏捷开发流程中的一个实践,一般的频率是一个迭代一次,也可以根据项目具体情况做调整。Showcase的目的是做功能演示,这同时也是展示开发团队面貌的时刻,其重要性不言而喻,但在我经历的项目中,总能看到一些不是很理想的地方。

Showcase介绍

1-showcase-meeting

Showcase就是开发团队把开发好的功能给客户的Product Owner(以下简称PO)等业务相关人员演示,以获取他们对所开发系统的反馈,是敏捷开发流程中的一个实践,一般的频率是一个迭代一次,也可以根据项目具体情况做调整。Showcase的目的是做功能演示,这同时也是展示开发团队面貌的时刻,其重要性不言而喻,但在我经历的项目中,总能看到一些不是很理想的地方。

Showcase之七宗罪

2-showcase

1.准备工作没做好

所有人就位,准备开始showcase的时候,突然发现环境没有ready,连不上了!

好不容易把环境弄好了,开始showcase,可是数据又没有ready,还要临时创建,花了大半天时间(创建、准备数据)才终于show到了真正要演示的功能……

主讲人手忙脚乱,而其他人都要在这种忙乱中等待,浪费了很多宝贵的时间,尤其是对于PO那些重要人物来说。

正确做法:充分做好准备工作

确定要做showcase的功能后,需要提前把以下事情提前做好:

  • 从业务的角度把整个要演示的功能尽可能的串起来,准备好showcase演示的步骤;
  • 演示数据也需要准备好,showcase的时候可以直接使用,只需要操作所演示功能部分,不需要临场创建准备数据;
  • 演示环境要提前准备好,包括部署好需要演示的应用程序版本,而且要告诉团队不要破坏准备好的环境。

2.没有上下文铺垫

着急忙慌的准备好一切之后,就开始页面操作了,既不先介绍一下要演示功能的来龙去脉,也不说明这个功能是干嘛的。那些日理万机的PO等业务人员很有可能没见过这个系统功能,很容易被搞得云里雾里、不知所云……

正确做法:开始演示前要先介绍上下文

根据自己对所演示功能的理解,先介绍该功能的业务价值,满足了用户的什么需求,让在座的各位业务人员能够更容易理解后续showcase的内容。

3.逐条过AC

Showcase的过程就是按照用户故事(story)的验收标准(AC, Acceptance Criteria)一条一条的过一遍,没有连贯性。这样的演示很难让观众把每条AC跟整体的系统特性、真正的业务场景联系起来,容易迷失。因此,常常会有“演示完了一个story,而客户却问这是实现了什么业务需求”的情况发生。

正确做法:以功能为单位演示

不要一个一个用户故事的演示,而是将整个功能串起来,最好定义出单独的业务场景演示给客户看,并且尽量使用业务语言描述。这样能让客户的业务人员感觉更有亲切感,看到开发团队的人员能够用业务语言进行描述和演示,他们一定会留下好的印象。

4.企图覆盖所有路径

在系统功能中,通常会有“用不同路径实现相同或类似功能”的情况,比如一个上传文件的功能有多个入口,但到达的上传文件页面是相似的。有人在演示这个文件上传功能的时候,企图把所有入口的文件都完整演示一遍,到后来根本没有观众愿意关注,都在私下讨论了,有时也会有客户业务人员直接出来制止。

正确做法:只演示最关键路径

在遇到多个路径实现相同或相似功能的时候,对其中一条最复杂/重要的路径进行详细演示,其他路径提到即可,并指出其他路径不同的地方,不需要一一演示,以节省时间。

5.过多提及跟演示功能无关内容

有人天生能聊,showcase的时候也喜欢啰啰嗦嗦的说一大堆,经常会提及一些跟正在演示的功能无关的东西,或者提及团队采用的技术方案等业务人员不感兴趣的内容,导致showcase过程不能按时结束,甚至忽略掉某些重要的反馈。

正确做法:只提及要演示的功能

有时候在一个showcase周期内可能开发了一个主要的功能,以及对一些小的feedback进行了改动等,这时候showcase可以考虑只演示最主要的功能,那些小的feedback就不需要show了,也不要提及任何还未完成的功能模块,特别是对于团队正在开发的技术卡或者还不成熟的技术方案等,一定不要提及。因为对方是业务人员,不会对技术相关内容感兴趣。

6.认为showcase仅仅是BA或QA的事情

业务分析师(BA, Business Analyst)和质量分析师(QA, Quality Analyst)通常是团队中跟业务打交道最多的,也是最了解业务的,而showcase就是给客户的业务团队做系统演示,于是团队其他角色就会有人觉得showcase仅仅是BA或者QA的事情,跟自己无关,也不关注。

正确做法:人人都可以showcase

Showcase不是某个角色独占的。团队中的所有人只要对业务、对要演示的系统功能足够了解就可以负责showcase。通常可以采用让团队中的不同人员轮换负责showcase的方式,以增加团队成员在客户面前的曝光率,同时也能增强团队中不同角色人员熟悉系统、熟悉业务的意识。另外,就算不主导showcase,团队人员也可以尽量多参加showcase会议,这是一个了解系统、听取客户反馈的绝佳机会。

7.不熟悉的新人负责showcase

既然showcase不仅是BA或QA的事情,常常也会有其他角色来参与负责这件事情。从团队能力建设的角度考虑,PM有时候会让一些比较junior的同事或者新来不久还没有好好了解系统的同事来做showcase,结果就是演示过程非常生硬,甚至会有很多说不清楚的部分,而在一旁听着的BA/QA只好着急的上来帮忙解释。

正确做法:showcase前先充分了解系统和业务

虽然人人都可以showcase,但不建议采用给青涩新人提供showcase机会的方式来帮助他们提高能力,如果要给新人锻炼机会,可以让新人在结对编程、Story Kickoff、Desk Check的时候多多主导,等到对系统和业务有了一定了解时再给客户展示比较好;或者新人非常有意愿直接主导showcase,那么一定要在演示前做好对系统和业务的充分了解,以能应付和解答客户的挑战和疑问。

总结

3-showcase-professional-efficient

前面关于showcase的正确做法都是围绕“专业(Professional)”和“高效(Efficient)”展开的,showcase的目标观众是客户的PO等业务人员,他们是决定是否认可开发团队所开发功能的重要人物,因此在showcase过程中表现出专业性和高效率非常重要。因此,只要记住这两个词,并严格遵循,showcase一定能做好。

Share