- 网络有一个引人注目的目标:为了有效运行,网络必须由一个引人注目的共同目标驱动。一旦这种迷恋得到了普遍分享,那么谁来创造价值就不再重要。交付的事实很重要。就像在篮球队中一样,进球得分并不那么重要:重要的是是否进球。
- 该网络由小组(small group)组成。这些大型网络不是建立在个人集合的基础上的,就像老式的布道者将大批人群聚集在一个大帐篷中一样。德勤边缘研究中心主任约翰·黑格尔(John Hagel)说:“成功的运动都是围绕当地的小型行动小组进行的,它们共同努力,在不同的环境中取得影响。这些行动小组由松散耦合的网络团结在一起,使他们能够寻求他人的帮助,并从每个小组的不同行动中观察并学习哪些行动可以发挥最大的作用。”
- 小组具有行动导向:小组会培养协作精神,但这是一种特殊的协作。这些小组与多年的讨论,研究,沉思或反思无关。它们是关于将思想付诸实践,而不是关于抽象知识,甚至是为了思想本身而在思想上。这些小组致力于以参与者认为重要的方式改善世界的方向。
- 网络是小组的总和。网络不包含小组:它是小组的总和。小组不是组织内的小组:从概念上讲,它们就是是组织。
0 Comments
按:我们在介绍图解技术时通常很谨慎,但在讨论组织内软件资产的演进时,绘制Wardley地图 (Wardley mapping)是一个非常有趣的方法。简单说来,Wardley地图从客户的需求入 手,逐步绘出满足这些需求的各个功能和系统,以及这些功能和系统的演进,以呈现出组织内部存在的价值链。这项技术的价值在于协作绘图的过程,而不只在于产出的图表本身。 我们建议由合适的人员一起绘制Wardley地 图,并将这些图表视为活跃、不断发展的事物,而非已完成的产出物。
-------------------------------------------------------------------------------正文分割线-----源自wiki------------------------------ 沃德利构图(Wardley Mapping)是业务或服务结构的映射,映射为客户或用户提供服务所需的组件。Wardley 构图以Simon Wardley命名,他声称自己在2005年创建了它们。 摘要 Wardley地图中的每个组件都按其对客户或用户的价值以及该组件的成熟度进行分类,范围从定制到商品。 组件被绘制为图形上的节点,其中y轴上的值和x轴上的商品。 对用户没有直接价值的定制组件将位于此类图表的左下方,而对用户具有高直接价值的商品组件将位于此类图表的右上方。 组件在图表上连接,边缘显示它们已链接。 Wardley映射的大部分理论都是在一系列12篇博文[2]和一个名为Wardleypedia的专用wiki中列出的。 [3]随着该技术的使用扩展到新的机构并被用于绘制新事物,该技术在实践中的应用已经偏离了原始的愿景。 示例 想象一下,我们想要建立一个新的无人机快递服务。 用户需要从我们公司快速接收包裹。 我们作为一家公司的目标是通过快速向客户提供包裹来满足这种用户需求。 这是一种高价值,低商品价格的组件,位于Wardley地图的左上角。 如果有数十家竞争无人机快递公司,这个组件将会在Wardley地图上移动,表明该服务更接近于商品。 其他组件的映射类似。 例如,无人机操作员需要了解天气状况,以确定无人机应该采取的路线以及它可以承载的最大重量。 天气信息对客户来说价值不大,可以从各种天气数据提供商那里购买。 因此它位于Wardley地图的右下角。 设置无人机快递服务所需的关键部件(左)。 Wardley地图上的相同组件(右)。 使用 Wardley地图在英国政府内部使用,特别感兴趣的是政府数字服务(GDS) [4],用于战略规划和确定政府数字服务现代化的最佳目标。 它们已被用于绘制高速二(HS2)的现有和计划的技术基础设施和服务。 [5] 工具 领先边缘论坛的Atlas2 [6]工具旨在协助创建Wardley地图。 [7] 批评 用于将业务或服务抽象为组件的Wardley映射过程通常对于第一次体验它的人来说并不直观。 一个特别的挑战是每个组件在Wardley地图上的主观位置,不同的人甚至同一个人在不同的时间可能将一个组件放置在地图上显着不同的位置。 虽然在确定这些不确定性和意见分歧方面仍然有价值,但批评者声称,如果不涉及Wardley地图绘制过程,就可以实现同样有价值的讨论。 沃德利绘图的支持者声称,这个过程的大部分价值在于“揭露假设。允许挑战并建立共识” [8] - 但批评者担心这个过程实际上让人们“将假设清洗成事实,将挑战归于一致(并且仍然产生共识) )”。 [9] 参考
https://en.m.wikipedia.org/wiki/Wardley_map 附记: 缘起于Cynefin Framework以及JTBD目标品牌的企业内部架构实际操作需要。 背景 服务设计、敏捷和精益创业,这三个领域可以互相学习什么。 服务设计、敏捷和精益创业具有许多相同的原则,特别是在验证性学习(validated learning)和不确定性方面。在每个学科中,失败的早期轨迹为快速修正提供了机会,这种情况是应该被寻求的,而不要被抵制。三者提供的工具和过程都被设计,以能够为各种不同长度的反馈回路(过程)提供学习机会。 快速失败法是对 W Edwards Deming的“计划—--执行—--检查—--行动”(PDCA)循环的修订。首先,我们计划出预期结果;接着执行被计划的过程;然后检查比对实际输出与预期结果,最后,在完成根本原因(对实际结果和计划结果之间所存在的显著差异)的分析之后,我们采用任意的结果(实际输出或预期结果)进行行动。每一个学科将这个周期的一个版本整合到其核心过程。服务设计的重点是服务的协同设计和迭代原型。精益创业是使用假设检验的方法,来清晰业务假设和修正客户发展,为可持续的商业模式进行快速搜索。敏捷,关注的是人及如何团队合作,使用测试和开发者实践的方式,如结对编程,以确立软件质量,并缩短开发的反馈循环。 许多主要原则似乎是相同的,并且许多工具是熟悉的(或感觉上是熟悉的),但一些核心的想法似乎也互相冲突。服务设计常常以(至少最初)少数定性分析实例的有效性呈现,这与精益创业的假设检验的定量分析相左右。服务设计,坚信用户/客户价值和真实性,这与精益创业的方式有些冲突。精益创业的价值,是视市场规模而定的,而这一市场规模的认定是基于市场中的人们在做什么,而不是建立在人们在说什么,所谓寻找一个可持续的商业模式的基础之上。但这会使彼此间造成潜在的不尊重。一起创新创业的合作伙伴会感到自己像实验室内的小白鼠一般,不断转型(pivot),不停地从一个假设跑向下一个假设,同时这也使用户/顾客失去了服务。 尽管有一些明显的冲突,但仍然有很大的收获,我们找到可以把这三个学科融合一起的方法。三者之间内在的张力,为探索发展服务与产品的基本概念提供了机会。在接下来的探讨中,我们将采用在国际服务设计联盟(SDN),精益创业网(leanstarup.com),以及敏捷联盟(Agile Alliance)中的定义与理念。 共同理念 每一门学科都是通过它们普遍可接受的、标准工具的过程,导引出一个常见的路径信息。然而,每一门学科中都没有一种工具可以统辖全部三个学科。但是,每一门学科都辩称,它自己的核心过程,应该是为每个团队的需要和为他们工作的当前语境所量身定制的。每个学科都会假设在非线性的工作旅程中,我们前进,并不断探索学习。 在极端不确定的条件下交付价值 商业价值是客户所渴望的。然而,新的项目往往是在未知的领域里进行,有效的规划难以开展;并且需要沿着探索的流程,在进程中积极寻求减少不确定性。精益创业努力找到可持续的商业模式;而敏捷看起来在减少危险的存留假设;服务设计则旨在尽可能多的了解用户/客户体验。这三者,以各自的方式,为决策的向前进展而努力建立信心。通过减少不确定性和重新排序任务,他们将更了解项目的交付价值。 验证性学习 每个学科都需要确认的事情做出假设(潜在用户/客户假设)。精益创业测试的假设是作为“建立—--测量—--学习”这一过程的一部分;敏捷是将项目细分,展示给用户/客户,并与用户/客户讨论,来确定彼此相互交汇中所产生的商业价值;服务设计通过与用户/客户一起原型化体验,达到共识的商业价值。每个学科借助原型和行为观察来帮助决策,并且迭代产品版本,以此确认之前对客户的假设。 从“小”开始,失败前行和最小化浪费 根据Donald G. Reinertsen 的说法,我们从失败中学到的要比成功中学到的更多。我们想做一些低价值的小实验,它可以被迭代成一个更大的产品/服务。我们希望在正在进行的流程中,去掉那些不能提供价值的部分。“敏捷”以测试驱动的开发方式进行工作;“精益创业”迫使我们与潜在的客户共同测试我们的假设;服务设计则使用低保真原型和其他工具。所有学科的目的都是在大量的投入之前对假设进行测试。 共同框架 一个来自第一次MoDAL聚会的声明称:“我们还是不知道该如何把工作完成。”毕竟,不论我们如何地了解每一种方法,大多数从业者想知道的仍然是如何将正确的工具应用到一个项目中,并得到最好的结果。 那么,我们如何在项目中应用一个组合式的方法呢?一个方法是试着结合所有三个学科将一个完整的项目流程视觉化(在我们第一次聚在一起的时候,我们以不太正式的方式进行了尝试)。Nordstrom创新实验室提供了这样一个可视化项目。 以下,将展示我们自己的完整可视化版本。在这个图中,圆圈外所标注的(利益攸关者,假设和能力)代表每个学科的驱动因素;同时,交叉点(Need Alignment需求校准、Asset Alignment资产校准和Feature Alignment特征校准)代表学科之间的关键点上的交汇。 该模型假定一个项目可能会从任何地方开始(例如从用户观察,创始人的想法或团队的能力),根据规模和范围的项目,它可以遵循一个单圈(与交叉点处提供检查)(在一个圆环中独立运行),也可以在每个圆环中“跳来跳去”(切换),而不需要进入三角形循环模式,以便使各学科的视角最大化。 1。需求校准Need Alignment 服务设计/精益创业的交叉点,代表合作创造的价值和核心业务模型的交集。这也可能涉及到商业模型画布中的价值主张/客户细分的部分。 2.资产校准Asset Alignment 精益创业/敏捷方法的交叉点,代表以假设驱动的原型或最简可行产品,换而言之,就是什么都可以从假设中被真实的创造出来,并给于技术和团队能力。 3.特征校准Feature Alignment 敏捷方法/服务设计的交叉点,关注的是深度和特征集;在能力限制下应该发展什么,以满足共同创造价值的要求。 关键的项目组成部分 团队 团队永远是起点,无论是合作伙伴的精益创业团队及其驱动而建立的一个可持续的商业模式;还是敏捷和服务设计团队的跨部门工作协助沟通,提供外部要求,或组织(机构)使用服务设计,有效共同创造服务,赢得更好的利益攸关者的参与。然而,敏捷,可能提供了最为坚实的一套团队优化方法和思路,把重点放在那些做工作的人身上,以作为他们的工作本身。 想法与探索 最初的想法可能来自企业自身的需求,企业创始人,客户,观察报告或其他地方。无论想法从何而来,我们更关心三个学科分别是如何处理的?精益创业的方法侧重于基本的想法,探讨如何使用像商业模式画布这样的工具,或通过客户探索(customer Discovery),使它被开发成一个可持续的商业模式。服务设计提供了丰富的工具,从人种志学到创新工作坊,来探索更深层次的需求。在这一点上,敏捷这一学科使用了与服务设计相似的思路,即在问题空间中进行思维的发散。 实验与原型 每一门学科如何测试想法?精益创业通过一个科学的方法来制定和测试假设。服务设计使用设计工具来计划,但依赖于原型,从想法推出到反馈循环。敏捷的方法是作为一个尝试的方法超越原型,实现在每个开发阶段的功能版本。在最初阶段,这可能是尽可能多地配置到团队中来建立思路。 开发与迭代 实现这一点的学习路途中将会遭遇挫折、感受愉悦和惊喜。这一想法将通过旅程被转化,三个学科中的每一个都会有助于将想法塑造成一个可持续的概念,这是一个自身拥有的最简可行产品的版本。随着想法的发展,早期的低保真原型将被完善为更高保真度的原型。 部署 我们可以顺利地从“开发”过渡到“部署”,而没有任何正式的公告。服务可能会随着时间的推移,其粗糙的边缘将得以改善。精益创业将寻求跨越鸿沟,将早期的采用者变为大多数早起用户,但仍然有思想的假设检验(方法),去推动和发展一个可持续的商业模式。服务设计师将继续开发更深入的用户理解,基于接触点和统筹创建有意义的服务。敏捷团队将改进他们的开发过程,融合以用户为中心的服务设计,并确保精益创业所关注的核心商业价值在过程中不会丢失。 总结贡献 下方表格作为起点,提供了对每个学科相互的最好学习的总结。 结论
发展一个共同的方法,结合三个学科的优势,并没有冲突地实现所有,以上这些都是艰巨的任务,而且不太可能综合地适用于大多数项目。然而,在商业环境中学习本身就是一个核心技能,这一关键方面是开放周边思想和技术,来帮助企业为他们的利益相关者实现价值。 三个学科中的每一个都在复杂性中成长,每个学科都有其专有的工具和资源的派系。然而,每一个情况都是独特的,坚持一个单一的方法会忽略了这点,所以应该基于手中的课题来激发自己的流程。在这方面,三个学科的核心理念为项目开发提供了更广泛、更有用、更广阔的视角。 学科间的融合已经发生;有时,一个或两个学科在会议或论文发表中被发现弄在一起:一个服务设计的讨论发生在一个精益和敏捷的活动上;或者也许服务设计的书中有敏捷开发的章节。 本文摘译自《触点》杂志 2014年12月 第6卷 第3期,仅用于学习。另,完整文章可联系我获取。 1.有自己的观点但必须思路开阔
要有自己的观点,当机立断。同时,知道如何测试最具风险与不确定的领域。在验证过程中,以客观事实为依据,用开放的心态来思考,得到更多的认知,用以修正与提高自己原本的想法。 2.清晰阐述你的假设。 产品是假设的产物,假设需要整理清晰并清晰呈现。要向每个人展示这些假设,反思探讨,使之趋近完美。 3.精准的优先级排序。 时间是最稀缺的资源,优先顺序必须精准。 4.限定小而精的产品功能范围。 化整为零,快速迭代,快速反馈。 5.与客户交流。 投入资源构建与客户沟通体系建设,及时而频繁地客户沟通,两次测试之间不易隔得太久。 6.在创建产品之前,先进行测试。 在尚未证实产品-市场适配之前开展创建工作是冒进。基于可交付的设计工件的迭代远比创建市级产品来得更加速成,且成本更低。另一个原因是防止“敝帚自珍,心态不开放,不情愿否定自己”形成投入偏见。 7.避免局部极大化。 不要忽略其他更好的可替代方案—--那些选项之外的可能。从一个更新颖的、更广阔的视角来观察,将自己的思维提高一个层次,用发散思维提出新的创意加以探索。 8.采用更有前途的工具和技术。 当有足够多的团队成员认为新方法比原先的方法更好时,尝试新的技术和工具。一味追求新技术无必要,但是相对走在时代前沿时可取的。当一个新想法看起来有希望、有可能显著提高团队工作绩效时,应该给予它们一个机会。 9.确保团队的技能水准。 成功创造一款产品需要广泛的技能组合。充分评估团队的强项与弱点,改善与提升技能水平,不断强化团队能力(例如额外的人员招募、供应承包商、顾问或培训)。 10.培养团队的协作精神。 创建产品是一项团队运动。团队必须互相协作,并改进团队协作,以及改进工作质量,增加实现成功产品的可能性。 摘自:The Lean Product Playbook 书评:日益变化的时代,阈限思维提供了一个如何突破信念的边界,提升认知水平的蓝图,帮助我们澄清自己的想法,与他人建立联系,以深刻的人文和深远影响的方式有力地传递我们的想法。值得一看! 摘要: 《阈限思维:通过改变你的想法创造你想要的改变Liminal Thinking:Create the Change You Want by Changing the Way You Think》,2016年9月出版。 作者:Dave Gray ,XPLANE 创始人,也是《Gamestorming:创新、变革&非凡思维训练》(Gamestorming:A Playbook for Innovators,Rulebreaker,and Changemakers)》和《互联网思维的企业(The connected company)》(译为“互联思维的企业”更为贴切,出版社功利沾互联网思维的风!)的合著者,《Selling To the VP of No》一书的作者。 为什么有些人在变化中成功而其他人却失败了?这是因为他们的想法不同! 什么是阈限思维? 阈限思维是通过理解、塑造和重塑信念来创造变化的艺术。现在有什么信念阻止你?你有一个选择。你可以创造你想要的生活的世界,或者生活在一个由别人创造的世界里。如果您准备开始进行改变,那么请阅读本书。 信念是人们所说,所想,所做的一切的基础。当人们改变自己的信念时,他们会改变自己的行为,改变自己的生活。 阈限思维是任何人都可以学习的一套技能。 阈限(Liminal) 一词源于拉丁语词根“Limen”,意思是“阈值”,意为“在结构过渡期间模棱两可的状态或过程,具有在不同结构与状态之间转换的功能”。说简单点,就是一种处于游离的中间态。从字面上说,是门槛,临界点。但是门槛也是每一次旅程的开始。阈值是标记一个状态与另一状态之间的边界。阈限思维背后的思想是,在你周围总是有门槛,机会之门。它们中的大多数对你而言是隐形的,因为你专注于其他事情。但是它们提供了成长和变化的潜力。调整自己的思维以达到阈限思维能够帮助你看到其他人无法看到甚至想象的机会。这是一种心理敏捷性,可以让你在别人不能做的地方创造变化。 阈限思维,即是帮助我们突破经验、注意力、理论和判断的限制,突破思维的边界,得出更接近现实的答案。 阈限思维是发现、创造和使用阈值来创造变化。这是一种正念,可以让你创造积极的变化。 三个规则 这九种阈限思维的做法(详见后文)可以概括为三个简单的规则: 1.接触你的无知。 2.寻求理解。 3.做一些不同的事情。 六项原则 六个原则构成了一个信念理论:它们是如何形成的,它们为什么是必要的,它们是如何被强化的,以及为什么坚持自己的信念,即使它们是不完整,过时或无效。他们是关于信念的信念。 1.信念是模型。信念看起来像是世界的完美表征,但实际上它们并不是完美的的模型,对于驾驭复杂的、多维的、不可知的现实而言。 2.信念是被创造出来的。信念是根据选择的事实和个人的主观经验使用理论和判断来构建的。
敏捷实践编年史记录了自1968年起至今敏捷的发展与演变史。
英文原文:https://www.agilealliance.org/agile101/practices-timeline 1968年:“康威定律(Conway’s Law)” “康威定律”被提出并概括为:“任何组织,在设计系统(在这里定义更为广泛,不仅限于信息系统)时,产生的设计在结构上必然会复制自身组织的沟通结构。”长期以来,“康威定律”都只是被当成民间传说,而非得到充分论证的科研成果,尽管最近有些研究为其提供了一些学术支持。(直到90年代中期,软件开发的社会性仍然在很大程度上为软件工程学术研究忽视。) 二十世纪七十年代: Barry Boehm提出了“Wideband Delphi”估算技术,这是“计划扑克(Planning Poker)”估算法的先驱。 1976年: D. Panzl 的系列文章描述了具有似于 JUnit 特性的工具,证明自动化单元测试有着悠久的历史。 1976年: Glenford Myers的著作《软件可靠性(Software Reliability)》出版,其中阐述了一条“公理”——“不应该由开发者来测试自己的代码”(此时仍是由开发者测试自己代码的黑暗年代)。 1977年: 创建了用于 UNIX 系统的 “make” 工具——自动化软件构建的原则从来就不是一个新想法。 1980年: 在 Harlan Mills 主编的文集中可以发现,在 IBM 联邦系统部中进行了关于增量开发的实质性讨论。在Dyer的文章中明确指出“软件工程的原则是,建议组织“每个增量完成的功能要尽可能地与其他增量相隔离。”然而,这个想法还是有过多的进度的和阶段的方法,而不是一个适应变化的方法。 1980年: 源于丰田生产系统的“可视化控制(visual control)”概念,是对“信息辐射器(information radiators)”的预期。 1983年: 在CHI(人机交互)会议论文集中描述了,在“施乐之星(Xerox Star)”的设计期间,施乐帕克(Xerox PARC)研究中心大范围使用“人类因素测试(human factors testing)”技术,这为可用性(usability)测试埋下了伏笔。 1984年: Barry Boehm 在项目中使用原型,以便在项目早期实证学习(empirical study),这本质上是一种迭代策略。这表明此时迭代方法已首次开始得到认真关注,极可能是由于诸如个人电脑和图形用户界面的兴起因素导致的。 1984年: 在 Brodie 的著作《Thinking Forth》中提出了“构造(factoring)”的概念,书中将其表述为“把代码组织成有用的片段”且这件事情“发生于详细设计和实现期间”,这是对重构的预期。 1984年: 对“瀑布”顺序式方法的批判早已开始,而对作为替代物的“增量方法”的构想也正变得越来越突出。一个很好的例子是,早期在《软件工程中基于知识的沟通过程》上一篇文章倡导使用增量开发,具体原因是“不存在完整和稳定的需求规格”。 1985年: 或许首个有明确命名的、用于替代“瀑布”的增量开发方法是Tom Gilb的演进交付模型(Evolutionary Delivery Model),绰号是“演进(Evo)”。 1986年: 在一篇著名的文章中,Barry Boehm提出了“软件开发和改进的螺旋模型”,一种通过合适的方法(尽管展示的“典型”例子是基于原型,但不仅限于原型法)来识别和减少风险的迭代模型。 1986年: 竹内和野中在哈佛商业评论发表了他们的文章《新新产品开发游戏(The New New Product Development Game)》。这篇文章描述了一种橄榄球方法(ruby approach),方法中“产品开发过程是在一个精心挑选的多学科团队的持续互动中产生的,团队成员自始至终都在一起工作”,这篇文章经常被引用为 Scrum 框架的灵感来源。 1988年-1990年: 事件驱动的图形用户界面软件的兴起,及其功能测试面临的挑战,为Segue 和Mercury等公司开发的“捕获和回放”类自动化测试工具提供了机会。这类工具在之后十年在市场上一直处于主导地位。 1988年: “时间盒(timebox)”被描述为 Scott Schultz 的“快速迭代开发原型化(Rapid Iterative Production Prototyping)”法的基石,这种方法应用于杜邦公司的副业——信息工程协会。 1988年: 尽管通过把对象拟人化(例如 CRC 技术)来推理设计问题的思想似乎是很自然的,但仍存在着一些强大的反对者,比如 Dijsktra 的这篇文章《在实际计算机科学教学中的残酷性(On the cruelty of really teaching computing science)》,看起来就好像面向对象正在打击主流思想一样:“在计算机科学中,拟人化的隐喻都应该被禁止”。 1989年: Ward Cunningham 与 Kent Beck 合作的文章中描述了 CRC 技术。卡片上采用这种特定格式,源于Cunningham 设计的应用(其用途是为了把设计文档存储为超卡片堆Hypercard stack)。 1990年: 在一篇 ACM SIGPLAN 的文章中,Bill Opdyke 与 Ralph Johnson创造了“重构(refactoring)”这个术语——“重构:一种在设计应用框架和演进面向对象系统中使用的辅助手段”。 1990年: 黑盒(black box)测试技术仍然在测试学科中占据主导地位,尤其是以“捕获和回放”测试工具的形式进行的测试技术。 二十世纪九十年代: 由于快速应用开发(RAD)工具和集成开发环境(IDE)的崛起,“make”类的构建工具毁誉参半。 1991年: James Martin 在其著作《快速应用开发》中描述的RAD(快速应用开发)方法,或许是首个把时间盒和“迭代”(较宽松意义上的“整个软件开发过程的一次重复”)紧密结合在一起的方法。这本书在某个章节中还描述了时间盒的细节。 1991年: Taligent 公司独立开发了一个测试框架,这个测试框架与 SUnit 有着惊人的相似。 1992年: 在一次拜访 Whitesmiths 公司时,Larry Constantine 创造和报道了“活力二人组(Dynamic Duo)”这个术语:“每一台终端前有两位程序员!当然,实际上只能由一位程序员来操作键盘编辑代码,但他们两个是并肩作战的。”Whitesmiths 公司是由 P.J. Plauger 创建的编译器供应商,C语言的实现者之一,存在于1978年到1988年。 1992年: 在 Opdyke 的论文《重构面向对象架构(Refactoring object-oriented frameworks)》中,对“重构(refactoring)”这一术语进行了全面的描述。 1993年: Wilson 等人的文章《合作对实习生程序员的好处(The benefits of collaboration for student programmers)》,是一个“表明结对工作对编程任务特别有好处”的早期实证研究。在结对编程通过极限编程(Extreme Programming)得到普及之后,出于“验证”的目的,后续又进行了更加充分的研究。 1993年: Jim Coplien 编写了最初的站立会议(Stand UP Meeting)模式。 1993年: “持续集成(continuous integration)”这一短语已经在使用,并在敏捷过程这一称呼之前就出现了这一说法。例如这一年有一篇文章把它与“计划(scheduled)”集成进行了对比,并建议采用后者,理由是持续集成存在“缺乏全面测试”的问题。这也帮助解释了为什么自动化测试会如此受敏捷团队的青睐,因为它是持续集成的使能器(enabler)。 1993年: Jeff Sutherland发明了 Scrum,并作为过程在 Easel 公司使用。 1994年: Jim Coplien 描述了其对“超能的(hyperproductive)”Borland公司 Quattro Pro 团队的观察结果,注意到他们几乎完全依赖于每日会议(daily meeting)“这个项目召开会议远远多过做其他任何事情”,这篇文章也同样被引用为对Scrum 有巨大的影响。 1994年: Kent Beck 编写了用于 Smalltalk 编程语言的 SUnit 测试框架。 1995年: Coplien 在其早期版本的《组织模式(Organizational Patterns)》中,以程序设计模式语言的方式(Pattern Languages of Program Design)命名了“代码所有权(Code Ownership)”模式,这有效影响了后来敏捷用语的发展。然而,他倡导专属的个人代码所有权,并提醒人们不要采用“集体代码所有权(collective ownership)”——他把这同于根本就没有代码所有权。Coplien承认对“个人所有权(individual ownership”存在异议,但他认为其模式的其他方面能够缓解存在的问题。 1995年: Alistair Cockburn发表文章《应用开发中人类因素的增长(Growth of human factors in application development》,提出为什么迭代方法会逐渐被接受的主要原因之一是:软件开发的瓶颈正在转向(个人和组织)学习,并且人类学习本质上是一个迭代和试错(trial and error)的过程。 1995年: 基于与CRC卡同样的灵感,Ward Cunningham 创造了 wiki 这个概念,成为后来的维基百科的原型,这无疑是万维网发展历史上最具影响力的理念之一。 1995年: 在最早的 Scrum 著作中介绍了作为迭代(iteration)的“冲刺(sprint)”概念,然而其持续时间是可变的。 1995年: 在首本描写模式的著作——《程序设计模式语言(Pattern Languages of Program Design)》的“一种有生产力的开发过程模式语言(A Generative Development-Process Pattern Language)”章节中,Jim Coplien 以 Alexandrian 模式风格的形式,给出了“结对开发(Developing in Pairs)”模式的简短描述。 1995年: 在1995年3月-4月版的《面向对象程序学报(the Journal of Object Oriented Program)》中,Andrew Koenig 最先创造了术语“反模式(antipattern)” : “反模式就像是模式,但它并不是真正的解决方案,它提供的东西只是貌似解决方案,但实际上根本不能解决问题。” 1995年: 在 OOPSLA 大会上,Ken Schwaber 和 Jeff Sutherland 联合发布了 Scrum。 1996年: Steve McConnell 描述了九十年代微软公司在 Windows NT 3.0 上使用的“每日构建和冒烟测试(Daily Build and Smoke Test)”技术。其重点不在于自动化而在于应用频率,即在时间上被认为是非常“极端”的日循环。 1996年: 自动化测试是极限编程的一个实践,但并不强调对单元测试和验收测试的区分,也没有要特别推荐的概念或工具。 1997年: Ken Schwaber描述了“每日Scrum站会(daily scrum)”(这在其早期的著作中并未出现,例如1995年的文章《Scrum开发过程(SCRUM Development Process)》),这个活动后来被 Mike Beedle 重新整理成了模式形式。 1997年: 在 Alistair Cockburn 的著作《面向对象项目求生法则(Surviving Object-Oriented Projects)》中,描述了非正式地使用敏捷实践的几个项目(最早可以追溯到1993年),但并未给出敏捷的标签,而只是概括为“增量工作,逐个聚焦”。 1997年: Kent Beck 和 Erich Gamma 编写了 Junit 测试工具,其灵感来自于 Beck 早期在 SUnit 上的工作。 在接下来的几年中,它日益普及,并标志着“捕获和回放”时代的结束。 1998年-2002年: “测试先行(Test First)”被精化为“测试驱动(Test Driven)”,特别是在 C2.com Wiki 上。 1998年: 持续集成和“每日站立会议(daily stand-up)”被列入极限编程的核心实践。 1998年: Linda Rising在著作《模式手册:技术、策略和应用(the patterns handbook: techniques, strategies, and applications)》中转载了 Keonig 对反模式(antipattern)的定义。 1998年: 《反模式——危机中软件、架构和项目的重构(AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis)》这一著作普及了“反模式 (antipattern )”这一术语。 1998年: 在最早描述极限编程的文章《走向极限编程的克莱斯勒公司(Chrysler goes to Extremes)》中描述了几个极限编程实践,例如:自选任务(self-chosen tasks)、测试先行(test first)、三周迭代(three week iterations)、集体代码所有权(collective code ownership)和结对编程(pair programming)。 1999年: 在早期的极限编程精化中,“系统隐喻(System Metaphor)”实践被提出并用于解决业务与技术之间的知识转化和认知摩擦问题,然而这个实践难以理解故而没能推广开来。 1999年: 在一篇写给《C++报道(C++ Report)》的文章中,Robert C. Martin对“迭代(iterative)”和“增量(incremental)”术语,给出了最早的、敏捷观念的描述。 1999年: 在 Alan Cooper 的著作《交互设计之路(The Inmates are Running the Asylum)》的某个章节中,首次描述了“用户画像(Personas)”实践,基于之前的工作以“目标导向的设计(Goal-Directed design)”来构建。 1999年: Kent Beck 在一篇IEEE计算机文章《使用极限编程来拥抱变化(Embracing Change with Extreme Programming)》中首次描述了“简单设计规则(rules of simple design)”,对之前在 OTUG 邮件列表列表上的讨论做了总结。 1999年: “重构(refactoring)”实践,在几年前就已经被纳入极限编程,并由 Martin Fowler 的同名著作而被普及。 1999年: Kent Beck 在其著作《解析极限编程(Extreme Programming Explained)》中创造了“大可视化图表(Big Visible Chart)”这个术语,尽管后来他把此归功于 Martin Fowler。 1999年: Ron Jeffries首次提到使用“橡皮糖熊(Gummi Bears)”代替“故事点(story points)”作为用户故事的估算单位。(后来此事被归结于一个由 Joseph Pelrine 领导的 XP 项目) 2000年(大约): Scrum 的每日站立会议形式中的“三个问题(three questions)”为极限编程团队广泛采用。 2000年(或更早): “驾驶员(Driver)”和“领航员(Navigator)”的角色被引入以帮助解释结对编程,已知的最早来源是一个邮件列表记录。然而值得注意的是,这些角色的现实性一直都存有争议,比如 Sallyann Bryant 的文章《结对编程与神秘的领航员角色》。 2000年: Martin Fowler 的一篇文章中提供了或许可以说是对当时可用的持续集成(continuous integration)实践的最为完整的描述。 2000年: Freeman、McKinnon 和 Craig 在他们的文章《内部测试:用模拟对象进行单元测试(Endo-Testing: Unit Testing with Mock Objects)》中描述了“模拟对象(mock objects)”测试技术,暗指路易斯·卡罗尔(Lewis Carroll)的“假海龟(Mock Turtle)”这一角色。 2000年: Ken Schwaber 首次描述了“燃尽图(burndown chart)”。在富达投资集团(Fidelity Investments)工作时,他试图为 Scrum 团队提供一个简单的工具包,于是发明它,并在其网站上做了正式描述。 2000年: 术语“团队速率(velocity)”添加到极限编程相对较晚,用于替代先前被认为过于复杂的概念——“负载因子(load factor)”。 21世纪初: 尽管这种实践早已不是什么新鲜事,也不仅仅局限于敏捷团队;但部分归功于敏捷实践的兴起,使得“make”类自动构建得以复兴。 2001年2月11-13日: 在美国犹他州瓦萨奇山的雪鸟滑雪度假村,17位从事软件开发或者帮助他人从事软件开发的人相聚一堂,以在他们各自不同的软件开发方法中寻找共识。此次会议的产物就是敏捷软件开发宣言(Manifesto for Agile Software Development)。后来几位会议成员继续合作,成立了敏捷联盟(Agile Alliance)。 2001年: Brian Marick,一位“情景驱动(context-driven)”软件测试学派的公开成员,参与了导致敏捷宣言发布的雪鸟事件。他经常把自己描述为团队的“预兆测试者”,并把一些探索性测试中的实践意识引入到敏捷社区中。 2001年: 定期回顾是敏捷宣言的“团队要定期反省如何能够做到更有效,并相应地调整团队的行为(At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly)”原则的实践之一,虽然还不是必然例行的实践。 2001年: Mary Poppendieck的文章《精益编程(Lean Programming)》,引发了对敏捷与精益思想(以精益或“丰田生产系统”而闻名)间结构相似性的关注。 2001年: Cruise Control,是第一款“持续集成服务器(continuous integration server)”,在开源许可协议下发布。它能自动监测源代码库,触发构建和测试过程,并把执行结果和测试报告档案发送给开发人员。从2001-2007年可以看到大量类似工具的出现,导致可能过度关注工具超过了关注实践本身。 2001年: 在Norm Kerth的著作《项目回顾(Project Retrospectives)》中描述的可视化手段中,“活力震荡仪(Energy Seismograph)”或许可以视为是“妮可-妮可日历(niko-niko calendar)”的先驱。 2001年: Bill Wake的一篇文章指出了敏捷团队所使用的两种不同喜好的估算——相对估算和绝对估算(relative and absolute estimation)。 2001年: “重构(Refactoring)”终于“破茧化蝶”, Martin Fowler发表言论,描述了Java语言集成开发环境中自动化重构辅助工具的广泛可用性。 2001年: 在 Cem Kaner、Jams Bach和Bret Pettichord的著作《软件测试经验与教训(Lessons Learned in Software Testing)》中介绍了一些探索测试技术的技巧,并首次提到“情景驱动的软件测试学派(context driven school of software testing)”。 2001年: 在《极限编程实施(Extreme Programming Installed)》中描述了“快速设计会话(quick design session)”实践。 2001年: 在英国 Connextra 公司,发明了用户故事的“role-feature-reason”描述形式。 2001年: Jeff Sutherland在其文章《敏捷可规模化:在五家公司发明和重新发明了Scrum(Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies)》中,首次给出了“Scrum of Scrums”的描述(总结IDX公司的经验)。 2001年: 极限编程社区早期是赞同“回顾(retrospective)”实践的,比如“XP 2001”大会上的这篇文章《适应极限编程风格(Adaptation: XP Style)》。 2001年: 为了区分“交互的(social)”用户故事与“文档的(documentary)”传统需求实践(诸如用例(use case)),Ron Jeffries提出了用户故事的3C(Card,Conversation,Confirmation)模型。 2001年: 《免疫可预见的项目失败(Immunizing Against Predictable Project Failure)》一文被发表,本文后来很大程度上使得定义项目章程成为一项敏捷实践活动。 2001年: 在 Alistair Cockburn 的著作《敏捷软件开发(Agile Software Development)》,出现了对敏捷项目背景下“反思研讨会(reflection workshop)”的首次描述。 2001年: 术语“项目回顾(Project Retrospectives)”在 Norm Kerth 的同名书籍中进行了介绍。 2001年: Alistair Cockburn创造了“信息辐射器(information radiator)”这个术语,有部分的扩展隐喻,它把信息传递等同于热量和气体的发散。 2002年: Laurie Williams和Robert Kessler撰写了《结对编程技术(Pair Programming Illuminated) 》是专门研究结对编程实践的第一本书,讨论了迄今为止的理论、实践和各种研究。 2002年: 极限编程的发明者之一 Ward Cunningham 发布了 Fit,这是一种基于类似 Excel 表格式的验收测试工具。 2002年: Bill Wake 的早期文章提醒呼吁关注团队内部对于一些常用术语理解可能不一致的问题,例如“完成(Done)”。 2002年: 一个早期的实践者描述了在更为广泛的环境下的运用用户画像(personas):Jeff Patton 的论文《击中目标:将交互设计添加到敏捷软件开发中(Hitting the Target: Adding Interaction Design to Agile Software Development)》也许是在敏捷环境下的第一个正式描述,虽然这一话题至少从 2000 年开始就在一些邮件组被非正式地讨论过。 2002年: 在将精益理念应用于软件的早期(未发表)讨论中,将未发布的特性视为“库存(inventory)”,Kent Beck提到在LifeWare和几个其他的企业运用持续部署。然而,这个想法还需数年时间去提炼和编撰(refined & codified)。 2002年: Scrum 社区汲取了度量“速度(velocity)”的实践。 2002年: 燃尽图在 Scrum 社区中得到普及,以及诸如其替代做法仅仅反转垂直方向的“燃起图(burnup)”,或者更复杂的“累积流图(Cumulative Flow Diagram)”,这与燃起非常类似,但似乎是一个独立的发明。 2002年: 计划扑克的当前形式在 James Grenning 的一篇文章中被列出。 2002年: Rebecca Wirfs-Brock 和 Alan McKean 通过他们关于责任驱动设计(Responsibility-driven design)的书:《对象设计:角色,责任和协作(Object Design: Roles, Responsibilities and Collaborators)》来推广 CRC 卡。 2003年: Industrial Logic 的 Joshua Kerievsky发表了“Industrial XP”,这是一套建议的极限编程的扩展,其中包括项目章程活动,基本上和他们2001年文章中定义的一样。 2003年: BDD 的祖先 AgileDox 是一个自动从 JUnit 测试生成技术文档的工具,它的作者是 Chris Stevenson。 2003年: Bob Martin 将 Fit 与 Wiki(Cunningham 的另一个发明)结合在一起,创建了 FitNesse。 2003年: Kent Beck 在《测试驱动开发(Test Driven Development:By Example)》一书中简要提到 ATDD,但认为这是不切实际的。尽管 Kent Beck 持反对意见,部分归因于 Fit / FitNesse 的普及,ATDD成为公认的做法。 2003年至2006年: Fit / FitNesse 组合让其它工具黯然失色,成为敏捷验收测试的主流模式。 2003年: C2 Wiki上的一篇匿名文章描述了乒乓编程(Ping-Pong Programming),这是结合结对编程和测试驱动开发的一个适度流行的变体。 2003年: 早期的 Scrum 培训资料暗示了未来“完成的定义(Definition of Done)”的重要性,最初只是以幻灯片标题的形式:“关于完成的故事(The story of Done)”。 2003年: Mary 和 Tom Poppendieck的著作《精益软件开发(Lean Software Development)》将“敏捷任务板(Agile task board)”描述为“软件看板系统(software kanban system)”。 2003年: Kent Beck 出版《测试驱动开发(Test Driven Development:By Example)》。 2003年:得益于 XP Day 大会的定期聚会,更多的团队开始实行项目和迭代的回顾。 2003年: 用于快速评估用户故事的 INVEST 检查单来自 Bill Wake 的一篇文章,该文章还为用户故事分解得到的技术任务改写了 SMART 缩写(Specific具体的,Measurable可衡量的,Achievable可实现的,Relevant相关的,Time-boxed时间盒的)。 2003年: Mike Cohn 在其网站上描述了五列任务板格式;那时候,正如 Bill Wake 收集的相册展示的那样,各式各样的变体仍然比比皆是。 2003年: Joshua Kerievsky 创造了术语 “NUTs(Nebulous Units of Time,模糊的时间单位)”,作为“故事点”的替代品。 2003年: Eric Evans 创造了术语“领域驱动设计domain driven design”,并在同名著作中进行了描述,最终成为“系统隐喻(System Metaphor)”的可行替代品。 2004年至2006年: 每日会议被作为敏捷核心实践推广,随着任务板广泛使用,“在任务板前面召开每日会议” 成为最终的关键指导原则。(例如 Tobias Mayer 描述的那样) 2004年: Kent Beck 提出“完整团队(Whole Team)”作为之前名为“现场客户(On Site Customer)”的实践的新名称。 2004年: Alberto Savoia 的文章提出了“极限反馈设备(Extreme Feedback Devices)”,例如熔岩灯或专用监视器,以显示最近一次集成的结果,这是持续集成的一个重大创新。 2004年: 为了验证他关于弱化“测试”术语而代之以“行为”的假设,Dan North 发布了 JBehave。 2004年: INVEST 首字母缩略语是 Mike Cohn 的著作《用户故事与敏捷方法(User Stories applied)》中推荐的技术之一,在第二章详细讨论了这个技巧。 2005年: 计划扑克技术在 Scrum 社区中开始流行,这是 Mike Cohn 的著作《敏捷估计与规划(Agile Estimating and Planning)》中多个规划技术中的一个。 2005年: 术语“Backlog梳理(backlog grooming)”最早记录的使用源自 Mike Cohn 在“Scrum开发邮件列表上”的观点;几年之后,这个实践才被更正式地描述。 2005年: 首个邀请学员思考他们自己的“完成的定义(definition of done)”的练习出现在 Scrum 培训材料中“以后的迭代”部分。 2005年: Jeff Patton 在文章《It’s All in How You Slice It》正规化表达了故事构图(story mapping)的概念,但并没有给出这个名字。 2006年至2009年: 一些新工具的发布,证实了社区在 BDD 上的投入,比如 RSpec 或者更近的 Cucumber 和 GivWenZen。 2006年: Jean Tabaka 在她的著作《协作解析(Collaboration Explained)》一书将项目章程作为有效协作的关键实践之一; 虽然她明确地引用了《Industrial XP》,但她的陈述与 2001 年的文章有所不同,表现出受到了其它来源的综合影响。 2006年: North 与 Chris Matts 合作提出了“Given-When-Then 画布”的概念,将 BDD 的范围扩展到业务分析,并将这个方法写入了《Introducing BDD》。 2006年: Akinori Sakata在其文章中首次描述了妮可-妮可日历(Niko-niko calendars)。 2006年: 描述持续部署核心的首篇会议文章《部署生产线(Deployment Production Line)》,由Jez Humble、Chris Read和Dan North发表在 Agile2006 的会议记录中,是对几个 Thoughtworks 英国团队实践的整理成果。 2006年: Esther Derby 和 Diana Larsen的《敏捷回顾(Agile Retrospectives)》的出版完结了对心跳回顾的编纂。 2007年: 在那个时候,“完成的定义(Definition of Done)”已经是一个完全成熟的实践,它作为一个文本化的清单展示在团队办公室已经变得非常普遍。 2007年: “Kanbandev”邮件列表的成立,为受看板启发的(Kanban-inspired)敏捷规划实践的提供了一个讨论场所。 2007年: 来自看板团队的最早几份实践报告被发布,这些团队使用了一套特别的称为“看板(kanban)”的修订方案(没有迭代,没有估算,带着 WIP 限制的持续任务板),其中包括来自Corbis(David Anderson)和BueTech(Arlo Belshee)的报告。 2007年: 简化的三列任务板格式(“Todo”,“Doing”,“Done”)在当时变得比原始的五列版本更为流行和更为标准。 2008年: Alan Cooper 在敏捷 2008 上的主题演讲,标志着敏捷和交互设计之间争论的正式和解,很长一段时间这两者之间被认为是存在矛盾的。Cooper是被敏捷领袖作为“外部人士”邀请来的,他在第二年已经被认为是“很内部的人士”。 2008年: Cem Kaner给出了“探索性测试(Exploratory Testing)”的一个新定义,反映了这种测试方法的不断完善。 2008年: Kane Mar以“故事时间(Story Time)”作为名称,首先正式描述了“Backlog梳理(backlog grooming)”,并建议把它作为一个例行会议。 2008年: Agile 2008 大会专门设置了一个论坛来讨论“用户体验(User Experience)”的相关实践,比如可用性测试(usability testing)、用户画像(personas),以及纸上原型(paper prototyping)。 2008年: Jeff Patton的文章《新的用户故事Backlog是一张地图(The new user story backlog is a map)》图文并茂地详尽描述了“故事构图(story mapping)”实践。 2008年: 虽然最初提到团队开始使用“就绪的定义(Definition of Ready)”的时间是在年初,但第一次正式的说明似乎是从十月开始的,并且很快就被纳入了“官方”的Scrum培训材料。 2009年: “持续部署(continuous deployment)”实践已经非常成熟,尽管仍有些争议,因为Timothy Fitz的文章《IMVU的持续部署(Continuous Deployment at IMVU)》仍然饱受评论。这篇文章不仅在敏捷领域变得非常重要,而且也是近期备受关注的精益创业(Lean Startup)或DevOps的核心要素。 2009年: 两个致力于探讨看板方法的实体机构成立,一个是旨在解决商业问题的“精益系统协会(Lean Systems Society)”,另一个则是没有那么正式而旨在提升社区的知名度的“有限 WIP 协会(The Limited WIP Society)”。 2010年: Freeman 和 Pryce的著作《测试驱动的面向对象软件开发 (Growing Object-Oriented Software Guided by Tests)》提供了一个整合“模拟对象(Mock Objects)”、“测试驱动开发(TDD)”和面向对象设计的全面描述。 2011年: “Backlog梳理(backlog grooming)”实践升级为Scrum的官方元素,并纳入了《Scrum指南(the Scrum Guide)》。 2015年: James Coplien发表了文章《两人智慧胜过一人(Two Heads are Better Than One)》,它提供了结对编程的历史的概述,可以追溯到 20 世纪 80 年代中期(如果没有更早的话)。 2017年: Janet Gregory 和 Lisa Crispin 创建了“敏捷测试(Agile Testing)”的定义,标志着该主题的第一个简洁的定义。 翻译后记: 直觉让我觉得敏捷实践有所遗漏,比如FDD、ASD等敏捷方法中的实践,以及近年来发展出来的影响构图、D2D等实践、敏捷规模化等方面都未列入。 1.拥抱产品愿景
PO代表客户声音,与相关利益者一起创建产品愿景。每个决策都基于产品愿景。确保可持续开发产品,提供清晰的产品表述给开发团队,提高产品成功的可能性。 2.超越客户期望 真正理解客户的意图与产品的目标,超越客户期望。愉悦客户是终极目标。 3.得到授权 完全得到授权能够迅速做出产品的重要决定,与开发团队可持续步伐相匹配。 4.排序产品待办列表Product Backlog 在优先级、风险、价值、学习和依赖之间进行平衡,对产品待办列表进行排序。 5.偏好面对面交流 面对面对话交流是最好的沟通方式。 6.知晓商业模式business Model。 知道何时应用特定模型。例如商业模式画布、精益创业、影响构图。基于这些模型驱动产品开发。 7.共享经验。 以各种形式,比如研讨会、会议等分享知识、经验和教训。 8.掌握用户故事构图等技术。 既要掌握大局,又可以深入必要的细节。 9.专注于功能。 最大化客户价值,功能是价值的载体,功能包括完成工作的特性、情感、社交等功能。 10.知识渊博。 深度理解产品功能知识,理解构建技术(部件/组成)。对于大型产品或许不可能在细节层次深入理解,但是大致上必须知晓,以便在此基础上做出可靠的产品决策。 11.理解领域。 理解产品的领域和环境。包括对市场机会窗口的敏感性。 12.灵活穿梭于不同层级 定义战略级、战术级、操作级。赢得高层支持采纳战略级解释,获得中层支持用战术级别去获得支持,细节层次激励和提供给开发团队。 13.可用。 快速回答问题以及及时提供有效信息给利益相关者,比如客户、开发团队和Scrum Master。 14.知道何时和如何说“不” 知道产品和服务的核心价值是什么,对于其他婉拒。 15.作为企业家 企业家是PO的最佳比喻。聚焦于市场机遇、业务价值和投资回报率,对可能的风险进行应对。 16.掌握和应用优先级矩阵、产品愿景、路线图、人物画像、画布、Sprint Goal等工具提高工作效率。 敏捷的团队领导者,在团队中起着至关重要的作用:战略层面的工作,帮助团队达成开发目标。根据具体情况指导团队交付成果,使得团队与客户的价值一致。
敏捷团队领导的职责可大致分为四类:人员、产品、流程和项目。根据领导者的具体背景、能力和职业道路,通常不会将每项职责都发挥到极致。另外,随着敏捷团队的演变会按需对四类职责进行适当的调整。 人员—--让团队成员尽量专心工作
产品—--主要在于让所有人集中精力开发正确的产品
流程职责—--帮助团队遵循流程,按需对流程进行调整,让流程顺利运转。
项目职责—--不论面对的是单一项目还是长期持续的价值交付协议,还有另一类职责:将团队的工作与组织的需求联系起来。
培养与团队中各角色的关系 在传统的“命令-控制”式架构的组织模型中,项目主管会告诉团队成员组织希望他们做什么。沟通的形式多是通过团队领导向下传达。相比之下,在敏捷型架构中,敏捷团队领导还需要跟组织进行沟通,将团队的需求告诉组织。现在沟通的形式大多是向上传达。敏捷团队不再只是为组织服务,而主要是为团队服务。 敏捷团队领导与团队中各个角色之间有何关系? 与交付团队的关系:大多数团队成员按根据职能划分的层级结构进行报告,例如开发、质量保证(QA)或架构。应当引导、激发和支持团队成员对团队而非功能组的忠诚。 作为敏捷团队领导,应当引导、支持、鼓励和指导团队成员,而非只是检查团队的工作。应协助他们为了服务于共同的目标而进行自组织。团队的气氛轻松愉快;团队的人却很难管理。要根据团队成员的看法,帮助他们尽可能快速有效地开展工作。应当给予团队支持,让团队以更高明的方式工作,并且适应需求的变化,而不是只顾着榨干团队的工作能力。 与产品负责人的关系:正如向交付团队提供支持一样,还应当支持产品负责人。许多产品负责人会写出待开发项并排定其优先级——然后时间就用完了。敏捷领导可以预先将待开发项全部整理一下,为下一个规划周期进行准备。另一个可提供支持的领域就是与团队中全体成员建立并维持联系。去和利益相关人、管理者和顾问委员会沟通;维持互惠交换关系;进行对话以产出有用的工件——这一类和其他类别的支持活动通常需要耗费大量的时间。由于产品负责人需要维护功能路线图,他/她需要与比其更忙碌的人交谈,因此敏捷领导应当帮助其建立和维护这类联系。而在谈话中究竟会透露什么信息(任何与该领域相关的信息、产品要求、路线图等)往往由产品负责人自己决定。 如果产品负责人没有履行其职责,敏捷领导应该怎么做?产品负责人未能承担起责任是一个非常重大的风险,可能是整个团队成功的最大阻碍。如果产品负责人由于正当的理由遇到了麻烦,敏捷领导可以挺身而出,帮助这位不称职的产品负责人。也许现在他正焦头烂额,需要更多培训,或暂离工作岗位。但是如果产品负责人不承担其责任,不称职,或不希望承担这一角色——你就不必替他出头。将问题的根源暴露出来,以此让产品负责人承担起责任,因为这个问题在组织内的牵涉更广,仅凭你一己之力是无法解决的。 与利益相关人的关系:利益相关人不太可能与团队进行日常互动,他们往往只会直接与两个人沟通:产品负责人,与他谈要求、系统细节和优先级;以及敏捷领导,其他一切事物的联络人。他们希望敏捷团队领导倾听他们担心的问题,邀请他们参加相关会议,告诉他们最新消息。如果产品负责人很忙而利益相关人很多,与他们沟通的担子就会更多地压向你这一边。 照料好利益相关人。他们大多身居要职,如果他们觉得不受重视,你和你的团队就可能不会有好果子吃。以最大限度地提高交付成果的价值为宗旨,帮助他们管理与团队的互动。以包容、开放和体贴的方式与他们沟通——他们也会相应地投桃报李。 与项目发起人的关系:项目发起人(通常是公司或工程部的总裁或部门主管)是重要的利益相关人:他们代表着高管和公司在项目中的利益。他们以公司资金和其他资源为赌注,运行项目,收获组织回报。许多项目有一个或两个发起人。 敏捷团领队应当结识项目发起人。早在起草项目章程的时候就会与项目发起人互动。尽管敏捷团队领导和项目负责人很有可能是章程的作者,但发起人是唯一的签字人,他们可以轻易变更章程,甚至叫停整个项目。之后,他们会在必要的时候于会议上为项目辩护或为你争取更多时间和资源。 你与项目发起人之间的互动与按照传统方式运行的项目中的互动很相似。发起人会问: ——我们是否能够按预定完成目标? ——有哪些风险? ——我们能如何增加成功的机会? ——还有什么事需要告诉我的吗? ——你需要什么? ——我能帮你什么忙? 与团队成员管理者的关系:大多数实施敏捷式开发的组织都是在现有的架构上叠加敏捷式结构。如果所在组织是按职能划分的层级结构,那么,团队成员会来自多个不同的技术职能部门,例如开发、测试和数据库设计。这些团队成员会向多个管理者报告,其中一个也许正好就是你的老板。这些管理者也许与团队联系密切,或者在日常活动中不怎么参与你的团队。 敏捷团队领导和职能部门的管理者的总体目标一致的:让组织持续交付价值。你们的策略也应该一样的:充分发挥相互协作的自组织团队的力量。如果情况确实如此,与职能部门的管理者之间应该能够建立良好的关系,为敏捷团队锦上添花。如果情况不是这样,那么,可能会遭遇敌对关系、部门对抗和公司政治的洗礼,令团队成员垂头丧气。 摘自Gil Broza分别于2012年1日和2日发表在ProjectsAtWork上的两篇文章The Human Side of Agile和Agile Team Relationships。 Gil Broza是3P Vantage的所有者,著有 The Human Side of Agile 一书。 敏捷开发仍然需要文档,只是有所不同。
源代码是最佳文档,没错,但不是全部真相,另外,其可阅读难说最佳! 文档最重要的的作用是沟通,显然文档不是好的沟通工具。文档对自己可用作思考与规划的工具,对团队成员是相互沟通的工具,对组织内部其他团队是知识传递的工具,对组织是资产(某种意义上是需要投入成本维护的负债!),对客户是投资回报的结果之一,对社会是责任/法律核查的依据。 写文档要考虑的要素: 谁是读者?因何而写? 读者要的是什么? 如何让读者易读易理解? 何时写最好?涌现式文档。 如何产出、存放及交付? 敏捷文档的价值观是增值且恰好(Just Enough)。 敏捷文档的准则:轻量化;高质量(准确、最新、简洁、易读、严谨);尽可能趋向自动化(方便、易于维护、保证质量);同步化(明确描述的文档与程序同步,即活文件 living document)。 敏捷开发的文档一般包括: 需求文档:What 及 Why。 架构文档:How 软件系统如何架构运行; 程序文档:精化需求/产品代码 + 验收条件/测试代码;技术实现上表现为实例化需求SBE/验收测试驱动ATDD/行为驱动开发BDD等。 本文是学习Industrial Logic公司的CEO Joshua Kerievsky 《Modern Agile》 一文的摘要。 未经授权,仅为学习之用。 现代敏捷的四个指导原则:
使员工更加优秀; 以安全为先决条件; 快速地试验与学习; 持续交付价值。 “使员工更加优秀”原则指的是对整个生态系统的思考,其中并非仅有用户, 还有评估员、销售人员、经理和购买者等。 “以安全为先决条件”原则,心理安全是高绩效团队所具有的最重要属性。 如果一个人处于恐惧文化中,那么任何精心设计的实践和过程都无法对他有所帮助。 “快速地试验并学习”原则指的是能够“严谨地从失败中抽取出价值”,进而实践于快速反馈循环之中。 “持续交付价值”原则指的是去做到不可能的事情,正如为实现软件部署安全而每天完成五十次的交付。 该原则包括:从质量保证转向质量工程,从短程冲刺转向持续流程,从手工构建转向持续部署。 用“使员工更加优秀”原则替换“客户合作胜过合同谈判”; 用“持续交付价值”原则替换“工作的软件胜过详尽的文档”; 用“快速地试验并学习”原则替换“响应变化胜过遵循计划”; 用“以安全为先决条件”原则替换“个体和互动胜过流程和工具”。 |
Author我是一名敏捷教练致力于帮助软件组织探索和设计更好地交付高价值软件的方法,专注于向软件团队讲述如何创造价值以愉悦客户并利用精益与敏捷指导软件开发。 Archives
六月 2023
Categories
全部
Click here to edit.
|