敏捷

敏捷（共9篇）

1.敏捷 篇一

近几个月来，关于Scrum、技术负债、质量等等问题的争论一直无休无止，先有James Shore的敏捷的衰落一文，而后Martin Fowler在博客上发表了Flaccid Scrum，指出Scrum教练应该承担更多的责任，在推广Scrum的同时，也不能忽视技术实践。Uncle Bob和Ron Jeffies也分别发表文章（Dirty Rotten ScrumDrels，Speed Kills，Context, My Foot，Quality-Speed Tradeoff, Are You Kidding Yourself?）表示类似的观点。

一些敏捷实践者在盐湖城的敏捷圆桌会议中也对敏捷开发中的常见问题进行了讨论，Sean Landis会后在个人博客上总结了常见的十一个问题：

1. 技术负债在敏捷团队中会快速的膨胀。

2. 敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。

3. 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。

4. 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。

5. 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往会想方设法通过消极怠工来掩饰自己能力的不足。

6. 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。

7. Product Owner承担了太多的责任，不堪重负，从而成为团队的瓶颈。

8. 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题。

9. 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一步演变成为政治游戏。

10. 当Product Owner开始决定开发的方向，他就会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。

11. 敏捷实践大多是针对程序员的，很难在组织内平衡工作量。缺乏对团队中的非程序员提供更好的文档以及培训支持。

Chris Tyler在个人博客（注，可能需要爬墙）中针对这些问题做出了回答。

问题一，是事实，但这并不是敏捷本身的问题，只不过是在敏捷导入和实施过程中没有引起足够的重视。经验丰富的敏捷教练往往十分重视工程类实践，会强调重构在迭代中的重要性。很多的敏捷实践(比如TDD，持续集成，重构)及很多敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。Uncle Bob甚至认为应该在最初的敏捷宣言中加入第五条原则“Craftsmanship over Crap”，来强调技术的对成功的敏捷项目的重要性。

问题二，是事实，但这恰恰又是敏捷的卖点。我们应该做到：谦虚有耐心；勇于承诺；团队成员互信互助，而不是互相指责批评；承认自己的能力不足，不断追求进步，需要的时候寻求团队成员的帮助。很多方法论认为只能通过审查监控的手段来确保项目的顺利运行，而敏捷团队更多的是依靠个人的责任心。在优秀的敏捷团队中，能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有走人。

问题三，说老实话，在了解敏捷之前，研发团队才是疲于奔命。敏捷原理打破了传统的思维模式。人很容易犯错误，但是很多敏捷实践(结对编程，持续集成，TDD)能够帮助开发团队及早发现问题，纠正错误。因此敏捷反而把我们从传统的思想束缚中解脱出来。可能是由于对敏捷的过度宣传，导致大家对敏捷期望值过高，认为敏捷开发是解决所有问题的万灵药。其实我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的。如果能够从其他更成熟的敏捷团队或者敏捷教练那里吸取经验这样会更好，否则只能合理的逐步的导入实践。很多敏捷项目确实存在过于频繁的交付，那是由于人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到Done标准的工作量）来调整下一个迭代工作量，

管理资料

如果团队不能自主调整工作量，这其实已经偏离了敏捷。

问题四，是事实。但是这并不意味着不能在不成熟的组织中导入敏捷实践。这类组织可以逐步地导入敏捷实践。很多人太过心急，想“一口吃一个胖子”，但这往往是不切实际的。当然，同时必须要注意的是，不能因为采取逐步导入的手段，而降低敏捷定义的门槛(Ron Jeffries有一篇文章“Agile Is, Not, Maybe”)。

问题五，绝对是事实，敏捷需要勇气，但是这绝对是好事。态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。每个人都会经历从学徒到专家的过程（获得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The Aspiring Software Craftsman）。由于每个人的能力不同，背景不同，能达到的高度也是不一样的。团队成员应该承认个体差异，努力帮助较弱的团队成员，使其快速成长。

问题六，可能是事实，但是这在非敏捷团队中也屡见不鲜。不可否认的是在敏捷项目中，很多人过分强调了YAGNI，因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。YAGNI是很有用的，但是需要其他实践比如TDD和BDD（行为驱动设计）的支持。Kent Beck在极限编程一书中讲述了怎样借助TDD，实现演进式设计。另外需要注意的是，这其实在很大程度上是一个平衡的问题，怎样在YAGNI与预先设计之间做平衡。

问题七，也是事实。但是作为对产品最有热情的人，Product Owner难道不愿意花时间和精力帮助团队开发出符合需要的产品么？敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内就能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可能组成全功能的团队。

问题八，这可能也是事实。其实在其他方法论风行的时候，也遇到过类似的批评，比如RUP。大家都期望找到一种能够解决所有软件开发痛苦的方法论。作为有经验的敏捷实践者，教练，经理和架构师，对敏捷的宣传应当适度，尽管敏捷确实能够解决很多软件开发中遇到的问题，但是它毕竟不是万灵药。不要使他人有过高的期望。

问题九，这绝对是事实。Chris Tyler提出的建议是，尽早与其他部门沟通，大家的最终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈（参见约束理论）。基于这个共同目标，各个部门一起对流程进行修改，就会减少相互诟病。

问题十，这并不是一个问题！Product Owner应该控制产品发展的方向。Product Owner应当熟悉业务，明确他最终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。但作为开发团队不应该对业务方面干涉太多。

