2018-03-13 05:55:32 weixin_37478507 阅读数 12
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

一、极限编程

极限编程(ExtremeProgramming,简称XP)是由KentBeck在1996年提出的。极限编程是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

1.1、XP的核心价值

XP的核心价值观是沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气(Courage)、谦逊(Modesty)。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱;无论是术语命名、专著叙述内容和方式、过程要求,都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践,在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键,是用“沟通、简单、反馈、勇气和谦逊”的态度来对待XP;轻松愉快地来感受XP的实践思想;自己认真实践后,通过对真实反馈的分析,来决定XP对自己的价值;有勇气接受它,或改进它。

1.2、为什么称为“Extreme”(极限)

“Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它所不提倡的,XP则一概忽略(如开发前期的整体设计等)。一个严格实施XP的项目,其开发过程应该是平稳的、高效的和快速的,能够做到一周40小时工作制而不拖延项目进度。

1.3、XP核心实践

基于敏捷的核心思想和价值目标,XP要求项目团队遵循13个核心实践

l 团队协作:通过客户、开发团队、项目经理三方共同参加的会议来确定开发计划。

l 规划策略: 计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。

l 结对编程:系统的每一行代码都是两个人用一个键盘完成的。

l 测试驱动开发:先写测试,后写代码。

l 重构:不断优化系统设计,使之保持简单。

l 简单设计:为明确的功能进行最优的设计,不考虑未来可能需要的功能。

l 代码集体所有权:开发队伍中任何人可以修改任何其他人的代码,代码不属于某个个人。

l 持续集成:至少每天将整个系统集成一次,保持一个能运转的系统。

l 客户测试:客户自己也是软件开发队伍的重要一份子。

l 小版本发布:尽快发布,尽早发布。

l 每周40小时工作制:保证休息,保持体力。

l 编码标准:必须有统一的编码规范,确保代码的可读性。

l 系统隐喻:将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。

二、 水晶方法

水晶(Crystal)方法论由Alistair Cockburn在20世纪90年代末提出。他把开发看做是一系列的协作游戏,而写文档的目标是帮助团队在下一个游戏中取得胜利。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型,以及记录了一些选择结果的设计注释。水晶方法也为这些产品定义了相应的角色。值得注意的是这些文档没有模板,描述也不太规范,但目标清晰,能够满足下次游戏开始的条件。

对于水晶方法论,根据方法论的轻重可以分为透明水晶和橙色水晶等。透明水晶一般适用于轻量级的团队。不管是哪种水晶,都会对团队的角色、团队的工作项和产出、核心实践、支持过程等进行定义。

三、动态系统开发方法

动态系统开发方法(DSDM)倡导以业务为核心,快速而有效地进行系统开发。可以把DSDM看成一种控制框架,其重点在于快速交付并补充如何应用这些控制的指导原则。

DSDM是一整套的方法论,不仅仅包括软件开发内容和实践,也包括了组织结构、项目管理、估算、工具环境、测试、配置管理、风险管理、重用等各个方面的内容。

3.1、DSDM的基本观点

DSDM认为任何事情都不可能一次性圆满完成,应该用20%的时间完成80%的有用功能,以适合商业目的为准。实施的思路是,在时间进度和可用资源预先固定的情况下,力争最大化地满足业务需求(传统方法一般是需求固定,时间和资源可变),交付所需要的系统。对于交付的系统,必须达到足够的稳定程度以在实际环境中运行;对于业务方面的某些紧急需求,也必须能够在短时间内得到满足,并在后续迭代阶段中对功能进行完善。

3.2、DSDM的基本原则

l 活动用户必须参与。

l 必须授权DSDM团队进行决策。

l 注重频繁交付产品。

l 判断产品是否可接受的一个基本标准是符合业务目的。

l 对准确的业务解决方案需要采用循环和增量开发。

l 开发期间的所有更改都是可逆的。

l 基本要求是高层次的并区分优先级(以在低优先级的项目上获得一定的灵活性)。

l 在整个生命周期集成测试。

l 在所有参与者之间采用协作和合作方法。

四、精益开发

精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于生产制造管理,对于IT系统建设,精益开发的常用工具模型是价值流模型。

4.1、精益开发的基本原则

l 杜绝浪费:将所有的时间花在能够增加客户价值的事情上。

l 推迟决策:根据实际情况保持可选方案的开放性,但时间不能过长。

l 加强学习:使用科学的学习方法。

l 快速交付:当客户索取价值时应立即交付价值。

l 打造精品:使用恰当的方法确保质量。

l 授权团队:让创造增值的员工充分发挥自己的潜力。

l 优化整体:防止以损害整体为代价而优化部分的倾向。

五、Scrum

Scrum 是一个用于开发和维护复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint
backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目.

5.1、Scrum 过程框架

Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum过程框架的基石包括如下三个方面:

第一:透明性(Transparency)。透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。

第二:检验(Inspection)。开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三:适应(Adaptation)。如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。

5.2、Scrum的四大支柱

第一、迭代开发。在Scrum的开发模式下,我们将开发周期分成多个1-4周的迭代,每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的,如果我们选择了1周的迭代,那么保持它的长度不要发生变化,在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能,而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。

第二、增量交付。增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的,它意味着从用户的角度可工作。

第三、自组织团队。Scrum团队是一个自组织的团队,传统的命令与控制式的团队只有执行任务的权利,而自组织团队有权进行设计、计划和执行任务,自组织团队还需要自己监督和管理他们的工程过程和进度,自组织团队自己决定团队内如何开展工作,决定谁来做什么,即分工协作的方式。

第四、高优先级的需求驱动。在Scrum中,我们使用Product Backlog来管理需求,Product Backlog是一个需求的清单,Product Backlog中的需求是渐进明细的,Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候,从Backlog最上层的高优先级的需求开始开发。在Scrum中,只要有足够1-2个Sprint开发的细化了的高优先级的需求,我们就可以启动Sprint了,而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

5.3、Scrum团队介绍

