Algin敏捷

鸡和猪的故事
一天，一只鸡散步时遇见了猪。
鸡对猪说：“嗨，我们合伙开个餐厅吧。”
猪说：“好啊，那准备取什么店名呢？”
鸡说：“要不，就叫火腿和鸡蛋吧。”
猪直接拒绝了：“那可不行。我要割肉，你只要下蛋。这样下去，我迟早要完蛋。”
这个故事实际上反映了软件开发过程中的2种不同角色，即需要完全投入的“猪”和只要部分投入的“鸡”。真实项目过程中，往往会发生这样的现象，产品经理或领导，喜欢临时往项目中新增任务，打乱原先的开发节奏，导致程序员压力倍增，士气低落，项目延期。
而Scrum，就是为了保护“猪”这种角色，兼顾“鸡”的感受，从而确保整个项目正常交付。它是一套敏捷开发流程。
Scrum的角色
就Scrum的职责来讲，分为：
1.Project Owner：即产品经理，大部分时间担任了“鸡”的角色，迫于领导的压力，喜欢往团队中不断增加任务或修改需求。
2.Scrum Master：类似于项目负责人，他需要做的是保护团队，兼顾产品经理的需求，确保项目的按时交付。
3.Team：开发测试设计人员，Scrum Master本身可能也是开发人员。
Scrum的流程

Scrum用到的工具
1.用户故事。迭代计划会议用到，Product Owner以用户的角度去描述需求。如，作为一个学员，我希望能在做完一份试卷后，系统能针对我的薄弱点提供相应的指导及练习。
2.Product Backlog。迭代计划会议用到，Product Owner事先将所有的用户故事按优先级排好，放到一个列表内，这个列表就是Product Backlog。
3.Sprint Backlog。迭代计划会议用到，整个开发小组通过估点将用户故事按优先级移入到迭代计划内，迭代计划中待完成的用户故事列表即为Sprint Backlog。
4.估点。主要用于评估用户故事的大致工作量。下一篇文章会额外介绍估点。
5.燃尽图。主要用于迭代进度的管控。下一篇文章会额外介绍燃尽图。
Scrum标准流程之Sprint Planning Meeting
迭代计划会议中，整个小组通过估点的方式，按优先级将用户故事从Product Backlog中移入到Sprint Backlog，表示整个小组承诺本迭代要做完的任务。做完的标准是测试通过，除非此任务不可测试。
Scrum标准流程之Daily Stand Up Meeting
迭代计划会后，小组成员按个人喜好领取自己的任务，并在每天的站立会议上讲一下自己昨天做了什么，今天准备作什么，大概什么时候完成，以及遇到了什么问题。当有人提出遇到难题时，Scrum Master需要在会后安排人帮忙解决，而不是在会议上直接解决。每个人大概30秒-1分钟，整个会议一般不超过15分钟。每一个工作日结束后，需要画燃尽图（下一篇文章会额外介绍）。
Scrum标准流程之Review Meeting
一个迭代开发阶段结束后，进入内部演示会议，工作成果给整个小组演示（包括Project Owner）。EduSoho的做法是，bug及小优化不演示，点数较大的功能点做演示。
Scrum标准流程之Restrospective Meeting
内部演示结束后，整个小组（包括Project Owner）召开一个迭代回顾会，回顾本迭代中大家哪些做的好，哪些做的不好，每人各列举3个好的以及不好的，列的时候只讲现象，不分析原因，不找解决方案。然后整个小组投票选出3个不好的，分析原因，寻找解决方案，并指定执行者。
为什么只解决3个不好的？每个小组的精力有限，如果要一个迭代内解决全部问题，不太现实，先优先解决3个最重要的，多次迭代后，会发现整个小组的变化越来越明显。
TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。

BDD,Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。在过去数年里，它得到了很大的发展。

DDD(Domain-DrivenDesign领域驱动设计)是告诉我们如何做好业务层！并以领域驱动设计思想来选择合适的框架。
我们知道软件的产生过程是：分析、设计、编程、测试、部署。过去，分析领域和软件设计是分裂的，分析人员从领域中收集基本概念；而设计必须指明一组能在项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题。 模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。
2004年著名建模专家EricEvans发表了他最具影响力的著名书籍：Domain-DrivenDesign–TacklingComplexityintheHeartofSoftware（中文译名：领域驱动设计　2006年3月清华出版社译本，或称DomainDriven-Designarchitecture[EvansDDD]）。时值今日，DDD开发框架已经层出不穷（如RoR、RIFE、JdonFramework等），我们项目软件包结构都变成了这样：xxx.model;xxx.service，DDD思想可以说是遍地开花了.领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道.
模型驱动设计(Model-DrivenDesign)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。单一的领域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计，会编程。

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.

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

Kanban，“看板”是一种生产管理系统，由1940年代的丰田汽车公司发明。名称源自日文“看板”。在软件开发过程，可以使用用“看板卡”（经常为即时贴）来执行看板。这些卡片不是作为提高生产量的信号，而是用于记载生产数量和标记生产过程。在虚拟看板系统中，会使用虚拟看板卡。在软件开发中,我们采用虚拟看板系统来限制在制品。
Agile方法的四个价值：
（1） 较之于过程和工具，更注重人及其相互作用的价值。
（2） 较之于无所不及的各类文档，更注重可运行的软件的价值。
（3） 较之于合同谈判，更注重与客户合作的价值。
（4） 较之于按计划行事，更注重响应需求变化的价值。
Agile方法的指导原则：
（1） 在快速不断地交付用户可运行软件的过程中，将使用户满意放在第一位。
（2） 以积极的态度对待需求的变化（不管该变化出现在开发早期还是后期）。Agile过程紧密围绕变化展开并利用变化来实现客户的竞争优势。
（3） 以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用。
（4） 在项目过程中，业务人员和开发人员最好能一起工作。
（5） 以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任。
（6） 在项目组中，最有用、最有效的信息沟通手段是面对面的交谈。
（7） 项目进度度量的首要依据是可运行的软件。
（8） Agile过程高度重视可持续开发。项目发起者、开发者和用户应能始终保持步调一致。
（9） 应时刻关注技术上的精益求精和设计的合理，这样能提高软件的快速应变力。
（10） 简单化（尽可能减少不必要工作的艺术）是基本原则。
（11） 最好的框架结构、需求和设计产生于自组织的项目组。
（12） 项目组要定期对其运作方面进行反思，提出改进意见，并相应进行细调。