问题十一，对于这个Chris Tyler既同意也不同意。敏捷团队是全功能的团队。如果业务分析师、Product Owner没有和团队在一起参与开发，那不是真正的敏捷。敏捷教练、经理也应该承担培训团队中除了工程师以外的成员的职责。对某些团队来说，文档会是一个问题，因为客户总是要求开发团队提供文档。其实行为驱动测试BDD就是一种既能够提供需求文档又能够照顾到代码实现的好方法。敏捷中也有文档（参见“敏捷的文档”），只不过是文档的形式发生了变化，变成了XUnit测试以及代码。进一步BDD可以成为业务人员和开发人员的桥梁，能够使业务人员更好地理解XUnit测试以及代码（另外其实还有Fit）。对于已经习惯于基于类似于IEEE的那种需求管理方式的Product Owner和公司高层们，对开发文档形式的改变，他们应当保持开放和学习的心态，充分信任团队，而不是给开发团队带来阻碍。

最后，Chris Taylor总结到，敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。但是我们不能因为这个就放弃向理想努力。尽管过去有很多团队导入敏捷失败，我们还是不能全面否定敏捷，毕竟也有很多成功的敏捷团队。正如敏捷项目团队在开发中不断进行反省修正一样，我们也要通过反省来加深对敏捷的理解和认识。

作者简介：滕振宇（ Daniel Teng），Irdeto BSS高级软件经理，CSP。对Scrum、精益软件开发、系统架构设计、领域驱动设计有多年研究，有着丰富的实践经验以及教练经验。创建并领导 Irdeto BSS上海开发团队并成功导入Scrum以及极限编程的一些实践。

来自：www.infoq.com/cn/news//03/agile-traps-and-pitfalls

2.敏捷 篇二

在20世纪80年代的时候, 因为美国市场上出现了大量的由德国和日本生产的高质量产品大量占用了美国的市场, 迫使美国原先的制造策略由着重产品的成本从而转为产品的质量。进入了90年代, 由于产品更新换代的速度加快, 市场上的竞争更加转向严峻。日本生产的汽车更新换代的速度比美国快了一倍多, 美国制造商所关注的焦点转变为速度。因此, 美国必须缩短产品开发周期, 来取得实质性的进展。

美国政府为了改变现状, 从而把制造业发展战略目标瞄向21世纪。为了重新夺取美国在世界上制造行业上的龙头老大位置, 美国政府因此资助了里海大学的雅柯卡研究院和美国通用汽车公司二者组织了一百多家相关的公司, 耗费大量人力物力分析研究400多篇优秀报告之后, 提出了一份尤为重要的发展战略决策《21世纪制造企业战略》。在1988年敏捷制造这个全新的新概念第一次被提及, 孕育而生。1990年向世界半公开之后, 马上引起了全世界国家的看重。1992年美国联邦政府将这种初新的制造模式敏捷制造当成21世纪制造业的新型战略。

2 敏捷制造基本原理

必须运用专业化和标准化的信息集成和电脑网络相结合的结构作为基础, 各个企业采用分布式的结构相互连接, 创建虚拟制造下的环境。把竞争合当作首要原则, 从虚拟制造的环境下进行动态选取、择优录取成员, 构成虚拟环境下的企业, 加快生产的速度。

下面从三个方面来理解敏捷制造的内涵分别从市场/用户、合作伙伴和企业能力来深度解析。

2.1 敏捷制造的初始点是及时的对市场/用户需求的响应

由于市场/用户需求日益多样化和个性化, 企业要想要想在全球化市场中竞争取胜, 就需要能够快速响应市场/用户的需求, 这就是敏捷制造思想的出发点。

为了对市场/用户需求做出快速响应, 企业必须首先考虑:a.市场用户是谁;b.什么是市场/用户的需要;c.企业对市场产生的及时回应是否值得?对于这些问题的明确回答依赖于信息技术和企业信息网。在明确以上问题的基础上企业才能对市场/用户的需求做出快速响应, 快速设计且制造高质量成本又低的产品, 以次来满足市场/用户的需求。

2.2 敏捷制造必须不断加强该企业的能力

为了能对市场/用户提出的需求做出快速回应, 企业必须不断提高能力。企业能力是企业在市场中生存的综合能力表现, 对企业能力的衡量要综合考虑企业对市场/用户的响应速度以及企业产品的质量和成本, 为了提高企业能力, 企业必须采用先进制造系统技术, 并依靠信息技术建设企业信息网, 在此基础上企业还要实现技术、管理和人员的全面集成。

2.3 敏捷制造强调采用动态组织

为了能够以最少的投资、最快的反应速度对市场/用户的需求做出响应, 敏捷制造采用灵活多变的动态组织。动态组织是为了以最少的投资、最快的反应速度对市场的需求做出响应, 有两个或两个以上的成员组成的一种有时限的相互依赖、合作和信任的组织、成员可以是来自企业内部的某些部门, 也可以是企业外部的公司, 每个成员只做自己擅长的工作, 一旦成品或者项目任务完成组织即自行解体, 各成员可立即转入其他产品或项目。动态组织发展的最高阶段是虚拟组织或者虚拟企业, 这是一种对市场/用户需求做出快速反应的企业组织形式, 它是有两个或两个以上的而且也成员组成的在有限的时间和范围内进行合作的而相互依赖和相互信任的组织。

3 敏捷制造技术应用

国内外的各大公司及企业对敏捷制造技术都进行了深入的研究并取得了一定的成果, 对敏捷制造的应用也更为成熟了, 这对于敏捷制造的发展来说是非常有利的。这预示着敏捷制造的应用将会更加的广泛, 将在各个行业中得到应用。

日前, 已经有上百个美国公司、企业在开展和敏捷制造有关的实践性活动。欧洲也有不少公司正在进行企业改造和重组。美国生产工业压缩机的Ingersoll-R公司, 1988年建立动态公司采用敏捷制造过程后, 开发技术水平比原来更先进的压缩机只需以前的1/3到1/2的时间, 价格方面也从原先的50万美元变为如今的12.5到25万美元。在这之前原来开发新产品仅设计就消耗工时8到12个月, 从样机制造到试验评定耗时一年到一年半不等。可想而知敏捷技术给该公司带来的利益是有多么巨大。