在Scrum的工作方式下,总共只有三个角色,
这三个角色分别是产品负责人(PO),Scrum Master和开发团队。

我们通常可以以划龙舟的团队角色来类比Scrum的角色,划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色,他对产品的方向负责,对产品的Why和What负责,对产品的愿景,产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色,他帮助团队保持高昂的士气,并进行良好的协作,他是一个Scrum的专家,团队的教练,团队的服务式领导。Scrum中的团队,对应到龙舟赛的划桨团队,团队必须协调一致,作为一个整体前进,在这样的环境下单打独斗,各自为政没有任何胜算。

Scrum的开发团队对实现Sprint目标需要做的所有事情负责,包括技术方案和决策,团队分工(谁做什么),执行Sprint开发任务等,而且作为自组织的团队,他们也对他们的工作进度的跟踪和管理负责。Scrum开发团队的主要职责包括如下五个方面:

Ø 执行Sprint

Ø 每日检视和调整,每个开发团队成员都应该参与每日站会,一起检验Sprint目标的进展情况,跟进当天的工作情况调整计划。

Ø 梳理产品列表,每个Sprint都需要花一些时间来准备下一个Sprint,主要用来梳理产品列表,包括PBI的创建和细化、估算和排列优先级顺序。

Ø sprint规划,在Sprint计划会议(Sprint Planning Meeting)上,在ScrumMaster的引导下,开发团队和PO合作,为下一个Sprint建立目标。

Ø 检视和调整产品与过程,每个Sprint结束后,开发团队都要参加两个检视和调整的活动,即Sprint评审会议(Sprint Review Meeting)和 Sprint回顾会议(Sprint Retrospective Meeting)。

5.4、什么是用户故事

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

1. 角色:谁要使用这个功能。

2. 活动:需要完成什么样的功能。

3. 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达:作为一个<角色>, 我想要<活动>, 以便于<商业价值>


张洪强
微信公众号:PMO杂谈 (微信号:zhanghq009)

2018-07-23 11:19:45 toafu 阅读数 1752
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发既不是Scrum,也不是XP。

造成这个状态的原因,一方面是行业特点 —— 软件开发还是一个充满不确定性的手工业,方法套路当然不可避免因人而异;另一方面作为一个提倡端到端软件交付的组织,敏捷开发本身并不能解决我们所有的问题。基于这两点,大家都不是特别愿意去总结ThoughtWorks的敏捷方法,换言之“标准化”就不在我们的基因里。

标准化的初衷

那么为什么这个时间点来谈这件事情呢?从我个人角度来说对内对外都到了必须总结的时间点。在上一篇文章《忘记“规模化敏捷”》中,我批判了市场上的所谓规模化敏捷框架,如空中楼阁,概念打包。但这样的现象确实也表明敏捷开发已经进入大规模采用阶段,一定的标准化是必须的。

ThoughtWorks快20年的敏捷开发实战经验不总结给更广大的社区,于我自己感觉是一种不负责任。对内ThoughtWorks中国已经从我加入时,北京东西宫每天流窜两趟招呼到所有人,变成了全国六地1,200多人的数字化服务公司。每年还是很多人为着敏捷慕名而来加入ThoughtWorks,而我能给新员工分享一点敏捷开发实践的机会可能一年一次都难了。

留在ThoughtWorks的一个重要原因就是差异永远大于共识,这样的环境里想总结点啥,没实战经验保底肯定是会被鄙视的。作为一个开发加入,在近十年的ThoughtWorks生涯里,我做过敏捷开发里除了测试以外的所有角色,如果把咨询的部分经验算成敏捷教练,和最近在努力的UX方向,应该是给了我足够全面的视角来审视ThoughtWorks的敏捷开发。在中国区持续最长时间的离岸敏捷交付团队近4年的经历,和敏捷咨询8年的经历也应该让我有一定经验支撑来谈这个话题。

标准化的范围

即使有上面的经验,也只能聚焦在“开发”,而不是“ThoughtWorks敏捷”。针对市场探索和产品创新的方法仍然存在根本性认知上的不同,数字化时代的不确定性又让此刻去更大范围标准化的想法不切实际。但我认为敏捷开发 —— 即从开发团队启动交付到持续迭代运行 —— 已经为我们应对市场不确定性,构建高响应力组织,提供了基石,让我们能够在数字化时代将整个软件开发逐渐改进为真正的价值和成效驱动,而不仅仅是快速交付了一堆不知道有用没用的特性。

在下面的总结过程中有两个“技术处理”希望大家理解。

第一,软件开发手工业的属性造成了不同的团队成熟度显然是不同的,总结的ThoughtWorks敏捷开发实践并非所有团队都能够做到,但我强调的一点是所有团队都共识这些实践是有价值的,可能出于某种外部约束做不了,比如部门墙造成业务人员无法参与。

第二,尽量不引入ThoughtWorks自己的“黑话”,跟Scrum、Kanban和XP这些经典框架相似的实践,保持命名一致,毕竟标准化的作用之一是对外推广。

换上咨询顾问的帽子,ThoughtWorks敏捷开发方法应该是现在市面上实践过程中最接近敏捷宣言价值主张的实战了。当然距离理想的价值和成效驱动的精益模式仍然有相当的距离,面临的挑战和困难可能不是敏捷开发能够解决的,但这些问题现在却反过来在压迫正确的敏捷开发方法,造成不少团队越来越多的困惑。当一个有追求的开发团队需要持续去解释TDDPair不会降低效率时,技术卓越的追求就在逐步被消磨了。

ThoughtWorks敏捷开发核心原则

铺垫很长,希望尽可能在讨论范围上保持客观,现在让我们一起来看看ThoughtWorks敏捷开发模式。

为了帮助大家理解,我尝试从软件开发实践和管理体系两个维度去解释。先列举一下核心实践,然后从软件开发的几条管理主线帮助大家串联一下这台看似松散,实则精密的机器。这里要再次提醒大家我们讨论的范围仅仅是开发段,所列实践也不会特别关注团队文化建设。

在展开具体实践前,首先要明确ThoughtWorks敏捷开发的核心原则:价值驱动、技术卓越。

