* 现在项目管理过程存在哪些问题？你有什么好的解决方案？
* 为什么要学习项目管理？
1、确保开发团队富有成效，并能在长时间内提高生产力；
2、不需要通过询问来中断开发活动的流程，即可确保干系人能够随时看到项目进展的信息；
3、一旦出现新的特性请求就进行处理，并把他们纳入产品开发周期。
* 什么是瀑布式开发？什么是敏捷开发？有什么区别？
瀑布开发是由W.W.Royce在1970年最初提出的软件开发模型，瀑布式开发是一种老旧的计算机软件开发方法。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
区别：
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
* 为什么使用敏捷项目管理方法?对团队有哪些价值？对个人有哪些价值？
更好的产品质量；更高的客户满意度；更高的团队士气；增强合作和责任感；定制化团队结构；更多相关的测量指标；提高绩效可视性；增加项目控制；提高项目可预测性；降低风险。
团队：更高的团队士气；增强合作和责任感；定制化团队结构
个人：有创造性、创新力、自组织自管理、持续学习、跨职能、协作意识、沟通能力
* 敏捷开发的价值观有哪些？你是如何理解每一条价值观的？
敏捷价值观有四项内容，即：
1、个人与互动胜过过程与工具
在项目管理过程中，过程和工具是比较重要的。在过程、工具和个人、互动相比较，过程、工具就显得没那么重要。这也就是我们常说的：成也萧何，败也萧何。事在人为。天下事，重在商榷。
2、可用的软件胜过复杂的文件
在互联网plus、大数据时代下，通过收集有效数据、信息，再进行汇总、分析、挖掘，项目干系人通过移动端即可实时监控项目进展和状况，这远比复杂的文件更高效。那么，要想实现这一功能，就离不开可用的软件平台。
3、与客户合作胜过合同谈判
甲乙双方，在平等互利的基础上，签署合同。换句话说：签订合同，就是在平等的基础上，为了实现双赢。只有彼此合作，才能追求双赢。这也正是项目管理之所以重视沟通的原因所在。
4、 响应变更胜过遵循计划
项目的特征之一就是渐进明细。人们常说：计划赶不上变化快。在规划阶段，不论我们的计划做得多么详细，在实施阶段，总会有意想不到的问题发生。在项目管理过程中，变更在所难免。正确面对变更，是每个项目管理者最睿智的抉择。
* 敏捷开发的原则有哪些？谈谈你对每一条原则的理解？
1、成果交付原则
价值排序，尽早交付
敏捷原则第1条：我们第一优先的任务是，通过尽早且持续交付有价值的软件（系统）来满足客户
项目之所以被立项，是因为它有存在的价值。既然项目是有价值的，那么它越早交付，价值呈现越明显。在安排交付顺序（里程碑）时，把握客户的痛点和敏感点，优先交付客户关注的内容，可以尽早、持续地让客户满意，有效降低项目收尾时，客户不满意的风险。
拥抱变化，提高优势
敏捷原则第2条：即使在最后开发阶段，也要竭诚欢迎改变需求，敏捷过程掌控变更，以维护客户的竞争优势。
在项目管理过程中，既然无法回避变更，那么就该正确面对变更。发生变更，分析变更，做出正确判断，最后执行变更计划。敏捷团队不能坐视问题不管，要敢于迎接改变，尽早修正，让价值最大化、伤害最小化。
持续交付，小步快跑
敏捷原则第3条：经常交付可用的软件（系统），频率可以从数周到数月，以较短的时间间隔为佳。
在项目管理过程，我们与客户沟通，往往出于两种原因：第一种原因是遇到问题，需要沟通、协商、解决，第二种原因是有成果产出，需要用户确认。如果能持续、快速地交付成果给用户，无疑会博得用户的青睐、支持和认可，利于项目工作推进。
成果达成，衡量进度
敏捷原则第7条：可用的软件（系统）是进度的主要测量标准。
现在，一些企业实行项目管理考核制，旨在提高项目管理效益，可是人为衡量、鉴定项目的进度，相对困难（延误的借口总会有的），甚至产生意见和分歧。如果能借助相应的管理软件（平台），可以让干系人直观地查看项目进度，回避意见和分歧。
追求卓越，强化敏捷
敏捷原则第9条：持续专注于追求卓越的技术与优良的设计以强化敏捷力。
精益求精，让敏捷更加敏捷。在发布、迭代的过程中，不断精益设计，卓越产品或成果，产出令用户满意的产品或成果。返工少了，变更少了，项目更敏捷了。
精简产品，杜绝浪费
敏捷原则第10条：精简——精髓是要尽最大的可能，排除不需要做的工作。
敏捷管理，虽然以客户为导向，拥抱变更，但是同样要控制范围，尽最大可能排除不需要做的工作。坚决杜绝需求范围蔓延现象。
2、人员交互原则
团队合作，每日互动
敏捷原则第4条：业务人员与开发者在项目进行中，必须每天一起工作。
不论是传统项目管理，还是现代项目管理，甚至敏捷项目管理，都提倡集中办公。不过敏捷管理，要求更加苛刻。敏捷团队成员，必须在一起工作，每天组织15分钟立会。
信任成员，给予支援
敏捷原则第5条：项目靠积极的个人来完成，给予他们所需的环境与支持，并相信他们可以完成工作。
无数条河流，汇聚成大海。来自不同岗位、技能的成员，组成敏捷团队，共同完成项目工作。相互信任、支持和配合，积极、主动完成工作，加强团队凝聚力，工作就会无坚不摧。领导再像仆人一样提供服务，为团队创造环境，给予支持，项目不敏捷都没人信。
当面沟通，高效明了
敏捷原则第6条：在开发团队与团队成员之间，面对面的沟通是传播信息最有效率与效能的方式。
影响沟通效果的因素之一就是距离。如果项目团队成员能面对面沟通，是最高效的沟通方式。
各方成员，稳定节奏
敏捷原则第8条：敏捷过程提倡稳定持续的开发，发起人、开发者及用户都应该能不断地维持稳定的步调。
敏捷管理，是在愿景、资源和时间明确的条件下，采取的一种高效管理方式。这也就意味着资源不会改变，保证项目时间进度。持续稳定的工作节奏，有利于控制项目的时间进度。项目干系人应该维持稳定的步调，在适当的时机做适当精度的规划、设计，才能按时持续输出可用的阶段成果。
同心协力，自我组织
敏捷原则第11条：最佳的架构、需求及设计皆来自于能自我组织的团队
团结就是力量，这力量能克服各种困难。敏捷团队是自我组织、管理的团队。敏捷项目管理没有明确的架构、需求及设计时间。团队成员同心协力，一起规划、设计，一起完成任务，一起克服困难，一起分享胜利的喜悦。
团队自省，持续改进
敏捷原则第12条：团队定期自省应如何更有效率，并据以调整与修正行为
* SCRUM有那些价值观？你是如何理解每一条价值观的？
1、承诺– 愿意对目标做出承诺
2、专注– 把你的心思和能力都用到你承诺的工作上去
3、开放– Scrum 把项目中的一切开放给每个人看
4、尊重– 每个人都有他独特的背景和经验
5、勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
* SCRUM有哪些角色？谈谈你对每个角色的理解？
Scrum主管、产品负责人、开发团队
1、Scrum 主管：Scrum master在这里不是项目经理的意思，他更像是这个团队的保姆，他要负责整个团队的鼓励工作，为团队服务，给团队提供理论支持，引导团队。更像是教练的一个工作。
2、产品负责人：Product Owner是这个Scrum团队里边儿唯一一个经过授权的人，他负责的是整个产品。整个产品开发做什么，不做什么，哪一部分在哪个时间点交付的这个工作，也就是说，负责构建产品待办列表。
3、开发团队成员：在Scrum里头，这个团队是近似于全功能的跨职能团队，其实敏捷对团队的要求是非常高的，这也是他成本高比较贵的原因之一。
* SCRUM有哪些工件？每个工件存在的价值是什么？
1、产品待办列表，它其实有点儿像我们现在产品开发中讲的需求池的概念，通常来讲，我们会把所有需求一股脑的扔到这个列表中去，但是这个列表会有一个与传统的需求池不一样的地方。这个列表里面所有的需求，都是有价值的，有次序的。
2、冲刺待办事项，通过我们价值的体现，包括我们对它的排序。我们就会得出这样一个结论，我们应该先做什么，后做什么。
3、潜在可交付产品增量，这个东西大致的意思是，我们在做产品的时候，是一个迭代增量的过程。
* SCRUM有哪些事件？每个事件的价值是什么？
1、第一个叫Scrum计划会议，把产品待办事项列表里面的东西决定哪些可以在Scrum计划会议里边儿解决掉，把目标、范围和任务纳入确定的冲刺待办列表。
2、第二个会议，我相信很多的企业，很多的团队在做，叫做每日站会。我为了我们团队的目标，昨天做了什么；我为了我的团队目标，今天我要完成什么。
3、第三个会议叫做Sprint评审，Scrum review。这个会议就是来评价你迭代的这个产品，是不是可以纳入到潜在可交付的产品增量，这还是个潜在的，还是不可交付的，经过了这个会，你能不能交付这个事儿就能定了。
4、第四个会议叫Scrum回顾。通过回顾，我们不但能够找到过去的一些缺点和失误，还能发现一些优点，并持续的改进下去，这对于敏捷团队尤为重要，为什么呢，因为敏捷这件事，第二个原则就是要持续的改进。
* 什么是仆人式的领导？谈谈你期望的领导是什么样子的？P216
Scrum主管相当于仆人式的领导，指挥团队、排除障碍、防止团队注意力分散、帮助团队成长，帮助团队寻找解决方案，而不是分配任务。其他团队成员也可以承担起仆人式的领导角色，可以帮助主管提供所需要的帮助。
倾听、理解、相信、检查、说服力；专注于个人与互动这一敏捷原则
* 如何才能保证团队成功的实施SCRUM敏捷项目管理？
获取组织和个人的承诺
招聘合适的人员：开发团队、scrum主管、产品负责人
建立适当的环境：创建适合敏捷的环境
开展培训：敏捷导师
获取持续的支持：充分的沟通
* 谈谈你对SCRUM的看法？有哪些可取的？有哪些不可取的？
把项目量化为多个冲刺
以提供更好的产品质量
提高客户满意度
增强团队士气
增强合作和责任感定制化团队结构
提高绩效可视性
降低风险
可取：比如敏捷工作中全天的工作、站会、周会；信息开放
不可取：关于采购管理，我们不涉及，就先不考虑
* 都有哪些沟通方式？谈谈你对每种沟通方式的理解？
低科技沟通方式
面对面沟通方式召开简短的每日例会。
向产品负责人提出问题
与你的同事们沟通
团队成员看到：
冲刺的目标
达成冲刺目标所必须的功能
在冲刺中已完成了哪些工作
在冲刺中接下来还要做什么
谁正在进行哪项任务
还剩下哪些工作要做
工具：
一两块白板
大小不同颜色的便利贴
许多不同颜色的彩色笔
一块冲刺阶段专用的看板
高科技沟通方式
视频会议和网络摄像头。
即时消息软件
基于网络的桌面共享
协作网站
* 如何理解自组织和自管理？我们团队还有哪些需要加强？P212
Scrum团队成员直接对可交付的成果负责，组织他们自己的工作和工作和任务，实行自我管理。激发团队主人翁意识，前提是团队之间建立全面的信任；相比传统项目，自管理能激发团队的创新能力和创造力。
* 日常工作中都存在哪些干扰？如何有效消除这些干扰？
多个项目、多个任务、监管过渡、外部影响、管理层
消除：
确保开发团队专注于单个项目
专注于单个任务
放手让团队自己干，自管理与自组织
化解干扰项，产品负责人要决定是否为新任务牺牲部分既定功能
要为开发团队屏蔽来自管理层的直接要求
* 什么是产品愿景、产品路线图、冲刺（迭代）、发布？如何理解它们之间的关联关系？
产品愿景：是一个用来表明你的产品是如何支持公司或组织战略的电梯游说或快速总结。
产品路线图：产品需求的总体视图
冲刺：一段确定的迭代时间，创建特定的产品功能
发布：发布出来用于生产的一组可用的产品特性
都是价值路线图的一部分，是项目的整体路线
* 敏捷项目管理是如何提升质量并降低风险的？
提升质量
质量：指某个产品是否可工作并满足项目干系人的需求，提升质量的要点是预防。
强调技术卓越和良好设计
将特定质量开发技术引入产品生产
开发团队与产品负责人之间进行日常沟通
用户故事中包含验收标准
面对面沟通和集中办公
可持续开发
对工作和行为进行定期检查和调整
降低风险
因素：完工定义(已开发、已测试、已集成、已归档)、自筹资项目、从失败中快速抽身
从根本上降低风险：分多次冲刺迭代的开发模式使项目投入后短期内即可验证产品的可用性，产品负责人积极介入提供产品反馈，帮助团队开发出预期的产品。
