敏捷是局部优化的吗?

2013-11-09  来源:本站原创  分类:管理  人气:2 

据我对敏捷社区中人们扩张敏捷边界的建议的审视,我认为敏捷正逐渐进入到局部优化的危险之中。

在继续下去之前,让我先回顾一下对优化系统和局部优化系统的定义:

“优化系统是在整个系统的价值流之上对系统的优化或对浪费的消除的系统。”

“局部优化系统是在系统的部分价值流对系统的优化或对浪费的消除的系统。这有可能会导致整个系统效率降低。”

项目价值流

敏捷专注于项目价值流,这很正确,我认为没人会质疑:以敏捷的方式执行项目时项目价值流是最大化的。

敏捷是局部优化的吗?

那项目之外的价值呢?项目集和公司价值呢?

项目集价值流

如果我通过所听到的被最频繁提及的一致的意见来遵循敏捷,那么就会缺乏下面两种项目信息:

项目记忆 —— 关于项目是如何规划和执行的信息。

解决方案记忆 —— 关于项目的技术或功能的解决方案

如果我在便条上写用户故事,通过看板进行管理,我的回顾记录、应用程序和自动化测试用例是最后主要的文档,那我能回答一下这些问题么?

  1. 我怎么才能查找之前的项目以充分利用机会?我非得先通读代码和测试,然后再通过某种方法才能决定如何充分利用机会么?
  2. 我怎样才能回顾之前的项目历史,查看之前是怎样进行估算的,以帮助我这次作出更好的估算?
  3. 既然我们认识到永远也没有足够的时间去创建出所有的自动化测试用例,我怎么才能知道如果一个新需求变更是否正在实现某种设计之外的功能,并将产生我无法预期的副作用呢?因为我还没有自动化测试来确保这个需求变更当前的正确性。
  4. 我怎样才能确保我的解决方案能够符合多个相互没有高层认识的项目呢?
  5. 如果公司雇员已经完全换血,我有足够的文档在未来十年中来维护这些应用程序么?
  6. 如果部门中的现实是,在项目进行时部门中许多人都不能专注在项目上。那我怎样才能管理这样的部门呢?对于这类情况我需要更多的文档么?

从本质上说,敏捷软件开发项目是独立的项目,主要由全职成员组成,且几乎没有跨越项目的监管。这导致了对项目集价值流关注的更大的需求。

公司价值流

或许最近最麻烦的倾向之一是这样的说法:不应再进行任何估算了,因为它们必然是错误且浪费时间的。建议直接启动项目,在项目进行两三个迭代之后就可以确认速度了,据此速度给出完成项目的精确估算,并通知客户。

这一说法是从整个项目的角度来看的。每个启动的项目都需要商业案例的支持:投入X美元将获得价值Y的回报,并且这在商业上是可接受的。如果我们不再对项目进行估算,我们将会冒后面这些风险:启动错误的项目;消耗项目的投资,直到我们确定花太多钱了,或是回报的价值太小了。

如果我们真的关心公司长远的生存能力,那么宣称我们不再需要进行估算是荒谬的。这其中隐含了我的信念:用户故事点必须转换为小时数。在我与开发人员的讨论中,他们要求每个用户故事都有小时数,以确保他们走在正轨上。

虽然我喜欢拿用户故事和用户故事点数来进行估算,但如果我们不把用户故事点转换为小时数,那我们就是局部优化的。我们在把开发过程置于满足商业案例之前。不把与项目的商业案例相关的估算的上下文告诉开发人员,就相当于我们在商业案例和开发人员之间形成一个隔离层。我们会让项目迭代更加高效,但同时也可能牺牲了满足商业案例的能力。

但商业案例不正是项目存在的理由吗?