这两个四字短语在ThoughtWorks这个开发系统里有着不可撼动的地位。毕业刚加入的热血青年质问项目经理一个Story的价值何在?AngluarReact谁更全面?这样的讨论在内部是被鼓励的。

这两个核心原则甚至上升到了价值观的层面,于是我们认为好的客户一定能够“耐心”跟团队辩论价值,而让团队“听我的”业务人员基本只能维持在一个商务上的甲方。如果开发团队某晚上努力把Angular换成React,管理者(甚至客户)也被要求在强调风险管理的基础上,肯定团队为技术卓越追求付出的努力。

这对管理人员来说近乎是残忍的,这也是为什么ThoughtWorks在2010年左右经历了一批外聘PM的离职。虽然现在我们创造出了很大PM的管理空间,但值得警惕的是如果没有那些“恼人”的价值问题,和技术上的一点偏执,ThoughtWorks敏捷开发模式很可能就不存在了。

ThoughtWorks敏捷开发核心实践

在核心原则下,ThoughtWorks不同团队实践非常多,想要找到万变不离其中的骨干其实挺困难的。记得当年一家保险公司CIO带队来参观,看完早站会后直言不讳没有看懂一个50人的团队在干啥,只看到不同人群在自由组合。于是我花了一个早晨只为解释一小时过程背后的“隐次序”。


(图:一个现场团队的早站会)


(图:这是一个离岸团队的现场)

既然是核心实践,就从一个最小集开始,如果减掉我就认为不再是ThoughtWorks的敏捷开发模式。当然由于ThoughtWorks开发团队更多做的是互联网软件的开发,这个实践集并不一定适用于类似嵌入式设备和合规系统的软件开发。以下是我认为的集合,欢迎大家一起来研讨!

1. 基于统一迭代节奏的全功能团队

刚加入ThoughtWorks的时候认识到开发团队除了开发和测试(当然这里我们认为是QA)外,还有BA —— 业务分析师。10年前这个角色在和任何客户合作的时候都需要解释,当然现在大家都已经在开始谈论UX和DevOps了。全功能团队这个实践本身并非是说要固定哪些角色在开发团队,而是强调为了交付软件所需要的技能都应该在一个团队里。在不远的将来,可能我们会再讨论Data Scientist的融入问题。

这个实践还要强调“统一迭代节奏”,要求团队各个角色同步协作,而不是每个角色自己迭代。我看见过太多的伪全功能团队,一个迭代开发完的Story由QA下一个迭代测试。


(图:全功能团队跨职能协作示意,一个典型团队包含了BA、Dev、QA和UX。)

2. 基于Story的需求及范围实时管理

Story是开发团队的最小工作单元,由于价值驱动的原则,Story INVEST原则是各个角色广泛认可的。如果哪个角色(包含业务)看不懂一个Story,那么大家会认为Story本身有问题。

ThoughtWorks敏捷开发不对Story进行更技术的Task拆分,这样做保证了大家都关注Story承载的业务价值,当然这需要技术能力上的“全栈”文化支持,即大家以能够同时做多个技术栈为荣。

运行成熟的ThoughtWorks开发团队有Tasking这个环节,形式可能是全队在迭代启动会上针对复杂Story进行“实现预演”,也可能是资深开发人员在自己显示器上贴出的彩色纸条,每张纸条承载着一个技术动作。小虫和晶晶是我见过把这种Tasking深入工作骨髓的人,有幸看到他们基于这种Tasking模式的神pair是终生难忘的!


(图:开发人员贴在显示器前彩色的Tasking小纸条)

虽然有整体项目的Backlog,但Story一般是迭代澄清,为了保证统一迭代,BA一般只会提前一个迭代梳理下一个迭代(类似Scrum中的Sprint)的需求。非常成熟的ThoughtWorks开发团队在这个过程中能够让客户或业务负责人持续迭代参与Story澄清,并能够持续调整Story优先级

国内由于固定合同项目较多,很多需求澄清发生更早,但实际上很多人不理解保持一定并发性,正是驾驭软件不确定性的关键。“实时性” 是精益Just In Time能够起作用的核心机制。

范围管理上由于这样的Story迭代机制,基本也需要实时,常用的工具是燃起图(Burn-Up)和累积流量图(CFD来至于Kanban)。Scrum的燃尽图并不推荐,原因是很容易营造一种遵循计划的假象。对于客户/业务和项目管理者,从燃起图能够看到实时需求范围的变化,按期交付风险也能够实时推测。累计流量图在成熟团队广泛应用,它能够直观告诉开发团队瓶颈在哪里,驱动改进。能够收集累计流量图所需的数据,本身也说明团队具备了一定的成熟度。



(图:燃起Burn-Up图示意,上图为一个最简单的统计展现,仅包含已完成和总共的Story个数。下图是一个相对长期和复杂产品,针对Story进行了类型划分的管理。注意这里的“完成”,包含了Story的分析、开发和测试,甚至一些团队Story DoD中要求上线。制造过程中的Story都是没有完成。)

行业里目前很关心这方面的电子化平台,ThoughtWorks由于历史原因,用各种平台都有,目前最多的是Jira、Mingle和Rally。但实际上这些平台主要目的还是为了离岸敏捷交付团队,本地的交付团队很多是物理墙+Excel(或Trello)。Story本身不作为审计和追责记录,真正的交付是线上工作的软件。

3. 基于持续集成和测试前置的质量内建

持续集成是敏捷实践中最广泛共识的技术实践(没有之一)。ThoughtWorks对持续集成的重视可以从历史经典的开源CrusieControl窥见一斑。由于大显示器的普及和CI展示看板的美化,现在各个团队基本都采用一个显示器展示CI的实时构建情况,但历史上还是有很多类似警报灯这样的创意出现的。


(图:为一个典型的团队CI看板展示)


(图:看板一般所在的团队位置。)

