Scrum团队成立

团队名称：开拓者

团队目标：努力让每一个小伙伴在学会走路的基础上学会跑。

团队口号：我们要的只是这片天而已。

团队照：正面照+背影照(那就是为什么组名叫开拓者)

5.2 角色分配

　　产品负责人(决定开发内容和优先级排序，最大化产品以及开发团队工作的价值)：古林萍

　　Scrum Master(负责确保团队遵循 Scrum 的理论、实践和规则。Scrum Master是团队中的服务式领导):陈嘉慧

　　PM项目经理(团队的领导, 带领、平衡、推动、激励、目标达成、交涉，平等工作之外管事也管人):林志杰

　　用户(从最终使用者的角度把握所开发软件的用户体验，团队工作必须响应并满足用户需求):郑铭泽

 团队项目选题

　　金融工具：复利计算与投资记录项目继续升级，开发定位明确、功能专注的工具类软件。

《构建之法》读第六、第七章有感

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

<1> 陈嘉慧:

我的理解是，Scrum方法论是敏捷过程的一种，敏捷过程的精髓在于快速交付。

第一步：找出完成产品需要做的事情，每一项工作用天为单位计算。

第二步：把整个产品分为几个相互联系的冲刺，也就是sprint，团队成员主导任务的估计和分配，各取所长，能动性得到较大发挥。

第三步：冲刺阶段各个团队相互独立，所有的问题都只能在这个冲刺完成之后进行交流。冲刺期间，每天需要开一个站立会议，告诉队友我昨天所做，今天将做，遇到问题。

第四步：得到增量版本，交付。

敏捷方法用时间来管理，来驱动每一个冲刺，积少成多，最后形成不断迭代增量的版本。这种时间驱动彻底断除了我们延期完成工作任务的想法。
我们开发软件是为了解决现实社会和生活中的各种问题。人们的需求各种各样，我们该如何找到需求呢？
        1.获取和引导需求。需求是需要挖掘的，我们既可以引导客户，结合自身行业经验，得到需求，也可以分析技术的发展趋势和全球产业变化社会发展的大趋势分析需求，如大数据云计算移动互联网。
        2.分析和定义需求。规整需求，定义需求的内涵，从各个角度量化需求。
        3.验证需求。如果需求分析没有做好直接开工的话，容易做无用功，造成返工。软件团队要跟利益相关者沟通，通过分析报告，用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
        4.需求管理。如上所说，需求会不断变化，或者说解决需求有了新的捷径和方式，这些都要求我们因地制宜，跟着变化而变化。
        5.需求的分类：功能性需求要求产品必须实现某些功能，开发过程需求要求开发流程必须产生哪些文档在什么时间交付，非功能性需求要求服务质量例如12306网站要做到实时响应。
        那么，作为一个开发者，需不需要到需求中来呢，非常需要，因为软件的各种约束各种技术实现会影响到他们的工作过效率。我们一定要让相关角色在需求分析阶段有机会提出他们的需求，并且按照这种需求尽可能去实现。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

<2> 林志杰：

第六章

Scrum是什么

Scrum 是一个用于开发和维持复杂产品的框架，由若干个短的迭代周期Sprint组成（2到4周）。包括3个角色（产品负责人，Scrum Master，Scrum团队）、3个工件（产品Backlog，SprintBacklog，燃尽图）、5个活动（Sprint计划会议，每日站会，Sprint评审会议，Sprint回顾会议，产品Backlog梳理会议）、5个价值（承诺，专注，开放，尊重，勇气）

为什么要Scrum

Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。对软件开发非常有效。

Scrum怎么做

——做敏捷的做法，用巧妙的方法。

总流程：一、找出完成产品需要做的事情

二、决定当前的冲刺需要解决的事情

三、冲刺。一切交流通过Scrum大师来完成，保持专注

敏捷的适用范围

Scrum流程

总结：1、方法上侧重于个人和交流，可用的软件，与客户合作，响应变化。

2、自我方面提高自主管理，自主组织，全面提高自已自身水平，做到能独当一面。

Scrum的范畴

一，是敏捷宣言。只要符合敏捷宣言，不管是谁说的，都是敏捷。

二，是Scrum指南。这是一本由Scrum两位创始人Jeff Sutherland和Ken Schwaber维护的一本Scrum的游戏规则书。字字珠玑正确的运用Scrum其实也很简单，只需要理解Scrum指南并严格按照每一条规则去做就好了。

三，是Scrum联盟的Core Scrum（核心Scrum）。Core Scrum与Scrum指南最大的一点区别是增加了Scrum的5个价值观：尊重，勇气，开放，专注，承诺。这5个价值观都是人类的一些美德。

第四个东西是Scrum认证。Scrum认证是一个很贵的培训，得到很多企业的认可。

Scrum的三大支柱

一、透明度。在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。当队员人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

二、检验。开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。

