J.P.摩根运用LeSS框架实施大规模敏捷

顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架(LeSS)的?

背景

J.P.摩根的全球核心处理技术集团由Simon Cooper领导,是一个遍布全球的3000多人的组织。2013年集团决定要改变为(真正的)Scrum,并采用Large-Scale Scrum(LeSS)框架,这意味着在组织设计要做出相应改变。

之前他们曾零散地采用了”Scrum-But”及各种敏捷工程技术,主要是在开发团队中,但现有的权力和组织结构并无显著改变,与业务的交互也是一样——仍然是“合同谈判”而非“客户协作”。仍然存在负责交付“合同”的研发项目经理、团队主管、单一职能的专家角色,以及单独的组件团队和职能团队(比如测试团队)。

年初Craig与Simon Cooper及其直接下属的经理做了一次有力的对话,随后他们就决定将组织设计转变为基于LeSS的Scrum框架。

这次领导力对话认清了组织中目前“合同游戏”的动态,它阻碍了组织提高敏捷性和改善以客户为中心的特性交付。

这次领导力对话也针对真正的特性团队进行了探讨——跨组件和跨职能团队,它可以端到端地交付客户特性,不存在移交、依赖或延迟。这需要消除组织内的藩篱,比如职能部门和组件团队,以及相应的经理角色。

Read More

关于BDD的起源和工具

过去的几十年间,人们曾用过测试先行的方式,但20世纪90年代才真正提出测试驱动开发的方法。

BDD源自一些TDD实践者在寻求更好的词汇来描述在TDD循环中测试的意图。

英国人Dan North在2006年发表了《Better Software》的文章,首先意识到了TDD思想和”测试”一词会误导人们。Dan将这种风格的TDD命名为行为驱动开发,成功地将测试先行编程推进了一步。

由于test一词并没有抓住指定期望行为的精髓,它反而承载了太多的含义。相反,社区开始谈论specifications(需求说明,简称specs)和行为,而非测试与测试方法。

今天的BDD语境和领域远远超出了代码——最引人注目的是将BDD提升到需求层面,与业务分析和需求行为结合起来。

Read More

手机银行中的单分支开发或主干开发

长期维护的特性分支,这种做法会为每个新的大型特性或项目建立一个分支,仅当准备发布时才合并回到主干上。看似可以独立地开发每个特性,互不干扰。不幸的是,软件系统是如此复杂,随着主干与分支渐行渐远,接下的合并工作本身将会成为一个项目,带来无数的新缺陷,这真是一场噩梦。
当团队需要同时支持多个客户的不同需求时,版本控制仓库中很可能为此存在了许多分支。这显然会造成大量重复浪费以及高昂的维护成本,在临近产品发布时带来巨大风险。

2011年,@申导 进入某银行的网上银行工作。由于各国市场环境、政策法规等原因,以借记卡为例,看似相同的业务和账户,其背后的处理逻辑和外部集成系统可能都是不一样的。
当时的代码库中,多个国家的代码互相拷贝,由不同组维护,各有自己的思路,虽然最早是同一个基础框架发展而来,但短短几年后各自结构和规范差别越来越大。比如,页面login有的在iframe里,有的不在。相同的修改需要到处merge,例如安全性补丁,回归测试工作量大。

秋天,他所领导的敏捷团队开始开发新一代手机银行项目,目标是用同一代码库来支持多个国家的业务需求。

Read More

用户故事图谱 User Story Mapping

传统的产品待办项列表(Product Backlog)相对于传统管理办法是一个巨大的进步,但是仍然存在一些问题:

  • 只见树木不见林
  • 重要的待办项容易淹没在各种细节中
  • 看不到全貌因而难以排列优先级
  • 并未明显地聚焦于用户需求
    而故事图谱是一个可视化Product Backlog的简单工具,有助于解决上述问题,特别是当PB越来越大,越来越复杂的时候。

Read More

固定范围、固定交付日期情景下团队盲目做出不能实现的承诺,如何改善?

