极限编程（eXtreme Programming，XP）
极限编程的思想源自Kent Beck 和Ward Cunningham 在软件项目中的合作经历。
在这里，“eXtreme”的意思是希望将软件开发过程中一些好的方法发挥到极致。XP 注重的
核心在于“沟通、简明、反馈和勇气”，用一句话来概括XP 的这4 个核心价值观就是：
通过充分的交流和沟通，使产品的设计尽可能简单明了；同时通过客户经常性的反馈，生
产出符合客户要求的软件产品，并且有勇气迎接需求的改变。
另外，极限编程者还总结出一系列经典的实践，形成了XP 的12 个主要实践方法，
这些方法对极限编程具有指导性的意义，分别是：客户计划的制定、小版本发布、隐喻、
结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持
续集成、现场客户。
RUP（Rational Unify Process，Ratioanl 统一过程）
RUP 试图总结现代软件开发过程中所有好的实践经验，形成一种有很强适应性的软件开发过程。它包括了软件开发中的6 大经验，分别是：迭代式开发、管理需求、可视化建模、使用基于组件的软件体系结构、验证软件质量、控制软件变更。
RUP 的9 个核心工作流分别是：
业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。
RUP 的基本原理是：
以满足客户需求、为客户创造价值为最终目标；
尽可能早且不断地化解重大风险；
把注意力放在可工作的软件上；
在项目执行过程中尽可能早地适应变化；
在项目早期设计、实现并测试一个可执行的架构；
使用组件来构造系统；
建立高效、协作的团队；
要始终重视产品质量，否则追悔莫及。
以上RUP 的基本原理构成了RUP 的灵魂，在这些指导原则下，RUP 又给出了其他一些最佳实践，比如：为了化解业务风险，它始终以用例为中心；不是逃避变化，而是直面变化；为了化解时间风险，它采取迭代开发，尽量在早期探知到时间的延迟，以便采取更灵活的策略；为了化解技术风险，它强调架构设计；为了化解质量风险，它强调测试优先。而这些也恰好是RUP 的主要特点。在这些最佳实践之后，才是具体的过程组织形式：具体由哪几个阶段组成？而每个阶段又包括哪些工作流，要产出哪些产品？而且这些形式不是固化的。RUP 只是提供一个模板，可以在开发过程中进行裁减。
Lean（精益软件开发方法）
精益生产的概念首先出现在制造业中，由日本的丰田公司提出。大规模制造理论认为，一定程度的浪费、一定程度的废品是正常的和被允许的。而在软件开发中，资源浪费、成本居高不下也同样成为软件开发的一大障碍。处于变革的十字路口的软件开发行业，总是能不断地从其他行业中寻找可借鉴的理论。这种借鉴来的思路就被称为精益编程（Lean Programming）。
Lean 方法的主要思路有：消除浪费，将所有的时间花在能够增加客户价值的事情上；延迟决策，在一个复杂多变的环境中进行软件开发，需要根据实际情况保持可选方案的开放性，但时间不能过长；尽早交付，软件交付的周期越快，用户的需求就会越清晰，软件应对需求变化的灵活性就越高，让客户的需求来推动工作的进展；加强学习，承认变化的存在及其不可预见性，加强反馈和交流，在实践中发现问题、解决问题，并最终形成解决方案；授权给团队，正确的决策取决于准确的信息，让开发团队参与决策，让团队成员充分发挥自己的潜力。
无数的经验和教训都已经证明，软件开发中一个巨大的浪费源头就是不注重质量而导致的返工。人们常常为了追赶工期而降低对质量的要求，殊不知这会带来更大的损失。
Lean 强调消除浪费，这正是为了避免低质量和返工造成的浪费。尽管这样做一开始看起来似乎有些麻烦，但它所带来的收益是实实在在的。
如果采用Lean 方法，还要注意不要钻牛角尖。消除浪费并不意味着扔掉所有的文档；尽量推迟决策并不意味着拖延决策，不能晚到错过了时机、耽误了工作才作出决策；尽快交付并不意味着匆忙交付和马虎行事，否则会为日后的系统维护带来更多的麻烦和浪费，这恰恰是与消除浪费的原则背道而驰的；授权给团队也并不意味着放弃领导。
Scrum 是一种灵活的敏捷软件开发管理过程，这个名词来源于英式橄榄球。Scrum 方法由Ken Schwaber 和Jeff Sutherland 提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标——发布产品的重要性高于一切，团队高度自治，成员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进，而且每隔2～4 周，每个团队成员都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强它的功能。
User Story 和Use Case 是两个不一样的概念。Use Case 指的是用例，通常用UML 图来描述，也是用来描述需求的很好的工具，已经有很多年的历史。Story Point 的计量在一开始不可能做得很准确，只能做一个大概参考，而且由架构师一个人决定也是不妥的。
User Story
Sprint Backlog 里的项目我们通常用User Story 来描述，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。User Story 要由Stakeholder 来编写。User Story 的形式很简单，人们可以很容易地掌握编写User Story 的方法。这样就可以保证是由与项目相关的领域专家们来写User Story，而不是开发人员。
我们通常把User Story 写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定Sprint Backlog。而且，Stakeholder可以随时更改一个Story 的优先级，那么此时开发人员就应该相应地调整Story 的开发次序。
一个User Story 的大小和复杂度应该以能在一个Sprint 中开发完毕为宜。如果UserStory 太大，可能会导致对它的开发横跨几个Sprint，这种情况是需要避免的，此时就应该将这个User Story 分解。
User Story 通用的公式格式
作为<某个角色>，我可以<做什么>，以完成<什么目的>
例如：作为一个病人，我可以预约一个医生，让他给我看病。
这种表达方式清晰明了，提供了足够的信息以供测试。更详细的实现细节会在要完成这个User Story 的Sprint 开始之前确定下来，并补充到Sprint Backlog 中去。这是一种把客户需求分解为可测试的且有优先级的任务的有效方式。
为了能及时、高效地完成每个Story，Scrum 团队会把每个Story 分解成若干个Task。每个Task 都是可以在明确的时间内完成的，而且时间是以小时为计量单位的。
特别提示：每个Task 的时间最好不要超过8 小时，就是要保证在1 个工作日内完成，如果做计划时发现有些Task 的时间超过了8 小时，就说明Task 的划分有问题，需要特别注意。
Scrum 管理工具
ScrumWorks、Rational Team Concert、XPlanner
ScrumWorks 是一个专门针对Scrum 项目管理的商业软件，详见http://danube.
com/ScrumWorks，专业版的价格大概是每用户每年几百美金，软件的授权费采用固定
的期限，到期还需要继续购买。ScrumWorks 有桌面和Web 两种界面，都是基于Java
的，服务器的安装需要JBoss 的支持。Product Owner 和Scrum Master 通常使用桌面
应用程序入口，而普通团队成员则可以使用Web 应用程序入口。
IBM Rational Team Concert 是一个十分强大的开发协作平台，属于商业软件，详
见http://jazz.net。Rational Team Concert 是基于一个名为Jazz 的IBM 开源平台开发的，
Jazz 本身是基于Eclipse 的，而Eclipse 本身是跨平台的，所以Rational Team Concert
给用户在不同平台上带来的体验是相同的。Rational Team Concert 最强大的地方在于
可以轻松地与IBM Rational 软件配置管理工具进行集成，比如著名的代码管理工具
ClearCase、软件缺陷管理工具ClearQuest 和Build 管理工具BuildForge 等。Rational
Team Concert 自身也带有一个代码控制管理（Source Control Management）工具。
由于采用了Eclipse 平台，所以开发团队甚至可以把Rational Team Concert 也作为
一个开发IDE。这样，整个软件开发的生命周期，例如编码、代码控制管理、测试、管
理、调试、Build 集成等，都可以在一个系统中完成，实现All-in-One，非常方便
XPlanner 的计划模型比较简单，支持迭代开发。在项目开始的时候，首先建立一个迭代，然后可以在迭代里面建立 Story，以小时为评估，每个Story 可以进一步分解成
任务，每个Story 和任务都可以分配到人。XPlanner 也有一些迭代统计和监控功能，可
以根据当前的进度情况生成柱状图，甚至还支持Scrum 里面的Burndown Chart。
不过，XPlanner 给人的总体感觉比较简单，比较适合非常小的团队
工欲善其事，必先利其器。找到一个合适的敏捷项目管理工具并不难，就算没有，Excel 也是一个很好的替代工具
Sprint 计划（Sprint Planning）
在每个Sprint 开始之前，需要召开Sprint 计划会议，会议时间一般为4～8 小时，参加人员有产品责任人、Scrum Master、Scrum 团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner 从产品Backlog 中挑选高优先级的任务，并与Scrum团队一起决定在这个Sprint 中需要完成多少功能。Scrum 团队将这些任务分解成小的功能模块。Scrum 团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
敏捷开发的价值观认为计划是不可能精确估计的
在混乱中建立秩序是Sprint 开始阶段的目标
敏捷开发倡导面对面的交流。可以工作的软件胜过面面俱到的文档
敏捷和Scrum 倡导团队自我管理，在任务分配上提倡每个人按兴趣和能力自主选择任务
每日Scrum 会议，也叫Daily Scrum
第一，你今天都做了什么？
第二，你明天准备做什么？
第三，工作中有什么困难使你无法继续下去？
Ajax，简单点说就是JavaScript 采用异步方式访问后台服务器，然后根据返回的结果动态地修改前台页面的DOM 节点，而不再是使用传统的Post 和Get 方法来得到数据，从而实现以页面的局部刷新代替整个页面的刷新，可以说是Web 应用上的一次飞跃，使Web 客户可以享受到如同桌面客户端一样的体验
JSUnit 是为JavaScript 而设计的，JUnit 是为Java 程序设计的，都是自动单元测试的框架。我以前一直以为单元测试是测试员该干的工作，今天才明白原来得开发来做
每日Scrum 会议（Daily Scrum）
每日Scrum 会议（Daily Scrum），即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立举行，如图4-3 所示。由于是以站立的状态开会，因此时间比较短，一般为15 分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum 会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
会议由Scrum Master 主持，Scrum 团队的所有成员轮流回答以下3 个问题。
（1）昨天我完成了什么工作？
（2）今天我打算做什么？
（3）我遇到了什么障碍？
通过每日 Scrum 会议，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master 除了倾听团队成员的发言外，还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作顺利进行的障碍。即使有的问题Scrum Master 没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的成员来帮助快速地解决问题。另外，还有两点需要注意的地方：其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，团队成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。
每日Scrum 会议是Scrum 的精髓，最简单又最复杂，如何更有效地召开，需要不断地改进和摸索。
给经理写会议记录无可厚非，但是如果变成了汇报工作就违背了Scrum 的初衷。有些团队经理甚至把每日Scrum 会议变成了监督和指挥团队的会议，这完全违背了Scrum 的精神。
Burndown Chart 的横轴表示整个Sprint 的总时间，纵轴表示Sprint 中所有的任务，其单位可以是小时、人天等。一般来说，Burndown Chat 有Sprint Burndown Chat 和Release Burndown Chat 之分
Sprint Burndown Chart 可以体现Sprint 的进度。如果Sprint Burndown Chart 一直是上升状态，或当Sprint 进行一段时间之后，Sprint Burndown Chart 上当前点的Y 值仍然与Sprint 刚开始时相差无几，就说明这个Sprint 中的Story 过多，要拿掉一些Story以保证这个Sprint 能顺利完成。如果Sprint Burndown Chart 下降得很快，例如Sprint刚过半时Y 值已经接近零了，则说明为这个Sprint 分配的任务太少，还要多加一些任务进来。在Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现
Release Burndown Chart 用于记录整个Scrum 项目的进度，它的横轴是这个项目的所有Sprint，纵轴是在各个Sprint 开始前所有尚未完成的工作，它的单位可以是个（Story 的数量）、人天等。
Burndown Chart 是常用的衡量团队进度的可视化工具。敏捷开发可以给项目提供更多的可视性
每日Scrum 会议一般是15 分钟左右，最好在每天的清晨开
每日 Scrum 会议设立的主要目的是让团队里的所有人都能及
时地理解别人都做了什么？准备做什么？有什么问题？其实也就是整个项目都完成了什么？还要完成什么？有什么问题阻碍了项目的进行？自己是否有好的想法来解决这些问题？通过大家提供的信息，Scrum Master 以及每个人都可以非常明确地知道整个项目的进度，如果整个进度已经落后于之前的计划，那大家就要想办法来赶上进度了。而且实践证明，这个方法很有效。如果我们的工作比计划提前了，就可以适时地去调整后面的工作，例如可以增加一些任务
每日Scrum 会议是一个让大家同步信息的平台，而不是一个交流问题、讨论问题的渠道
固定的时间和固定的地点也有助于团队把每日Scrum 会议坚持下来，至于召开的时间则没有定论。大多数团队选择早上一上班的时间，因为头脑清醒；如果是跨国开发团队，比如关毅他们，下午下班前召开比较合适，因为信息可以更及时地反馈给比北京晚10 多个小时的加拿大团队
Burndown Chart 是常用的衡量团队进度的可视化工具。敏捷开发可以给项目提供更多的可视性。
组织中，有些老板不喜欢员工一下班就走。在敏捷实施中，让老板认同对敏捷的价值观是最重要的
在很多组织中，敏捷开发都是从下到上推行的。尽可能多地得到上层的支持是非常关键的。初期采用敏捷开发的团队对于迭代式开发的实质（可以工作的软件而不是仅开发完功能）要求很容易忽略或觉得难以达到，不妨循序渐进
Sprint 评审会议在Sprint 结束时召开，由开发团队展示这个Sprint 中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而且客户、管理层、Product Owner 以及其他开发人员等都可以参加。在每个Sprint 结束时，应该组织一次Sprint 评审会议。Scrum 开发团队将在会上展示他们在这个Sprint 中所做的工作，一般采用向大家演示产品新功能的方式来展示。相对来说，Sprint 评审会议不必很正式。通常不需要用到PPT，而且长度最好控制在两个小时之内。也就是说，不要让Sprint 评审会议成为Scrum 团队的负担，不必让他们花太多时间来准备这个会议。
为什么一定要用Demo 的形式来展示产品的新功能呢？因为这种方式有很多好处。
首先，参与会议的人都能直观地看到Scrum 团队的工作成果；
其次，利益相关者们可以据此提出更切合实际的反馈意见；
第三，为了完成Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做Demo，也许不少功能会停留在“已完成99%”的阶段。
相比较起来，在有Demo 的情况下，也许“已完成”的功能数量会相对少一些，但它们是确确实实完成了的。否则，那些“99%”的貌似完成的功能势必还要拖到下个Sprint 来解决。
由于Scrum 具有高度的可视性，所以团队中谁的状态都隐瞒不了。关于任务Done（完成）的标准是个非常重要的问题。在一开始总以为代码完成了就算Done 了，其实这离Scrum 的标准还差得很远
发现问题不是坏事。Sprint 评审可以帮助团队尽早地发现问题，尽早地得到使用反馈。
Sprint 回顾会议的宗旨就是：Scrum 团队如何在下一个Sprint 中做得更好Sprint 回顾会议通常是最容易被忽略的。然而，Sprint 回顾会议其实是非常有用的，它是整个Scrum 开发框架中第二重要的事件（最重要的是Sprint 计划会议），因为它是让Scrum 团队成长和进步的最好的机会。如果不开Sprint 回顾会议，不久以后你就会发现，你的团队在不断地犯着同样的错误。
不应该有理由和借口抛弃团队
不要隐瞒团队的技术实力，否则很难做切合实际的计划和评估
Wiki 是个不错的敏捷项目文档管理工具
善于寻求帮助是个好习惯，不仅仅是针对敏捷开发项目
Story、Backlog、Task（任务），它们之间的关系是怎样的呢？在Scrum 中，产品要完成的功能清单叫做产品Backlog。每一个Backlog项通常也叫Story，因为它是由User Story 来描述的，一个Story 是由一个完整的User Story 来描述的。有时候，一个比较复杂的Story 也可以分解若干个成更小的Story。Task 是任务，在具体实现每个Story 的时候都要将其分解成具体的任务，比如编码、测试、调研、Code Review 等，这些都是Task，而不能称为Story
其实类似升级机器这样杂七杂八的事情还有很多，有些就可以算在计划预留的缓冲里面
燃烧曲线是衡量团队进度的重要工具。但是不要过分依赖它作为监督和考核的依据，否则就会变味。因为团队会把重点放在生成漂亮的曲线上，而不是项目本身。
Scrum Master 要有敏锐的“嗅觉”，及时发现团队成员遇到的问题。
ECF ：Eclipse Communication Framework，是一个基于Eclipse 的协同工作框架，它让开发人员在开发产品时，相互间可以及时地沟通和交流。而最新的消息是，有爱好者开发出了可以在ECF 上共享同一个编辑器的插件。也就是说，两个人可以同时编辑一个文档，其中任何一个人的修改另外一个人都能实时捕获到，就如同是在面对自己桌面一样。
敏捷本质上也是一种先进的管理思想
将投资和回报最大化，快速反映市场的风云变换，敏捷开发是应对危机的最好武器
网友评论