Scrum相关

Scrum坚持如下敏捷开发原则：保持简单、接受变化、不断迭代、不断的反馈和改善、 协作和减少浪费
     Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。
     Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。 Scrum一词来源于橄榄球运动，指“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。”
     Scrum这一过程是迅速、有适应性、自组织的，它代表了从顺序开发过程以来的重大变化。
      Scrum的迭代过程被称为“快跑”，时间为2-4个礼拜。
     Scrum团队一般由5-10人组成，Scrum团队不仅仅是一个程序员队伍，它还应该包括其他一些角色，如产品经理、设计人员和测试人员等
     Scrum包含三类角色: Scrum Master， Product Owner， Scrum Team
     相对于传统的开发模式来讲，agile也好，scrum框架也好，都是现在软件开发中用于应对快速变化的市场和需求快速反应的一种变通
     Scrum是一个非常轻量级的流程。简单讲是先建立一个产品"订单"(backlog)，做一个短期“冲刺” (sprint)计划，执行这个计划，每天开会讨论计划中的问题和进展，计划完成后演示工作成果，再对该阶段的工作做回顾、反思，接着不断重复以上流程。

      瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划 分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下 落。

     瀑布模型有以下特点：

   1. 为项目提供了按阶段划分的检查点。
   2. 当前一阶段完成后，您只需要去关注后续阶段。
   3. 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，其主要问题在于：
   4. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
   5. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

     早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

     在做大的变革之前，积极听取其他成员的意见，努力理解其他成员的观点；获得团队主要成员的支持，是保证变革成功的重要一环。

     软件开发根本就没有什么灵丹妙药可言。虽然敏捷编程技术可以很快开发出优秀的应用软件，但不是说这项技术适合每个项目。在实施敏捷之前，一定对现有项目做好分析，要对症下药。

     在Scrum开发模式下，为每个Sprint起一个名字，不但可以增加团队软件开发的乐趣，提高大家的参与程度，还可以记录下Scrum Team当时的心情

Scrum注重的是管理和组织实践，XP关注的是编程实践，可以分别解决不同领域的问题。可以组合使用，互相补充。

· 一条可以实行的实践原则，会比长篇大论的理论有用许多，没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践，必须通过XP或其他方法来补充

· 使用XP，可以使开发人员成为更好的Developer， 但Scrum方法能够迫使那些效率低的developer变得更有效率。

· Nokia的Scrum标准

1. Scrum 团队必须要有产品负责人，而且团队都清楚这个人是谁。
2. 产品负责人必须要有产品的Backlog，其中包括团队对它进行的估算。
3. 团队必须要有燃尽图，而且要了解他们自己的生产率。
4. 在一个Sprint中，外人不能干涉团队的工作。

· scrum虽然强调文档、流程和管理的轻量化，但并不是意味着没有控制，没有计划，只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整，从而达到提前交付

· ScrumMaster与传统项目经理相比，必须从从传统的控制者转变为引导者。

· scrum中，对任务细分和时间估计，需要整个开发小组和Product Owner的参与。

· Sprint计划会议议程

上午(2 Hours)

1)充实并讲解Product Backlog[Product Owner] (50 Minutes)
2)重新调整Product Backlog条目优先级[Product Owner] (10 Minutes)

休息(10 Minutes)

3)设定Sprint目标[Scrum Team] (10 Minutes)
4)选择Product Backlog条目，组成Sprint Backlog[Scrum Team] (40 Minutes)

下午(3-4 Hours)

1) 分成两个小组，进行任务细分， 定义"DONE"，给出任务估算. (60 Minutes)
2) 小组间互相评审，解决争议(20 Minutes)

休息(15 Minutes)