4 技术发展的趋势

工艺设计从先前的用经验来判断变为定量分析标志着先进制造技术的一个重要发展趋势, 在敏捷制造组建的系统上, 人、技术与组织构成了最基本的三要素。构筑和实施敏捷制造模式需要多种技术层面上的支持, 在先进技术相互匹配的基础上才能充分发挥制造模式带来的优势。因此解决问题的关键首要有关键技术打好基础, 敏捷制造中主要有如下关键技术:1) 并行工程 (CE) 技术;2) 虚拟制造 (VM) 技术;3) 网络技术;4) 模块化技术;5) 系统集成技术;6) 动态联盟;7) 产品数据管PDM技术贯通了如上技术才能真正的掌握敏捷制造技术。从而确定工艺参数, 优化工艺方案, 预测加工质量, 计算机视觉技术、人工智能技术、机器人技术、数字化信息处理技术的加入, 造就了制造技术向着高效化的工艺, 生产过程机器人、数字化的控制以及智能化的方向进行发展。

对敏捷概念的深入研究、内涵以及实践更好地应用于中小企业因为敏捷制造拥有技术、资源等多方面优势。在美国敏捷化协会工作的专家认为资源被限制的中小企业, 以后极大可能成为敏捷制造的关键力量。往后对敏捷的概念、内涵以及实践的深入研究将会更加对其发展作出贡献。

5 总结

3.打造敏捷性企业 篇三

谈到敏捷企业，不妨倒过来分析，问这样一个问题：企业在过去的运行中，有多少时间被无谓地浪费了？从现实观察来看，所有组织当中，时间都在被大量浪费，无论是获取信息的时间、回应市场需求的时间，还是做出决策的时间。很多组织之所以浪费时间，是因为他们遵循非常古老的流程，没有认识到在以前起作用的东西，放到眼下可能会引发致命的拖延。缺乏即时的流程和时时更新的信息，企业会付出惨重的代价，导致成本的上升，宝贵的商业机会被错过，在竞争速度上输给他人。

我们可以用一个三层气旋来示意企业如何浪费时间。第一组气旋叫做领导流程，第二组是管理流程，第三组是运营流程。三组流程加起来共十个气旋，每个气旋代表一个具体的商业流程。

具体细分我们会发现，在所有这些环节当中，都可能产生时间的巨大浪费。换句话讲，引导企业成为一个即时企业、成为一个敏捷企业，就包括一系列环节的改进，比如把资本转化为企业能力；面对内部或者外部刺激制定新的或者经过改良的商业战略（这属于领导流程）；面对外部威胁产生有效回应；把创意变成产品和服务；以目标为导向，人员、文化、技能、组织和工作结构的系列推进等（这属于管理流程）。把这些东西用时间概念推演一下，比如，你会发现把创意变成产品和服务，可能一个企业面临非常漫长的时间，包括内部和外部信息的汇集、分析和分发，人员的组合，创新的管理，市场的对接等，如果管理不到位，都可能是耗时费力的事情。再比如，从运营的这组流程来看，企业从供应链管理到销售订单管理到营销到内部价值创造，流程的所有地方都存在大量可以压缩的时间。

打造敏捷性企业最终的一个核心的目标，是在企业当中达到一种自组织状态。我们的问题是，公司怎样变得敏捷？答案就是从下到上，这意味着控制决策不再单纯来自上层，个体的团队必须被赋权实践。考量服务型企业，我经常说的一句话是，非常有效的标准是看一线员工有多少授权，这并不等于混乱和无政府主义，也不等于完全缺乏计划。设置目标和激发当地行动力，让每个团队都有动机和授权，在这样的自组织框架下，形成整个公司知识管理的闭环。

设想企业遇到某个商业事件，需要处理某种商业问题，整个管理的过程在自组织实现后发生了颠覆性变化，中间会形成一个强有力的闭环，这个闭环的核心是在组织内部制造我们称之为“社会性创新资本”这样的东西。闭环包括个人在企业当中如何学习，在企业当中团队如何形成并开展团队的学习，最终，企业如何把这些知识累计为一个知识库，这个知识库如何进行分享和扩散。通过这样的一个知识库的作用，一个商业问题最后找到完满的答案。

敏捷企业的敏捷度可以分为三种。第一种叫做战略性敏捷度，就是如何发现并抓住改变游戏的机会。第二种叫做组合性敏捷度，能够把人才、现金和管理重点迅速由前景不佳的商业领域转移到更有吸引力的商业领域当中。第三种是运营性敏捷度，即如何在集中的商业模式当中挖掘机会。在动荡的市场环境下，只依赖于一种敏捷度是危险的，换言之，一个好的敏捷企业，必须同时发展三种敏捷度。

敏捷企业的领导者同传统企业的掌门人是不一样的。讲到后者，一个经典的画面就是他被比作船长，船长在过去航行的时候，手持望远镜洞察未来，并坚定不移往前推进。然而今天企业所面临的局面常常是漫天的大雾，企业航船不知道驶向什么地方。企业领袖在这个过程当中产生一个巨大的变化，今天的领导者必须带领企业在重重迷雾中航行，因此对于企业领袖的要求也在发生变化，他必须通过建立敏捷度的多重组合，才能够使自己的企业立于不败之地，无论前面遇到何种惊涛骇浪。

4.敏捷到底是什么？ 篇四

