敏捷开发— —Scrum 学习笔记
敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于”非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
如果要实行一个很好的scrum,通常要满足两点：一、团队有三名或以上的研发工程师；二、团队内有一名合适的Scrum Master。当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。
Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）,Scrum Master和开发团队。
特性团队的特点：
长期稳定的团队，逐个端到端完成客户特性 以客户为中心的特性驱动 跨职能、完整团队 共享代码库，统一的持续集成 拥有通用型专家 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
-
角色：谁要使用这个功能。
-
活动：需要完成什么样的功能。
-
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
每日站会
Scrum的理论基础是通过保持过程透明性让参与过程的所有人了解真实状况，然后进行检查和调整，每日站会是Scrum过程进行每天的检查和调整的环节。
团队商量决定谁做什么（不能有领导任务指派），为当天排一个计划 团队沟通状态，了解现状，发现障碍 团队回顾昨天的工作，做调整，持续改进 每日站会一定要站着开，每个人要精神集中，不能有懒散的表现。
每个人回答三个问题：
我昨天完成了什么任务？
我今天打算做什么任务？
我遇到了哪些障碍或困难？
同一时间只能有一个人发言，会上只说和这三个问题相关的话题，任何跑题的讨论，需要被ScrumMaster制止。一些的确需要讨论的问题，可以先记录下来，会后作为专题来讨论。
ScrumMaster
一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议，控制时间盒以及处理团队成员提出的障碍的话，你可以将这个角色当作成兼职来对待。在这种情况下，团队仍然有可能达到预期的目标，而且有可能不会发生什么重大事故。但是如果你展望团队能够做到你之前无法想象的事情的时候，你就成为了一位出色的ScrumMaster。
一位出色的ScrumMaster一次能够负责一个团队。