敏捷精灵日记13

[敏捷精灵日记]

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

阅读详细......

敏捷精灵日记12

[敏捷精灵日记]

• 拥抱变化（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的时间，可能得到一定的效果，但总体上会消耗的更多的资源，让团队疲惫不堪，造成生产力低下。

阅读详细......

敏捷精灵日记11

[敏捷精灵日记]

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

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 + 每次迭代都给出可以发布的版本。

阅读详细......

什么是敏捷软件开发？

敏捷软件开发不是一个具体的过程，而是一个涵盖性术语（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

阅读详细......

敏捷精灵日记10

[敏捷精灵日记]

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

阅读详细......

敏捷精灵日记9

[敏捷精灵日记]

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

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

阅读详细......

敏捷精灵日记8

[敏捷精灵日记]

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

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

阅读详细......

敏捷精灵日记7-2

[敏捷精灵日记]

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

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

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

阅读详细......

敏捷精灵日记7-1

[敏捷精灵日记]

• 采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。
• 在 “冲刺”和“冲刺”之间，留几天缓冲时间很重要。团队需要一段时间做一下调整，赶一些非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的人，必须在截止日期前给出答复。

阅读详细......

敏捷精灵日记7

[敏捷精灵日记]

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

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

• Sprint1---"越狱记（Breakout）
  

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

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

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

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

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

敏捷精灵日记6

[敏捷精灵日记]

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

阅读详细......

敏捷精灵日记5

[敏捷精灵日记]

• 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上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

阅读详细......

敏捷精灵日记4

【敏捷精灵日记】

• Scrum 团队强调自我管理，自我引导，这其实是管理的最高境界，如果团队里面的每个人都能够时刻关注公司的或者部门的business，那么整个公司的利益自然会最大化，但是现实往往不是这样的。那么设立Scrum master时，是不是可以让每个人在每个sprint里都有这样的机会来带领团队，并感受这种business的view呢？实际操作中这个是不是有难度呢？起码在我们现在团队中还不是轮换Scrum Master的，没准以后我们可以试试！

• 让Daily Scrum会议保持紧凑有效的指导原则：
  • 第一指导原则：主题明确，不能参杂其他无关的话题。
  • 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
  • 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。
  • 第四指导原则：确保整个团队都要参加每日Scrum会议。
  • 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议
  • 第六指导原则：每日Scrum站立会议应该控制在15分钟之内。
  • 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
  • 第八指导原则：Scrum站立会议要在每日同一时间同一地点举行
• Scrum Master要及时解决Daily Scrum上提出的阻碍。这一点非常关键，Scrum Master必须要做到，否则会影响每个成员反应障碍的积极性。
• 利用burn down chart来跟踪细分任务的完成情况，可以在项目进程的任何时间点都能够看到项目进展状况，而不是每周或者项目完成之后，从而保证了开发进度处于可控制的状态。

阅读详细......

敏捷精灵日记3

【敏捷精灵日记】

· 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)

阅读详细......

敏捷精灵日记2

[敏捷精灵日记]

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

• 瀑布模型有以下特点：
  

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

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

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

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

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

阅读详细......

敏捷精灵日记1

[敏捷精灵日记]

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

阅读详细......