在软件世界里，我们都喜欢跟风。我们从对一种开发方法的青睐转为对另一种开发方法的热衷，其实就是太过极端。有些人已经跟了一辈子的风，最后自己也受够了这种方式。

五年前，我在新加坡做了一场50人规模的演讲。演讲期间，有一位资深人士极其沮丧地站起身来，然后跟我说五念之内UML和RUP就会销声匿迹，而我也将风光不再。我喜欢这种挑衅，于是就温和地问他为什么会这么说。他告诉我说，他的一生都在从事软件开发：“在60年代，我们都是用汇编语言，然后过渡到了Cobol和Fortran，之后又做了数据库的设计。”接着，他又描述了采纳新技术所经历的每一个阶段：结构化编程、面向结构的分析与设计、面向对象、面向组件等等。当听说到一种新的标准建模语言时，他感到很不舒服。我就告诉他，我所经历的是与他不同的另一条技术路线：汇编、组件化汇编、组件化程序设计、面向结构的组件编程、面向对象的组件编程，而现在则是面向对象与面向方面的组件编程。这一路过来都是与组件有关的。而且我们一路过来都在使用某种可以用UML来描述的建模语言。

看来到如今我还在这个阵营之中，而且还打算再待上很多年。那个很不高兴的家伙第二天更加郁闷，因为他被他的老板炒掉了。不过，UML和RUP略显动力不足倒是不争的事实，只是离消亡还远着呢。它们只是在这个快速变化的世界里打了个小盹而已。

我们曾经处于一种极端，即做任何事情都使用UML，并像大多数人一样坚信它在软件开发过程上的强大描述能力；另一方面，我们又倒向了另一个被叫做敏捷的极端。年轻的一代人正在开始着他们的第一次跟风，目前来说就是敏捷了。非常有趣的是，那些稍稍年长的人们正在从软件工程的极端倒向敏捷。我们不停地追逐，而我们所在的公司也在跟随着我们的步伐。

如今，每个人都敏捷了。可不，敏捷之外的就成了愚蠢的。我也要清楚而大声地喊出来：我是敏捷的大粉丝，我们在Ericsson的团队也是极其“敏捷”的。

可是，我所交谈过的大多数人对敏捷真正所讲述的东西并不十分清楚。去年三月，我参加了一场英国的敏捷“传教士”座谈会。组织者原本希望我是反对敏捷的，然而他们失望了。观众让我们为敏捷做出定义，台上那些声称是敏捷专家的“传教士”们开始畅谈起来，

他们不停地强调敏捷最重要的要素就是迭代。那可是完全错误。迭代式开发是RUP的核心实践，而且它远在RUP出现以前就已经存在了。它原本被称作螺旋式开发，是由Barry Boehm在70年代末创建的。于是我不得不帮助他们来解读敏捷：

敏捷是关于三件事情的：

1. 最重要的，敏捷是一门社会科学。这是敏捷最大的特点所在。它关注的是如何让大家像一个团队一样来工作，如何激励团队成员，如何相互合作等等。

2. 敏捷是轻量级的。与RUP完全依赖“显式知识”不同，敏捷还依赖很多隐含的知识。在RUP中，我们努力把我们认为是最佳的实践写出来。不过，既然实际情况是人们根本不读关于开发过程的书，写下它们也就变得毫无意义。相反，敏捷认为要想开发出优秀的软件，有知识丰富的人就足够了。虽然这一点显然会遭受置疑，但事实的确如此。

3. 敏捷也提供了一些技术性的实践。这实际上是敏捷中最不重要的一部分。这些技术性实践大多不是新生事物：就像我前面提到的，迭代与增量式开发都有悠久的历史；用户故事（user story）可以看作某种形式的简化版用例（use case）。最为有趣的新点子是测试驱动开发。我并不是说敏捷的实践技术没有价值，我只是要强调：如果仅有这些内容的话，我们是不会为敏捷如此痴狂的。

就像你们所看到的，软件工程与敏捷抓住了软件开发的不同方面。软件工程的强处在于技术性实践；而敏捷的优势是社会工程。因此，它们是互补的。

软件工程就像是件紧身衣，而敏捷是轻巧的，并且更难于驾驭。问题在于，我们能否集合两个世界的优点。是的，我们能！

最后，软件工程阵营有一系列的实践技术，对岸的敏捷方法也有另一些略带重复的实践。我们能找到一种共融之道吗？是的，我们能！

要做到这些，我们必须用崭新的理念来看待“实践”。我们可以不再赘述过程了，实践取而代之成为了第一等公民。过程只不过是实践的组合。与其谈论第二代软件过程的被动与臃肿，我们不如展望第三代软件过程的灵活与面向实践。

如果你打算看看第三代软件开发过程，可访问我的网站www.ivarjacobson.com。

5.敏捷就是微观管理 篇五

Mike Cohn认为敏捷最大的秘密是敏捷实际上就是微观管理。Mike提到敏捷的所有实践都支持微观管理。他认为：

Daily scrum是对团队每天工作计划的微观管理，确保每个人都会做他们所承诺的事。

持续集成是为了当某些人破坏构建时，能够被大家知道。

结对编程是为了防止开发人员分心、镀金(做的太多，超出了所需要做的事)、只做有趣的工作，并把事情做好。

对于上述观点，Artem Marchenko补充道：

对于很多人来说，敏捷看起来就是大量的微观管理：开发人员需要每天汇报他们的工作，管理细化到每个特性，团队最好能够每二到四周就提交demo，有了问题可以思考几个月并构建良好的架构。听起来像微观管理，不是么?

那么，谁在实施微观管理?

很明显，是项目团队。团队实施微观管理是为了他们自己的利益。团队用微观管理来管理每天的工作和每个迭代的内容。当团队讨论每天的任务时，他们就是为了团队和组织的利益，作为一个整体在实施微观管理，