ThoughtWorks持续集成纪律有两条核心,第一是必须每次提交触发构建;第二是每次提交必须基于上次的成功构建。这两条纪律是底线。如果有人说哪个团队CI红着没有修复,基本就等于说这个团队没有干活儿,因为理论上对着失败的构建提交代码是无效的。

持续集成对代码管理的要求是主干开发,这是ThoughtWorks开发团队的默认模式。去年和刘冉、覃宇通过《代码管理核心技术及实践》一书阐述了行业内流行的分支开发模式实践和工具,但在ThoughtWorks内部,即使对使用比较广泛的GitFlow模式,也是持负面意见居多。显然主干开发的代码管理成本是最低的,但同时也引入了较高的代码实践能力和协同纪律的要求。

持续集成已经是软件开发过程中质量内建的经典实践,在这个基础上ThoughtWorks开发团队有共识的是测试前置,落地过程中有两个经典方法,即开发的TDD和提前验收(Desk Check或叫Shoulder Check)。

TDD不用在这里多讲了,每年总会有一两次争论,第二个“D” —— Drvien —— 驱动,永远是大家争论的焦点,但先写单元测试是ThoughtWorks程序员基本素养。代码走查形式多样,但成熟团队一般都从单元测试开始,如果你跟骨灰级程序员新老头走查,他会第一句问你“给我看看你的测试”。

提前验收操作起来是比较容易的,即开发人员完成Story后,在最后提交前邀请BA和QA快速在开发机上做展示。这样做的好处是尽量避免Story被移动到后期测试或客户验收的时候,才发现需求实现有问题,返工浪费。由于这个预验收时间很快,所以有些团队说是“站肩膀后面”检查。当然这个不是机械的规定,简单Story也不一定要做提前验收。


(图:提前验收现场,Story开发人员快速讲解实现,现场客户也有可能参加到Story验收交流中。)

ThoughtWorks敏捷开发对回归测试考虑不多,质量内建意味着不希望最后靠测试把质量关,相比之下,大家对代码走查和Pair这些开发过程中的质量实践更看重,但这些实践的频繁运用在很多团队都受到了成本的约束,并非普遍。关于分层的自动化测试也是一个质量保障的核心话题,但随着技术的进步,认知在逐步清晰,我个人认为还不能说是非常成熟的基础方法。


(图:一团队的代码集体走查现场)


(图:开发人员的pair开发,往往会达到1+1 > 2的效率增长。)

4. 基于Velocity和Cycle Time的持续改进

持续改进是每个团队必须做的,回顾会议(Retrospective)是基本形式,回顾的内容很多,从交付质量、实践,到团队氛围。但实质上最基本的改进还是围绕Velocity(即迭代交付的Story点数)和交付时间Cycle Time。这里的Cycle Time还称不上“端到端”,原因是很多团队前期的产品梳理和后期的用户验收还是遵循客户合作节奏,比如2个月一次上线。当然原则上共识的是,每次持续集成构建出来的版本都应该是可发布的。

Velocity是一个很有争议的话题,这个速率理论上只服务于项目管理,即目前规划和实际情况是否出现偏差,是否需要进行风险管理,调整项目范围等。

ThoughtWorks敏捷开发模式坚决反对把Velocity作为交付KPI,即不作为迭代内的开发合同。假设合作上不存在信任问题,还是有一个无法回避的预测问题,如果Velocity和计划的偏差很大,那么实际的调整成本较高。当然这是一个行业问题,在“大规模手工打造”这个行业现状没有改观之前,最好还是能够坦诚开发过程中遇到的问题和变数。

Cycle Time是从需求进入开发团队,到制造出可工作软件的速度。理论上当然是越快越好,Kanban告诉我们流速快的团队效率高、响应力快。如果不注意Cycle Time去“改进”Velocity,很可能造成更多的WIP(Kanban引入的在制品概念)堆积在迭代内,最后大家赶工埋下质量隐患,得不偿失。所以我们可以看到在ThoughtWorks合作的两个百人以上规模的大型团队里,都强调团队集体学习Kanban实践。


(图:一个团队三个半月的累计流量图,能够有效看到在某一个阶段的WIP和Cycle Time数值,并分析潜在问题。)

5. 基于客户深度参与的统一团队

从ThoughtWorks历史的交付项目上来看,能够建立互信持久合作关系(>3年)的客户基本都深度参与了迭代开发过程。中国区历史最长,合作规模最大的三个交付项目都是客户团队和开发团队完全整合的。

客户参加迭代内站会、展示会和回顾会是ThoughtWorks敏捷开发提出的要求。即使在通讯手段相对落后的七八年前,离岸的客户也是几乎每天和开发团队通过电话进行“站会”。这样做的好处不言而喻,大家都能够体会到这种模式下快速建立的信任关系。当然客户和开发团队都有很多其它工作要做,所以这样的协作模式就要求控制每种会议的时间。一些比较普遍的原则有:

  • 迭代站会不超过15分钟
  • 需求澄清每次不超过1小时
  • 展示会1小时以内
  • 回顾会不超过两小时

虽然如此,这样的模式对客户时间要求依然很高。在咨询其它IT组织的过程中,相关业务人员(即开发团队客户)往往会有畏难情绪。但其实只要时间盒控制好,建立这样的协作节奏后,总投入时间是下降的。看似集中方式的合作模式,比如每个月1天时间需求梳理,其实根本没有办法杜绝后续实现过程中发现的细节问题。而到了迭代验收时才说出的“这不是我想要的”,更是巨大浪费的源头。

对比Scrum的经典四会,ThoughtWorks敏捷开发和最后的评审会(Sprint Review Meeting)的差异相对较大。开发团队更希望是针对实现的业务场景进行展示,所以会议的名字也变成了展示会(Showcase)。当然不少团队也会评审迭代的产出,有相关的迭代进展报告。


(图:一大型离岸合作客户将Showcase扩展到整个公司月度的跨产品展示。)

不少和国内客户合作的开发团队有相对更重一些的迭代总结材料,会占用PM不少的时间。这点上需要警惕,面向价值的原则意味着整个团队,包含客户,都应该更多去思考迭代实现的业务,而不是关注迭代大家的工作量。后者应该是开发团队自己去持续考量和改进。