在我给客户提供需求培训和教练服务时,以及在各种敏捷社区活动中,被多次问到scope fixed,deadline也fixed的时候,团队被强制“承诺”必须完成全部需求,此时除了抱怨还有其它方法吗?我把这类问题定义为“固定范围、固定交付日期情景下团队盲目做出不能实现的承诺,如何改善”的问题。

除了背地里大骂那些经理们无知之外,我们真的无计可施了吗?非也,”THERE IS ALWAYS A WAY OUT”, 我整理了下我在不同场合的回答和思考,做成了一个脑图,敏捷教练不传之秘也,供大家参考。

更多敏捷教练经验观点见 https://www.uperform.cn/blog-article/

Spotify的新型敏捷矩阵组织:部落、分队、分会和协会

组织导入敏捷往往更加关注形式和标准化,然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。Spotify是继Pandora之后,国外第二大音乐媒体网站,在从6个人扩张到1200人的过程中,它使用一种了新型的矩阵组织来扩展:部落、分队、分会和协会。

Read More

如何理解用户故事INVEST规则中的独立性和破解依赖?

用户故事INVEST规则中的第一个“I”,Independent独立的,是说用户故事应该是自包含的,没有对于其他用户故事的内在依赖。但在实践中,很多人觉得这个基本很难做到,甚至完全不可能,造成很多困惑,那到底该如何理解这条规则呢?

借鉴前人的知识,结合本人的认识和经验,这篇博文从理论和实践角度对此做一个深度剖析,希望能对你有所帮助。

Read More

优普丰十年敏捷推广的心得总结

(作者:Bill李国彪;审校:谢炜玮/Jacky申健)

上篇-从零到一的信心加持
下篇-保持归零的敏捷初心

核心看点:

关键时刻:听说并尝试Scrum;成为CSM;翻译第一本Scrum著作;成立优普丰;第一次CSM上海公开课;第一次中国Scrum Gathering大会;结识Vernon史文林;奇虎360公司内训;

关键心得:选正确的事;顺势而为;跟对人;心态开放;拥抱意外的学习;要专注;把手弄脏;快速试错;恒心;社区;善观察;多思考;找对人;

自2007年优普丰敏捷学院成立并开始专注在中国推广敏捷,光阴如梭,已有十个春秋。虽我不善词藻,回想敏捷在这十年中给我以及我身边的朋友、同事、社区的伙伴及各大客户带来的变化和成长、开阔的眼界,以及更积极和正向的思维方式和心态,我抱着感恩之心,不禁想写点什么与大家共勉。如今回顾这一历程,信心不断加持,也鼓舞我们投向未知的但也是无比广阔的未来。

Read More

Git命令扫描频繁修改代码热力图以提高代码质量

对于大型复杂架构的产品代码,如何知道哪些是被频繁修改的?哪些不稳定或蕴含了潜在的缺陷或者需要频繁的回归测试,以保证持续交付的质量?如果能根据代码痕迹画出热力图或云图。据此就能找到那些不稳定的模块和代码,调动人员review这些代码,分析导致变动的原因,解决那些不稳定因素,不管是耦合问题,还是抽象层次问题,那么代码的质量会直线上升,程序员工作量就会直线下降。

Git Log加命令行管道

git log命令的结果中包含了所有的提交信息,可以通过参数只筛选出文件名,然后先按照文件名进行排序(sort),然后用(uniq)命令来统计每个文件名出现的次数,然后再按次数排序(sort),最后是(head)命令来找出提交次数最多的10个,即是那些被频繁修改的代码文件。

git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10

管道命令可以任意拼接,比如只想从所有C#代码里面来扫描,就再加一个grep管道来过滤即可:

git log --pretty=format: --name-only | grep .cs$ | sort | uniq -c | sort -rg | head -20

Git Effort

如果你在安装GIT命令行时安装了附加工具包git-extras,就可以用git-effort命令来扫描, 它会列出你的仓库中所有文件及提交次数。例如,你可以用下列命令来忽略少于4次提交的文件:

git-effort --above 4