第三只眼的专栏

 Joh scumniotales是Scrum早期开发者之一，现任Serena Software公司生命周期管理副总裁。scumniotales介绍了Scrum和Agile的商业及技术发展趋势，同时描述他在Scrum初期研发阶段所积累的经验，以及目前Scrum发展的现状。最后，对于大众及管理层对Scrum应抱有哪些期待、是否应该采纳Scrum等，John Scumniotales也提供了重要建议。

 Scrum的三个法宝: Product Backlog, Sprint Backlog 和Burndown Chart. Product Backlog在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作

 作者 Danijel Arsenovski译者 张逸 发布于 2008年11月3日 下午10时49分原文见 http://www.infoq.com/cn/articles/RefactoringMyths公正地说，.NET社区对于重构技术的研究起步太晚。直到今天，.Net开发的旗舰产品Visual Studio仍然无法在C#中突破重构的界限（http://www.martinfowle

 在那些最简单也最常谈起的敏捷实践中，每日站立会议（又称作每日例会）就是其一。 Jeff Martin在scrumdevelopment Yahoo!邮件组中问道： 我搜索过相关知识却一无所获，我想我一定是用错了词。谁能给我一个每日例会的范本？我们遇到些困难，导致有些团队成员想取消会议，或是一周只开两次会。 这个问题得到了很多回复。 Marcie Jones认为原因在于（缺乏）推动会议进行的技

 SCRUM方法如下：SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程(Empirical Process)，而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程，因而可重复（Repeatable）执行并能产生预期的结果，并能通过科学理论对其最优化。经验性过程与之相反，应作为一个黑箱（Black box）来处理，通过

 极限编程（XP，eXtreme Programming）是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力

真正的大师，给我们讲述一个高深的理论的时候，往往让你感觉不到他是在给你讲一个理论，更像是在讲故事，深入浅出。大学的时候，曾经遇到一位讲《政治经济学》的教授，当时大家听他的课，着迷到一定要占座，这样好坐到前面几排。工作后，读了《最后期限》，再次产生这种共鸣。几年前，读了《TOC》系列后，就再没发现这样的大师。今天，偶然遇到了这个Scrum对话系列的网文，该文作者通过对话的方式介绍了在微软软件开发中一

一个没练过正统功夫的，突然一天去练九阳真经，看来是要人打通任督二脉才行，否则，并容易走火入魔。所以一定要先敏捷在规范！此外敏捷最重要的是人和交流。如果不是一个很好的团队，或者说交流不通畅，敏捷和规范都会大打折扣。原文blog.csai.cn/user1/15522/archives/2008/27236.html ----敏捷精灵先敏捷再规范，先做到再写到，先短期利益再长远利益，先实效再完备。

引自 blog.sina.com.cn/s/blog_493a84550100ax35.html最近看了InfoQ上关于精益看板在软件开发上的一些实践和应用的文章，敏捷软件开发借鉴了很多TPS精益生产的思想，虽然没有完全提到看板的概念，但是看板在敏捷软件开发实践中是很有必要进行的。具体InfoQ的一些文章请参考:将看板应用于软件开发：从敏捷到精益http://www.infoq.com/cn/ar

敏捷软件开发不是一个具体的过程，而是一个涵盖性术语（umbrella term），用于概括具有类似基础的方式和方法。这些方法，其中包括极限编程（Extreme Programming）、动态系统开发方法（Dynamic System Development Method）、SCRUM、Crystal和Lean等，都着眼于快速交付高质量的工作软件，并做到客户满意。敏捷软件开发又称敏捷开发，是一种

 在过去的几个月中，我们在每个Sprint 计划会议上，都会花上几分钟的时间，一起为当前的Sprint起名字，现在回顾一下，还是非常有意思的。---敏捷精灵看一下我们为项目A起的Sprint名字：Sprint1---"The Big Con" Sprint2---"Breakout" Sprint3---"Hours to doom day" Sprint4---"Th

 SCRUM 敏捷开发 基础及失败成功案例分析 什么是敏捷开发方法？什么是SCRUM？有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。那么，敏捷这个词到底由何而来呢？在九十世纪中期，涌现了一批软件

   在实际的项目实施中，尽管旁边常常站着解决项目问题的专家，但当项目经理被不自觉地卷入到项目的各种问题中时，项目管理的各种方法也变得苍白无力。此时，敏捷开发往往成为项目经理的制胜法宝。一张空白表格挽救一个项目不久前，笔者曾经接手一个蹩脚的软件开发项目，这个项目曾一度处于失败的边缘，整个开发团队也是精神涣散。然而，他们的任务却很复杂：项目团队要开发一套复杂的银行管理系统