ThoughtWorks敏捷开发管理体系

做了多年的组织转型咨询,如果约束到软件开发领域,管理体系(暂且认为文化部分属于领导力)基本就是以下四个方面:

  • 需求管理:包含从需求澄清到需求最终实现的整个生命周期。

  • 技术管理:包含开发、测试技术的选择和运用。

  • 质量管理:包含开发过程中的质量管理及软件交付前的质量保障。

  • 迭代管理:包含开发团队迭代运作规则及纪律。

显然ThoughtWorks敏捷开发需求管理是围绕Story展开,其核心是能够支持小批量、小批次的精益模式,同时还要能够尽量保证每个Story业务价值明确。《用户故事与敏捷方法》这本书可能是ThoughtWorks内部没有任何负面评价的实践级著作了。近十年时间里,大家稍有微辞的地方可能是书中对故事大小评估的描述,但INVEST原则的抽象可为神来之笔。

Story作为需求的管理方法,所有的技术、质量和迭代管理其实都是围绕这个中心,毕竟最后开发目的是实现价值,而Story承载着业务价值。顺便提一句,Story的质量其实是一个核心问题,ThoughtWorks从来不提倡一句话Story描述,即仅仅表面上遵循了As … I want … So that的经典模式,验收条件对于一个Story来说至关重要。

值得一提的是围绕Story的可视化系统,每个团队都会有一面类似下图的迭代看板,看板上流动的是迭代内的Story,而Story的生命周期则通过顺序的泳道展现给团队所有人。


(图:基础的Story迭代看板设计,黄色卡片上会写出Story的基本信息。)


(图:一个团队的Story看板,每个团队都会有自己的内部流程设计,所以各个团队的看板泳道设计也不尽相同。)

技术和质量管理的核心仍然是前文提到的质量内建。持续集成和自动化测试实际上都将质量管理融入到了技术工程体系里。在ThoughtWorks敏捷开发体系里,很难将技术管理和质量管理分开,重过程质量是这个管理体系的精髓,由此也在2012年演进为《持续交付》的概念。

由于是全功能团队,并工作在统一节奏下,所以迭代管理的范围中,除了类似Scrum四会协作仪式机制,其余硬性纪律较少。为了保证(成果和问题)“集体所有”(Collective Ownership),ThoughtWorks敏捷开发实践方面特别注意不会聚焦到个体,比如我们说到的Story估点和Velocity统计都是团队为单位,不会指定或统计到个人。

迭代过程中的缺陷也不会追述到某个特定开发人员。唯一产生个体比较和竞争的可能是在技术卓越原则下的比拼,比如作为TL,至少你写出的代码应该是让团队其他成员赏心悦目。

虽然本文不谈文化,但这里还是必须强调这样的管理模式本质上是将“价值驱动、技术卓越”上升到文化价值观层面作为支撑才得以实现的。即便经常拿尚奇口中的“tech@core”开玩笑,但实质上这是ThoughtWorks敏捷开发模式能够工作的重要底座。也是为什么很多其他团队感觉ThoughtWorks这种管理模式不可行的核心症结。

最后问一句,和你感受和认知的ThoughtWorks敏捷开发差异大吗?-;)


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

2019-12-02 19:51:59 feiyangyang980 阅读数 12
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波

精益开发

我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。

概述

精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于生产制造管理,对于IT系统建设,精益开发的常用工具模型是价值流模型。

精益开发的基本原则

  • 杜绝浪费:将所有的时间花在能够增加客户价值的事情上。
  • 推迟决策:根据实际情况保持可选方案的开放性,但时间不能过长。
  • 加强学习:使用科学的学习方法。
  • 快速交付:当客户索取价值时应立即交付价值。
  • 打造精品:使用恰当的方法确保质量。
  • 授权团队:让创造增值的员工充分发挥自己的潜力。
  • 优化整体:防止以损害整体为代价而优化部分的倾向。

对原则的理解

