一.敏捷开发理论和概念
1、Scrum 敏捷项目管理
Scrum由三个角色，六个时间箱，四个工件组成。
Scrum 介绍：适用于需求难以预测的复杂商务应用产品的开发。团队以短小迭代（也称为“冲刺 (sprint)”）为单位进行工作。
Scrum 管理优势：团队按照商业价值的高低先完成高优先级的产品功能，并自主管理。
Scrum 目标：
2、Scrum 核心价值观
（1）承诺（Commitment）：承诺不只是把一项工作分配给团队，也不是简单的答应去完成。它是建立在目标之上的来自内心的接受和应许，这里只有“做”和“不做”，没有“让我试试”。
（2）专注（Focus）：像邮件和不相关的会议就是很常见的一些分散注意力的事情，我们需要做得是不转移注意力，把精力全部集中在承诺的事务上。
（3）公开（Openness）：保持一直让任何有兴趣的人员都可以在墙上、wiki页面或者仪表盘工具上获知项目当前状况，能够了解多少功能已经完成，哪些正在做，每次迭代和发布的目标是什么。
（4）尊重（Respect）：每个团队成员都必须被尊重的看待，大家一起指定工作规范（working agreements）。
（5）勇气（Courage）：为了接受并负责任的交付产品，团队成员必须有足够的勇气来对大家说“不”，比如不能承诺时，对纳入sprint的故事说“不”等。
3、Scrum实践原则
（1）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
（2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
（3）经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
（4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
（5）围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
（6）在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
（7）工作的软件是首要的进度度量标准。
（8）敏捷过程提倡可持续的开发进度。责任人、开发者和用户应保持一个长期恒定的开发速度。
（9）不断关注优秀的技能和好的设计会增强敏捷能力
（10）简单——使未完成的工作最大化的艺术——是根本的。
（11）最好的构架、需求和设计出自于自组织的团队。
4、Scrum价值观之宣言
（1）个体与交互重于过程和工具。
（2）客户协作重于合同谈判。
（3）可用的软件重于完备的文档。
（4）响应变化重于遵循计划。
5、Scrum特点
（1）规定了一个非常简单的开发流程。
（2）是现有设计流程的总结。
（3）以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。
（4）是一个控制由利益和需求冲突导致的混乱的流程。
（5）是改善交流并最优化合作的方式。
（6）是一种检测产品开发和生产过程中障碍并将其去除的方式。
（7）是最大化生产率的一种方法。
（8）适用于单一的项目到整个组织。Scrum可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
（9）能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。
6、Scrum 三种角色与职责
（1）产品负责人Product Owner：重点是产品业务方面，从业务角度出发对需求并对权重排序，合理的调整产品功能和迭代顺序。
（2）项目经理Scrum Master：提高团队的开发效率，提出培训团队的计划，列出障碍。
（3）团队成员Team：尽一切可能去完成任务，发布产品。充分理解产品负责人的产品愿景，合作完成冲刺(Sprint)中每一个目标。
7、Scrum 典型产物
（1）产品Backlog：包括需要交付的内容，根据业务需求的价值排列，可以增减或调整，产品的Backlog将根据不断增长的需求来持续驱动维护。
（2）既定产品Backlog：是冲刺(Sprint)计划会议的产物，它定义了团队所接受的工作量。在整个冲刺(Sprint)过程中它将保持不变。
（3）冲刺(Sprint) Backlog：涵盖了最终版本的既定产品Backlog的任务。团队通过它来协调开发进度。
（4）障碍 Backlog：列举了所有团队内部和团队相关的阻碍项目进度的问题。Scrum Master需要确保所有的障碍Backlog中的问题都已分配并可以得到解决。
8、Scrum 燃尽图
产出工件（Artifacts）：
（1）产品Backlog（Product Backlog）
（2）发布燃尽图（Release Burndown Chart）
（3）SprintBacklog（Sprint Backlog）
（4）Sprint燃尽图（Sprint Burndown Chart）
9、Scrum 开发流程：
10、Scrum 框架：
角色（Roles）：产品负责人，Scrum教练，团队。
仪式（Ceremonies）：Sprint 计划，Sprint 评审，Sprint 回顾，每日scrum例会。
二.敏捷开发流程和操作
六个时间箱：
1、Sprint（全员会议）
2、发布计划会议（评估会议）
3、Sprint计划会议
冲刺(Sprint) 计划会议1：
Sprint计划会议包含两部分内容：“做什么”和“怎么做”。
Sprint计划会议1：确定该Sprint将要完成什么任务，用时4小时。
产品负责人给团队介绍最高优先级的Product Backlog条目，并一起决定接下来的Sprint中开发什么功能。
Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择多少Product Backlog的条目。
冲刺(Sprint) 计划会议2：
Sprint计划会议2：团队研究在Sprint内如何构建产品增量，用时4小时。
团队先以设计展开工作，设计过程中，团队确定任务，这些任务就是将Product Backlog转化成可用软件的具体工作。
任务需要被分解，以便在一天之内完成。这个任务列表就是Sprint Backlog。团队通过自组织，并且是自己认领的方式分担任务，
任务认领可以在Sprint计划会议上进行，或也可以Sprint中及时（Just-in-time）确定。
4、每日站会
冲刺(Sprint) 每日例会：
每个人回答3个问题：a.你昨天干了什么？———b.你今天打算做什么？———c.有什么困难或依赖吗？
5、Sprint评审会议
冲刺(Sprint) 评审会议：
目标：根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到Sprint 的目标。
通常采用演示新功能或底层架构的形式。
非正式：规定用2小时来准备，不需要幻灯片。
整个团队都参与。邀请所有人(让别人都知道)。
会议进程：
（1）团队按 Backlog 中的问题，逐个地介绍这次 Sprint 的结果，和演示新功能。
（2）如果产品负责人想要改变功能：添加一个新问题到Product Backlog 中。
（3）如果对功能有一个新的想法：添加一个新问题到Product Backlog 中。
（4）如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog。
会议结果：对这次Sprint 的结果和整个产品的开发状态的共识。
6、Sprint回顾会议
冲刺(Sprint) 回顾会议：
目标：定期查看哪些东西工作正常，哪些不正常
指导原则：不管我们现在发现了什么问题，必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩
通常15–30分钟：
每个sprint结束后进行：
全体成员参加：Scrum教练，产品负责人，团队，客户和其他相关人员。
示例：会议白板：
示例：产品Backlog：
示例：规划冲刺 (Sprint) Backlog：
提升冲刺 (Sprint)执行效率：
计划与跟踪：
总结：实践是最好的学习方法，实践是检验真理在惟一标准。
每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践。
CMMI更加关注于流程，Scrum更加关注于人。
Sprints(冲刺)：
Sprint的本意是指冲刺，在Scrum中，一个Sprint就是一个迭代，Scrum 项目通过一系列的sprints来推进，Sprints类似于极限编程的迭代。
Sprint长度通常2-4周，它是一个时间箱，在项目进行过程中不允许延长或缩短Sprint长度。
稳定的周期会带来更好的节奏。
Sprint由Sprint计划会议、开发工作(需求分析、设计、开发、测试、质量控制等)、每日站会、Sprint评审会议和Sprint回顾会议等活动组成。
Sprint一个紧跟一个进行，之间没有任何时间间隔。
时间盒迭代（timeboxing）：
1.时间盒迭代（timeboxing/timeboxed iterations）的核心思想：在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。
2.如果在迭代进行中，开发团队发现进度落后，无法完成全部的迭代开发任务和计划的需求功能时，敏捷方法通常允许或要求开发团队与客户协商，
减少开发任务或需求（可以放入下一次迭代中），以保证在既定的时间点提交高质量的成果（尽管这个成果可能不完整）。
三.实施Scrum
1、如何组建Scrum团队
先确定Scrum Master的人选，然后再由Scrum Master去组建其他团队成员。Scrum Master应该由熟悉Scrum流程和敏捷原理的人担当。
2、谁做Product Owner
最好由客户中最熟悉业务的人员担当，可随时作为业务决策者的角色。
如果客户方没有人选，可由项目经理充当PO，但无论是需求调研还是业务决策都需要和客户保持密切沟通。PO不需要懂技术，但需要把控产品的功能、方向、UI、UE和质量。
3、如何组建Team
根据项目的需要决定团队中要有哪些职能。团队中没有Team Lead，但需要有架构师。尽量选取能力较强的人作为团队成员。
四.Scrum工具
五.问题
如何编写Product Backlog？
Product Backlog包含的内容：
ID：统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
名称：简短的、描述性的故事名。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
重要性：产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
估算：团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（storypoint），一般大致相当于一个“理想的人天（man-day）”。
如何做演示：它大略描述了这个故事应该如何在sprint演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。
六.瀑布模型
1、软件工程
（1）系统概述：
（2）系统规划：
（3）系统需求：需求调研，出Demo
（4）系统设计：数据库表结构设计（数据字典），技术框架SSM搭建（系统架构）。
（5）系统开发：
（6）系统测试：
（7）系统部署：
（8）系统验收：
2、文档清单
（1）系统架构.xls
（2）系统需求说明书.doc，系统数据库需求说明书.doc
（3）系统设计说明书.doc，数据库系统设计说明书.doc，数据字典.doc
（4）系统测试报告.doc，系统测试用例.doc，系统测试计划.doc
（5）系统用户手册.doc，系统维护手册.doc