书籍介绍
作者：周金银
博客：http://www.cnblogs.com/zhoujg/
原文下载地址：敏捷方法之Scrum v0.2原文下载
笔记内容
软件复杂度有三个主要因素：业务、技术和人员。《agile project management with scrum》（中文书名：Scrum敏捷项目管理）一书中有一个复杂度的图。
X轴表示技术（成熟度），Y轴表示业务（一致度）。从图中可以看到，业务和技术是正交的，各自对复杂度都有影响，我们在开发过程中需要做的通过各种办法尽量确保从Anarchy－Complex－Complicated－Simple进行转移。 技术和业务最终都需要人来执行，而每个人拥有不同的技能、经验和观点，当这些人在一起合作时又会使得开发过程变得复杂。
这些复杂性将导致开发过程中存在很多不确定性，所以项目初期制定的计划其实基本上不能真正的坚持下来。而当项目开发遇到困难时，项目组可能会为了表明自己做计划的能力，或者不想经历复杂的变更过程，而继续努力的坚持这个已经错误的计划。范围、时间和成本，这 个金三角几乎没有领导不知道，而项目组为了保证”遵循计划“，对外宣称项目组运行状况良好，保证当前人员在预计时间肯定能保质保量的完成开发。而代码质量 只有开发人员知道，领导们容易忽略和难以控制这个环节，所以最后一味的遵循计划就势必导致提供给客户的是一个不满意的产品。
Waterfall VS Agile
瀑布式开发是计划驱动的，合同谈判后项目组制定计划并且遵循计划，在过程与工具支持下通过面面俱到的文档来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。而敏捷开发是价值驱动，通过自组织团队在短期迭代过程中不断的交付对用后有用的功能来进行产品开发。从上图的正反三角形图形可以看出两者的驱动是不同的。
客户协作 胜过 合同谈判
虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。
响应变化 胜过 遵循计划
虽然我们致力于响应变化，但并不是像上面漫画所说的不需要计划了,反而我们需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通 过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调 整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。
个体与交互 胜过 过程与工具
一个使用普通工具的优秀人员会比使用优秀工具的普通人 员做得更好，一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时 和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径 解决开发过程中遇到的问题。
可以工作的软件 胜过 面面俱到的文档
虽然我们致力于提供可供做的软件，但并不是不要文档。我们在开发过程中仍然需要进行内部交流， 也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求和算法，只要自组织团队认为足够就行了。
Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级，以便将最具价值的功能安排在下一个迭代中完成。团队的责任是开发软件功能，他们是自组织团队，团队所有成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则需要对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需督促 全体成员遵从Scrum规则和实践。
Prodcut Backlog
产品backlog根据用户价值罗列所有即将在产品中开发的功能，通过简洁的展示需要实现的功能，我们可以对项目进行规模上的估算，确定发布计划和迭代计划。
Product backlog应该由Product Owner来制定
怎么拆分故事
很大的故事基本上都能进行拆分，只要确定每个小故事莹然可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。
书籍介绍
Scrum被认为是目前全球最流行与最有效的敏捷项目管理理念与方法之一，在软件业发达地区被众多知名企业广泛采纳。本书是Scrum理论与实践的重要奠基之作，作者是Scrum的缔造者，深受软件行业人员尊重的敏捷大师。本书详细描述如何在复杂技术项目中使用 Scrum，并结合真实的Scrum案例及专家洞识，在简明及高度概括的理论之上更侧重于实践，并不断强调Scrum原则的坚持及实践的灵活性。
此书探索Scrum的每一方面，包括科学原理、伞新的项目角色及责任、ScrumMaster、产品负责人、如何有效管理未知因素和不断变化的产品需求、如何结束混乱、如何计划和报告、及如何扩展项目团队规模等，并着重于如何驱动项目以实现最高的投资回报。
笔记
Scrum的核心价值观是：承诺、专注、公开、敬重和勇气。它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则。
在黄昏里希冀皓月与繁星
在深夜希冀着黎明
在炎夏希冀凉秋
在严冬又希冀新春
这不断的希冀啊，
使我感触到世界的存在，
带给我多量的生命的力。
这样，
我才能跨过——
这黎明黄昏，黄昏黎明，春夏秋冬，秋冬春夏的茫茫的时间的大海啊。
项目复杂程度越高，便越需要将决策权委派至工作前线的独立个体。
Scrum能有效运作的另一个原因在于，它可以就一个问题集思广益。
Scum将小型团队转化为自身命运的管理者。
Scrum团队接受挑战，找寻应对挑战的方法，发挥创意，避开工作障碍，而这一切都无法由中央控制及调度系统预先安排。
如果团队规模合适，能激发各成员的参与积极性，同时团队成员能意识到他们对自身命运的掌控，那么各成员的经验，意见和想法便可以充分利用，而非遭到压制。
产品负责人应引导团队工作以实现企业最大价值。这类工作不仅包括将最高优先等级的产品Backlog转化为功能，还应坚持工程惯例和标准。
未能促使改进的评审会议是成果贫乏且令人沮丧的。
ScrumMaster负责扫除开发团队、产品负责人和客户之间的障碍，确保客户能直接推动开发工作。ScrumMaster的另一个职责是告诉产品负责人，如何利用Scrum使项目投资回报最大化，达成项目目标。
Scrum基于协作需要理解，也即顺畅的交流。若产品负责人只谈商业，团队只谈技术，双方无法交流，也就没有协作。
Scrum的生产力源于：首先选择正确事项，然后高效完成选定事项。
团队从被管理到自我管理的转变过程十分困难，但在生成力和工作愉悦度方面的回报显著。
ScrumMaster的职责不是管理团队，他们应学会自管理，不断调整方法，提高成功机会。
瀑布式开发过程使人际互动和面对面交流最小化，产生隔离。该过程强调人际书面交流，但团队需要广泛的交流，以减少误解和后继错误。成员不仅被办公场所隔离，其工作与互动也因开发过程而隔绝。
Product Backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。已划分有限等级的项目需求清单，标有将其转化为完整产品功能的预估时间。以天为单位，条目在产品Backlog中优先等级越高，预估值越精确。清单随业务和技术条件的变化而改变。
Product BlackLog Item：包括功能和非功能性需求及其他议题。按业务和依赖性的重要程度划分优先级，并做出预估。预估值的精确度取决于BlackLog Item条目的优先等级和细致程度，入选下个Sprint的最高优先等级条目的预估会非常精确。
Sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。
Increment（增量）： 团队在每个Sprint中开发出的产品功能。
Iteration（迭代）：项目中的一个周期。Scrum中，该周期为30个连续日历日，或者一个Sprint.
Done(完成)：“完成”状态需要项目各方认同，且符合组织的标准、惯例、和指导方针。每日Scrum简会或Sprint评审会议上汇报为“完成”的产品，必须符合该协商通过的定义。
Sprint Backlog:一个sprint周期内所需要完成的任务，定义团队在Sprint中的任务清单，在Sprint过程中形成，每项任务信息包括负责人及其在Sprint中任一天时的剩余工作量。
Sprint Backlog任务：团队或其成员为把产品Blacklog条目转化为系统功能所需完成的任务。
ScrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。
Time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。
Sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。
Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？ 是否遇到了障碍？ 即将要做什么？通过该会议，团队成员可以相互了解项目进度。
Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。
Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时