杜绝浪费,浪费是可耻的,这个很好理解,但是在这条的描述中,精益提出“把所有的时间都放在能够增加用户价值的事情上”,这样太容易被曲解了,最值得考究的就是什么才算能够增加用户价值的事?及时交付对用户有价值的产品算是增加用户价值,那么我们要做的事就仅此一件了吗?显然太片面,我们需要做的远不止这一件事。健康的团队才能产出优秀的产品,“毕其功于一役”的大决战当然是一场拼尽全力的冲锋,但是“路漫漫其修远兮”,“上下求索”显然又是个长跑的过程,不健康的团队谈不到长远的发展,所以“所有时间”中必然要包括培养出一只有战斗力的团队。再有,概述中就提到的,我们需要通过什么手段消除浪费呢?通过不断地改良流程,敏捷宣言中说“个体的主观能动性以及个体之间的互动优于既定流程和工具”,这只是强调个体的主观能动性和互动更加重要,但是并没有抹消掉流程的重要性,而且敏捷非但没有忽视流程的重要,恰恰相反,在敏捷开发的原则中说“简洁是减少重复劳动的艺术”,而流程就是保持简洁有力手段,这一点在精益中被尤为强调,所以在制定更加简洁高效的流程上花时间绝不是浪费。
推迟决策,就是提出尽可能多的可行方案,有利于针对实际情况做出选择。我们应该把重点放在后半句的“时间不能过长”上。假设我们把相当宽裕的时间留给了提出尽可能多的方案上,我们得到了相当多的可行方案,但是方案再多总要根据实际情况选择最行之有效的那一个,那么怎么评判是不是最行之有效的方案呢?简单点讲就是找到这些方案中最能满足“时间”、“范围”、“资源”三者之间平衡的方案,耗时太长显然就压缩了项目的可用时间,对“范围”和“资源”也必将产生影响。推迟决策是为了找到平衡“时间”、“范围”、“资源”的最佳方案,那么掌握不好“推迟”的时间就是在舍本逐末。
加强学习,这和上面讲到的培养有战斗力的团队相呼应,学习是强化团队、保持团队活力的最佳方式,至于什么是“科学的方法”,我觉得应该是最适合自己团队的方法,是组建读书会、学习小组这类组织,还是搞黑客马拉松、分享讲座这种活动看你对团队的了解,哪种方法最有效,最能持续发展就选那种。
快速交付,精益开发是敏捷开发的一种形式,既然是敏捷开发那就不能不提快速交付,在我们软件开发中的实践就是尽可能缩短迭代周期,并且在每次迭代中给用户提供稳定可运行的并且有价值的软件,这是敏捷开发的核心手段,精益中如此,其他的敏捷方式比如“极限编程(XP)”、“水晶方法”、“动态系统开发法(DSDM)”、“SCRUM”也是如此,只是各种方法都有自己具体实践,几种的方式对迭代的实践我会放到后续的文章中讨论。
打造精品,“XX出品必属精品”,当一个公司被冠以这样的评价,如果这个评价是正面的而非带有讽刺意味,那么说明这家公司得到了用户极高的认可,“赢在用户”一语双关,既是说精品的受益者是用户,也是说只有精品才能在竞争中赢得用户。
授权团队,团队,还是团队,好产品离不开好团队,好团队要培养也要被信任,授权团队可以最大化地激发团队中成员对产品的主人翁意识。用人不疑,疑人不用,需要的是睿智和胸襟,不能放任不管任由其自生自灭,也不能大权独揽,手里攥着大印把角都磨圆了,还怎么激发团队的主观能动性。
整体优化,整体优化不应该被简单理解为全面优化,我认为对整体有利的优化就可以称之为整体优化,当局部优化的程度达到足以提升整体的成效时就是一次整体的优化,这条原则强调的是局部优化的投入不应该大到拖延整体的进度。当你跟上级说我要优化一下项目架构(不要以为架构层面的就是整体,说到底研发团队也只是整个项目的一部分),大概要花两三个月的时间时,可以让软件的执行效率提升20 ~ 30%,否则将来软件的执行效率会很差,一般情况下你会得到什么答复?糟糕一点儿当然是被一口回绝,好一点儿的可能会被问问“现在的架构有什么局限?”、“新架构能带来什么好处?”,多数人在多数情况下是争取不到这么长的时间去做这种拖慢产品进度的优化的,无关于这次优化是关乎局部还是整体。或许经过几个版本的迭代后你所担心的问题终于发生了,软件运行的效率大大降低,这个时候我们应该暗暗冷笑上级只顾眼前利益吗?我觉得我们应该考虑一下自己给出的方案是不是真的考虑了整体,方案够不够敏捷。其实张口就要几个月的时间本身就是没有考虑到整体,技术停下来优化各两三个月那让产品、设计、运营放三个月长假吗,或者你独立出来搞几个月,你确定几个月后你还追的上产品这几个月来的迭代?一个优化需要两三个月的时间这显然是不够敏捷的,甚至无法保证最终优化的框架是不是真能达到预期的效果,“不能达到预期效果”正是困扰瀑布流模式的问题,也是敏捷开发提出短周期提交可用软件所要解决的问题,当你坐在上级的位置上肯定也要考虑局部优化对整体利益的影响,既然我们是在敏捷开发这个大的项目开发流程下,那么局部的优化也应该遵循敏捷的原则,化整为零,逐步迭代。我想针对上面说的花两三个月的时间优化框架这个请求,如果我们提出的方案是三到五个迭代每个迭代两到三周,每个版本都可以让项目开发的效率提升5~10%,再跟上级讲讲不优化可能带来的软件运行效率问题,我想上级点头的可能性会大大增加吧。

2011-09-09 15:51:09 SmartTony 阅读数 910
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波
 自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开发的一种主流方法。没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来新的问题。我在今年6月份上海举办的ScrumGathering中进行了一场敏捷个人话题的分享,我说到,想要Doing敏捷并不难,只要花上几天功夫学习敏捷知识之后就可以在小范围团队中去实践了,而要做到真正的Being敏捷则并不容易,而导致并不是真正敏捷的原因中,人是一个主要问题之一,这也是为什么现在敏捷社区中对人开始越来越关注的原因。

    动起来就敏捷了吗?

    你的团队可能已经开始敏捷开发了,实施之后觉得没什么变化,或者可能变得更糟。我们知道敏捷宣言、敏捷原则和价值观,但是知道和做到是有很大区别的。而要做到之前,我们不仅需要知道,而是需要从意识层面去认识并认可这些深层次的东西,这无异于是一场个人的变革,因为我们需要重新认识自己、认识团队,认识早已习惯的环境。

我们很多人并不真正的认识自己以及团队,这势必会造成不能很好的发挥自己的能力以及促进团队的成功。为了帮助别人,我首先必须让自己先敏捷起来,所以在Scrum过程中不断的对人的思考和实践,我逐步提出了"敏捷个人"这个新概念。

管理者应具备的敏捷理念

你是技术和敏捷方法狂热者,你可能觉得你了解Scrum或者XP, 但是你会发现你实施的时候会有问题。因为你可能不是管理者,你不知道他们想什么。你也不是具体做产品的人,你也不知道他们想什么。广联达作为优秀的IT软件厂商一直都在尝试新的技术和方法过程中不断总结出自己的理解。我们认为,敏捷必须站在多个层次的人的角度去看,敏捷是基于精益的思想,采用优秀的管理实践和优秀的开发实践,以保证目标和客户价值为基础不断追求最佳的投入产出比。而敏捷落地的另一个重要方面就是以人为本,持续优化。

当我与团队成员进行面谈时,你问到技术方面的内容,他们可以谈很多,但是当问到一些有关个人和团队成长相关的问题时会发现,大家对这些软性方面的认识是很缺乏的认识的。而工作绩效的提高,往往又是这些隐藏在冰山之下的因素在起着主导作用。

为了贯彻的把敏捷执行下去,作为管理者,我们要学会帮助别人,并获得持续的优化,只有以这两个为指导才能更好的将敏捷落地。