3) 关键路径分析(20 Minutes)
4) 制定资源计划(20 Minutes)
5) 任务领取(20 Minutes)
6) 风险分析(20 Minutes)
7) 其他事情(10 Minutes)


   

      Scrum 团队强调自我管理，自我引导，这其实是管理的最高境界，如果团队里面的每个人都能够时刻关注公司的或者部门的business，那么整个公司的利益自然会最大化，但是现实往往不是这样的。那么设立Scrum master时，是不是可以让每个人在每个sprint里都有这样的机会来带领团队，并感受这种business的view呢？实际操作中这个是不是有难度呢？起码在我们现在团队中还不是轮换Scrum Master的，没准以后我们可以试试！
     让Daily Scrum会议保持紧凑有效的指导原则：
          o 第一指导原则：主题明确，不能参杂其他无关的话题。
          o 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
          o 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。
          o 第四指导原则：确保整个团队都要参加每日Scrum会议。
          o 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议
          o 第六指导原则：每日Scrum站立会议应该控制在15分钟之内。
          o 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
          o 第八指导原则：Scrum站立会议要在每日同一时间同一地点举行
     Scrum Master要及时解决Daily Scrum上提出的阻碍。这一点非常关键，Scrum Master必须要做到，否则会影响每个成员反应障碍的积极性。
     利用burn down chart来跟踪细分任务的完成情况，可以在项目进程的任何时间点都能够看到项目进展状况，而不是每周或者项目完成之后，从而保证了开发进度处于可控制的状态。




     Sprint 评审会议不是让开发团队做成果“演讲”——会议上不一定要有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。
     在Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发 团队会跳过此过程, 这是不合适的,因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum 开发团队，产品所有者和ScrumMaster 都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。
     敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。
     Scrum回顾会议的议程：
      1、在白板上写上主要指导原则；
      2、在白板上画上一个至少三页纸连在一起长的时间轴；
      3、在白板上写上“我们的成功经验是什么”；
      4、在白板上写上“有什么能够改进”；
      5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。
     Scrum回顾会议的最高指导原则。即‘无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。'
     在项目过程中，处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候 很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地“敲击”对方，或者反复“锻炼”开发过程与方法，就能够 让每一 位成员都炼就“火眼金睛”。
     进行Scrum回顾时，发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。
     在每个Sprint开始的时候，我们都必须要明确这个 Sprint结束的时候我们需要Review的是 哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。 ”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除拒 绝通过这些相关的 User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

      管理中的愤怒和羞辱是会传染的.如果高级经理喜欢骂人,低级管理者也会这样做。
     如果经理使用辱骂的方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
     作为一个经理，宁讲错话，不讲假话。假话一旦揭穿，底层员工从此再也无法信任上层经理


      Sprint0---"兵不厌诈（the Big Con）"

因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊

     Sprint1---"越狱记（Breakout）

经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第二个Sprint取得重大突破（breakout）

     Sprint2---"虎口余生（Hours to doom day）"

这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的工作就无法进行，将是非常关键的一次攻坚战。

     Sprint3---"大结局(The Big End)"

这次计划会议，作为Scrum Master，自己因为有事没有参加，汗！但大家认为阶段性工作基本差不多可以做完了，起了个结局的名字。

      采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。
     在 “冲刺”和“冲刺”之间，留几天缓冲时间很重要。团队需要一段时间做一下调整，赶一些非sprint计划中的事情。这段时间是一个很好的用来解决一些技术 或者工具问题的机会。你会发现你慢一下后，会变得更有效率。这就是为什么叫“sprint”的一个理由，你不可能无休止的冲刺。
     没有规矩，不成方圆。由团队共同制定出来的Scrum 团队规则，可以更好的保证Scrum的顺利实施。

[Scrum团队规则]

1. 每日站立例会迟到，罚款￥5.
2. 对于每个，未及时更新任务状态和剩余工作量，整个Team留三次免罚机会，以后再有人违反，则罚款￥5.
3. 对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款￥5.
4. 进行任务细分时，每个任务估算最大不能超过18小时(三天)
5. 在Sprint计划会议上, 认领了一项任务的人，可以对该任务估算做出不超过50%的调整
6. 对于复杂任务的估算和分解，采用“DELPHI”方法
7. 每个人都可以添加新的product backlog条目, 但必须标示为 'Not Reviewed'， 以方便Product Owner审议.
8. 为提高Sprint回顾会议的效率，在Sprint回顾会议之前,每一个人应该给出“我们做得好的地方、需要改进的地方”
10. 在Sprint计划会议上, 我们应该预留10%的估算时间作为缓冲，以应对突发事件
11。 在Sprint计划会议上, 我们应该进行关键路径、风险、外部依赖的分析
12. 对于Review，发出review的人必须给出截止日期，参与Review的人，必须在截止日期前给出答复。


