敏捷精灵日记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，自己因为有事没有参加，汗！但大家认为阶段性工作基本差不多可以做完了，起了个结局的名字。
阅读详细......