如果我们把敏捷个人作为一种文化,那么我把它叫做个人文化,也代表着敏捷个人更多的是一个个人成长的代名词。一个公司想要敏捷,我认为需要从图中的三个层次去共同推进。企业文化作用于敏捷组织,精益可以作为一个指导思想;团队文化可以作用于敏捷团队,Scrum和XP可以作为方法;而个人文化作用于个人,敏捷个人可以作为一个很好的框架来帮助个人的成长,进而自下而上的来促进敏捷文化的形成。

我是敏捷个人吗?

    工作中我们都在不同岗位,所有用的技能都是不一样的,敏捷个人并不侧重于硬技能,而更偏重于软技能,他们相信态度可以带动知识和技能。

    "敏捷"这个出现10年的词到现在都没有明确的回答,那对于"敏捷个人"来说就更没有明确的答案,但是,我还是想通过一些问题来让大家简单的认识一下敏捷个人应该具备的一些软技能,大家也可以通过这些问题来简单自测一下。

  1. 每个月都会进行自省吗?
  2. 每2个月都会看至少一本对提高自我能力有帮助的书吗?
  3. 清楚自己的优势并且在工作中发挥出来了吗?
  4. 清楚自己的目标吗?你的目标和团队目标是否一致?
  5. 知道如何有效沟通吗?
  6. 知道提高自己的工作效率吗?
  7. 你现在处于什么状态?有激情吗?为什么有或者没有?
  8. 你对形成敏捷团队有什么贡献?你如何影响身边的人?

一个人的成长是无止境的,所以上面也只是涉及到敏捷个人的习惯、认识自己和管理自己的少量问题。如何让自己变得敏捷起来?这个开始起来很简单,但是一点都不容易。敏捷个人可以帮助大家走出第一步,但是后面的路更长,更难走!敏捷团队也需要认识到,敏捷个人是在不断成长的个人,不能期望每个人突然的改变,它是一个过程,有可能还会比较缓慢,但是一旦形成这个氛围之后,你的团队将会快速的成长。

敏捷个人是什么

敏捷个人虽还显得有些稚嫩,但到现在已经有一些的方法、框架、原则来指导大家进行成长。但是就像管理并不能真正的改变一个人一样,一个好的团队能够影响一个人,但更重要的是他能够通过自身改变去成长。敏捷个人也不能改变任何人,它只能帮助这个人改变自己!也就是说,敏捷团队是一个敏捷的氛围,它起的作用是让大家意识到做一个敏捷个人对自己的意义所在,并促进和帮助个人不断的成长。下面我将概要的介绍一下敏捷个人的一些要点,希望通过这些介绍能够让大家对敏捷个人有个概要的认识。

敏捷背后的成功驱动

要让团队成员成为敏捷个人,则需要激发大家对成功的追求,因为只有对自己的成长要求之后,大家才会积极主动的去追寻成长的道路。

敏捷个人框架

敏捷个人框架和Scrum有点类似,它更多的是一个具有指导性的框架,并不会限定每个人具体应该怎么发展,因为每个人都是独一无二的,每个岗位对软技能的要求程度也是各不一样的,例如业务人员对沟通要求就比开发人员要求高很多。敏捷个人认同个人之间的差异性,你的目标可以不一样,方法可以不一样,但敏捷个人框架提炼出的成长阶段、内容框架、价值观、原则等可以作为成长过程中的指导。

下图是敏捷个人的框架图,包括三个层面、二个阶段和一个指南。三个层面指的是先从意识去改变认识,然后再去学习方法,最后才是应用工具。两个阶段指的是在强调进行自我管理之前先更好的认识自己。一个指南包含了一些价值观、原则和敏捷结果和敏捷生活等实践。

敏捷个人价值观

如果最近因为生活方面导致情绪不好,在没有与人沟通调整过来的时候,工作绩效会比平时低很多。这也是为什么在前面我讲到,管理者需要把团队成员作为完整个人看待,而不能仅仅关注工作结果,而忽略了影响工作绩效的原因。

作为一个完整的个人,敏捷个人提出了相应的三个价值观:快乐、高效和平衡。这个快乐是来自内心的一种幸福感,高效指的是做正确的事和正确的做事,而平衡这一点是作为完整个人更应该经常注意的一点,团队只有保证个人这三方面在不断的完善下,团队才能够和个人持续的改进。

敏捷个人原则

    原则可以作为大家做事应该遵守的一些要点,敏捷开发有自己的原则,敏捷个人也有自己的一些原则。

  • 积极主动:做事勇于担当,负责,积极
  • 知行合一:立刻执行,不拖延
  • 少就是多:要事第一,从少做起
  • 发挥优势:认识自己,充分发挥自己的优势,而不是去极力弥补自己不重要的弱势
  • 方法胜过结果,结果胜过活动:遇到重复性的工作,方法的总结很重要。在达到目标的结果上,采用的具体活动并不重要。
  • 精力管理生活时间管理:每个人的精力是有限的,如何保持旺盛的精力比时间管理更重要。

敏捷结果

    敏捷结果是一个敏捷个人的由一系列的单一练习组成一个提高绩效的最佳实践,每个练习都会有一个知识点让大家来实践练习,下图是其中的一些知识点。

 

一年一度的【敏捷之旅】接下来就要在全国大范围的开展了,期待在敏捷之旅中能与更多朋友面对面的交流。

2010-06-02 11:22:00 rain1999 阅读数 354
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13655 人正在学习 去看看 张传波
转自 http://blog.vsharing.com/agiledo/

