敏捷开发实践名词术语图谱(地铁线路图)

什么是敏捷

Agile Alliance: 敏捷是一种建立和响应变化的组织能力。用于应对不确定和动荡环境,并取得成功。^1

Scrum Alliance: 敏捷是一个形容词,是一种思维或践行敏捷宣言与敏捷原则组织级方法,从而感知和响应市场变化。具体地,Scrum是一种框架、方法论、工具,利用客户反馈来快速交付高价值的增量。^3

敏捷宣言

敏捷宣言^2的作者们选择了“敏捷”(Agile)这个词,是因为这个词所代表的适应性和变化响应力对他们的方式方法至关重要。(参见 https://martinfowler.com/articles/agileStory.html)

这种思维是关于你如何理解当今环境所发生的一切,识别你所面对的不确定性,边前进边找出应对措施。

敏捷开发

Agile Development - 敏捷(软件)开发是一系列方法和实践,使得解决方案在自组织、跨职能团队的协作中逐步浮现出来^1

敏捷组织(业务敏捷)

敏捷组织是一种以人为本的的组织形式,拥抱敏捷文化,无所谓采用特定框架,也无所谓叫不叫敏捷这个名字,组织中的团队都会在敏捷思维与价值观的驱动下交付客户价值。这类组织会基于员工的反馈,持续地调整他们的工作方式。他们崇尚“响应变化高于遵循计划”,以迭代和增量的方式频密地向客户交付价值。^3

敏捷和Scrum不仅仅限于开发者,也可以扩展到市场、财务、人力等部门。

误区:许多业务领导以为敏捷是一个即插即用的管理系统或者神奇的大型软件,可以立即治愈大多数功能失调的部门–这其实是幻觉

敏捷实践及名词的集合家谱

各条线代表了不同敏捷流派或“部落”中的实践集

不只限于Scrum、极限编程XP或特性驱动开发(FDD)等,也不限于结对编程、测试驱动开发、站会、计划会和迭代时间盒,而是一把遵循了敏捷宣言和原则的大树,支撑着上述方法论和实践共同的价值观理念。

极限编程 Scrum 设计
团队 产品管理创新 测试
精益 DevOps 基础

Scrum和Sprint名词的历史和误区

Rugby(英式橄榄球)运动是1845年开始的。Scrum方法创始人们是读了1986年HBR论文《The New New Product Development Game》而受到了Rugby运动的启发,并在1995年发布论文,正式提出Scrum方法。论文链接见:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.4164http://jeffsutherland.com/oopsla/schwapub.pdf

Scrum是Agile敏捷开发方法的一个流派,Sprint一词(英文原意是Rugby运动中的短距离冲刺)是1995年Scrum一词(英文原意是Rugby运动中的争球)创立者为了区别于其他增量迭代式开发(IID)方法(例如 XP极限编程方法),而从Rugby运动借来的比喻,意为一个短的时间盒,期望每个时间盒末尾能有潜在可交付的产品增量以供反馈和调整。

如今敏捷行业,Iteration和Sprint几乎混在一起使用了,甚至包括一些新兴的精益产品创新方法如谷歌的Design Sprint一词也效仿设计了5天的固定时间盒。

Read More

UCAC敏捷教练静修-4月杭州-静待花开

什么是VUCA时代,这个时代对个人有什么影响?如果是往年,还真要费一番口舌去解释,然而现在,我们刚刚过完2018,没什么能比这个年份更好的解释VUCA了。
2018 年,一些大公司干着干着突然遇到危机了,多少被公认有前途的行业,干着干着突然就遇到了拐点。有多少人设,轰然坍塌,年初的豪言壮语,到年底只剩下一地鸡毛。

如果你用吃瓜群众的心态旁观2018, 那么它无疑是一个观赏性十足的年份。一年之内,你就能见证无数起“眼看他起朱楼,眼看他宴宾客,眼看他楼塌了”。然而每一个轰塌的背后,都有无数人失去工作,辗转求职,陷入应付生活成本的焦虑中。前一天还在吃别人的瓜,今天就轮到自己成为吃瓜事件的主角。

所有那些曾经看起来坚固牢靠的东西,现在都想打一个问号,罗振宇说,「这个世界还会好吗?」

这就是VUCA时代,一个充满变数的,模糊的,复杂的时代。

Read More

一线外包公司老板告诉你如何与甲方签署敏捷外包合同


作者:王洪亮

近几年,随着社会化分工的趋势,许多领域的客户都考虑到软件外包服务,在开发新的项目中,会涉及到一些系统,设备和业务领域等进行开发,如果全部自己开展起来,承担着技术积累风险和短时间开发的风险。出于时间和成本的考虑,客户会考虑到软件外包。
与此同时,随着敏捷传入中国并发展了十五年以上,敏捷产品研发的观念逐步替代了传统的项目管理,也带来了新旧观念的现实碰撞。近期很多客户跟我们探讨过软件外包项目合同如何签署,而笔者除了在多家企业担任敏捷教练之外,也是在自己的企业中负责了多个外包服务项目,并以敏捷的理念与客户进行合作。所以这次我们根据如何在敏捷语境背景来行展开,谈谈如何签署敏捷的软件外包服务合同。

一 合同的形式

本次讨论的合同形式主要为固定价格合同和T&M合同。

Read More

title: SOA with REST: 用RESTful构建企业级SOA解决方案
date: 2015-03-06 13:29:55
tags:
- SOA
- RESTful
categories:
- programming
- architecture

这是一篇读书笔记,也是在翻译本书过程中,对重点的摘录。

本书不仅展示了REST是一种适合于构建面向服务解决方案的媒介,同时也展示了面向服务的架构模型是能够充分发挥商业潜力的REST风格的技术架构的坚实(通常也是必要的)基础。

  • 面向服务计算的目标是战略性的和面向业务的。
  • REST的目标是以技术为中心的,并且有助于实现战略目标和战术性业务目标。
  • 虽然并非所有的REST设计目标与每个面向服务计算的目标都有联系,但是大多数REST的设计目标都直接支持面向服务计算的目标。
  • REST与面向服务计算的目标之间没有冲突。

Read More

20131214 QClub天津站:Global Day of Coderetreat 活动纪实

Code Retreat,一个在没有工作压力下让人锻炼写Code技巧的活动,本次天津站在天津华苑站吶吧咖啡厅,由敏捷教练 – 申健带领大家进行。

当天到场参与的有将近20人,除了实践了结队编程(Pair Programming)以外,也尝试了TDD的作法,除了多数人使用的Java以外,也有使用C++的同好参与。虽然因为时间的因素没有进行难度太高的课目,但是每个人都扎扎实实的练习了一把,也都一致表示收获丰富,下次有一样的活动必定参加~~~^^

1.活动场地:吶吧咖啡厅,论场地、论气氛,还有美女程序媛n名,各方面天津场都完胜!!天津果然是过日子的地方啊~~~

Read More

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