对于一个组织来说，同一组开发人员来完成多个项目，这是常有的事儿。在这种状况下，应该如何组织团队呢？他们的工作又该如何计划和分配呢？原文见http://www.21manager.com/html/2008/10-22/12562185.html　　　　如果可分配的资源较多（比如说，可以为每个项目分配6至10个开发人员），而且已经知道这些项目的大小和相对优先级，一般来说，将开发人员划分为两个或多个团

极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为 目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功 的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用

作者 Kenji Hiranabe译者 苑永凯 发布于 2008年2月19日 上午3时0分 http://www.infoq.com/cn/articles/hiranabe-lean-agile-kanban对于这个问题，Martin Fowler认为这是这是基于一种错误的假设。我也深有同感，的确，敏捷和精益的思想相互交织如此之深，以至于你在使用敏捷的时候也总在做精益的事情，反之亦然。我们可以考

作者 Amr Elssamadisy译者 郑柯 发布于 2008年8月23日 上午3时51分 http://www.infoq.com/cn/news/2008/08/sd-traffic-jamKen Delong解释了他认为软件开发“超级困难”的原因：每个人都知道编写软件很难，但是我想探讨一下为什么软件开发这么难。软件开发受本身四个特性之困，而这些特性也将其推到了“复杂的自适应系统”之境地，并

看了这个关于Kanban在软件开发中的应用，真是大开眼界！感觉受益颇丰。转过来，以飨读者。摘要 看板1是丰田生产方式（Toyota Production System，TPS）中用来支持非集中“拉动式”生产控制（non-centralized "pull" production control） 而使用的卡片。作为精益生产的工具，它现在已经应用于世界各地的制造企业之中。如今在敏

 Scrum定义了许多角色，根据猪和鸡的笑话分为两组，猪和鸡一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆起什么名字呢？”，鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样？”，“我不这么认为”，猪说, “我全身投入，而你只是参与而已”"猪"角色猪 是全身投入项目和Scrum过程的人； they are t

 Scrum有三个仪式：Sprint规划会，Sprint评审会，Scrum每日站会Sprint Planning Meeting（Sprint规划会）根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司，客户就是市场，Product Owner扮演市场代理的角色。一个Product

 只有做好敏捷回顾，才能不断地改进，实现正反馈，如何做呢？不妨看看国外大师们。。。。敏捷回顾活动“最高指导原则”的辩论设想邀请几位善于思考的聪明才智之士一起坐下来，一边喝茶一边讨论“最高指导原则”（Prime Directive）——敏捷回顾活动的基础。如果你还不了解敏捷回顾，那我可以向你推荐Norm Kerth关于项目回顾的书籍或Esther Derby和Diana Larsen关于

在世界杯的历史上， 这个团队是最成功的，曾获六次冠军。在荷兰女子曲棍球队主教练Marc Lammers演讲中，我意识到为什么这个团队可以取得如此卓绝的成就。她们的成功，在很大程度上，要归功于教练 Marc的执教方式。Marc Lammers发现了可以令团队释放全部能量的秘诀，大家不仅像一个整体一样齐心协力，每个人作为团队的一份子也各尽所能；而这一切都以意想不到的方式发 生。我的的确确得到很多启示。

最近，关于下一代功能测试工具发展方向的讨论热闹地开了锅。不过，还是众多组织仍然在努力让传统的“录制-回放”测试工具跟上敏捷的脚步。被称为“测试狂人”的Elisabeth Hendrickson告诉他们为什么不要再白费功夫了。 Hendrickson将她的看法出色地总结为下面这种索引卡片的形式： 为什么传统的、“录制-回放”式的、重量级的、商业化测试自动化解决方案做不到敏捷三个原因：

在博客右栏目做了一个敏捷方法的调查，但似乎好多朋友对这些方法还没有概念，这里对七种主流敏捷软件开发方法做个简单介绍！原文 www.livebaby.cn/blog/u/meil/archives/2008/2695.htmlXP　　XP（极限编程）的思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，

http://www.infoq.com/cn/articles/agile-coach-a-to-z作者 Patrick Kua译者 李剑 发布于 2008年9月23日 下午11时47分 敏捷方法学带来了新的角色——“敏捷教练”，它不常见于传统方法学中，甚或不曾为之提及。已驾轻就熟的实践者，可能会视之为浑然天成，羚羊挂角、无迹可 寻；而初窥门径的新手则会心生疑云：“敏捷教练为何如此重要？‘部