1．持续集成最大的优点是可以避免传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

     访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码（以及以前的版本）。
     支持自动化创建脚本，使 创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
     测试完全自动化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运行一套完整的系统测试。
     提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
     提倡开发人员频繁的提交（check in）修改过的代码。


2．项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。

有效限制持续集成(Continue Integration) 反模式的建议：

     经常提交代码，可以防止集成变得复杂。
     在提交源代码之前运行私有构建，可以避免许多破碎的构建。
     使用各种反馈机制避免开发人员忽视构建状态信息。
     有针对性地向可以采取措施的人发送反馈，这是将构建问题通知团队成员的好方法。
     购买更强大的构建机器，从而加快向团队成员提供反馈的速度。
     避免构建膨胀。


      TDD 以可验证的方式迫使开发人员将质量内建在思维中, 长期的测试先行将历练开发人员思维的质量，而事后的单元测试只是惶恐的跟随者.
     重构不是一种构建软件的工具，不是一种设计软件的模式，也不是一个软件开发过程中的环节，正确理解重构的人应该把重构看成一种书写代码的方式或习惯，重构时时刻刻有可能发生。
     软件构建学问中总有一些理论上很美好，但是一使用就可能面目全非，比如传统的瀑布模型。敏捷里很多被称之为思想的东西，恰恰没有太高深的理论，但都是一 些实践的艺术，强调动手做而不是用理论论证。TDD就是这样一种东西，单纯去研究它的理论，分析它的优点和缺点没有任何意义，因为它本身就是一个很单纯的东西，再对其抽象也得不出象“相对论”那样深厚的理论。更多的实践会给出正确的答案的。
     结对编程不是一种形式化的组合，在实际的XP小组中，结对的双方应该是根据需要不断变换的，对的结成应该是自发的，应该保证双方都是对这部分工作感兴趣的人，而不是强行指定。
     结对编程不是结队编程，是2个人，不是更多


     就象Scrum一样，并不是所有的team都有能力实行XP，也不是所有的项目都适合实行XP，要看实际情况而定。
     xp中，多数实践方法是互相加强甚至是互相保证的，不能单单拿出某一个实践来单独实施，譬如结对编程，缺乏TDD/重构/简单递增设计的实践的有效补充，效果可能会大打折扣。



     对Prodcut Backlog中的用户故事做估算时，如果某项太大太空难以确切估算，及时对它细化。
     使用计划纸牌可以极高的提高估算速度。一次估算中，如果任何两个人的估算值相差过大，一定要停下来澄清后，再重新估算。
     给团队配置两倍的人，并不能得到两倍的生产力的。人越多，交流的成本越大，效率就越低。如果希望靠增加人员来提高软件团队的生产力，无疑是南辕北辙


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

敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。

价值观

雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：

人和交互重于过程和工具。

可以工作的软件重于求全责备的文档。

客户协作重于合同谈判。

随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

原则

宣言中还包括以下原则：

对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。

我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

可以工作的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单--尽可能减少工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

对比其他的方法

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法
集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。

对比瀑布式开发

两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。

敏捷方法的适用性

在 敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的 适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的 角度看，组织结构的文化、人员、沟通泽决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：

组织文化必须支持谈判

人员彼此信任

人少但是精干

开发人员所作决定得到认可

环境设施满足成员间快速沟通之需要

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法适更用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

另 外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为 主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可 以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。

方法列表

目前列入敏捷方法的有：

软件开发节奏，Software Development Rhythms

敏捷数据库技术

AD/Agile Database Techniques

敏捷建模，AM/Agile Modeling

自适应软件开发，ASD/Adaptive Software Development

水晶方法，Crystal

特性驱动开发，FDD/Feature Driven Development

动态系统开发方法，DSDM/Dynamic Systems Development Method

精益软件开发，Lean Software Development

Scrum

测试驱动开发，TDD/Test-Driven Development

