开发方法：深入理解敏捷开发的常见误区之二
开发方法：深入理解敏捷开发的常见误区
作者: Jaln, 　
　　责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
敏捷仅仅是一个软件过程
　　如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。
　　涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：
　　把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。
　　把人的能动性调动起来，给动力而不是给压力。
　　要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。
　　没有绝对的权威，每个人都有可取之处。
迭代就是敏捷，UP属于敏捷。
　　看到这么多人都把UP归入敏捷，我都开始怀疑是不是自己搞错了。但是在我的印象中：
　　UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的(不排除有些客户目标也不明确)，但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
　　4. 敏捷是彻底革命的。
　　敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。
　　5. 敏捷是反文档的。
　　文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
　　应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。
　　因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
　　文档不是目的，有效沟通才是目的。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。专注敏捷，Scrum敏捷开发
敏捷软件开发绝不再是一个新名词了，但理解还是时时有偏差。敏捷宣言中的第一条&个体和互动高于流程和工具&，有人就误读为&有了沟通，一切都迎刃而解& ，因此花费大量精力整顿团队合作，却轻视了工具（技术）。其实宣言中的意思只是想强调个人和沟通更重要而已。
实际上，既然是软件开发，在所难免得面临工具的选择，而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中，工具（这里谈的是软件工具）层出不穷，数不胜数，那么到底该怎么去选择适合的工具呢？
本文将根据我十几年的企业级软件开发经验给出一点建议，和大家一起来探讨敏捷和工具（特别是在企业实施中的工具）这个话题。
为了避免不必要的麻烦，文中尽量用开源软件作为介绍，但这并不是说我排斥商业软件，恰恰相反，在很多时候，只有商业软件才提供了你需要的功能（当然大部分情况下开源软件会很快迎头赶上）。
背景知识：应用程序生命周期管理
聊到软件开发中的工具，一般都会提到这个术语&应用程序生命周期管理（Application Lifecycle Management ，ALM）& ，说句老实话，有点烂，谁都想把自己往上靠，谁都有自己的一套说法，图1为我心中贯穿企业开发项目全程的ALM全局观。
图1中列出了ALM中的各个子系统，以及我略有研究的相对应工具的名称，让我们一起先来简单地过一遍整个过程。
图1 开发项目中应用程序生命周期管理及其工具
产品开发始于一定的需求，需求有好几个层次，从产品需求到项目需求，进而产生出用户故事（User Story）， 然后团队会分解出任务（Task）。团队开发者利用IDE（如Eclipse）去完成相应的代码，单元测试完成后，再推送到代码库（git），这些和软件配置管理（Software Configuration Management，SCM）相关。
构建系统会从代码库中获取最新的代码，进行编译、打包、功能测试和系统测试，可以设置在质量系统中显示一些相关信息，如果一切顺利，甚至能直接上传到在线系统更新上线。此外不管是开发中还是运行中一般还都会有一个缺陷管理系统。
BugZilla大家应该很熟悉了，用Redmine的人少一些，国内也有越来越多的公司在使用，很好用的一个敏捷协作软件，在线的高效看板协作。Nexus是一个Java软件包的管理工具，需要和Maven结合使用，Sonar是一个Java项目的质量控制工具，它集成了如单元测试、覆盖率、静态质量检查等内容。为什么任务管理下的Redmine有红叉呢？我们稍后会解释。
限于篇幅，本文只会谈到其中的一部分工具。作为参考，可以阅读Manning出版社的新书《Agile ALM》，它对SCM、单元测试、功能测试等话题进行了更深入的探讨。
敏捷中有些工具是必需的
如果你说敏捷实施大半年了，但持续集成 (Continuous Integration，CI）服务器却还没有架起来，那我实在是不晓得你都在敏捷些啥东西了。无论你究竟&信仰&哪种敏捷，产品开发各个方面的自动化（Automation）和持续集成都必不可少。要了解持续集成，可以看看Martin Fowler的文章，可谓白皮书级别的经典，有中文翻译版。
使用CI就一定会用到CI服务器，可选的有很多，其中Jenkins是现在最流行的一个，而且架设起来也很方便。它是从Hudson继承而来（自从2011年5月Oracle决定把Hudson捐献给Eclipse组织，两者的关系和将来的发展方向也可能带来更多变数）。
在Jenkins构建服务器中，可以定义任务（在Jenkins中叫job），以完成一些构建步骤（如签出代码、编译、各种类型的测试、打包等），它有极丰富的插件（plugin）资源作为支撑，可以来集成产品软件开发的各个要素，它把你所需要的一切都自动化起来。
图2 Jenkins项目自己的Jenkins构建服务器
在Jenkins构建服务器的首页，每个任务还都有一个天气图标表示其状态，非常直观，例如&太阳&就代表着一切正常（至少从构建结果来看）。它是产品项目开发的晴雨表，项目状态是否正常一目了然。不管是对Jenkins不了解还是想提高，我强烈推荐阅读John Ferguson Smart的Jenkins开源书：Jenkins: The Definitive Guide。
对敏捷来说，并没有&CI服务器要还是不要&一说，它就是必须的，一定要好好地实施。基于持续集成再往前走，就是持续交付（Continuous Delivery）了，这也是敏捷的一个新热点，其中加入了很多新元素（如自动化验收测试、持续部署等）。
别让工具牵着鼻子走
工具很重要，但会不会有些误区呢？当然有，我们一起来看个我经常碰到的一个例子。
讲到敏捷实施一直都会提到白板（Whiteboard）的使用，先得提醒大家，它也是一个&工具& （现在可以用，在线看板），白板的其中一种用法叫任务白板，主要是提供给团队使用的。
图3 每日例会用的任务白板（图来自《硝烟中的Scrum和XP 》一书）
图3就是常见的任务白板，团队的需求，一般是用户故事（User Story），被放在最左边一栏&NOT CHECKED OUT&，作为团队一个迭代的输入，然后分解成任务（Task）用报事贴（俗称黄贴）贴在白板上&CHECKED OUT&那一栏，并签上自己的名字，就算是领任务啦。当做完了一个任务就把它（黄贴）挪到下一栏&DONE！:o)&，代表做完了，最右边一般还会留出部分空间，用来记录进度条和注意事项来提醒团队一些重要的事情。
如果说Jenkins构建服务器是产品开发的晴雨表，那么任务白板就是团队开发的晴雨表。
一般一大早在每日的站立会议（Daily Standup Meeting）上，整个团队所有人都会围在白板前，分享所负责任务的进度，顺便挪动一下任务到相应的状态栏，用这种方式能够减少很多不必要的汇报型会议，而且团队成员也能很快地了解开发的整体状况。相信如果某个黄贴在白板上连着三天都没动，团队里一定会有人站出来帮忙的。（没有？！那还是先组织他们参加团队合作的培训吧。）
有时候团队坐得比较分散，或者有人喜欢流行的在家办公方式，这时可能会开始使用一些图形化的电子白板来管理团队任务，大家对着屏幕介绍进度，效果似乎还不错，其他人（包括经理们）也非常高兴，因为他们可以随时从网上了解到团队的进度了。慢慢地，面对面的时间看起来也可以节省下来，只要窝在座位上点点鼠标，挪挪电子黄贴（如果支持漂亮的拖拉就更好了）就已经足够了。
这是敏捷的好实践吗？
是否嗅到了一点怪味道？它就是我想谈的工具带来的误区，电子白板会削减团队之间的沟通，降低团队的透明度，违背了敏捷重视人和团队的原则。如果你的团队成员不经常去更新电子白板上的任务时间，慢慢地你看到的都是不太准确的信息了。有人可能说我们还是面对着电子白板开每日站立会议呀，那我希望你有个很大的屏幕吧，这样效果更好。
那为什么没说它不对呢，因为在一些场合下，它还是有作用的。关键是团队要能充分认识到它的局限性，因此我极力反对在团队组建初期用电子白板，可以等团队充分领会到敏捷中人与人沟通的重要性后再引入。
这也是在图1中特意用红叉提醒不要用Redmine来管理任务（Redmine这个白板功能的插件很差，不如用leangoo）。
所以要了解你的需求，不要让一些工具牵着鼻子走，要了解敏捷实施的目的，否则出了问题还以为工具不到位，拼命要更强的功能，结果陷入大误区。
有些工具会带来意想不到的好处
传统的敏捷著述中通常会提到CI的部分，然而工具的运用并不限于此，例如我在实际项目中用到的Gerrit，它非常契合敏捷的宗旨，也给我们带来了意想不到的好处。
代码审阅是一个不错的敏捷开发实践，让人非常头疼的是实施。大企业中通常是制定出一大堆相关的规范和流程来指导代码审阅。我听说好多公司都会把代码打印出来，进行走读，这可真是累啊。这种方式会给人不信任的感觉，而且应该是挺浪费时间的。
结对编程（Pair Programming）也是非常好的一种代码审阅的方式，值得好好地学一学，只是我对它并不太感冒，体会是在大企业实行结对编程的难度很大，当然如果能找到合适的推动者，那还是可以尝试尝试的。
那看看开源社区是怎么解决这个问题的呢，使用的又是什么工具呢？Google的Android系统是现在非常热门的开源项目，它的代码审阅（包括贡献者的代码）使用的是Gerrit，非常棒的东西，在自己的企业中架设起来也非常方便，我一用就爱上它了。
Gerrit是一个基于Web的代码评审和项目管理的工具，面向基于Git版本控制系统的项目，所以如果你没用git（干嘛不用呢），就没法用Gerrit了，接下来来看看在Gerrit中怎么实施代码评审的。
● 首先开发者（贡献者）的代码变更通过 git 命令被推送（push）到Gerrit管理下的Git 版本库，推送的提交转化为一个一个的代码审核任务（见图4）。
●&代码审核者可以通过Web界面查看审核任务、代码变更，通过Web界面做出通过代码审核（Review）或者拒绝（Reject）等决定。
●&测试者（一般可以设定为CI服务器执行）可以通过访问来获取（fetch）代码变更进行相应测试，如果测试通过，就可以把这个评审任务设置为校验通过（Verified）。
●&最后经过了审核（Review）和校验（Verified）的代码变更可以通过Gerrit界面中提交动作合并到版本库的对应分支。
相比代码走读，它的好处在于，审阅动作发生在向主干提交代码前，可以只看变更的部分显得很贴心，网上随时随地审阅起来也很方便，这也是有别于结对编程的一个好处。
任何人都可以审阅提交的代码，整个团队的代码都一目了然，审阅起来更方便，非常符合开放、透明的敏捷精神。使用之后能够显著提高代码质量，甚至于等到习惯了以后，代码不被审阅一下，都觉得实在是不好意思提交代码到主干上去。
Gerrit中，通过特定分支，任何审核任务的代码变更都能访问，所以如果需要细看或是合并到本地都异常方便。
Gerrit刚开始实施可能会有点不习惯，毕竟整个工作流有所变化，因此实施时需要通盘考虑。
如上只是近期我特别喜欢的一个工具，其实类似的工具还有许许多多，这不过是沧海一粟而已。
水能载舟，也能覆舟，工具和敏捷的关系亦如此，下面我给出几点建议：
● 积极尝试新工具，如今的软件开发世界中，工具层出不穷，要不断与时俱进，了解最新动向和如何用有效的工具去辅助敏捷的实施，在自己的软件开发环境中去尝试和了解这些工具，尝试这一点很重要，不要只看说明或戴有色眼睛去看待这些工具，应该通过实践摸索找到最适合你的选择。
● 人总是第一位的，要了解你的团队，了解他们的需求，有些时候甚至可以为了团队，冒险一下采用新技术、新工具，这样可以提高团队的凝聚力（敏捷要素之一）。我待过的一些部门推动Git时，就是这么来的，很多时候过多的讨论其优缺点反而是浪费时间，不如多花点时间多试试。
● 实施敏捷也离不开组织的支持，特别大型企业涉及到的人很多（可能水平不一），这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程，这样会使得实施更容易些。
●&唠叨这么多，实际上也只是讲到一些皮毛，还有很多东西需要我们继续研究下去。
来源：程序员
阅读(...) 评论()敏捷开发（对于敏捷开发模式的理解） - 缘泉 - 博客园
随笔 - 80, 文章 - 0, 评论 - 23, 引用 - 0
一、敏捷开发定义
& & &敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
二、敏捷开发原则
& & 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
& & 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
& & 3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
& & 4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
& &5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
& &6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
& &7、工作的软件是首要进度度量标准。
& &8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
& &9、不断地关注优秀的技能和好的设计会增强敏捷能力。
& &10、简单----使未完成的工作最大化的艺术----是根本的。
& &11、最好的构架、需求和设计出自与自组织的团队。
& &12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：
组织文化必须支持谈判
人员彼此信任
人少但是精干
开发人员所作决定得到认可
环境设施满足成员间快速沟通之需要
最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。
另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是要有效的&负反馈&，否则错误会迅速膨胀，并在最终提交时造成极大返工。您现在的位置：
关于敏捷开发模式:CIO最应该知道的10大原则
Yesky天极新闻
　　【天极网IT新闻频道】市场调研公司Gartner发布的最新报告显示，CIO目前需要为快速变化的数字业务场景提供支持，而同时又发现传统的项目和开发方式无法满足需求。在这样的情况下，企业正越来越多地转向敏捷开发(Agile Development)模式，以加速项目的推进，展示自身的价值。
　　Gartner于近期在澳大利亚悉尼举办“Gartner应用架构、开发和集成峰会”。而Gartner研究主管Nathan Wilson表示，在执行良好的情况下，采用敏捷开发模式将变革IT与业务部门之间的关系，并有利于IT充分发挥自己的价值。然而，只有CIO和整个IT管理团队专注于必要的文化转变，这样的价值才能实现。
　　Wilson表示：“如果能良好地完成，那么在CIO响应业务部门越来越多的创新需求方面，敏捷开发模式将成为各种方式有机的一部分。而如果完成情况不佳，敏捷开发模式带来的问题会比解决的问题更多。”
　　在敏捷开发模式中，开发者也可借助应用性能管理(APM)工具提升开发速度、让应用更快发布，并且能精准定位使用体验中的瓶颈。以OneAPM为例，其功能也很适合支持敏捷开发模式，对广大开发者来说，只需要把业务做好，把要提供给客户的服务做好，无需再去关心性能问题。
　　Gartner列出了敏捷开发模式的10大指导原则：
　　1.敏捷开发并非单一的方法
　　敏捷开发模式是软件开发的一整套方法，这些方法有着共同的哲学，但在具体执行时也有很大的差别。这些方法适用于解决不同的问题。经验丰富的大型组织可以利用不止一种这样的方法。不过在开始阶段，组织可以首先尝试其中一种方法，在熟练掌握后再尝试更多。
　　2.敏捷开发理念具有系统性
　　敏捷开发是高度系统性的方法，其中每个元素对成功而言都非常重要。对于敏捷开发，组织的一个常见误区在于只重视其中某些元素，例如“敏捷迭代(Sprint)”，而忽视了其他元素，例如对“技术债务(Technical Debt)”的管理。这样的组织能快速完成开发并发布新代码，但将会积累越来越多的技术问题。
　　3.部署敏捷开发模式需要业务部门和IT的合作
　　如果没有业务部门负责人、管理层，以及用户社区的参与，那么敏捷开发的优势无法得到充分的发挥。如果公司其他部门不愿以新的方式去工作，那么与业务部门经理和用户的沟通将非常必要。
　　4.引入敏捷开发模式是循序渐进的过程。
　　在敏捷开发模式中，熟练的开发者能完成大规模的开发，这就像是翻越山。不过，积累必要的经验需要很长时间。如果组织刚刚转向敏捷开发模式，那么需要从头开始建立开发者的信心和能力，使他们逐步有能力承担大型开发任务。
　　5.敏捷开发意味着持续学习
　　敏捷开发的实践者需要持续优化质量和效率，这意味着每次开发都需要进行经验总结，从而优化开发策略和具体实践过程。这样的分析和学习并不仅仅是一小部分高级开发者的责任，而应当成为所有参与者的基本工作之一。
　　此外，需要学习的也并不仅仅是软件开发技能，还包括项目管理技巧、系统架构、质量保障，以及IT预算管理等。
　　6.敏捷开发意味着团队，以及团队的团队
　　在敏捷开发模式中，发布代码的基本组织单元是小型团队。这样的团队通常包含5到9名成员，需要同时承担开发和质量保障工作。从人力资源的角度来看，管理敏捷开发团队一方面需要将团队以高效的方式凝聚在一起，另一方面也要鼓励团队中的不同成员提出具有交叉性的创意。
　　如果人员流动过于频繁，那么团队将无法形成高效的组织单元;但如果团队之间的人员流动不足，那么每个团队将逐渐变成孤岛，失去与其他团队的交流。需要指出，相对于传统开发方式，在敏捷开发模式中，团队的座位位置更加重要。
　　7.记录、管理及清理“技术债务”是所有敏捷方法的核心理念
　　“技术债务”的定义是，软件现在的状态，以及在可靠性、性能、便携性、可用性、可维护性和安全性等方面满足一定质量要求之间存在的差异。所有开发活动都会造成技术债务，而敏捷开发模式的不同在于，技术债务可以被识别，并被记录至待办工作列表，而不是被弃之不顾。
　　任何希望引入敏捷开发模式的组织都必须采用所选择方法的必要元素，进行必要的重构，清除技术债务。
　　8.在敏捷开发模式中，如果需要与第三方开发服务提供商合作，那么需要额外的关注
　　许多公司的IT部门都会将应用开发工作外包给专业服务提供商。尽管在敏捷开发模式中，服务提供商可以扮演一定的角色，但商业模式和互动模式将会出现很大的不同。在敏捷开发过程中，坐在一起办公是关键，因此能将大量工作任务外包给第三方的机会不大，而通过某种方式在内部补充人员很可能是一种更有用的方式。
　　9.敏捷开发模式的影响力将超出软件开发团队
　　敏捷开发模式的有机组成部分之一在于“持续地交付”。敏捷模式意味着与业务部门经理和用户的持续互动，这将在业务运营环境中持续带来新版本软件。这也意味着业务管理和关系管理的方式，以及运营团队的基础架构会发生明显的变化。
　　10.你仍然可以使用开发方法
　　在大部分商业和公共组织中，应用开发将会出现多种多样的问题。一些问题可以通过敏捷模式来解决，另一些问题可能更适合增量式的迭代开发模式，而还有一些问题可能需要利用传统的瀑布模式。敏捷模式并没有“更好”，而只是“更适合”某些问题。
IT新闻微信公众平台
第一时间获取新鲜资讯
使用手机扫描左方二维码
* 网友发言均非本站立场，本站不在评论栏推荐任何网店、经销商，谨防上当受骗！没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！}