俗话说，自己写的代码，6个月后也是别人的代码……复习！复习！复习！涉及的知识点如下：
- 软件工程概念
- 敏捷开发过程scrum
一、什么是软件工程？请用一句话描述。
软件工程是一门研究性的学科：它用工程化的方法（联系建筑工程……），构建和维护有效的、实用的，和高质量的软件。简单来说，软件工程有三要素：过程+方法+工具，而软件工程是目标，软件过程是步骤，方法和工具是辅助。
二、那么，软件过程又是什么？
软件过程：首先它是一个框架或者说步骤，它是一个为建造高质量软件而所需要完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
三、常用的软件开发过程（开发框架）都有什么？选一种做简单介绍。
1、瀑布模型（Waterfall Model）：开发过程是通过设计一系列阶段顺序展开的，过程如下：先明确要做的是什么，然后看用户的需求是什么，分析需求之后简单得出一个demo（画出原型图，草图等），然后进行架构分析和设计，总结出设计文档，之后讨论详细的开发细节，而后实现，最后测试……如图：
瀑布模型的优点：
–为项目提供了按阶段划分的检查点
–当前一阶段完成后，您只需要去关注后续阶段
瀑布模型有以下缺点：
–各个阶段之间极少有反馈
–只有在项目生命周期的后期才能看到结果
–通过过多的强制完成日期和里程碑来跟踪各个项目阶段
–不适应用户需求的变化
2、scrum敏捷方法，Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球，Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。
3、ICONIX过程，包括愿景分析、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现……
四、什么是敏捷开发过程？
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。说白了就是更加灵活！面向人的需求为核心！是一个逐步适应性的过程！敏捷是一种思想！敏捷和瀑布模型比较：
那么敏捷是不是就是万能的呢？其他过程都不好？不是的，一定澄清几个误区，对敏捷开发的误解：敏捷固然好，但是其他方法不是都没用。遵循敏捷过程的常见软件开发模型有scrum，xp（极限编程）……其中比较流行的是scrum。
五、scrum概念
Scrum是一个框架，顾名思义scrum是橄榄球运动里带球过人，争球的含义，而带球过人需要计划！在球场上，在比赛每段的开始，双方都要摆开阵势，教练和队长都可以参考计划。而在软件开发公司。敏捷方法的每个迭代的开始，团队领导者都应该做好本迭代的计划，尤其是需求条目的优先级排序、选择本迭代的工作、设定必须完成的内容等。且带球过人需要灵活应变！在球场上，哨声响起，尽管队员们努力按照计划推进，但场上瞬息万发，队员不可能实时按照教练指令亦步亦趋地行事，而是靠平时训练中形成的素养见机行事，达成目标，在软件开发公司，在每个迭代开始后，团队领导不可能也不必需要事必躬亲，而是应该由具体执行的人选择如何去做。团队领导要做好的是协调资源、解决困难、提供指导，以达成目标。
1、敏捷开发的角色
产品负责人PO，负责产品的需求提炼、条目化，优先级排序，PO直接和用户以及其他关系人交互。scrum过程管理者scrum master，负责维护scrum方法的秩序，并协调解决非技术问题。最后是team团队，自组织的相对扁平化的管理方式进行项目的开发工作。
scrum团队结构：
名词解释：每个迭代的冲刺周期过程又叫sprint，其中贯穿了很多活动……
sprint计划会议：每次迭代之前召开，时间充足（4-8小时或者……），po，sm，team……都参加po从backlog积压的产品列表里找高优先级任务，并和team商量需要完成多少功能，po把功能分解为小的功能模块，而team要详细讨论如何完成……预估时间。
backlog（积压的待处理事务）：产品的backlog包括了所有需要交付的内容，内容根据业务的需求价值顺序排列，更加需求变化动态的增长或者减少。既定产品的backlog是一个迭代中的产物，定义了team接受的工作量，整个sprint中不变，sprint backlog涵盖了最终版本的既定产品backlog的任务，团队通过它来协调开发进度，障碍backlog列举了所有团队内部和相关的和阻碍项目进度的问题，sm需要确保所有的障碍backlog问题都已经分配并且可以得到解决。
每日立会：早上开比较好，与会人员站立而开，10几分钟足以，任何人都可以参加，sm主持，但只有team能做相关任务的发言，每个team要问三个问题——昨天做了什么？今天要做什么？遇到了哪些问题？然后更新燃尽图。
sprint评审会议：每次sprint结束时召开，时间一般2个小时内控制，team展示本轮迭代完成的任务，不需要ppt，展示demo！此会，客户，po，管理层……都能参与，目的是让po去断定项目开发的进度和迭代目标是否一致。
sprint回顾会议：sprint结束之后召开，时间一般1-3个小时左右，po，sm，team都参加，目的是对刚刚接受的sprint进行总结，反思，提高适应能力。需要总结分析成功经验和解决的困难。
2、Scrum主要特征：快速开发尽快交付，团队合作适应变化。
3、Scrum的适用场景：
•7人，+or-2
•偏小一些会更适合
•最好能坐在一起
•客户参度不高
•快速移动互联网项目
•自主性研发的产品
六、scrum开发方法的具体流程
- 项目的提出（项目的背景，项目的主要朋务对象，目标—愿景，商业价值，服务对象的细分）以Project Owner为主要提出者，team辅助！
项目的背景：“大数据时代已到，数据越来越具有价值，没有数据寸步难行，有了数据可以在诸多领域干很多事，比如互联网金融。从互联网上爬来自己想要的数据，是数据的一个重要来源，而且往往是必不可少的来源。所以……要能稳定的、高效的和实时的带来数据……”。
项目的主要服务对象：区分客户和用户！客户是系统的购买者，用户则是系统的使用者。知乎爬虫系统服务对象：某论坛-客户
项目的目标（愿景）：愿景就是向往的前景，是人们为止持续奋斗而希望达到的图景！比如*接班人要奋斗终生去努力实现共产主义–没有阶级、没有压迫、没有贫穷、没有失业、人人幸福的共产主义社会！福特汽车让每个家庭都有一辆汽车，微软让每个桌面都有一台计算机……故可以认为：伟大的愿景能成就伟大的事业！具体到软件的愿景，要想找到软件的愿景就要找到项目购买人——老大（专业术语），先找到老大，再得到老大购买该系统的目的，PO去做……我们已经知道软件项目是为了改善某个组织的某些方面，而购买软件的人（老大）毫无例外就是这个组织中最有话语权的干系人。比如企业的财务主管需要提高财务工作的效率，某企业的领导需要占领市场，领先对手，某官员需要彰显政绩……知乎爬虫系统的愿景就是根据论坛主需要，多样化，精确化丰富论坛内容（这里学习为主，模拟为主，故不考虑版权，但实际工作必须有版权意识！），
项目的商业价值（难分析，很重要）：先回答什么是商业价值？通俗地讲，商业模式就是项目通过什么途径或方式来赚钱。而解决别人愿意花钱解决的问题，就是商业价值。po主持挖掘商业价值，如果没挖掘出来……好吧，放弃该项目！
服务对象细分：也就是用户角色建模，良好的用户建模，可以保证不同用户都能方便地访问其功能 ，使用产品后也更容易获得其特定的价值，一般由project owner主持，借助团队的力量进行头脑风暴！
- 哪些用户可能来使用产品(或访问网站)
- 他们为解决哪些问题而来，or 为达到哪些目的而来
用户建模的步骤，四步曲
- 尽可能多的列出用户
- 找出关键用户——购买的决策者，主要的使用者
- 分类，合并次要用户
- 添加虚拟的和极端的用户，虚拟用户——假想的用户角色的代表。比如 “ Mario在SpeedyNetworks的人事部门负责招聘工作，该公司是一个高端网络组件制造商。他已经在该公司工作了6年。Mario有弹性的时间安排，每周周五他在家工作。Mario对电脑相当在行，他觉得对于自己所使用的软件产品，他几乎都是超级用户。Mario的妻子Kim，正在斯坦福大学化学系攻读博士。由于SpeedyNetworks几乎一直在扩张，Mario总是在物色优秀工程师。” 极端用户——很可能让你编写出原本可能遗漏的故事。
2、产品功能列表的定义，所谓产品功能列表是一个需求、or 特性等组成的列表-产品backlog是Scrum的核心，是一切的起源，按照重要性的级别进行了排序，里面包含的是客户想要的东西，使用用户客户的术语加以描述。产品功能列表主要是Product Owner写，Team也有权利，但最终由PO进行取舍。
产品功能列表写成什么形式——用户故事user stroy的形式！因为在产品定义阶段我们很难全面描述出来我们项目的需求，我们需要一种方法去探讨需求——用户故事。传统的需求说明书是这个阶段的结果。 PS：产品功能列表格式
| ID（统一标识符） | Name（标题）–简短的、描述性的故事名 | Story（故事）–故事内容描述 | Priority（重要性）–产品负责人评出一个数值，指示这个故事有多重要 | Initial estimate（初始估计）–团队的初步估算，表示和其他故事相比，完成该故事所需的工作量 | How to demo（如何做演示）–它大略描述了这个故事应该如何在sprint 演示上进行示范 | Notes（注解）–相关信息、解释说明和对其它资料的引用等等 | |
额外的字段（非必需）
•Track（类别）–当前故事的大致分类
•Components（组件）–通常在Excel文档中用“复选框”实现
•Requestor（请求者）–这项需求的提出者
•Bug tracking ID（Bug跟踪ID）–故事与bug间的直接联系
那么用户故事又是什么鬼？
用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来。基本的叙述格式为：“作为一个……，可以……，以便……” 的样式和思路写成的用户需求，就是用户故事。作为一个网站站长，我希望能通过xx爬虫系统抓取xx数据，以便于我的网站用户能方便的得到某些信息、作为一个网上商城的买家，我希望通过QQ号可以登录商城，以便于买东西……
用户故事三要素：角色、功能、客户价值，角色来源于用户角色建模的结果！功能使用主语-谓语叙述原则，动宾词组原则.比如针对显示xx数据：作为一个系统管理员，我希望可以显示xxx数据，以便vip用户……注意：角色和功能之间是主语-谓语关系；功能本身是动宾词组。我们一般把用户故事的标题写为功能的形式。关于客户价值，看似简单，其实很难写，我们先体验一下；“作为一个网友，我希望能够有个快速通知可以提醒我有新的新闻更新，以便于节省我浏览网站寻找新闻的时间，从而有更多时间做其他的事情。”、“作为一个站长，我希望爬虫系统能有效，快速的抓取xxx数据，并进行一些列分析……以便于我得到xxx信息。”
用户故事也是用来被卖掉的东西，看不到价值的故事不是用户故事。
让故事停留在业务层面，避免技术性故事，Eg:给xxxx表添加索引，它的真正目标是什么？当然是为了提高在后台系统中搜索事件表单的响应速度，最开始的技术描述只会作为一个注解存在（“为事件表添加索引可能会解决这个问题”）
好故事的准则
•独立的（Independ）避免故事间的相互依赖性。
–用户可以用Visa信用卡充值。
–用户可以用万事达信用卡充值。
–用户可以用美国运通卡充值。
思考：如何消除依赖？
合并故事——用户可以用信用卡充值。
通过不同的维度分割故事！——用户可以用一种信用卡充值，用户可以用另外两种信用卡充值。
•可讨论的（Negotiable）不要包含过多的细节
•对用户or客户有价值的（Valuable）
•可估计的（Estimatable）一般有以下3个原因会导致故事不可估计
–开发人员缺少领域知识。
–开发人员缺少技术知识。
–故事太大了。
解决方案
–PO讲解/和客户讨论。
–分解为更小的故事
•小的（Small）刚刚好的，比如：用户可以完成一次购物——大故事不好！
•可测试的（Testable）故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。通常，不可测试的故事发生在一些非功能性的需求上，这些需求和软件有关，但不直接和功能有关。
–用户必须觉得软件很好用。
–用户绝不需要花很长时间等待窗口出现。在95%的情况下，新窗口会在2秒内打开
用户故事的好处
•用户故事强调对话交流而不是书面沟通。
•用户故事可以同时被po和开发人员理解。
•用户故事的大小适合做计划。
•用户故事适用迭代开发。
3、产品发布和迭代周期：常见两种方式
每次迭代发布，移动互联网项目，自主性研发产品……
多次迭代发布，传统项目、大型项目
前面说了，迭代之前要开sprint计划会议，但是在冲刺计划会议之前要：
- 确保产品 backlog 的井然有序，产品 backlog必须存在，只能有一个产品 backlog和一个产品负责人，重要的 backlog 条目都已经根据重要性被评过分，PO应当理解每个故事的含义！
-
确定Sprint 计划会议日程
-13:00 – 17:00 （每小时休息 10分钟）
-13:00 – 13:30。产品负责人对 sprint 目标进行总体介绍，概括产品 backlog。定下演示的时间地点
-13:30 – 15:00。团队估算时间，在必要的情况下拆分 backlog条目。产品负责人在必要时修改重要性评分。
-15:00 – 16:00。团队选择要放入 sprint 中的故事
-16:00 – 17:00。为每日 scrum会议安排固定的时间地点 -
会议由Product Owner、Scrum Master、Scrum Team参加，产品负责人必须参加
- 确保质量不能让步：外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣，内部质量一般指用户看不到的要素，它们对系统的可维护性有深进影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
在冲刺计划会议中
- 确定Sprint目标及长度，半死不活的目标也比啥都没有强。
- 讲解Story：讲解故事就是要明确故事内容，决定spring包含的故事，使用故事索引卡，哪些故事需要从产品 backlog 拷贝到sprint backlog 中，在sprint中包含多少故事由团队决定 ，而不是产品负责人or其他人
- 估算时间；估算时间就是对故事的估算，估算的单位——故事点（理想化的人-天），可以使用计划牌
我们在这里使用以下几种技术：
–本能反应
–昨日天气，昨日天气（yesterday’s weather）——查看团队的历史
–生产率计算：用生产率计算来估算，这项技术包括步骤如下：
–参考实际生产率
–得出投入程度
–得出估算生产率
–计算在不超出估算生产率的情况下可以加入多少故事。
实际生产率：把上一个 sprint 中完成的所有故事的原始估算加起来，得到的和就是实际生产率
“投入程度（focus factor）”，以上一个例子为基础，团队的投入程度为：
18/50=36%
估算生产率:Eg：假设下个Sprint我们有30个人天，则生产率=30×36%=10个故事点
一些其他问题：如果没有历史数据怎么办？在新团队中使用的“默认”投入程度通常是 70%。
实际过程中我们用的是哪种估算技术？一般我们都是结合起来用
–审视上个sprint的投入程度和实际生产率
–估算一个投入程度
–再进行“直觉反应”的检查
产品负责人如何对 sprint 放哪些故事产生影响？
调整优先级
缩小范围
- 任务分解；“任务”和“故事”的区别是什么呢？——故事是可以交付的东西，任务是不可以交付的东西
spring计划会议中：定下每日例会的时间地点，一般是9:00，9:30 or 10:00，必须是每个人都能完全接受的时间。定义“完成”，产品负责人和团队需要对“完成”有一致的定义，
Sprint计划会议之后:Sprint 计划会议会产生一些实实在在的成果
–sprint目标
–团队成员名单（以及他们的投入程度，如果不是 100%的话）
–sprint backlog（即 sprint 中包括的故事列表）
–确定好 sprint 演示日期
–确定好时间地点，供丼行每日 scrum会议
让别人了解我们的Sprint
•sprint信息页；sprint 目标和演示日期
•经过团队认可、要添加到这个 sprint 中的故事列表
•Sprint 中每个故事的估算值
•明确每日例会固定丼行的时间地点
•把故事拆分成任务
4、scrum每次sprint设计的过程
不好的,引发风险,产品不能满足客户需求变化，bug率标高，代码质量堪忧
好的：
- 先界面原型设计，PO主持，那什么是界面原型？
界面原型指使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反映到介质上。将需求转化为可视画面以及人与系统的交互！
界面原型的好处：Prototype不仅仅可确定需求，它更可赢得顺客的心—阿伦 M.戴维斯 和 迪安 A. 莱芬韦尔，《用需求管理快速交付高质量的软件》的作者（Rational软件公司/IBM）
界面原型的目的:
•尽早验证需求
•尽早明确不确定性的因素
•方便便沟通交流
•为后续界面设计提供基础
界面原型的目的是需求验证，不必太纠结细节。
如果原型设计都没通过，就没有必要进行下去，如图：
画界面原型的工具;白纸、铅笔、橡皮、橡皮+铅笔+白纸、Axure、MS OFFICE、PS、Viso……工具只是工具，任何一种方法or工具都是为我们开发、生产过程服务的，我们不能成为工具的奴隶。根据实际以及环境选择合适的工具绘制。
2、数据库设计。这里主要讲解范式——”数据库的三范式
•第一范式
–关系R中的属性都是不可分割的项.
•第二范式
–在1N的基础上,每个非主属性完全函数依赖码.
•第三范式
–在2N的基础上,每一个非主属性既不部分依赖码也不传递依赖码.
从1范式到2范式
•1N | 消除非主属性对码的部分凼数依赖 2N
•假定选课关系表为
–SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)
–存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
–规范化 学生：Student(学号, 姓名, 年龄)； 课程：Course(课程名称, 学分)； 选课关系：SelectCourse(学号, 课程名称, 成绩)。
从2范式到3范式
•2N | 消除非主属性对码的传递凼数依赖 3N
•假定学生表为
–Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)
–规范化 学生：(学号, 姓名, 年龄, 所在学院)； 学院：(学院, 地点, 电话)。
对于三范式的理解
–每一列只有一个值
–每一行都能区分。
–每一个表都不包含其他表已经包含的非主关键字信息
3、系统设计
5、产品实施（监控过程），管理sprint backlog最有效的形式—挂在墙上的任务板！在每日例会的时候（or 会议开始前）更新任务板
在首次每日例会以后，任务板可能会变成这样
几天以后，任务板可能会变成这样
还有使用燃尽图（burn down chart）：是在项目完成之前，对需要完成的工作的一种可视化表示。Sprint燃尽图和迭代燃尽图，Sprint燃尽图展示了以故事点表示的在本轮迭代中剩余的工作量;
-y:预估剩下的故事点
–x:日期（非工作日除外）
–y/x=生产率
计划速率和实际速率:监测实际速率和计划速率的偏差
还有累计故事点图：表明了在每轮迭代结束时总共完成的故事点数。
每日燃尽图显示了团队在某轮迭代中的进度，你可以用这个信息判断计划的工作能否在迭代结束时都能完成。