XBreed

极限编程，en:XP/en:Extreme Programming

      精益软件开发的七大原则：

         1. 消除浪费(eleminate waste)
         2. 强化学习，鼓励改进(Focus on learning)
         3. “注重质量”build quality in
         4. “推迟承诺”defer commitment.
         5. “尽快交付”deliver fast
         6. “尊重员工” respect people
         7. 优化整体 optimize the whole



     准时化开发 = 持续集成 + 迭代开发 + 多次交付。
     零库存 = TDD + 每次迭代都给出可以发布的版本。

      拥抱变化（Embrace the change）

无论是多么明智，多么正确的决定，也有可能在日后发生改 变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变 的是变化”。团队更要信任利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风 险，实现团队最大化利益，理解这是适应市场变化的必然行为。而在接受变化的同时，我们应该积极的向利益干系人（Stakeholder）和客户代表反映实 现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案 可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。

   

      对一个项目开发来说，release (发布）拥抱变化。对于一个sprint/iteration，要拒绝变化。sprint计划前，product backlog都可以变化。
     ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。
     ScrumMaster使团队在Sprint过程中免受干预
     教授产品负责人如何实现投资回报最大化，以及如何利用 Scrum达成目标
     在影响Scrum正常实施的众多因素中，在 sprint过程中加入新需求，大部分人都很难很难抵御这样的诱惑，是scrum的第一杀手。
     在一个Sprint执行过程中，如果遇到一些问题导致 Sprint的原始目标不能实现，此时需要及时地 调整目标。如果不愿意调整目标，任意延长sprint的时间，就严格违反了Sprint的Time-Box特性，以后大家再遇到问题时，会自然而然的想再 延长Sprint，那么Sprint快跑的意义也就不存在了。
     从另外一个角度讲，如果急于看到结果而压缩 sprint的时间，可能得到一定的效果，但总体上会消耗的更多的资源，让团队疲惫不堪，造成生产力低下。


      正确衡量生产力的公式：生产力=已经完成的工作量 – 用于修正Bug的工作量 – 用于修正错误设计的工作量
     任何想在短期内迅速提高生产力的想法都是杀鸡取卵的自杀式行为。
     任何时候，工作超过40小时，都需要恢复期，无论你怎么调整；一周35-40小时可以这样安排：每天工作 10小时，持续四天，然后休息三天。上述“压缩工作周”，不仅可以减少缺勤，在某些情况下，可以提高生产力10-70%
     每周四天工作制会比五天工作制效率更高。
     短期不超过3个礼拜的冲刺会临时提高生产力， 团队可以有策略的选择加班，可以完成最近的最后期限；加班后，生产力会有同等程度的降低，应该根据这个因素马上调整计划
     按照项目划分成跨功能的小团队；对于大的项目，利用’Scrum-Of-Scrums’把小团队联系在一起；制定关于创建团队、划分大团队、团队间人员流动的流程/规则
     混合团队会比单一团队效率更高
     好的管理人员会想办法鼓励团队去创新，会选择预留一定时间让团队去思考如何创新，而不会压榨员工的每一分钟。


各类大中小型企业所运用的传统软件构建方法，即是众人在很多变体，但其典型性是在开发初期制定详细的计划，计，并且一切详细资料都记录在案。任务已设计制定，并工具和Microsoft Project 项目管理软件。开发团队预计开发而得出的。当项目管理者(stakeholder)全面审核开发计划并团队成员完成他们所专长的部分工作，即刻转交给其他成工作都已完成，成品将会转交给产品质量控制部门，在这的全面检测。在整个流程中，所有相对于原始计划的分歧成品与原始设计保持一致。

此种模式有优点但也有不足之处。它的最大的优点是非常记录下来，按照计划实施，保持各项事务尽可能的有组织参与,人对于此种工作方式并不适合。

比如：此种方式要求所有的建议和想法都要在开发周期的可以被容入开发计划之中。但是众所周知，好的想法和建开发最启始阶段，在开发中期，有时可以在产品交付使用许变化的产生，那么将会遏制创新的产生。在使用“瀑布新将不是好的征兆，而是对整个产品开发产生的危机。

瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个
成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的最实际的证据。但是实
际上，在大多数情况下，没人会读这些100 页左右的详细规格要求资料。同样，如果有人读取
该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资
料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的
产生也就不足为奇了。

当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品
时，你可能会立刻产生20 种方法以使产品更加完美的灵感。但是遗憾的是，这些非常有价值的
想法通常会在产品开发的末期产生，这时创新是最困难和最具有分裂性的——换句话说，是做
正确抉择最昂贵的时刻。

人的预知未来的能力是有限的。比如，某场比赛的最终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能
力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (根特)图表的衰败
表现。

另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要
求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些指引我们对瀑布方式的另一思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。

一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是在产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并
将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和最起始的想法保持一致，
而不是开发团队在实践中不断发现可能性而使其尽善尽美。

许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是一个极其付有逻辑性的方式，所以第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发
挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利
地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的
结果越差！

Agile (敏捷) 开发和Scrum

Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况, 以便取得更好效果的信念上。Agile 强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。
Agile 注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile 注重快速
迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile 的时候，经常会有这样的公认——感觉非常像回到了开发启始的阶段，我们曾经”做过”。

Scrum 是众多快速发展的Agile 方式之一。Scrum 是在十多年前由Ken Schwaber 和Jeff
Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ,
Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE Medical, CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这
是非常重要的。Scrum 是简单的，强有力的，并立足于常识之中的。




Scrum 是迭代的，增量型的流程。
Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。
在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。
每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint 做好准备。

Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。



敏捷精灵日记]

   1. 无论一个测试人员有没有发现Bug，都不能说明他有没有好好工作。测试人员的职责更多的应该是‘保证质量’（quality assurance），而不是“控制质量”（quality control）。一个好的测试人员应该是在问题出现之前，防止其成为Bug。
   2. 对于一个敏捷团队而言，再单纯以测试人员发现的Bug数量，作为衡量其绩效的唯一标准，是非常没有意义的。
   3. 如果有一个核心测试集，能够覆盖用户如何使用一个产品的常用情形，会更有价值。对所有用户使用情形都做自动化测试是没有必要的。

