课程来源： 学堂在线 -- 清华大学 -- 软件工程
6.1敏捷开发之Scrum
Scrum方法是1995年由Ken Schwaber和Jeff Sutherland博士共同提出，已被众多软件企业广泛使用，如Yahoo, Microsoft, Google, Motorola, SAP, IBM 等。
Scrum框架
整个开发过程是由若干个很短的迭代周期组成，一个短的迭代周期称为一个Sprint。
- 一个Sprint是一个1-4周的迭代，它是一个时间盒。
- Sprint的长度 一旦确定，将保持不变。
- Sprint的产出是"完成 "的、可用 的、潜在可发布的产品增量。
Scrum团队角色
自组织团队是敏捷软件开发的基本观念，即团队被授权自己管理他们的工作过程和进度，并且团队决定如何完成工作(任务的分配、技术决策、制定团队内部行为准则、保持过程透明度、监督和管理团队工作过程和进度)。
Scrum制品
产品订单：包含开发和交付成功产品所需要的所有条件和因素。产品订单的条目可以是功能性需求也可以是非功能性需求，还可以是主要的技术改进目标(如用Java代替C++重写系统以及已知的缺陷)。
迭代订单：团队承诺的在当前迭代要完成的任务列表，是通过选取产品订单项，来进一步细化和分解形成的。目的是将产品订单项转化为潜在的、可交付的产品增量。
可工作软件： 迭代开发的产出结果，是可以交付的产品增量，可交付的标准是在迭代初期设定的，每一次迭代都应该是一个可运行的版本。
产品订单
在迭代计划时，产品负责人告诉开发团队需要完成产品订单中的哪些订单项，开发团队决定在下一次迭代中他们能够承诺完成多少订单项。在迭代的过程中，没有人能够变更迭代订单，这意味着在一次迭代中需求是被冻结的。
用户故事
用于描述产品订单条目，是从用户的角度来描述他所期望得到的功能。
可视化管理
任务白板是团队开发的晴雨表，它将团队的任务和进度可视化地展现出来。而引入电子白板可能会削减团队之间的沟通，降低团队的透明度，违背了敏捷重视人和团队的原则。
燃尽图：以图形化方式展现了剩余工作量（Y轴）与时间（X轴）的关系。
Scrum规划
迭代计划会议
在每次迭代（或冲刺）开始时召开，一般是2~4小时，目的是选择 和估算本次迭代的工作项。
- 第一部分：以需求分析为主，选择和排序本次迭代需要实现的订单条目
- 第二部分：以设计为主，确定系统设计方案和工作内容
整个团队全员参与，产品负责人逐条讲解最重要的产品功能，开发团队共同估算所需工作量 ，直到本次迭代的工作量达到饱和为止。
产品负责人回答与需求相关的问题但不干涉估算的结果
每日站立会议
会议目的
- 团队在会议中做计划，协调其每日活动，还可以报告和讨论遇到的障碍。
- 任务板帮助团队聚焦于每日活动上，应在这个时候更新任务板和燃尽图。
每个团队成员需要回答
- 上次例会后完成了什么？
- 遇到了什么困难（或障碍）？
- 下次例会前计划做什么？
有简要的问题澄清和回答，但不应该有任何话题的讨论，是开发团队内部沟通会议，<=15min
迭代评审会议
会议目的
Scrum团队在会议中向最终用户展示迭代的工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。
基本要求
- 由团队展示有可能发布的产品增量，听取用户对产品功能的反馈
- 允许所有参与者尝试由团队展示的新功能
- 用户对团队演示的产品功能进行反馈
在迭代结束时候召开，由开发团队和相关人员一同评审迭代产出
迭代回顾会议
每一次迭代完成后，都会举行一次迭代总结会，会上所有团队成员都要反思这个迭代。举行迭代总结会议是为了进行持续过程改进，时间限制在1小时左右。
关键要点
- 会议气氛：团队全员参加，气氛宽松自由，畅所欲言，发现问题和分析原因；
- 关注重点：每次仅就1-3个关键问题做出可行的(方法简单、影响范围小、见效快，目标现实可行、积少成多)解决方案；
- 跟踪闭环：可以放入下一次迭代订单中执行改进。
6.2 用户故事与估算
用户故事
用户故事（User Story）是从用户角度对功能的简要描述。
- 独立性：：尽可能避免故事之间存在依赖关系，否则会产生优先级和规划问题。
- 可协商：故事是可协商的，不是必须实现的书面合同或者需求。
- 有价值：确保每个故事对客户或者用户有价值的，最好是让用户编写故事。
- 可估算：开发者应该能够预测故事的规模，以及编码实现所需要的时间。
- 短小的：故事尽量短小，最好不超过10个理想人天，至少在一个迭代中完成。
- 可测试：所编写的故事必须是可测试的。
用户故事类型
功能性需求，具体的是什么类型的用户，有什么样的需求，最终为了呈现什么样的效果
非功能性需求，如需要使用什么样的浏览器类型、技术增强以及缺陷修复等
产品订单
一系列用户故事的列表
敏捷估算
测算时，统计每个迭代所有已经完成的故事，对于没有完成的故事不计算在内
原则：开发团队一起估算，产品负责人和Scrum主管不参与实际估算(产品负责人负责阐述的澄清，Scrum主管负责指导和引导)
估算不是承诺，不应因其他因素而人工放大，成为团队与管理层之间的抛球游戏
准确与精确：估算应该准确但不必过分精确，过于精确的估算是浪费。
应该使用相对大小而非绝对大小进行估算
度量单位
故事点：一个相对度量单位。使用时，可以给每个故事分配一个点值；点值本身并不重要，重要的是点值的相对大小。
理想时间：一个绝对度量单位。理想时间是某件事在剔除所有外围活动以后所需的时间；一般为一天有效工作时间的 60－80%比较合理，但绝不会是全部。
理想时间
估算方法：团队查看每个故事，针对前面介绍的复杂性要素讨论故事，然后估计要用多少理想时间可以完成该故事。
- 这种方式是人们平时习惯使用的，容易理解和使用
- 人天生不擅长做绝对估计，很难达成共识
- 不同人的理想时间估算是不同的，因每个人的能力和认识的不同而不同
- 每个人的理想时间是不一样的，这种估算不能相加，由此产生的计划肯定是不准确的
故事点
基本做法
- 给一些简单的"标准故事"设定一个"标准点数"，形成比较基线；
- 其他故事与标准故事进行比较，给出一个相对的比例，得到该故事的一个估计值。
使用难点
- 故事点的项目或产品特征很明显，几乎无法进行跨团队比较；
- 如果没有历史数据，很难设定标准故事。
敏捷估算扑克
本质上是扑克牌，它基于Delphi估算原理，可以快速地估算出需要的数字。
分牌：每名参与估算的成员分得相同花色的一组牌，两张Joker不参与估算。
讲解订单故事：产品负责人从Backlog中选择一个条目，为大家详细讲解该条目；团队成员进行讨论并提问，产品负责人逐一解答大家的问题。
估算：当团队成员确认已经对该条目完全了解且无任何重大问题后，大家开始进行估算，同时选出代表自己估算值的纸牌，在所有成员选牌完毕后大家同时亮牌。
争论与讨论：若每张牌估算值差距明显，代表大家对该条目没有获得共识，需要对评估结果进行讨论。
共识：对该条目重新进行估算，直到团队的评估数值达成一致。
- 一般情况下，最多三轮就可以得出一个比较统一的意见；如果三轮之后依然没有得到统一的意见，那么Scrum主管应立即中断估算，取平均值或其他大家接受的值作为估算结果。
6.3 团队协作工具Tower
6.4 配置管理
软件配置管理
一种标识、组织和控制修改 的技术，它作用于整个软件生命周期，其目的是使错误达到最小并最有效地提高生产率。
软件配置项
软件配置项（Software Configuration Item，简称SCI）是为了配置管理而作为单独实体处理的一个工作产品或软件。
版本
版本是在明确定义的时间点上某个配置项的状态；版本管理是对系统不同的版本进行标识 和跟踪 的过程，从而保证软件技术状态的一致性，是软件配置管理的核心内容。
一个配置项，例如一个源程序文件，可以有一个主干版本，也可以由某个版本的状态产生若干分支，分支版本也可以合并到主干上面
基线
基线（Baseline）是软件配置项的一个稳定版本，它是进一步开发的基础，只有通过正式的变更控制过程才能改变。
版本控制
独占工作模式
并行工作模式
支持多个人共同修改同一个文件
分支管理
分支包含了一个项目的文件树及其发展的历史，记录了一个配置项的发展过程。分支包含了一个项目的文件树及其发展的历史，记录了一个配置项的发展过程。
- 代码库应该有一个且只有一个主分支，所有提供给用户使用的正式版本都在主分支上发布
- 主分支只是用来发布重大的版本，日常的开发应该在另外的分支上完成
- 如果开发分支上的文件需要正式对外发布，就在主分支上对开发的分支进行合并
- 除了主干和日常开发分支之外，还有一些临时性的分支，用以应对一些特定目的的版本开发，例如功能分支或者缺陷修复分支等
实现多人并行开发一个新系统，同步地更改多个并行版本的错误以及同时集成和发布多个版本
软件配置管理工具
Git
最初由 Linux Torvalds 编写，用作Linux 内核代码的管理，后来在许多其他项目中取得很大的成功。它除了常见的版本控制管理功能之外，具有处理速度快、分支与合并表现出色的特点。
Github是一个基于 Git 的开源项目托管库，目前成为全球最大的开源社交编程及代码托管网站。它可以托管各种 Git 库，并提供一个 Web 界面。
6.5 软件配置管理工具Git
版本库
远端版本库：非本机上，例如放在服务器上或第三方托管主机上
本地版本库
创建与提交
Unix系较新的操作系统一般自带，Linux在apt-get可以安装，OS X可以port安装或在htt p://sourceforge.net/projects/git-osx-installer/下载安装。
Windows没有自带git，msysGit项目提供了安装包，可以在https://git-for-windows.github.io/下载安装。
git init 将创建的空文件夹变成一个空的版本库
git status 列出当前版本库尚未提交的改动(将这些改动称为未跟踪的文件)
git add file.txt 将file.txt文件标记，该文件被git版本库获知了(已经被跟踪了)
git commit -m "msg" msg为提交消息，这样就会把版本库中已经被跟踪的所有文件一同提交到版本库中
克隆到本地
从远端拉取
将远端版本库的内容与本地版本库进行同步
git pull 自动从远端拉取文件commit，这样变动的文件就同步到本地
提交到远端
将本地版本库中的变动同步到远端版本库，实现远端版本库的文件变动
git push 要求本地版本库有远端版本库中所有的commit
一般先git pull 再进行文件变动并提交后再git push
撤销变动
git reset HEAD file4.txt 将fiile4.txt的改动设置成未跟踪的状态，但是改动仍然存在
git checkout --file4.txt 彻底抛弃这个文件改动，恢复到上次commit的样子
修改提交
git commit --amend 将此次的修改增加到上一次的commit中
增加新分支
合并分支
冲突处理
删除本地分支以及远端分支
Sourcetree | Free Git GUI for Mac and Windows
6.6 持续集成与交付
DevOps基本概念
为什么需要DevOps?
快速的集成和交付部署
- 更快从用户那里得到使用反馈
- 更可以迅速对产品进行改进
- 更好地适应用户需求和市场的变化
DevOps和敏捷开发的关系
开发团队和运维团队的协同成为快速交付高质量软件的瓶颈
DevOps是什么
目的：加强开发团队和运维团队的协作 使用自动化工具，尽早发现风险，实现持续、快速、可靠地交付高质量软件产品
DevOps实践
总结+概括如下
配置管理
软件配置管理的核心是版本控制。
持续集成(Continuous Integration CI)
开发者在代码的开发过程中，可以频繁地将代码部署和集成到主干，并进行检查、自动化测试和编译构建。
持续交付(Continuous Delivery CD)
在持续集成的环境基础上，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。
持续部署：在持续交付的基础上，把部署到生产环境的过程自动化。
提交集成：开发人员在开发环境中完成编码和单元测试之后，将代码提交到仓库中并发起集成
提交集成会触发私有构建，其目的是防止具有明显错误的代码进入仓库，从而保证代码的质量
集成构建：构建出产品的部署包，按线序进行编译、单元测试、代码扫描、打包
自动化功能测试、手工验收测试： 新功能是否符合要求
性能测试、安全测试：部署到预发布环境中，并进行印证，确定是否可以部署到生产环境中
DevOps工具链
