Scrum敏捷开发
第一次听到敏捷开发是在刚毕业后的工作中的，而公司使用的是这种开发方式。
随着敏捷开发的不断发展，一些企业公司，多多少少的不知不觉的融入了一种敏捷的思维。
很多初创的互联网公司，更多的是一种功能的叠加开发和业务的扩展，这种模式也很适合于敏捷的开发模式，而在开发过程中也多多少少看到了这种影子。
基本角色和任务
Product Owner需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级。
Scrum Master的职责是：负责监督整个 Scrum 项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；保证开发团队不受外力的干扰和阻挠；掌握产品开发进度，参与每日 Scrum 会议、Sprint 计划会议和 Sprint 评审会议。
首先是根据需求讨论得出Backlog，Scrum团队根据功能模块把每一个Backlog又继续划分为UserStory，注意User Story由是由市场和客户驱动的，这样可以确保是由项目相关领域专家们来写User Story的，格式如下：
作为<某个角色>，我可以<做什么>，以完成<什么目的>。
为了高效的完成每个Story，由Scrum团队把每个Story分解为若干个Task，每个Task规定明确的完成时间（以小时为计量单位，一般不超过8小时）。
Scrum会议是一个很好的团队交流并把握整个项目进度的良好方式，这个会议的主体和受益者是团队的开发人员。
敏捷开发中的测试
考虑到敏捷开发团队，拥有属于自己的测试是很重要的，因为这种开发方式是迭代式的，开发和测试的分开，更多的会让软件变成流程式的，而敏捷开发强调的是以人为本。价值为本，要时时刻刻想着客户，想 办法创造真正对客户有价值的软件。当做到了能更快速地提供价值的时候，就是敏捷了。
测试开发分开为两个隔离的部门有好的也有不好的，好的是即使项目再多，测试人员也不用太多，这种情况下测试的成本是会缩小，但是测试那边的工作也会比较繁琐，很多时候并不能真正的体会到作为共同创造一个产品的乐趣，而这种的考核项目的方式也比较传统，有时候并不能把测试和开发作为同一个产品的研发队伍去考虑。
特别是引入了自动化测试后，测试人员应该是和一个产品相关联的，而不恩能够把测试仅仅是当做一种技能，这样也更能提升在产品中的影响力和作用。
不能流于形式
当然，敏捷开发也是一种管理哲学，而不能流于形式，有些人说敏捷开发不适合于做产品类的project，也有些人说敏捷开发室为了测试而搞出来的，除了提高可测试性没有别的好处。根据自己的项目的实际情况进行调整，或者多多少少会受到一点启发，或者这种方式就确确实实是你需要的。
书籍
看了《轻松Scrum之旅:敏捷开发故事》，简单的做了个图，毕竟是别人描述的经验，并不以一定适合每一个团队，但是也可以从中受到一些启发：
下面是从《轻松Scrum之旅:敏捷开发故事》书中节选的一些片段：
在每个 Sprint 开始之前，需要召开 Sprint 计划会议，会议时间一般为 4～8 小时，参加人员有产品责任人、Scrum Master、Scrum 团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner 从产品 Backlog 中挑选高优先级的任务，并与 Scrum团队一起决定在这个 Sprint 中需要完成多少功能。Scrum 团队将这些任务分解成小的功能模块。Scrum 团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
在混乱中建立秩序是 Sprint 开始阶段的目标。
敏捷和 Scrum 倡导团队自我管理，在任务分配上提倡每个人按兴趣和能力自主选择任务。
JSUnit 是为 JavaScript 而设计的，JUnit 是为 Java 程序设计的，都是自动单元测试的框架。我以前一直以为单元测试是测试员该干的工作，今天才明白原来得开发来做。
会议由 Scrum Master 主持，Scrum 团队的所有成员轮流回答以下 3 个问题。（1）昨天我完成了什么工作？（2）今天我打算做什么？（3）我遇到了什么障碍？
最重要的体会是每日 Scrum 会议很容易使团队产生凝聚力，不再是过去那种“你干你的，我干我的”的状况了。
你一定要记得不能在会上对这样的问题做过多的讨论，这是在浪费所有人的时间，你要做的是会后联系其他的资源来解决这个问题。
做 Sprint 计划的时候不能光图完成得快，还应该把方方面面的问题都考虑到。这句话说起来容易，要做到完美还真是很难。好在现在是一个 Sprint 结束后就可以暴露问题，而过去要很晚才能发现。
发现问题不是坏事。Sprint 评审可以帮助团队尽早地发现问题，尽早地得到使用反馈。
不要隐瞒团队的技术实力，否则很难做切合实际的计划和评估。
善于寻求帮助是个好习惯，不仅仅是针对敏捷开发项目。
在 Scrum 中，产品要完成的功能清单叫做产品 Backlog。每一个 Backlog项通常也叫 Story，因为它是由 User Story 来描述的，一个 Story 是由一个完整的 UserStory 来描述的。有时候，一个比较复杂的 Story 也可以分解若干个成更小的 Story。Task 是任务，在具体实现每个 Story 的时候都要将其分解成具体的任务，比如编码、测试、调研、Code Review 等，这些都是 Task，而不能称为 Story。
Sprint Goal 是个鼓舞士气的好工具。
在 Scrum 中，实际上要求 Scrum 团队是跨职能的。一个 Scrum 团队应该包含开发人员、测试人员、美工及文档人员。敏捷的开发流程迫切需要一个跨职能的团队。
ECF 的全称是 Eclipse Communication Framework，是一个基于 Eclipse 的协同工作框架，它让开发人员在开发产品时，相互间可以及时地沟通和交流。
将投资和回报最大化，快速反映市场的风云变换，敏捷开发是应对危机的最好武器。
敏捷开发是最注重人与人之间的沟通的，而现在在沟通上出了问题，该怎么办？想来想去，最好的方式莫过于面对面的沟通了，让双方都多了解一下对方的产品，先把以前存在分歧的地方达成一致，以后再通过邮件
和电话沟通，应该就会好多了。
Scrum 的可视性能够保证及时发现问题。不要隐瞒风险。要用非技术语言给客户提供足够的信息以便他们提前做出决策。
还有自动化 Unit Test，要是每次做完 Build 都能自动跑一遍 Unit Test 就好了，现在的问题一个是覆盖率太低，另一个是没有自动化。
按照产品整合部门可以大大提高执行效率，开发和测试在行政上属于一个部门有利于使他们结合成一个真正的 Scrum 团队。
IBM Rational 推出的 Jazz 是一个创新的团队协作平台，它将成为下一代 Rational软件开发平台的基本框架。
在测试新功能的时候必须先对原来的老功能做回归测试，以保证新加进来的功能不会破坏系统原有的功能和完整性。还有，咱们应该尽量实现自动化测试，这也是事半功倍的。
在生活中，敏捷可以无处不在，Scrum 其实蕴含着先进的管理思想。
持续集成是敏捷开发中核心的工程实践，它是敏捷产出“可以工作的软件”（Working Software）的有利保障。
敏捷也不仅仅是一堆软件开发方法和开发流程，它的本质是一种哲学思想，是一种做事情的方法论。我的体会，敏捷之道就在两点，以价值为本，以人为本。价值为本，要时时刻刻想着客户，想办法创造真正对客户有价值的软件。当做到了能更快速地提供价值的时候，就是敏捷了。帮助客户成功，你也就赢了。以人为本，说到底，价值还是由人来创造。一家新公司或者一个新团队的关键是人才，有了人一切都好办，对人才要好好珍惜。当人的能动性超越了一切死的流程，就是敏捷了。记得有一句话是这么说的，‘Youdon’t do Agile, You are Agile !’”