在Agile 2008大会上，《Test Driven: TDD and Acceptance TDD for Java Developers》的作者Dave Nicolette和Lasse Koskela举办了一场研讨会，“战胜变化中的阻力”。不管是实施敏捷还是重新布置办公室，只要是变化就都会遇到阻力。问题在于遇到阻力时怎样应对。当我们提出改变的建议而遭遇阻力，我们往往都会先做出情绪化的反应

 我一直相信，软件开发如同协作游戏，看了 Jay Fields的大作Software Development Lessons Learned from Poker后，对这一点就更深信不疑了！推荐给大家！！---------------------------------------------------------------------我以前不是做软件开发的。在加入ThoughtWor

 敏捷软件开发日益得到各方追捧。但是，“敏捷”二字到底意味着什么呢？是单元测试，持续集成，还是遵循 XP 或者 Scrum？在本文中，我们将探讨如何将敏捷方法引入出现问题和尚未使用敏捷方法的项目中。敏捷方法学这些年以来，已经有一些敏捷方法陆续浮出水面：极限编程（Extreme Programming，XP）、Scrum、Crystal、精益开发方法（Lean Development

 当我们提起工作量估计的时候，我们会碰到同样的问题，我们如何来做估计？有什么方法可以遵循呢？如何估计才更准确？我对某个功能做了估计，但它超出了预计的开发时间，为什么？ Scrum团队已经做了和严肃的承诺去完成开发工作（可以交付的产品），必须要深思熟虑才可能成功。 成功的工作里昂估计的几个步骤:估计每个团队成员有多少时间可以在Sprint中被使用:估计每一个团队成员在当前的Sprin

 Michele Sliger指出在敏捷开发中每日站立会议、迭代计划会议、发行计划会议、项目回顾（retrospective）以及检讨会议都能应付风险。但是，她也提出结构性风险管理方法。步骤包括，风险确定——每次迭代中整个团队都进行一次，在结果纪录在白板或者活页样板上。风险分析——凭主观判断、直觉、及经验作定性分析去判断风险和潜在损失。敏捷开发中的短开发周期及定期检讨使这分析可行而有效。这有别

 传统的软件开发 各类大中小型企业所运用的传统软件构建方法，即是众人皆知的“瀑布”型开发方法。此模型存在很多变体，但其典型性是在开发初期制定详细的计划，在计划中最终产品己被仔细研究，设计，并且一切详细资料都记录在案。任务已设计制定，并且在工作中使用如Gantt (根特)图表等工具和Microsoft Project 项目管理软件。开发团队预计开发项目的时间是以累计其相关每一步骤而得出的。当项目管理

 结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计。同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早已习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处．只是这些好处必须经过缜密的思考和计划才能真正体

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者

面对现实：团队的变化 在 过去的几年里，我和很多团队一起工作过，有的时间很长，有的则很短。我注意到在这些团队中，都面临一个相同的问题，即团队的成员总是在变化。通常，任何项 目背后的变动都会引发这样的改变：比如员工生病或者度假，项目需求增加，出现新的项目或者仅仅是员工希望能改变当前的工作。然而像每日站立会议、结对编程 等这样的敏捷实践，如果没有足够的上下文场景，就无法提供给新员工以足够有用的信息

 假如你的团队已经使用敏捷或者敏捷过程的某些内容有几个月了，无论是开发人员、产品经理、架构师、QA，还是管理层，组织中的每个人可能都非常喜欢敏捷的这 次首航。此时，你可以认为，你的团队已经发现了一个合适的过程，并可以沿着这个过程走下去了。可需要提醒你一下：“别那么快下结论！如果不小心的话，这个 快乐的聚会可能会以你始料不及的速度结束。那么，还是先看看本文吧-----敏捷精灵”本文聚焦于

 一个轻量级的软件开发方法Scrum是一个敏捷开发框架，是一个增量迭代的开发过程.。在这个框架整个开发周期由若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的长度2到4周。在每个Sprint中，Scrum的开发团队拿到一个排列好优先级的需求列表，我们称它为用户故事或者叫Sprint backlog， 所以我们先开发的是对客户具有较高价值的需求。  在每个迭代结束

 在Scrum敏捷开发框架下，最重要的一环就是 Sprint计划会议，这个会议开不好，整个Sprint会让Scrum Team痛苦不堪，也很难完成最初的Sprint目标。经过多次尝试后，我们终于找到了我们自己的模式。这些方法和原则对我们来讲是最好的，这基于我们自 己的知识，我们自己的项目情景，对于其他团队不一定试用。---敏捷精灵跟任何其他会议一样，确定好会议日程sprint计

 February 11th, 2008To help some peers advocate for agile adoption, I prepared an experience report to demonstrate how my old team benefited from XP and Scrum practices. This is an extension and

如果我们有多个敏捷团队在同一个代码库上工作时，如何将彼此之间代码互相冲突的风险最小化？如何确保每个迭代结束时拥有一个干净的、可发布的软件版本？本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例——这正是我们在《Scrum and XP from the Trenches》中描述的公司所采纳的方式。本文并非专为版本控制专家所写，实际上这样的专家在本文中找不到新东西。本文是为我们