在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。

产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。

开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。

ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的 ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时，ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。



如何启动Scrum

  Scrum 的第一步是产品所有者清晰地展示产品的未来景象（vision）。这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。这就是Product Backlog,它存在（并发展）于产品的整个生命周期（图示2）。Product Backlog 包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和已知的bugs（“判断并修复定单流程中的错误”）。


Product Backlog 是由产品所有者随时更新，以反映客户需求的变化，竞争对手的发布，新的想法和见识，出现的技术障碍等等。



在项目开发的任何时候，Product Backlog 是唯一具有权威性的“需要完成的所有任务”的概况。只可以存在唯一一个Product Backlog；这就意味着产品所有者需要在所有的工作范围中作出优先项的决策。


      为Sprint中任务给出明确的”DONE” 定义是非常重要的，但即使你遵循这个最佳实践，但最终仍然会有集成问题，会存在Bug, 以及晚期的需求变更。所以，在正式发布前，单独计划1-2个Sprint, 专门做Bug修复，是非常合理的，并不是“反Scrum”的模式。

Sprint 计划会议是保证整个Scrum顺利进行的重要一环之一！如何开好，非常关键！

Sprint 计划会议在每一Sprint 的启始阶段进行。在Sprint 计划会议的第一部分，产品所有者和Scrum 开发团队（在ScrumMaster 的协助下）共同评审Product Backlog，讨论Backlog 中各项目的目标和背景，并提供Scrum 开发团队深入了解产品所有者想法的机会。在会议的第二部分，Scrum 开发团队从Product Backlog 中挑选项目并承诺在Sprint 的末期完成任务，从ProductBacklog 的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序依次工作。这是Scrum 的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，他或她只知道开发团队负责的项目是由Product Backlog 中按顺序从上至下进行的——换而言之，是从他或她选择的最重要的项目开始。开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。


Sprint 计划会议通常会持续几个小时——开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完 成Sprint 相关工作的时间开始——换句话说，是团队成员平均的工作时间减去他们花费在检修bug 和其他必要的维护工作，参加各种会议，回复电子邮件，午休等的时间。大多数人会有4 到6 个小时每个工作日可以完成Sprint 相关的工作。（图示3）