管理资料

然而，有些时候团队的成员会感觉被微观管理了。

Scrum master可能会过于关注团队的进度。这包括在团队中走来走去，询问任务的进度，质疑团队的估算。有时团队成员也会因为缺乏技术方面的技能或短处而害怕让事情变得透明。其他因素包括：

除了长长的报告、电邮和会议，管理人员还不停的询问进度。

管理人员企图和你讨论技术细节，而实际上他们却不懂。

管理人员根据心情随意改变你正在做的事或打断你。

这种微观管理确实存在于某些试图从传统软件开发向敏捷开发过渡的组织中。就像

Jurgen Appelo所说：

一些管理人员对于让团队一起做决定感到很不舒服，当团队离开他们自己做决定时，他们会感觉对发生的事失去了控制。管理人员认为决策必须是强制性的或至少不是混乱的。但正是这种混乱本身造就了整个宇宙，因此它不可能太坏。

微观管理人员必须认识到，他们应该“负责”而不是“控制”。试图“控制和抑制”通常都不奏效，有时甚至会对生产力产生反作用。

因此，虽然敏捷中充满着微观管理，但不同的是，团队会做这些管理。管理人员必须将权利交给团队，为了项目和团队的利益，每天由团队进行微观管理。

查看英文原文：Agile is Micromanagement

6.敏捷风险管理 篇六

Mike Cottmeyer提出以敏捷开发去识别和舒缓风险影响更为有效，他指出：

敏捷开发方式之所以能有效管理风险因为风险管理过程建立在我们执行项目的结构上，这隐含的意思就是风险在项目中无处不在，风险清单不能包括所有风险，也不能透过团队会议和定期的风险评估来减轻风险，风险处理必须是不能抽离的思想，我们减轻风险的策略不是处于项目以外，而是影响着如何规划和安排工作的本质。

他把风险分成三类：

业务风险– 涉及项目付运能否带来它所预期的价值

技术风险– 涉及技术方案在若干时间及资金下的可行性

后勤风险– 涉及人与其他基建之间的假设

根据Mike所说，敏捷开发的本质就是要求频密的付运、定时的检察和调整，这本身已经是风险管理。

但是也有人认为敏捷开发不是固有地处理风险。

Jurgen Appelo认为敏捷项目经常缺乏风险的关注。

他认为，

Prince2、PMBOK、CMMI都有包含风险管理的部份，但敏捷方法的书本上就很少明确地看到风险管理的内容，对此我感到莫名其妙。

他同r指出，项目经理经常埋头在项目里，而忽略了整体宏观形势，这导致严重缺乏对风险管理的关注。

另外，James Shore认为有效的风险管理能帮助团队作出更实在的承诺，他建议使用风险倍数(risk multiplier)和Burn-up图来管理项目有关的风险。

风险倍数包括常见的风险，例如人事变动、要求改变、工作上的障碍之类，这些风险倍数让你更准确地于设定日期和估计需要多少故事点数(story potints)。

James建议在团队使用较为精确的开发过程(相对于风险较高的开发过程，可参考James网站上这例子)，而且速度(velocity)固定、每个故事都在迭代完结时做到“Done Done”(不仅完成客户需要的功能，而且没留下支持团队的工作，原文出至于James的网站，亦可参考“The Power of Done”一文)的情况下使用以下的风险倍数。

风险倍数

机会率精确的开发过程所使用的倍数热10%1几乎没可能50%1.4伸延目标--只得一半机会，有机会再去完成90%1.8几乎可以成事的承诺

(这些倍数来至DeMarco和Tim Lister的RISKOLOGY模拟器(详文可参考「与熊共舞」一书)以及Todd Little的分析数据)

这风险倍数使用方式如下：

(假设团队的速度为14，十个迭代后发布的话，那么当前可运用的故事点数有140点)

机会率能完成的故事点数热10%140 (140 ÷ 1)几乎没可能50%100 (140 ÷ 1.4)伸延目标--只得一半机会，有机会再去完成90%78 (140 ÷ 1.8)几乎可以成事的承诺

从以上例子中：

让你可以跟项目有关人士和管理人员说：「我们几乎肯定会在发布前完成当中的78点，所以我们先承诺完成功能A、B和C，我们有一半机会能完成总共100点，所以我们安排功能X、Y和Z作为伸延目标，完成好A、B和C之后再去完成他们的，

管理资料

」

所以风险管理在敏捷项目中就如传统项目一样，都是核心部份，重点在于适当的重视、有效地处理而基于这里作出承诺。

查看英文原文：Agile Risk Management

译者附注：

James的网站有更多关于其风险倍数的内容，亦可参考他所写的“The Art of Agile Development”一书，特别是此文没有包括的Burn-up图。此外，风险倍数的使用还有其他注意的地方：

「承诺」背后的意义，值得思考的就是「承诺」到底是什么、管理人员如何理解和使用这里作出的「承诺」。要知道，这些还是机会率，如果最后变成合约，又或者客户拿来争议的「论点」，那么也是没有意思的。

风险倍数的由来，这里的1、1.4和1.8是如何得出呢?到底又有多适合您的项目情况呢?就连James自己的网页上 也有这样一句 “I”m guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don“t track that data” (我在猜这些数字对极限编程的情况有多准确，最准确的方式还是根据过往项目纪录来计算您的风险倍数，但很多公司根本不会记下这些数据)，所以千万不要把这 些数字看成什么魔幻数字。

延续上面这点，如果公司为了提供「承诺」而去收集项目相关数据，这是否对容户有所得益呢?容户为什么要投资金钱给开发公司去收集数据?客户又如何可以知道投资金钱让公司收集这些数据可以有所回报呢?