三、适应。如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

第七章

微软解决方案框架（MSF）

MSF基本原则

1、推动信息共享与沟通，除了技术机密、安全性等信息要采取必要的保护措施外，所有信息保留和公开

2、为共同的远景而工作。

3、充分授权和信任

4、各司其职，对项目共同负责

5、交付增量的价值

6、保持敏捷，预期和适应变化。预期变化，不是期望变化。

7、投资质量。对投资的重视，引起对质量的投资，引起对人、过程和工具的投资

8、学习所有的经验。定期进行阶段性的回顾和总结

9、与顾客合作

MSF过程模型

MSF模型是从传统的软件开发瀑布模型和螺旋模型发展而来，它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合起来。

MSF过程模型

MSF敏捷开发模式：1、更强调与用户的交流

2、质量上防患于未然，防止缺陷。

3、重视在实战条件下的质量。在精的基础上扩展功能

MSF中的里程碑式过程管理方面还是很值得学习的。它通过一步一步地达到预先设定的目标，从而使整个软件过程变得可控。同时也会及时的发现项目中潜在的危险因素，便于风险的管理。它把软件过程分为几个阶段以后，可以针对某一阶段中存在的问题进行定位、分析和解决，为提高软件开发的成功率提供了有效保障。

同时，也可以看到该过程管理模型中对过程划分得比较细。可以根据项目的规模和类型对这个过程管理模型进行简化。使之更加适合于我们公司的软件开发过程。

MSF的CMMI模型

MSF中，CMMI在所有流程上都加了一个“提议”阶段，通过“审核”或者决定“开始调查”，处于“提议”阶段的工作项可以变为“激活”状态。如果调查的结果不是要开始着手工作，那么工作项可以退回“提议”状态

CMMI其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

<3> 郑铭泽：

第六章

Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。　

敏捷方法用时间来管理，积少成多，最后形成不断进行版本的更新换代。通过严格限定时间的方式断除怠工想法。

如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

第七章

MSF没有像敏捷那样搞一个宣言，但是它也有一套思想框架—9条基本原则

（1）推动信息共享与沟通（Foster open communications）

（2）为共同的远景而工作（Work toward a shared vision）

（3）充分授权和信任（Empower team members）

（4）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

（5）交付增量的价值（Deliver incremental value）

（6）保持敏捷，预期和适应变化（Stay agile, expect and adapt change）

（7）投资质量（Invest in quality）

（8）学习所有的经验（Learn from all experiences）

（9）与顾客合作（Partner with internal and external customers）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

<4> 古林萍：

第六章

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法:Scrum of Scrums.

Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog）， 产品订单是按照优先级排列的要完成的工作的概要的需求。哪些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。

敏捷方法用时间来管理，来驱动每一个冲刺，积少成多，最后形成不断迭代增量的版本。这种时间驱动彻底断除了我们延期完成工作任务的想法。
我们开发软件是为了解决现实社会和生活中的各种问题。人们的需求各种各样，我们该如何找到需求呢？
        1.获取和引导需求。需求是需要挖掘的，我们既可以引导客户，结合自身行业经验，得到需求，也可以分析技术的发展趋势和全球产业变化社会发展的大趋势分析需求，如大数据云计算移动互联网。
        2.分析和定义需求。规整需求，定义需求的内涵，从各个角度量化需求。
        3.验证需求。如果需求分析没有做好直接开工的话，容易做无用功，造成返工。软件团队要跟利益相关者沟通，通过分析报告，用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
        4.需求管理。如上所说，需求会不断变化，或者说解决需求有了新的捷径和方式，这些都要求我们因地制宜，跟着变化而变化。
        5.需求的分类：功能性需求要求产品必须实现某些功能，开发过程需求要求开发流程必须产生哪些文档在什么时间交付，非功能性需求要求服务质量例如12306网站要做到实时响应。
        那么，作为一个开发者，需不需要到需求中来呢，非常需要，因为软件的各种约束各种技术实现会影响到他们的工作过效率。我们一定要让相关角色在需求分析阶段有机会提出他们的需求，并且按照这种需求尽可能去实现。

第七章

MSF没有像敏捷那样搞一个宣言，但是它也有一套思想框架—9条基本原则 
1. 推动信息共享与沟通（Foster open communications）

第一个原则，就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施

看不到所有的信息，那么项目进度以及项目中存在的各种问题就不能及时让所有人知道，这样MSF中其他的原则也就不能实行了。没有开放的信息，也就谈不上“授权”，或者“建立清晰的责任和共同的职责”，以及“保持敏捷，预测并适应变化”。这也是为什么“推动信息共享与沟通”是第一个基本原则。MSF团队模型和MSF过程模型也是建立在“信息共享与沟通”原则上的

2. 为共同的远景而工作（Work toward a shared vision）

“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件、行业软件，还是通用软件，要明确项目的目标是什么。