三种确保敏捷项目不是局部优化的方法

  1. 对项目进行估算 —— 确保对项目进行了估算,确保估算被纳入了让项目有存在的理由的商业案例之中。这些估算必须给予它们应有的关心和关注,而不仅仅是为了让项目通过审批而估算。我对如何对敏捷项目进行估算的建议改天另行探讨。
  2. 创建轻量级的解决方案架构交付物 —— 确保项目的解决方案架构的定义在高层次上进行,确保所有人都对这一解决方案有统一的认识。而后,这些交付物能用于项目监管,确保一致性并能充分利用项目集中跨项目的机会。
  3. 把用户故事估算转换为小时数并对时间进行追踪 —— 将用户故事转换为小时数,与开发人员一起设定预期时长,也为业务案例提供信息以确保项目走在正规之上。追踪时间,这可能会给每个人的日常工作生活带来不便,但实际上确实对项目集和公司有很大的价值。虽然了解项目的速度可以很好地进行预测和规划,但无法让我了解下面这些:
  • 何种类型的工作是我们估算不充分的或是花了比预期更长时间的?
  • 何种类型的工作是我们估算良好或是只花了比预期更短时间的?
  • 何种类型的工作是我们忘了估算的?
  • 我们遇到的什么问题增加了我们完成任务的时间?

总结

“我们以敏捷方式运作项目,是否在牺牲企业长远目标?”我认为没人会认为敏捷不是最好的执行项目的方式。但我确实认为有时敏捷仅仅关注项目和项目内的客户的价值,这可能会导致缺乏对项目集和公司价值的关注。

在对过程进行优化时,我们要确保时刻把整个价值流铭记于心。否则,会有一堆非常成功的项目存在于许多失败的公司之中。

关于作者

敏捷是局部优化的吗?
Terry Bunio
目前是Protegra的首席顾问。Terry从未想过成为一名项目经理。他的主要职业生涯都是在数据架构方面。随着时间的推移,Terry发现他喜欢上了帮助建立团队,增加客户信赖,促进个人成长,从事项目工作和帮助指导解决方案。这些似乎就是一些人眼中的项目管理。作为一名有实践经验的项目经理,Terry以挑战惯性思维和打破书本上理论的敏捷和现实世界的方法间的平衡而为大家所熟知。Terry致力于遵循精益原则来实现敏捷。