其他方法如Prince2、PMBOK或CMMI等对风险管理都有值得参考之处，而跟敏捷有关的独特观点则是减少开发上浪费而没必要的过程和活动，之前在「Scrum的风险管理」也有相关的讨论。

还有，要好好管理风险，评估形势的能力很重要，甚至比其方法更重要，例如如何猜量我们是否在“风险较高进行开发”呢?这里其实可以套用Stacey模型和Cynefin模型来辅助

7.敏捷软件开发实践总结 篇七

软件危机一方面是由软件生产本身存在着复杂性,另一方面却是与软件开发所使用的方法和技术有关。软件工程学正是为克服软件危机而形成的新的学科,但可惜的是时至今日人们并没有完全克服软件危机。

软件开发中当连续地犯错误时,我们会对错误进行诊断,并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。经过多次这样的增加之后,我们就会不堪巨大、笨重的过程的重负,极大地削弱我们完成工作的能力。一个大而笨重的过程会产生它本来企图去解决的问题。降低了团队的开发效率,使得进度延期,预算超支。它降低了团队的相应能力,使得团队经常创建错误的产品。遗憾的是,许多团队认为,这种结果是因为他们没有采用更多的过程方法引起的。因此,在这种失控的过程膨胀中,过程会变得越来越庞大。

2001年初,由于看到许多公司的软件团队陷入了不断增长的过程的泥潭,一批业界专家聚集在一起概括出了一些可以使软件开发团队具有快速工作、响应变化能力的价值观(value)原则。他们称自己为敏捷(Agile)联盟。在随后的几个月中,他们创建出了一份价值观声明。也就是敏捷联盟宣言(The Manifesto of the AgileAlliance)。

敏捷联盟宣言如下:

(1)个体和交互胜过过程和工具。

人是获得成功的最为重要的因素。如果团队中没有优秀的成员,那么就是使用好的过程也不能挽救失败的项目。但是,不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作,那么即使拥有一批优秀的成员项目也会失败。

一个由平均水平程序员组成的团队,如果具有良好的沟通能力,将要比那些虽然拥有一批高水平的程序员,但是成员之间却不能交流的团队更有可能获得成功。

团队的构建要比环境的构建重要得多。应该首先致力于构建团队,然后在让团队基于需要来配置环境。

根据调查总结:一般团队都具备创业型团队的特点:一个优秀的lead,带多名水平一般的员工;这样的团队存在两个问题:1)优秀员工的引入,受lead的水平限制;2)员工各自为政的开发模式,分享不够。

团队中的优秀人才并不是越多越好,优秀人才太多反而有更大的弊端。一是人力成本太高,他们可能消耗掉产品创造的大部分效益,那么就不划算了。二是团队分裂的风险太高,因为团队的空间有限,无法同时满足很多优秀人才事业发展的欲望;所以,团队的优秀人才恰好够用就行。

软件开发团队的lead应当具有四项素质,按级别从低到高排列;不错的技术才能(一段)较强的管理才能(二段)丰富的产品开发经验(三段)敏锐的商业头脑(四段)。目前大多数IT企业在物色团队的领导时,主要考察候选人的管理能力和技术能力。对于搞技术出身的人,如果他能当上小头目,一般地讲他的技术才能不会太差。然而即使技术水平是团队里最强的,如果他不具备带领团队所有成员正确干活的能力(即管理能力),那么他也就不不适合当lead。

(2)可以工作的软件胜过面面俱到的文档。

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,要使这些文档和代码保持同步,那么就要花费更多的时间。如果文档和代码之间失去同步,文档就会变成庞大的、复杂的谎言,会造成重大的误导。

( 3 ) 客户合作 胜过合同 谈判。

成功的项目需要有序、频繁的反馈。不是依赖于合同或者关于工作的陈述,而是让软件的客户和开发团队密切地在一起工作,并经常地提供反馈。项目成功的关键在于和客户之间真诚的协作。

( 4 ) 响应变化 胜过遵循 计划。

响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时,应该确保计划是灵活的并且易于适应商务和技术方面的变化。

较好的做计划的策略是:为下两周做详细的计划,为下三个月做粗略的计划,再以后就做极为粗糙的计划。计划中这种逐渐降低的细致度,意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划,就很难进行改变,因为团队会根据这个计划启动工作并有了相应的投入。然而,由于计划仅仅支配了几周的时间,计划的其余部分仍然保持着灵活性。

综观上述四个过程,敏捷开发强调以人为中心,而不是以过程为中心,强调尽可能的沟通(与客户,与团队成员),尽可能地以最简单的设计解决问题(从而能够拥抱变化)。

敏捷开发不同于以往的瀑布式开发,非常适合需求变动的情况,敏捷开发的工作量是随着需求的变化而不断发生变化的,所以整个过程中浪费很少(如图1所示)。

与传统的软件开发方法惧怕需求变化相反,敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持系统设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束所生系统都具有最适合于迭代中需求的设计。

上面的描述非常美好,读者不禁会问:敏捷开发人员如何知道要做什么的呢?

答案是:

(1)他们遵循敏捷实践去发现问题;

(2)他们应用设计原则去诊断问题;

(3)他们应用适当的设计模式去解决问题。

软件开发的这三个方面的相互作用就是设计。

到目前为止,已经有许多的敏捷开发方法可供选择,包括Scrum、Crystal、FDD(Feature DrivenDevelopment)、ADP(AdaptiveSoftware Development)、XP(e Xtreme Programming)等。S c r u m是最常用 的方法之 一。Scrum本意是橄榄球运动中的争球。在一般人的印象中,橄榄球运动是非常野蛮的,球员目的非常明确——破门得分。你可以抱着球跑,可以传给队友……各种方式都可以,目的就是要快速得分。敏捷开发就需要这种精神。下面我们来看一下Scrum大概的流程(如图2所示)。

