本期我们讨论的主题是项目管理
以前，一直以为“ Write the code, Change the world ”。但实质上，我们就一写代码的。如果我们能上升到项目管理的角度来实行Project Management, 定期的对issue进行 Risks control, 实时评估Project status，将Challenge(也可以说，坡道定点60度起步)中的风险即时的throwable，因为对于OTD(on-time delivery)来讲，我们只有两种状态:YES or NO.(就像计算机只有0和1两种状态，要么做完，要么没做完 99%也是没做完)
如果程序能解决任何问题，那么大型的IT公司只需要很薄的管理层和一大堆程序员。很显然，这是解决不了问题的。将会存在很多的风险。如果将来一个项目出了问题，那么一定是管理和需求分析阶段出了问题。
Produce owner；一个人太强势的时候，是不利于软件产品的。PO在Scrum开发模型中就相当于项目经理。代表企业的立场。
Scrum Master；(Scrum Master认证)维持Scrum各种活动秩序(打牌)，帮助团队解决非技术问题，发现过程中的问题。
代理地址：proxy.compaq.com 端口：8080 参考资料地址：https://www.youtube.com/
敏捷开发
先来说说，敏捷开发(Agile Development)它不是一门技术，而是一种开发方法，也就是一种软件开发的流程。它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
以人为核心和迭代式开发
在瀑布开发模型中，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。迭代则是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的task，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
Scrum和Sprint
敏捷它仅仅是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum就是敏捷开发的具体方式了，Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的，而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
如图所示，是Scrum的流程图。在讲解Scrum流程之前，先介绍一下其中的各个角色。产品负责人（Product Owner）:主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。流程管理员（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。开发团队（Scrum Team）:主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。Scrum的开发流程由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。
Product Backlog （Backlog含义，积压的工作）
在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。
Sprint Backlog
Sprint Backlog 是Sprint规划会上产出的一个工作成果. 当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum team和Product Owner协商，调整合理的工作量到Sprint中，以确保Sprint的成功实施。
Sprint Planning Meeting（Sprint规划会）
据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司，客户就是市场，Product Owner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景，规划出今后一段时间产品发展的路线图，以及根据对投资回报的贡献确定的产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。当为一个Sprint定义好足够多的Product Backlog，并且排列好优先级后Scrum就可以开始了，Sprint规划会是用来细化当前迭代的开发计划的。规划会开始的时候，Product Owner会和Scrum team一起评审版本，路线图，发布计划，及Product Backlog。Scrum Team会评审Product Backlog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况看有多少feature可以放在当前的Sprint中。Scrum
Team按照优先级的高低来确定开发的先后是很重要的。当Sprint backlog确定后，ScrumMaster带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。
Daily Scrum Meeting（每日站会）
一旦计划阶段结束，30天周期的Sprint就开始了。ScrumMaster需要组织团队成员每天开站会.这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上，每个团队成员需要问3个问题：我昨天做了什么，今天做什么，遇到哪些障碍。谁都可以参加这个会议，但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观，用于发现任何新的依赖，定位项目成员的要求，实时的调整当天开发计划.
Sprint Review Meeting（Sprint评审会）
在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner.Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。业务，市场，技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成 。会议的下半部分，是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。Sprint评审会结束后，新一轮的迭代又继续开始（中间最好修整半天或者隔个周末），迭代会一直继续，直到开发了足够多的功能去交付一个产品。
打牌
很有意思的一个术语，它的作用是防止项目在开发过程中，被某些人所领导。怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时，最后趋于一个point值。