这个目标必须是明确的，没有二义性；

这个目标不是当前就能达到，必须是通过努力才能达到的；

这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情对项目的远景没有帮助，你应该跟老板提出来

远景一般是由“有远见的人”提出，然后公开讨论，在讨论的过程中，可以消除误解，凝聚共识。这是一个项目的关键，是项目第一阶段要达到的主要目标

3. 充分授权和信任（Empower team members）

这一点的关键是“授权”这个词，授权（Empower）有两个意思：

给某人权力和权威
给予某人更多自信和自尊

在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也认为团队能兑现承诺，并进行相应的规划

充分授权的管理方式是MSF的核心观念之一。MSF团队模型就是建立在以下两个原则上的：

平等协作—成员之间、团队之间是平等协作的关系
充分授权给团队和成员

这就是为什么MSF团队模型是网状，而不是层次结构。这样做有什么好处？好处有两点：

被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责
MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着让真正做这件事的人按照自己的估计去完成任务。这样做的结果是啥？是人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的

组员充分授权，到头来发现事情都没做完，咋办?

这要靠工具的支持，在VSTS系统中，由于所有工作的进展都记录在案，任何延迟都会被及时发现

这样组长（或其他层次的领导）就不用把力花在“询问”，而花在“帮助解决”上，在最关键的时候提供指导和帮助

领导在项目中的角色是“支持成员完成任务”，而不是“控制成员，迫使他们完成任务”

充分授权在MSF团队模型的另一个含义是：信任，鼓励团队成员成长，每人都可以在某一时段、某一领域当领导

4. 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）

关键质量目标	MSF小组角色	出口条件
按约束条件交付产品	程序管理	我们的项目是在时间/资源的条件内交付的么
按产品规格说明交付产品	开发	我们是否按照功能说明完成了各项功能
保证所有问题都得到处理	测试	我们发现了所有的问题，而且都有处理方案吗
产品部署和后续管理	发布管理	客户能否快速方便地部署产品和进行后续管理
让产品更好用	用户体验	产品是否适应用户的使用习惯？易学易用
让客户满意	产品管理	客户是否（总体上）满意我们的项目

在项目进展的过程中，对于每一项任务，每个人都要明确以下几点。

Who：谁负责
What：做什么，具体的执行方案，什么叫做“做好了”
When：什么时候开始，什么时候结束
Why：为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？

与“信息共享与沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”—知道别人在做什么，为什么，以及整个项目的目标

5. 交付增量的价值（Deliver incremental value） 
现在的软件产业，特别是和互联网相关的产业，变化非常快，用户希望产品团队经常提供更新，以适应新的需求。我们要保证在两个方面保证客户的利益：

我们提供的新版本对用户真的有价值
和客户商讨一个最优的新版本的发布频率 
最优的频率会因为产品的特点（企业产品，消费者产品）和发布平台（办公电脑、家用电脑、互联网、智能手机及平板电脑）的不同而大不相同

在MSF团队模型中，“用户体验”这个角色代表了用户的利益，保证产品能真正易于使用；“产品管理”这个角色代表了客户的利益，保证了我们的产品能为顾客提供商业价值。搞技术的，要尊重这两个角色，因为他们代表的是我们的衣食父母

6. 保持敏捷，预期和适应变化（Stay agile, expect and adapt change） 
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化

除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易。我们对客观世界和软件系统的了解每天都在深化，原来觉得没问题的小细节忽然成了大问题。甚至原来一起打拼的同事忽然要离开……这些都要求我们团队保持敏捷的身段

7. 投资质量（Invest in quality）

对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。

投资要讲效率 
软件开发过程大部分时间花在了解/设计/变更/再了解/再设计的过程中。我们要重视质量，但并不是要不惜一切代价达到最高的质量标准（有人倒吸了一口凉气），因为提高人/过程/工具的质量是要花成本的！我们不是为提高质量而提高质量。我们要讲投资的效率。比如，在做快速原型的过程中，有些部分可以做得粗糙一点

投资要讲时机 
比如说对于某项技术的培训，最好的做法是在即将需要的时候进行培训。太超前或滞后都不灵

投资是长期的 
和投资股票/不动产一样，真正的投资者看重的是长线的收益；人的成长、团队的成熟都需要时间，不可能短期内立竿见影。那些“短平快”的东西，叫投机，不叫投资

8. 学习所有的经验（Learn from all experiences） 
在学习过去的经验的同时，也要避免让过去的经验妨碍解决现在的问题 
这一原则有两个含义——

把经验总结出来
分享经验

为什么要坚持总结和分享？是为了——

让团队成员从别人的成果和失败的例子中学到东西
帮助新项目重复以往成功的做法
培育团队总结的习惯和“批评与自我批评”的文化

MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广

在项目结束时，MSF推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责

 

0429团队项目-Scrum团队成立的相关教程结束。