相关文章
  • 敏捷是局部优化的吗? 2013-11-09

    据我对敏捷社区中人们扩张敏捷边界的建议的审视,我认为敏捷正逐渐进入到局部优化的危险之中. 在继续下去之前,让我先回顾一下对优化系统和局部优化系统的定义: "优化系统是在整个系统的价值流之上对系统的优化或对浪费的消除的系统." "局部优化系统是在系统的部分价值流对系统的优化或对浪费的消除的系统.这有可能会导致整个系统效率降低." 项目价值流 敏捷专注于项目价值流,这很正确,我认为没人会质疑:以敏捷的方式执行项目时项目价值流是最大化的. 那项目之外的价值呢?项目集和公司

  • 由外而内看敏捷软件开发(二) -- 从开发模式看敏捷 2014-11-12

    本文的第一篇阐述了敏捷软件开发的业务目标 -- "可持续的快速交付和稳健的灵活性",这一目标的实现,需要多个层面的支持.如图(一)所示,业务成功是最终目标,它需要有效开发模式的保障:开发模式的实施又离不开团队组织和技术实践的支撑:最后,通过持续改进.系统优化,获得持久的成功.这一层次关系中,外层是内层的目标,内层为外层提供支持. 图(一) 由外而内看敏捷 本系列文章将按照图中所标示的五个部分,由外而内分别阐述敏捷软件开发的各个方面.这也是文章题目(由外而内看敏捷) 的来源.本篇将探讨敏

  • 中国敏捷实践中的误区(一)敏捷不是银弹 2014-01-06

    不少公司在尝试实施敏捷开发,敏捷实践在中国越来越流行,但当中敏捷涉及思想和意识上的转变,容易造成各种管理和实践上的差异,笔者常见的有三种情况. 一.小瀑布开发 敏捷当然不是小瀑布开发,很多团队开始四周迭代时,都希望可以逐步改变团队以前的开发习惯,例如:单一功能团队.团队之间交接,然后就会发现团队在这四周内依然像瀑布式开发. 我们都鼓励短迭代,两周比四周能得到更快的反馈,两周迭代比四周迭代更有效打破前面提到的老习惯,而要达到两周迭代,就必需要适当的实践配合,用户故事纵向划分.敏捷建模.测试驱动开发

  • 敏捷?Scrum?吹皱一池春水,干卿何事! 2013-10-04

    2008年9月20日,ScrumChina 2008 Gathering活动在上海壹号码头酒店顺利结束,参与者约55人,分别来自上海.杭州.成都.北京.香港.新加坡.美国等地. 活动归来,失望远甚于之前的期待.也许,此次活动可以作为一个侧面,反映出国内某个群体对敏捷的理解和应用现状. 会议以Open Space的形式进行,首先由Bas Vodde介绍了Open Space的缘起和基本概念,还有本次活动的主题--Scrum in China.接下来参会者贡献了十多个话题,随着时间的推移,也有新的话

  • PMI敏捷认证专业人员知识体系 2013-10-09

    美国项目管理协会(PMI)没有为其新推出的美国项目管理协会敏捷认证实践者(PMI-ACP)考试的备考者提供专门的参考书,而是给出了考试范围和参考书目列表,由此构成该认证的知识体系. 持有项目管理专业人员(PMP)认证的人有项目管理知识体系(PMBOK)指南作指导,所以很多人期待敏捷认证也能有相应的知识体系指南. Chris Bodgwic是一位PMP,他说:"我原以为,既然PMI提供了敏捷认证,那么就会提供关于此认证的敏捷知识体系," 实际上,Chris和其他准备PMI-ACP考试的人

  • 掌握Scrum 实现敏捷 2013-10-24

    Joh scumniotales是Scrum早期开发者之一,现任Serena Software公司生命周期管理副总裁.scumniotales介绍了Scrum和Agile的商业及技术发展趋势,同时描述他在Scrum初期研发阶段所积累的经验,以及目前Scrum发展的现状.最后,对于大众及管理层对Scrum应抱有哪些期待.是否应该采纳Scrum等,John Scumniotales也提供了重要建议. 你能从体育运动中学到什么?比你想到的更多!你是否知道敏捷开发可能源自橄榄球运动吗? 在一篇极具创新和

  • 将敏捷团队从基础工具环境搭建中解脱出来 2013-11-03

    "敏捷宣言"中提到:"个体与交互胜过流程与工具".然而,对于敏捷团队来说,正确的工具搭配和流程可以起到催化剂的作用.采用敏捷的组织越来越多,而且很多团队都是在分散的地点工作:敏捷团队要想成功,良好的基础工具环境必不可少.要想快速搭建这个环境却常常使人挠头,因为要让多种工具协同工作.不过,现在有了像 Buildix和Assembla这样的工具,要感谢它们.因为有了它们,面临环境构建问题的团队可以快速通过工具设置阶段,进入到正常的工作流程. Jose Noheda指出:

  • 安全代码开发:敏捷的牺牲者? 2013-11-05

    敏捷团队以快速产生可靠和高质量的代码而著称.然而,快速交付的压力可能会导致走捷径的评审,缩减测试并缺乏对安全代码的重视.安全开发与敏捷共存是否只是一厢情愿的想法呢? 根据一项中小型企业的研究表明,敏捷团队并没有把安全当回事,即使是开发通过Web访问的系统.该研究引用说, 采访表明,小型和中型的敏捷软件开发组织不使用任何特定的方法来实现安全目标,即使当他们的软件是面向Web的,是潜在的攻击目标.这种情况下,研究证实即使在某些案例中安全是被明确要求的,安全设计作为实施团队的输入要求之一,最终的结果是

  • 敏捷体验设计的5个设计工作坊模版 2013-11-05

    和以往的那种简单粗暴的"头脑风暴",或者索然无味的"需求评审"不同,敏捷体验设计中的过程永远是开放的,强调在和客户的互动中识别需求,并产出设计,最终对项目交付内容达成共识.过去的五年里,我参与了几十次和客户的设计工作坊,这里把我经常使用的五种设计工作坊形式分享给大家. 模版1:用户价值定义 用户价值的定义是任何软件体验设计的基础──到底解决了什么用户的什么问题.对于问题的定义越准确和清晰,越能够对产品或特性设计方向达成一致,当所有的客户都认为,解决用户A在情境B下遇

  • 印第安人的灵魂--敏捷回顾 2013-11-07

    印第安人在赶了3天路后,会停下来小憩一天,因为他要等着自己的灵魂跟上来.敏捷开发在经历了一次迭代或者冲刺(Sprint)后,也需要休整,以等待团队的灵魂跟上来,这一过程被称之为"敏捷回顾(Agile Retrospectives)".敏捷回顾与项目总结会议不同,它并非项目结束之后的盖棺论定,而是在项目过程中,通过回顾会议及时总结上一次迭代中的得与失,以期达到改进项目开发.团队合作等敏捷活动的目的. 如果将项目开发比作是一次征途,那么在项目中期的短期休整是很有必要的.然而这种休整并非是将

  • 敏捷开发模式中的需求规划 2013-11-07

    敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现:其次打散的需求全部实现之后,组合起来的要是一个整体,而不是散碎的个体,这样就要求需求规划非常完整,需求拆分非常精确.所以个人感觉敏捷开发提升了开发效率,但是对需求规划的要求更高了.如果是产品经理来担当PO的话,就是对产品经理的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 很多人认为

  • 敏捷实施中的学习与阈限 2013-11-08

    给读者的话:如果你是首次接触开放式敏捷实施的一系列文章,你可以先回过头去看看这一系列文章的第一部分.第二部分和第三部分.上篇文章(第三部分)描述了阈限(Liminality)的概念,在阅读本文之前,先读一读这些概念是非常有必要的. 阈限状态中的稳定性 阈限是令人不安的,并且还会产生压力.关于开放式敏捷实施的一个设想是,在典型组织里引入敏捷会产生组织级的阈限.如果使用过渡仪式的方式来处理这个阈限,那么创造一个快速而持久的敏捷实施还是有可能的. 开放式敏捷实施背后的核心概念就是认清和解决阈限问题可以

  • 微软开发平台事业部全球资深副总裁潘正磊谈Visual Studio敏捷开发与Azure在国内的发展 2013-11-19

    2013年12月5日,TechEd 2013大会在北京召开,这次大会以"创新.开放.社区"为主题, 来自云微软和相关合作伙伴.社区的技术专家在会上和大家分享了微软的最新技术进展,今年是TechEd进入中国20年,微软在会上正式宣布启动第二届微软云创益大赛,开发者可以通过大赛官网报名参赛. 会上,我们围绕"敏捷开发"."Visual Studio"."Azure"等问题采访了微软开发平台事业部全球资深副总裁潘正磊女士,潘正磊于1

  • 腾讯敏捷教练艾永亮:敏捷企鹅的创新功夫 2013-11-20

    2011年6月24~25日,敏捷实践者的盛会Scrum Gathering大会在上海召开,此次盛会云集了传统行业和互联网行业的众多知名企业,如百度.支付宝.SAP.爱立信--来自于腾讯的嘉宾们也带来了腾讯6年敏捷实践的精华--创新的敏捷实践,结合着腾讯实际业务,故事性的展现了各项实践的由来和价值. 腾讯公司敏捷教练&高级项目经理艾永亮在本次活动中分享了腾讯在敏捷探索中的六项独特的实践: 本文将回顾一下其中最为吸引人的关于如何做到极速开发的几项实践. 2009年最火的游戏QQ农场,一周最多发布23

  • 敏捷开发模式中的四种会议 2013-11-25

    从敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要.应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好团队,好的团队一定经常开会.经常开会是需要时间的,因此有利有弊,如果会议时间和节奏控制的不好,就会占用掉团队很多的精力和工作时间,那就得不偿失了.在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同的会议上所讨论的内容是不一致的,只要把握住会议的关键点,就可以为团队的敏捷模式服务. 关于开会,日常

  • 敏捷应用生命周期管理 2013-12-08

    Agile ALM使用敏捷的价值观和策略来充实了ALM,ALM的敏捷做法提升了产品的质量,缩短了上市时间,且有利于开发者以一种更加愉悦的心情来工作.我对Agile ALM的定义可归结为,一些灵活的.对改变持开发态度的.高质量的过程和工具链.这是其中的一种ALM可借助来提供敏捷结构的方式. 敏捷应用生命周期管理(Agile Application Lifecycle Management,Agile ALM)正得到越来越大的推动,记得我在撰写"Agile ALM"一书的书稿时,几乎没有人

  • 敏捷管理中的管理角色 2013-12-11

    如何管理多个敏捷团队?在阿姆斯特丹敏捷管理大会上,Christoph Johann Stettina就敏捷管理和管理角色做了演讲.他研究了14个欧洲的大型组织如何在IT项目组合管理中运用敏捷项目管理方法.研究的初步结果报告已经发表,题为<敏捷项目组合管理:从实证角度看现行做法>. 根据Christoph的报告,在如何组织单个软件项目方面,敏捷软件方法引发了一场无声的革命.敏捷变成"新常态",而多项目管理是一个在单个团队之外变得敏捷的机会. Christoph对经典管理理论的

  • 项目管理沙龙第十一次聚会纪要--当敏捷没有共识的时候 2013-12-11

    本来这次聚会要讲一下项目管理的流程概貌,同时对第一个阶段进行一次试探性的深入探讨.可惜这次缺席人数太多,变成了"锵锵三人行",原定想要谈的内容,也就弱化了.其实每周一次的沙龙,并不需要太多的负担,就当是每周一次的茶会吧,大家紧张了一整周,放松个90分钟,也是应该的. 不过"三人行必有我师焉",只要有意愿,肯定能够谈出新话题来. 今天分享的知识是"Dreyfus模型",全称是"Dreyfus技能获取模型(Dreyfus Model of

  • 敏捷教练如何结对为团队服务 2013-12-30

    敏捷教练也可以结对而不再孤军奋战.在采纳敏捷时,两位敏捷教练可以互相协作,进而指导个人和团队学习并达到提高. Stephan Schwab写了一篇关于<敏捷教练遇到的风险和副作用>的博客.他在里面描述了人们为什么会在敏捷教练开始和团队成员一起工作的时候感到畏惧: 如果这样下去的话,将很可能不会给顾客带来任何帮助.因为,从教练出现的那一刻起,就意味着会带来挑战.它将无可避免地将改变一些东西.如果不是这样,就没人愿意去找教练.因为如果不接触任何东西,就不会获得任何帮助. 所以教练要环顾四周,改掉名

  • 预览Visual Studio11: 敏捷的支持.团队协作以及代码克隆监测 2014-01-15

    微软计划在即将到来的Visual Studio 11 中为一个软件项目中所有相关的干系人改善开发流程.开发.测试和运维团队的需求是复杂且不断变化的,为了应对这些挑战,微软已经开发"应用程序生命周期管理" (PDF) 旨在改善"软件建设的生产力和可预见性"过程. ALM(应用程序生命周期管理)的重点放在如下优先事项中: • 通过集成团队中所有角色来协作 • 及时和可操作的反馈以减少浪费 • 为手头的任务充分利用自然而适当的工具 • 根据意愿采取透明而灵活的最佳实践 最