当可利用时间确定下来，开发团队会从Product Backlog 的顶端第一项开始工作——换句话说，从产品所有者的最高优先权项开始——团队共同工作，将其分配为小块任务，并记录在SprintBacklog 中（图示4）。当任务确定后，团队成员可以自愿承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog 分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog 序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估算时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务（写在便签上）在Sprint 中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。



Scrum 的重要支柱之一是当Scrum 开发团队确认承诺任务后，产品所有者在此Sprint 期间不可以添加新的需求。这就意味着即使在Sprint 中途，产品所有者想要添加新要求，他或她在下一新的Sprint 开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该 Sprint；意味着开发团队停止一切工作，重新开始Sprint 计划会议等等。此种决断会产生很大的影响,除非在非常特别情况下，不会采用这种方式。

保证开发团队在Sprint 中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排 Product Backlog 中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint 中不可变更的，使其在决定从哪一项目开始工作更为细心。

作为回报，产品所有者也可以得到两个好处。首先，他或她有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum 开发团队将会做的很好。第二，产品所有者可以在下一Sprint 开始前，提出他或她希望的变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint 进行中提出任何变更，他或她只是需要等待一个Sprint 的完成时间或更短。不再僵持于是否变化——方向的变更，条件的变更，或只是简单的想法的变更——可能正式此原因，使得产品所有者成为Scrum 拥护者中最热衷的成员。

Scrum 介绍系列5--- 每日站立例会（Daily standup meeting）


每当Sprint 开始, Scrum 开发团队将会实施另一个Scrum 的重要实践方法:每日（站立）例会。这是在每个工作日特定的时间举行的短小（15 分钟）的会议，Scrum 开发团队的每一成员都将参与；为了保证其短小精悍，与会成员都保持站立（因此为“站立会议”）。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。

一个接一个，每个团队成员只可以向其他人汇报三件事情：

     从上次会议之后完成了哪些工作，
     在下次会议之前准备完成哪些工作，
     在工作进行中存在哪些障碍。


ScrumMaster 将会把障碍内容记录下来，在会后协助团队成员铲除障碍。在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后进行。产品所有者，经理和项目管理者可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论——每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向产品所有者，经理或ScrumMaster 汇报。这个会议并没有标准形式，有些团队感觉邀请产品所有者参加并将其每日工作做一简要阐述，是对团队工作极其有意义的。

在会议结束后，开发团队成员将对其负责的Sprint Backlog 中的项目做剩余时间的更新。这些信息会记录在Sprint Burndown Chart 图表中（图示5）。它是用来显示每日直至开发团队完成全部任务的剩余工作量（以小时或天计算）。理想的情况下，抛物线轨道在Sprint 的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少（对于Scrum 来说这是不太相关的事项），而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint 末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。此图表也可以使用Excel 表格管理，许多团队认为在他们工作室的墙上用图纸标明更为简单和有效，并可以用笔随时更新；这个技术含量不高的做法比电子表格更快速，简易和更可见。
Scrum 的核心原则之一是Sprint 的周期不可以延长——其结束于指定的时间不论开发团队完成任务与否。如果开发团队未完成其Sprint 目标，他们将在Sprint 的末期声明他们没有完成预期的任务。这个方法创造了反馈循环的可视性，并强制开发团队在Sprint 预期估算时做出更好的判断，并确保可以按时完成任务不会失败。开发团队通常在前几个Sprint 时试图完成许多任务，但实际上并不可以达到Sprint 目标；然后他们可能会过度小心而挑选较少的任务，结果会提前完成；在第三或第四个Sprint 时，开发团队通常会了解自己的工作效率，他们会按时完成Sprint 的目标。鼓励开发团队在某一Sprint 中挑选一个周期（比如两周）并且不经常变化——固定的周期可以帮助开发团队了解他们的实际工作效率，并且可以帮助其达到工作的节奏性（此指团队的统一“心跳”）。

在Sprint 结束后，将进行Sprint 评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10 分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