第二章：相关的术语解释
不了解术语，你就不懂团队沟通在说些什么。精确的运用术语可以提高沟通的效率，平时可能需要四五句话才能讲明白的东西，通过专业术语的运用，可能一句话对方就明白了。当然，前提是对方也得熟悉。既然作为团队的一员，团队的工作方式采用的是敏捷法，那就必须对相关的术语要有所了解，了解完了之后，在平时的工作中进行运用，加深体会。
和敏捷有关的术语整理如下：
什么是敏捷开发？
敏捷开发(Agile Development)是一种以人为核心、逐步迭代、循序渐进的开发方法。
敏捷开发不是一门技术，是一种开发方法。敏捷思维不仅仅可以用在开发，其实各个行业，各个岗位都可以用到，你可以叫敏捷运营，敏捷销售，敏捷市场。
敏捷开发注重的是人与人之间面对面的交流，而不是瀑布型的文档驱动，不能没有文档，但是不用写大量的文档，重点写必要的文档。
但是，哪些是必要的？哪些不是必要的？这个后面在详细展开了来讲。本篇主要了解术语。
什么是迭代？
迭代就是按照一定的周期发布可以交付，可以使用的软件产品，把一个复杂的、开发周期很长的开发任务，分解为很多小周期的任务，这样的一个周期就是一次迭代的过程，就是将大目标分解成小目标，大任务分解成小任务。这里一定要记住：发布的是可以交付，可以使用的软件产品！而不是堆砌了一大堆功能，东一点，西一点，看着做了很多，但是一个完整的功能都不能用，无法交付，无法使用。
什么是Sprint？
Sprint是短距离赛跑的意思，这里面指的是一次迭代，也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。每次Sprint的长短，有的团队喜欢一周，有的两周，有的一个月。Sprint不能太长了，太长失去意义，搞不好就成了瀑布了。
什么是产品Backlog，什么是Sprint Backlog？
产品Backlog指根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而包罗万象的计划。可行的方式是，先为一个项目写下所有它该具备的显著特性和功能，如果实在写不完，做好能保证团队的第一个Sprint冲刺有活可干就可以。
随着冲刺的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
我们内部将Product Backlog简称为PB，将Sprint Backlog，简称为SB。
什么是燃尽图？
燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（任务）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。如下是大概的一个样子。
敏捷开发都包括什么角色？各自的职责是什么？
产品负责人（Product Owner），简称PO。
负责最大化产品以及开发团队工作的价值。主要职责如下：
1、确定产品的功能；
2、决定发布的日期和发布内容；
3、为产品的ROI负责；
4、根据市场价值确定功能优先级；
5、每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）；
6、接受或拒绝开发团队的工作成果；
7、参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
一句话总结PO这个角色就是：告诉产品团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理。
敏捷主管（Scrum Master），简称SM。
确保Scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口人，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）。
一句话总结SM这个角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。
开发团队（Scrum Team）简称ST。
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
敏捷开发的流程
注意：初步的需求调研在每周迭代计划会议之前就已经和客户完成，PO需要去和客户进行沟通，了解需求。
1. 制定产品需求列表
PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表；也就是说，PO进行产品Backlog的编写。
2. 召开计划会议
PO召集ST和SM（也可邀请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物，
Sprint冲刺计划就是确定该冲刺阶段的长度（建议冲刺长度1-4周）、目标和冲刺任务清单及其工作量估算（以理想人天manday=7.5h估算，单位为小时计算），会议时间建议不要超过6小时；
在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集成，团队每天有完成任务清单的情况，都需要在svn上以增量形式发包并通知到相关人员；
项目计划会议上可以确定每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决，在私下进行沟通，不要在会议上讨论。站立会上只有TM人员有发言权，其他人员不要干预，SM主要是维护秩序、规则及其引导作用。
计划会议上将产品Backlog变成Sprint Backlog，简单的说就是，将PB拆分成SB。
3. 需求分析、设计、编码和测试
计划会议结束后，ST团队成员获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试；
这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等）。具体情况，需要项目组根据实际情况决定，但客户要求交付的文档必须要输出；
4. 冲刺任务单和燃尽图更新
每天SM需要根据每日站会上ST反馈的情况，进行更新冲刺任务单和燃尽图或SM和ST之间达成共识，ST各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。
5. 迭代周期结束点
已到迭代周期结束点，只有那些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。
这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需求列表中挑选优先级高的继续进行开发。
6. 冲刺评审会议
SM需要召开冲刺评审会议，邀请PO、客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时，参加人员除PO、ST全体成员及其相关利益人来参加外，也可以邀请其他相关人员参加。
7. 冲刺回顾会议
迭代输出的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后ST需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括：PO、SM、ST，其他相关人员也可以参加。
这里要说明的是在每次的计划会议上要注意安排时间做冲刺评审会议和冲刺回顾会议。下一次迭代的计划会议建议在上一次迭代的冲刺回顾会议结束后再开展。
8. 重复2-7步骤
直到所有列入本版本规划的任务都完成，最后发布版本；特别说明：通常最后一个迭代可能是全量进行验证的周期。
注意事项
一、每日站会不是汇报会议，不是向PO或者SM进行进展汇报，PO不需要参加，甚至SM也可以不参加。ST团队成员不能有是向SM进行汇报情况的想法，虽然现实感觉上往往如此。怎么解决呢？通过不与陈述发言的队员有眼神交流这种微妙的途径，SM敏捷主管可以避免大家的发言变成了对他个人的单线情况汇报。
就是说，如果SM要参加每日站会，不要和成员进行眼神交流。还有一个更激进的想法，让Scrum Master几天不去参加每日站立会议，从而鼓励团队自己组织会议。
为了强化大家的ownership意识，每个人都是team的主人，也可以轮流进行组织。
二、任务估算时间不能公开，每个人都写下自己的时间之后，如果差别较大，最大和最小估算者进行阐述和辩论，最后达成一个共同认可的任务完成时间。这里要注意，如果参与的人不懂该任务流程，参与估算就会影响准确率。
三、如果团队遇到问题，尽量自己先花1个小时进行解决，找到方向，如果1个小时还没有思路，问题解决不了，就抓紧反馈。你遇到的问题可能其他成员已经有解决方案了。
四、PO未参加计划会议，应与PO提前协商时间，若PO没有时间需调整时间，PO一定要参加计划会议；
五、如果产品backlog优先级发生变动，需要和PO一起决定；
六、任务的拆分及工时的评估需要和团队共同确定，不是SM一个人说了算。就是说，在将PB拆分成SB，并进行时间估算的时候，不能是SM一个人说了算。