1、在一个Scrum项目中,产品负责人(Product Owner)建立待开发的产品条目(ProductBacklog),并确定其优先级。开发中需求的改变也要写进去,对于调研、查阅资料、配置环境等也应考虑进去,因为这些也很占用时间,敏捷开发中不提倡冲刺,不提倡加班,讲究发挥团队最大价值;

2、根据所 列P r o d u c tBacklog情况,确定产品一个迭代(Sprint)所要完成的东西,每一个Sprint大概是2-6周的时间;

3、Sprint开始前,需要开一个迭代计划会议(Sprint PlanningMeeting)会议。会上,产品负责人(Product Owner)讲解本次开发要开发的条目(Story),将确定的Story放入Sprint Backlog中来;

4、Sprint开发过程中,团队每天都要开一个站立会议(DailyStand-up Meeting),以便团队之间了解彼此的开发进度;

5、Sprint结束之后 , 需要开评审会(Review Meeting),Scrum团队会在评审会议上把这个迭代的开发成功展示给大家;

6、之后还 要开一个 反思会(Retrospective Meeting),S c r u m团队会回 顾过去这 个Sprint,从中总结经验教训。

传统的项目负责人也罢,敏捷的项目负责人也罢,都会制定计划,而且会为之投入相当的时间。但是他们对待计划的态度截然不同。在敏捷开发中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。

1、知晓变 化 ( 即不确定 因素)可能随时发生,面对突发的变化,要进行相应的调整,而不能继续按原计划执行。

实际工作中我们会遇到:客户提出新的要求,开发团队的经验不能马上告诉:这个技术需求能不能实现或需要多长时间实现。一般需要三天时间进行预研,这样才能知道是否能做,需要多少时间完成。然后修改部分计划。

2、必要时,对项目的过程和实施办法做出随机调整。

(1)调节项目中的已知和未知。

哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(LeeDevin)共同执笔发表了《艺术性管理》(Artful Making)一书。书中提到一个价值1.25亿美元的IT项目最终失败的案例。失败的原因正是由于合作企业一味坚持原计划,亦步亦趋死板执行,拒绝用调整来应对突发的变化而造成的。书中写道:“‘为工作制定计划,然后按照计划做事’成了让他们盲从的真言,直接导致团队采取了毁灭性的做法,带来惨重的代价。……在商界,人人都以为这种问题很少发生,可实际上却非常普遍。”

现实中每一个项目都有其已知的条件和未知的因素,有其确定的一面以及不确定的一面,因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的,因为项目可以是生产性的,也可以是开发性的,还可以是介于两者之间的。生产性的项目不确定性很低,而开发性的项目却是高度不确定的。开发性项目强调预见性,项目执行的过程,就是朝着预见的方向探索前进的过程,而不是制定出严密周详的计划,然后严格实施的过程。也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。

实际中经常遇到类似这样的情况:

Product owner(需求方,可以是产品经理,可以是甲方,可以是单位的主管)不可能一次想清楚所有需求时,产品上线前的灰度发布会有些修改,上线后还要根据用户的反馈,可能还会进行不止一次的修改。(例如,如何鼓励用户进行评价。开始是要求用户必须评价,后来用户评价的频度降低了,而且大多是“哈哈哈哈哈”等无效评价;又选择做趣味性界面,增加了动画,但时间长了,也就降低了趣味性。有效评价还会再次降低,再次面临新的修改。)

(2) 驾驭风险,抓住机遇

人们不想采取敏捷的做法时,往往会找各种借口、理由,甚至抱怨:“这样做太费时间了”,或者“这样做成本太高”等等。所以无论是短期试点,更新数据,随时整合,自动检测,还是其他的各种变通性做法,总是会遇到这样的托辞。

多数情况下,虽不尽然,找种种借口拒绝调整,往往会直接导致效率低下,因为它让企业失去了精简流程、提高随机应对的机会。培养团队的敏捷性,必须进行小型的试点;而小型试点的目的就是找到方法,让重复的工作环节能够低成本地快速完成。而快速且低成本的工作习惯,又能促使团队面对变化,另辟蹊径。快速低成本的解决办法,还能够鼓励团队勇于创新,从而锻炼团队的创新精神。而这种创新又会影响到企业的其他部门,产生涟漪效应。这样一来,降低成本应对变化,就会促使企业重新思考它的商业模式。

(3) 采取可靠的而不是可重复的步骤

必须指出“可重复的”并不意味着敏捷。虽然实施可重复的步骤,已经成为许多企业的管理目标,但在产品开发的过程中,追求可重复的目标却不仅是错误的,而且会极大的遏制产品的开发。可重复意味着用同样的方式,做同样的事情,产出同样的结果。而可靠性却指的是无论遇到什么困难障碍都要实现既定的目标——也就意味着不断的做出调整,应对各种变化,实现既定目标。

可重复的步骤,通过制定标准和对流程的不断改进,来减少产品的质量变化。这是一个源于制造业的词。因为在生产制造中,产出什么样的产品,是已经定义好的。那么可重复性就意味在生产过程中,只要连续输入,就可以产出预期的结果。可以重复意味着从输入到产出的转换过程是可以复制的,而无需任何变化。它还意味着生产的过程不会有任何新情况发生,因为所有信息都全部预先知道,来保证最终的精准产出。但是,可重复的步骤在产品开发中毫无用处,因为首先很难精准地判断出最终的结果;其次项目不同,项目的投入也大不相同;第三,开发不同产品,从输入到产出的转换过程本身更是大相径庭。