使敏捷成为主流
敏捷开发已经被有效地使用了很多年, 即使项目结果很有希望,敏捷开发的采用也主要限制在公司内部。最近,采用敏捷开发的行业已经开始增加,比如保险行业,电信和金融服务领域,但是为了使敏捷 开发变成主流,还需要主要产业积极参与者的支持,散乱的敏捷景象需要被统一起来,敏捷的转变需要是逐步演进的而不是革 命性的。我们需要对大规模敏捷转变提供良好的支持,包括大规模的知识改变,处理必要的 HR 政策,以及可扩展的敏捷工具构架
敏捷开发是随着它的声望而增长的,敏捷过程的数量也是如此。这些包括XP、Scrum、OpenUP、AUP、DSDM、Lean Software Development、Adaptive Software Development、Rational Unified Process (RUP)、MSF、FDD、Crystal Clear、EssUP,以及Agile Modeling。
这 些项目中有很多都仅仅覆盖了软件开发生命周期的某些方面。例如,Scrum只覆盖了项目和需求管理方面,还需要与其它过程集成来完成整个生命 周期,比如XP和Agile Modeling。集成不同的过程非常困难而且耗费时间,主流公司都不愿意承担这些投资。
然 而,EPF项目解决了这个过程集成的问题。EPF是一个为软件最佳实践提供设计,配置以及开发平台的开放源代码组织。这个项目在今年初期就 已经开始,许多 前端的敏捷过程已经或者都将会在EPF内部获得,包括OpenUP、XP、Scrum、DSDM,以及 Agile Modeling。
我 们希望在EPF内部权衡所有这些敏捷方 法,最后开发可重用的敏捷过程的组件,这些组件能够组合在一起开产生不同的敏捷过程,比如OpenUP,XP,以及 Scrum,或者产生你们自己的敏捷过程。公司应该能够增添或者修改过程组件,在内部使用它们,或者使它们能够免费使用或者出售。
敏 捷开发经常以范式转换的方式出现 —— 对很 多公司来说是一个令人恐慌的建议。敏捷转换可以是一个持续的过程。您可以在每个季度转变额外的项目,并且每次您都可以进一步学习和改善您的转变过程。每次 您还可以引进一些实践。比如,您可以以迭代和测试驱动开发开始,然后可以遵循成对编程和配置团队的原则。
有 些敏捷实践,比如自我组织的团队,代表了真实的范式转换。允许团队成员影响结果的确定和让团队成员们真实地支配他们自己的工作和命运有很大的区别。当一个 团队遇到难于抉择的问题时,团队成员向他们的经理求助,经理回答说, 我 要出去喝杯咖啡,告诉我你们的决定。 这让 人们对谁是决定者的理解有了根本的转 变。这样能够将合作与动机引到一个新的水平,通常对生产力有根本的促进作用。
我 们还需要清晰地说明敏捷转变对公司的因素产生了什么样的影响,需要承担什么义务。如果您没有做好重访的准备,比如,您怎样处理测试,您怎样激发并奖赏员 工,您的IT公司与您的业务流程线是怎样联系起来的,以及您拥有什么样的工具框架,那么您就不会拥有全面的敏捷转变。
您 可以通过一个熟练的敏捷教练,对适当的人进行填鸭式教育灌输信息,而转变这个十人工作的方法,但是转变一个几百人的公司同样需要一个可靠的框架。让我们看 看一些需要处理的问题。
由 于Industrial Logic要完成一个在Kronos拥有600员工开发团队的敏捷信息转变的任务,它意识到仅仅依靠几次训练是不可能做到的。为了帮助转变关于XP的基本 知识,这个团队构建了一个基于网络的训练课程,它允许这些训练专注于团队进行XP实际运用训练的高附加值的活动。EPF和IBM Rational Method Composer通过交付电子化的知识来对这个范式进行进一步研究,并且这个交付要以允许采用的公司和团队易于修改的方式来表示。这样促使了知识大规模的 转变,同时允许这些知识被修改以适合单个项目的环境。从我们的经验可以知道,大规模的采用,需要用电子方式转移知识来补充传统的训练模式,无论是通过网站 训练、过程指导、教学指南还是其它的方法。
敏 捷开发对传统的HR关系一直持有一些不同的观点,比如雇员的激励与报酬,职业路线以及职责。我们需要在执行必要的变化时,及早从HR部门和管 理者那得到支持。
敏 捷开发需要在一群视其他人为自己伙伴的人中建立紧密地合作关系,它可以联合团队的领导阶层来改变这个动态关系。通常,在较大的公司中,一个职位的晋升(比 如从开发人员到构架师)意味着这是逃离编写代码这种地位低下工作的方法。但是这些公司需要专门的并且有经验的人充当他们团队中领导角色的导师,而不是挣得 了适当的工资而坐到了一定的位置的监管者。
对合作的重视还改变了您怎样奖 赏和衡量人的方式。衡量一个人不仅仅是评价个体生产力,您需要权衡个体为团队所带来的价值。最有价值的团队成员通常只有较低的个体生产力,因为他们花费了 大量的时间来指导他们团队成员。
这些与HR相关的观念反应了敏 捷价值,一个公司在奖赏和提升它的员工时清楚地说明它所想要的赖于生成的价值是十分重要的。 4 为了使敏捷开发变成主流,我们需要更好地阐述必需的HR变更以及如何实 现它们。
一 个关键的敏捷原则是,对个体和合作的关注要多于对工具的关注,也因此可能会造成这样的结果,许多敏捷导师对工具有敌对的态度。然而,工具框架能够为协作带 来很大的便利,并且对制作敏捷主流也有很关键的作用。事实上,一些传统的工具可能对敏捷开发并没什么益处,还可能约束有意义的合作。但是还有一丝希望 —— 一 个正在被开发的下一代工具,主要关注于软件开发的协作方面。
VersionOne Rally Software Development 已经运行了敏捷项目管理工具,为核心敏捷概念提供支持,比如速率、迭代计划、规模以及研究计划评估,以及可以在一两天或者更短的时间内将工作分解成很小的 单元。IBM Rational 与 IBM Research 最近协作预演了科技代码命名的 Jazz,它超出了当前的敏捷项目管理的解决方案来包含敏捷开发支持,增加了敏捷概念,比如团队合作、透明开发、持续集成,以及测试驱动开发作为第一类市 民。Jazz还是可定制的软件,能够被修改而支持不同的过程。

敏捷开发概念

阅读数 23

没有更多推荐了,返回首页