可靠的步骤过程关注的是产出,而不是投入。哪怕是投入完全不同,通过采取可靠的步骤,项目成员也能够想出各种办法,不断向既定的目标靠拢。也正因为投入的差异,他们决不会把一个项目所采用的步骤或做法,亦或是试点,复制到另一个项目中。

可靠性是受结果驱动的;而可复制性是受输入驱动的。如果把项目的步骤固定下来,那么项目本身就会因为投入和转化的巨大差异,而变得极其危险。即便是那些声称采用了固定步骤且获得成功的企业,他们的成功并非来自于固定的、可重复的过程本身,而是来自于企业员工在实施这些步骤时,进行的敏捷调整。

敏捷开发项目管理(APM)既是可靠的,又是可预测的:这样的项目过程,由于考虑到了各种不确定性因素,因而在规定的时限内开发出的产品,最能满足客户不断变化的各种需求。这一点是其他任何一种管理方式都无法比拟的。而之所以能够这样,不是因为项目经理制定出了极其周详的任务计划,也不是对这个计划实施了精微细致的管理,而是因为敏捷的项目管理者,营造了一个这样的工作环境和氛围:人人追求卓越,并愿意为实现目标而努力。

敏捷管理虽然是可靠的,但也并非是无往而不胜的,因为它并不能消除所有的不确定性,也无法避免全部的意外。但是,这样的管理方式能够设法转化意外和不确定性,使项目最终走向成功。

总结来说:敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净以及富有表现力。

8.敏捷刚猛 称霸篮下 篇八

年底压轴之作

04年以状元身份进入NBA联盟，09年开始连续三年获得最佳防守球员，这就是强力无双的德华特·霍华德，这个内线的“盖世英雄”绝非等闲之辈：赛场上神勇的他，在防守的时候是铜墙铁壁，进攻的时候更是摧枯折腐。凭借惊人的身体素质、亲吻篮筐的弹跳、能在禁区内横行的力量、超长的臂展和瓦斯爆炸般的爆发力，以及赛场上一个个的爆扣盖帽，这位具有神话色彩的明星球员，为NBA增添了不可磨灭的亮彩!

作为2011年底的压轴之作，伴随刚刚结束的霍华德3D中国行诞生的新战靴adipower howard性能正如其名，从内置外皆由力量浇灌。与此同时，作为为内线球员设计的球鞋，如何能让球员运动时脚下更加安心，远比让他们更快重要得多。

中锋球员的守护神

adipower howard便是这样一双兼具力量和舒适的典型内线球鞋。对于中锋来说，面对激烈的内线拼杀，球鞋的保护性异常关键，而这双鞋能够有效地包裹住霍华德的脚踝，其脚踝处坚固厚实的设计，为他提供最舒适和最稳定的保护；全新升级的SPRINT SKIN鞋面材料在轻质的前提下，为穿着者提供极致舒适的延展性及支撑性；中底的Alive科技提供额外的缓震，使霍华德更轻松地做各种跳跃，更自如地应对各种挑战；独特的Z-Torsion防扭转系统使霍华德在场上的每一步都更稳定。每一个细节设计，都成为霍华德活跃赛场不可或缺的守护神。

多款配色选择多多

此次在11月1日全国同步上市的adipower howard同样在配色上下足功夫，率先上场是称霸场上的黑白蓝和灰白篮霸气款，之后在12月会有冷酷帅气的蓝白色和火热劲酷的正红圣诞款以及白黑配色，选择多多，个性无限，为你打好入冬前最强劲的装备之战。

9.敏捷的近义词 篇九

敏捷的近义词

生动、快捷

灵敏、灵便

灵活、迅捷

矫捷、灵巧

机敏、聪明

飞快、火速

伶俐、急迅

敏锐、活络

赶快、灵动

快速、麻利

圆活、迅速

敏捷造句

1.他动作敏捷，眨眼间就爬上了顶。

2.小松鼠在树上窜来窜去，行动非常敏捷。

3.他思维敏捷，谈吐也锋利，驳得对方哑口无言。

4.警察叔叔敏捷的身手让围观群众都为之赞叹。

5.游泳健儿以优美而敏捷的动作游出了好成绩。

6.小猴子在树上敏捷地跳来跳去。

7.他行动非常敏捷，一转眼的时间就没了踪影。

8.早就听说他思维敏捷，今日一见，果然名不虚传。

9.他运球、转身、投篮的动作既连贯又敏捷。

10.这学生天资聪颖，文思敏捷，下笔成章，将来未可限量。

11.爷爷七十多岁了,头脑仍然很敏捷。

12.王老师才思敏捷,下笔成文,真令我们这些学生佩服之至。

13.他敏捷的辩别力使他急躁得毫无耐心作深思熟虑的判断。

14.我也希望自己能才思敏捷，下笔成章，然而就是做不到。

15.小明反应相当敏捷，只要老师教过的，他都能举一反三。

16.别看这只猎犬长得膘肥体壮，追起猎物来可敏捷得很呢！

17.他个子高,头脑敏捷,身手灵活,很适合篮球和排球运动。

18.这女子年方十八妙龄，才思敏捷，国色无双，待字闺中。

19.这个学生，才思敏捷，词意清新流畅，写文章时，没有丝毫的寻章摘句痕迹。

20.王老师才思敏捷,下笔成文,我们真是佩服之至。

21.她文思敏捷，在大学中文系读书时，就被同学们称为七步之才。

22.到底是年轻人,思维敏捷,锋芒逼人,提出的问题不好回答呀!

23.他的文思敏捷，信手拈来，总是佳言妙句。

24.老鹰敏捷地扑向小鸡。