敏捷宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
1. 个体和互动 高于 流程和工具
2. 工作的软件 高于 详尽的文档
3. 客户合作 高于 合同谈判
4. 响应变化 高于 遵循计划
尽管右项有其价值，我们更重视左项的价值。
//只有有技能的人员、可以工作的软件、与客户合作以及响应变化，产品交付才可能实现。
敏捷的12条核心原则
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 ------------------客户价值
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 ------------------拥抱变化
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 ------------------短周期
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 -----------------跨职能合作
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 -----------------激发和信任
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 ------------------面对面
7. 可工作的软件是进度的首要度量标准。 ------------------可工作的软件
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 ------------------可持续发展
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 ------------------技术卓越
10. 以简洁为本，它是极力减少不必要工作量的艺术。 ------------------简洁为本
11. 最好的架构、需求和设计出自自组织团队。 ------------------自组织
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 ------------------持续改进
价值变化短周期，合作信任面对面；
简洁软件可持续；卓越改进自组织；
---尽早持续交付价值；拥抱变化；短周期交付反馈；跨职能合作，激发个体信任；沟通面对面；
------------简洁为本，避免浪费；可交付的软件；可持续的节奏；技术卓越；持续改进，自组织的团队；
团队为何存在、要创造什么产品、为谁而创造以及如何共同工作，这些组成了敏捷项目管理的核心原则。
12原则的记忆要点：1个目标； 四个要求；4个团队建设规则；3个工作方针；
敏捷项目管理的《相互依赖声明》
2005年，敏捷项目领导力网络(Agile Project Leadship Network，APLN)联盟组织，签署了DOI (Declaration of InterDependence) ，站在敏捷领导者的角度栓释了敏捷的核心价值观。但敏捷项目管理的《相互依赖声明》更关注项目管理领域。
● 我们通过创造我们关注的持续价值流来提高投资回报率。
● 我们通过与客户频繁的交互和分享所有权来交付可靠的结果。
● 我们承认不确定性，并通过迭代、规划和适应来管理它。
● 我们通过承认个人是价值的最终来源、创造使他们有所作为的环境来激发创造力和创新力。
● 我们通过团队结果问责制和团队职责分享制来提升绩效。
● 我们通过因地制宜地应用具体的策略、过程和实践来改进效率和可靠性。
Declaration of Interdependence相互依赖声明
Agile and adaptive approaches for linking people, projects and value
敏捷通过自适应的方式，连接人、项目和价值
We are a community of project leaders that are highly successful at delivering results. To achieve these results:
我们是一个由一些高度成功地交付结果的项目负责人组成的集体。为了达到这些结果：
• We increase return on investment by making continuous flow of value our focus.
• 我们通过让所关注的价值连续地流流来 增加投资回报。---价值的连续流动
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• 我们通过与客户频繁的交互和共享所有权的方式，来交付可靠的结果。
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• 我们 预料到了不确定性，并通过迭代、预防和适应的方式来管理它。
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• 我们承认个人才是价值的最终源泉，努力建立一个使他们能够体现价值的环境，以此来 释放创造力和创新力。
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• 我们通过将问责按结果进行分组和按团队效率来分担职责，从而 提升绩效。
• We improve effectiveness and reliability through situationally specific strategies, processes, and practices.
• 百度一下，你就知道 我们使用根据具体情况而定的策略、过程和实践来 提高效率和可靠性。
召开有效引导会议必读的八本书籍排行榜
1、《罗伯特议事规则》，
2、《打破罗伯特规则》，
3、《结构化研讨——参与式决策操作手册》，
4、《引导：团队群策群力的实践指南》，
5、《开放空间引导技术：集思广益，解决冲突，达成共识，实现自组织的高效方法》，
6、《世界咖啡：创造集体智慧的汇谈方法》，
7、《未来探索：将愿景、承诺和行动融入全系统的引导方法》，
8、《虚拟引导的秘诀：在线会议引导的实操指南》。
引导技术在团队决策中的重要作用。但是，引导并不是万能的。敏捷中做为Scrum Master个人认为以下情况，最好不要做引导：
1，在具体的技术或者业务话题中，请不要做引导。---SM作为引导者要保持中立性
因为前者是技术人员的事情，而后者应该是业务人员的决策。即使你有一定的技术/业务背景也不要如此做。不仅妨碍了引导者的中立性，更可能使你迷失在具体的细节中而使会议的进展脱控。
2，在有破坏性冲突发生的时候，请不要做引导。 此时，应该直接制止其发生防止事态的恶化。
3，在需要做教练的时候不要引导。
这情况经常发生在团队开始导入敏捷的时候，团队对敏捷经常有疑惑。而这些疑惑通常是常识范围内的，此时可能已经超出教练的工作范围，此时我们不妨引入导师或者顾问来帮助解决此类问题。
敏捷概念关键字
尊重个人，自组织，自律；仆人式领导，为团队授权，关注和帮助成员的发展、成长和反馈；注重结果，而不是完美的 过程；倾听；引导+指导
专职人员，集中办公，诚实、透明、信任、安全的工作环境，平等话语权；参与式决策；自我组织+自我管理；
跨职能团队；通才；T型人才；
减少浪费；透明化；适应变更，持续改善；加强互动，面对面沟通；
合作而不是谈判；适应变化而不是遵循计划；关注团队而不是任务；
关注商业价值；优先级；短周期；小增量；尽早持续交付；频繁交付、探索、刺探(小型试验)、调整和适应；可持续的节奏（周期性演示、反馈评审和调整）；
需求：实例化需求+用户故事地图+影响地图----》产品路线图----》代办事项列表backlog---DOD（完成定义）--版本发布标准
交付功能的业务满意度；
愿意尝试任何新方法新技术；
参与式决策模型；仆人式领导风格；协作式团队工作文化；接受反馈的做法，促进团队改进；
共同目标--敏捷强调团队认同和承诺实现共同目标。
卓越技术追求；简洁设计和文档，刚刚好； 可持续的节奏；开发和业务始终协作；
回顾反省； 持续学习；
障碍：仆人式领导，工作重点由“管理协调”，转变为“促进合作”； 促进团队内外部的合作和对话；鼓励团队参与、理解并共担责任； 鼓励协作，成为搭桥者和教练角色；
移山引海--消除障碍，提供资源和支持；仆人式领导，为满足团队、项目和组织的需求而工作；
限制在制品数量；
开放协作的工作环境，开放公共区+安静私人区；团队定期聚集一堂，
分布式团队管理沟通的一些技术包括鱼缸窗口(长期视频会议连接构建渗透式沟通环境)和远程结对：
作为敏捷项目领导，首先要把重点放在如何组建跨职能团队，让所有团队成员 100% 投入团队工作。即使这只是关键团队成员每天一起工作和交流，也是迈向正确敏捷方向的一步。
西瓜项目：预测型项目状态报告用交通灯表示状态，常常不准，出现西瓜项目，皮绿-壤红，知道发布计划前些天才发现进度不扎实。
敏捷倾向于使用基于经验和价值的衡量指标，而不是百分比；
精益创意；
有一个真理永恒不变，那就是：检查、适应和透明度是成功交付价值的关键因素。
---PO决定一个用户故事的价值，团队决定一个用户故事的成本；
精益思想：消除浪费；尽早交付，获得反馈；延迟决策；增强学习；建立整体--确保质量内嵌在系统中的；
调研需求--编写用户故事--定义DOD---产品待办事项列表(加上技术故事和NFR等)---排优先级---规模估算--发布计划-----》进入探索迭代和适应阶段
发布计划会：提出发布的目的和价值
敏捷参与式决策指的是团队参与决策制定的过程。敏捷参与式决策模型
输入型：所有参与者有机会在决策制定过程中提供输入；
共享协作型：参与者不仅仅提供咨询参考，同时也要积极参与到达成决策的过程中。
命令型：决策由高级领导者或者一个小群体制定，团队成员被告知决定。
1、敏捷谈判和冲突管理 KennethThomas和RalphKilmann定义的五种冲突模型：
回避：从实际或潜在冲突中退出。目标是搁置。
妥协：寻找能让全体当事人都在一定程度上满意的方案。目标是退让。
缓解：强调一致而非差异。目标是找一个折中方案。
合作：综合考虑不同的观点和意见，引导各方达成一致意见并加以遵守。目标是双赢。
对抗：过高的自信和强势，很低的合作性， 目标是自己赢。2 、冲突的五层级
冲突是不可避免的甚至团队需要冲突。冲突的强度我们按照5 个层级来区分：
层级1最低，层级5最高，冲突层级越高，越难达成友好协议。
第一层级：团队意识到有问题待解决，团队保持关注发生了什么改变以及如何去弥补。
第二层级：团队成员开始有异议和冲突，团队成员疏离，进入冷战模式。第三层级：冲突变成竞争。人们开始寻找同盟，多种问题遗留未解决。关注点不再是解决问题、妥协，而是一定要赢。
第四层级：冲突演变为运动。带着正义和纠正的态度，团队成员认为冲突另一方不会改变，必须打倒。---中美竞争已经在逐步演变为运动
第五层级：冲突演变成战争。没有建设性成果。
持续集成的5个关键指标
CI（持续集成）的重点涵盖从代码提交到测试环境，CD（持续交付）涵盖到向最终用户的实际交付。有许多文章描述 DevOps 的指标，Pipeline的指标，这些指标往往对于CD有很好的覆盖，但很少有文章专门讲述CI的指标 。因此本文试图说明CI的指标，下面是CI关键指标表。
指标名称 说明 持续集成频率 在一个月或一周内进行了多少次 CI？ 持续集成成功率 持续集成成功次数对比总次数 最长失败持续时间 从一个 CI 失败到恢复通过，在观察期中最长的时间是多少？ 平均持续集成执行时间 CI 平均执行多长时间 测试用例数量 CI 中的测试用例总数
愿景 VS 使命：
1. 定义不同： 企业愿景是由企业内部的成员所制定，经团队讨论达成共识，形成的大家愿意全力以赴的未来方向。
企业使命说明了企业的根本性质与存在的理由。
企业宗旨从根本上说是要回答“我们的企业是什么”这个问题。实质上是要企业主为整个企业定下发展基调的问题，即“我们的企业将成为什么样的企业”问题。
2、作用不同：
企业愿景是企业对未来前景和发展方向的高度概括，表达了一种企业为之奋斗的心愿，聚焦企业管理领域，快速提升CEO自身领导力及管理能力籍此达到推动企业成长的目的。
企业使命为企业确立了一个经营的基本指导思想、原则、方向、经营哲学等，它不是企业具体的战略目标，或者是抽象地存在，不一定表述为文字，但影响经营者的决策和思维。
3、意义不同：
企业愿景回答的是"我是谁"的问题，企业使命回答的是"企业的业务是什么"的问题。
OpenUP是IBM精简的、开源版本的Rational统一过程（RUP）。RUP当然可以作为敏捷过程来使用，而且事实上很多组织也已经这么做了。
OPenUP，开放统一过程（Open United Process，OpenUP）是一种基于Eclipse过程框架（Eclipse Process Framework，EPF）的开源方法。如图3.5所示，OpenUP基于统一过程的四阶段的方法采用了迭代和增量（演进型）的生命周期，包含一套核心的敏捷实践。为了避免使用过多的流程，OpenUP遵循精益原则，只涉及最小集合的敏捷实践，更适合于小型敏捷项目。而根据具体情况，必要的时候，我们还可以在此基础上增量地添加一些有关企业、治理或技术相关的指南。OpenUP的重点在于，通过增量的方式一点点地扩充过程，以求找到团队或项目所需的最精简过程，而不是首先试图理解复杂臃肿的过程，然后在此基础上做适当的裁剪。后者难度较大，且效率不高，这点也已经过实践证明。
微增量代表短期的工作单元，它可以产生出项目进展过程中稳定、可测量的步调（典型的是以小时数或者天数作为度量单位）。该过程采用加强型的协作，因为产品系统需要以增量的方式由做过承诺的自组织团队开发。这些微增量提供极短的反馈循环回路，使得团队在每一个迭代过程中都能做出恰当灵活的决定。
OpenUP将项目划分为若干个迭代周期：有规划的、有时限的时间段，通常以周为度量单位。迭代使团队注重以一种可预见的方式向利益相关者交付增长式的价值。迭代计划定义在迭代期间应当完成哪些工作，其结果是一个可以演示或可以发布的构建。OpenUP团队将通过自组织来实现迭代目标和交付所承诺的成果。团队定义并“提取”出工作条目列表中的任务。OpenUP采用迭代生命周期（组织微增量如何应用）以得到一个稳定的、复合系统需要的构造，从而逐步地向迭代的目标前进。
OpenUP将项目生命周期分为四个阶段：先启阶段、精化阶段、构造阶段和移交阶段。项目生命周期为利益相关者和团队成员提供可见度和决策点。这将促进更有效的管理，并且允许在适当的时间做出项目是否继续的决定。项目计划定义生命周期，我们得到的最终结果是可发布的应用程序。
OpenUP的生命周期类似于DAD的。两者都有先启阶段，并且都通过首先在早期的迭代周期内构建“棘手的”部分，来尽可能早地降低风险。与其他基于同一过程框架的方法一样，OpenUP也专门有精化阶段：基准化体系结构，并尽可能多地降低风险。DAD也有类似的关注点（见第13章关于风险—价值生命周期实践的描述），但是没有为此专门分出单独的精化阶段。
什么是RUP
MoSCoW--基于价值的分析致力于了解由客户定义的价值与产品中的不同部分如特性和任务之间的关系是如何的。特性通常以基于价值和风险的优先级得到优先处理。
通过风险-价值指标和成本-价值指标，使用MoSCoW或Kano方法可执行优先级。
结对编程的实践发生在极限编程之内，它由两个程序员共同完成任务。它有助于集体代码所有权，因为每行代码都最少有两位程序员共同完成。同时它也能对最有可能首先运行的清晰代码进行网上审查，这样有助于缩减整体时间。它可能会也可能不会引导团队独立思考，因为结对编程中的其中一个风险有可能是一位成员停止思考和倾听，仅仅是跟随另一个成员的步伐来实施工作。
不仅在敏捷中，富有动力的团队对任何项目都至关重要。富有动力的团队运作更流畅，生产效率高，表现超越期望值。可提高动力的简单步骤包括：
- 1）共度黄金时间，团队成员可在个人层面上了解他人以此营造社区氛围，
- 2）提供反馈，指导和训练，赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练，
- 3）授权，授权团队成员作关键决策，在此期间，建立信任并显示领导对团队能力的信任。
【scrum3355原则 (3种角色、3个工件、5个仪式、5个价值观)】
3个角色：产品负责人（Product Owner）、Scrum Master、Scrum团队
3个工件：产品待办列表(ProductBacklog)、Sprint待办列表(SprintBacklog)、产品增量(PSPI：PotentiallyShippableProductIncrement)5个活动：
Sprint计划会议（Sprint Planning Meeting）、每日站会（Daily Scrum Meeting）、Sprint评审会议（Sprint Review Meeting）、
Sprint回顾会议（Sprint Retrospective Meeting）、产品Backlog梳理会议（ Product Backlog Refinement）
5个价值：
• 承诺 – 愿意对目标做出承诺
• 专注– 把你的心思和能力都用到你承诺的工作上去
• 开放– Scrum 把项目中的一切开放给每个人看
• 尊重– 每个人都有他独特的背景和经验
• 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
- Sprint Planning 是有时间盒限定的，以一个月的 Sprint 来说最多为 8 个小时，，4个小时用于选择故事和4个小时估算规模（故事点/理想人天）。对于更短的 Sprint，Sprint Planning 所需时间通常会更短。
- Daily Scrum 是一个属于 Scrum Team 的 Developers 的 15 分钟的事件。
- Sprint Review评审是 Sprint 的倒数第二个事件，Sprint Review 是有时间盒限定的，以一个月的 Sprint 来说，最多为 4 个小时。 对于更短的 Sprint，Sprint Review 通常所需的时间更短。
- Sprint Retrospective 结束 Sprint。它是有时间盒限定的，以一个月的 Sprint 来说，最多为 3 个小时。对于更短的 Sprint， Sprint Retrospective 通常所需的时间更短。
//敏捷团队是跨职能团队，团队成员在项目中互相协作，且拥有共同目标，而传统项目中不同的职能有不同的目标。
Scrum Manager 的主要职责是识别问题，困难，并协助团队解决问题，排除障碍。如果一个团队成员经常违背冲刺承诺，scrum master应该怎么做？
结对编程，是一种比较好的方式，可以快速学习提高质量，技术比较好的工程师和经验不足的工程师结对编程，以提升自己的能力。scrum master的职责是对团队成员进行指导、帮助、排除障碍等，所以应该对他进行一些技术的指导，去帮助他们提升自己。
Scrum meeting当中的“鸡”和“猪”
一幅由implementingscrum.com提供的卡通图片叫做“Scrum Pigs and Chickens?”在这幅卡通图片中，这两种动物其实代表了我们项目中的两种参与者，我们把他们叫做“鸡”和“猪”。
在这个故事中,他们计划合伙开一个的餐馆，并且有一个起名为“火腿和鸡蛋”的主意，但是，猪感觉这个主意非常不公平，因为这个主意会让他投入他的全部，甚至必须要提供自己作为主要原料，而与此同时，作为合伙人的鸡仅仅是需要提供她的鸡蛋就够了。
在SCRUM MEETING中，我们也可以将参与者划分为这样的两类，其中一部分是“猪”，另外一部分则是“鸡”。参加SCRUM的成员，要么是全身心，倾其所有地投入到项目当中，要么就是简单的参与者。让我们来看一下在我们项目当里，各种形形色色的职位角色都属于哪一类？
猪/全力投入 鸡/合伙人 例如：sm po 团队 例如 职能经理；项目相关方等； 自组织团队：每日例会，猪是主角，鸡是客人，要适当闭嘴，不要喧宾夺主，尤其是很短的每日站会。 “鸡”和“猪”的角色分类对于一个SCRUM MEETING来说是至关重要的，因为这种分类说明了在一个SCRUM MEETING当中，谁是主动的，全身心的参与者。与会的猪们应该在会议上分享他们当前的项目进度以及他们在此过程中正在遇到的障碍。
鸡在一个SCRUM MEETING中并不是一个主动的，全身心的参与者。因此他们可以参加，但是应该只是作为一个客人的身份来参加，并且不应用他们当前身份对当前会议产生任何影响。
鸡并不是主动参与者的另外一个原因是，他们太容易喧宾夺主，很容易就会影响到SCRUM的方向，还可能会将整个团队的目标带偏。让整个会议始终保持一个特定的主题，并且应当包含所应涵盖的内容的责任担当者是SCRUM MASTER。不管是鸡还是猪，如果有人跑题了，这个时候，承担SCRUM MASTER角色的人应当站出来，让会议的主题回到本来的议题上去。
工作协议：迭代su
目标迭代速度： 昨日天气(yesterday's weather)， 大多数小组默认的假设是他们在下一次迭代中的速度等于最近一次迭代中 的速度。Beck与Fowler(2000)称其为昨日天气(yesterday's weather),因为我们对今天天气的最佳猜测就是它会和昨天的天气一样。 其他小组偏好使用-一个移动均值，这个均值比许县对计丰2次铁代做出的
敏捷项目章程： 项目之所以重要的原因、团队的前进方向以及项目的目标。
项目章程 是必需的，敏捷项目章程不是很详细， 关注于渐进明细。·内容包括概要的需求、关键的成功要素、里程碑和初步的预算。必须为团队授权进行敏捷过程的定义。
敏捷项目章程要回答以下问题：
1、我们为什么要做这个项目？这是项目的愿景。
2、谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分。
3、对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。
4、我们将怎样合作？这说明预期的工作流。
精益软件开发原则是： 清除浪费； 强化学习；尽可能晚决策； 尽可能早交付； 授权团队；构建完整性；全盘检视;
精益软件开发架构中存在的两种完整性类型有：概念性的和感知性的。
- 概念上的完整性是由开发者决定的，如果产品集成良好和功能详细，那么完整性会非常高。
- 感知上的完整性是由客户观察得出的，如果客户最初对产品满意，然后产品满足需求，那么完整性会很高。
计划扑克：计划扑克中每一个用户故事应分配的时间是2到3分钟
计划扑克是基于宽带德尔菲估算技能、也是以共识为基础的工作量估算技能。有时候也称为敏捷扑克（scrum扑克），往往在故事点和开发用户故事中用来估算相对工作量。
在计划扑克会议中，每一位成员各持有一副相同价值的计划扑克卡片。 计划扑克会议按如下运行：1）一名调停人，主持会议，不参与估算。 2）产品负责人对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票。
3）每一位成员抽取一张卡片来估算工作量。 4）每人抽取一张卡片后，同时将他们的卡片翻转， 5）持高和低估算的成员各有一次辩护机会。
6）达成共识前，不断重复以上流程。
通常计划扑克的参照用户故事是中码或者均码。估算者可利用参照点来做相对估算。
亲和估算
亲和是预测工作量的一个方法，基本的亲和估算模式涉及从小到大范围测量用户故事。
这个范围可以是斐波那契数列或者T-shirt尺码，常常贴在大型会议室墙上。然后参与者在估算时可将他们的用户故事贴到这面墙上。通常在故事点，开发用户故事中，而尤其在大型产品待办事项中作用巨大。
一支高绩效的团队表现为：
授权正确的成员 建立信任 以可持续的速度工作 保持稳定的速度/生产率开发 有固定时间回顾和反思工作 有团队领导负责移除障碍并提供指导和教练 自主管
理和自我约束 协作的。可运用以下几种管理技能建立或促进高绩效的团队氛围： 移除任何降低团队绩效的障碍 对团队绩效持高期望 教练和指导团队达到自身的最佳绩效。
表 A1-2敏捷在《PMBOK® 指南》知识领域中的应用
| 《PMBOK@指南》知识领域 | 敏捷工作过程中的应用 |
| 第4章项目整合管理 | 迭代和敏捷强调客户参与，频繁反馈，能够促进团队成员及相关领域专家参与整合管理。团队成员自行决定计划及方式。
项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更。 |
| 第5章 项目范围管理 | 敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。 敏捷方法有目的地构建和审查原型，并通过发布多个版本来明确需求。这样一来, 范围会在整个项目期间被定义和再定义。在敏捷方法中，把需求列入待办事项列表 |
| 第6章 项目进度管理 | 适应型方法采用短周期来开展工作、审查结果，并在必要时做出调整。 这些周期可针对方法和可交付成果的适用性提供快速反馈，通常表现为迭代型进度计划和拉动式按需进度计划。
为管理大规模的，全企业系统的，完整的交付生命周期，可能需要采用一系列技术，包括预测法、适应型方法或两种方法的混合。组织还可能需要结合几种核心方法，或采用已实践过的方法，并采纳来自传统技术的一些原则和实践。
|
| 第7章 项目成本管理 | 对易变性高、范围并未完全明确、经常发生变更的项目,详细的成本计算可能没有多大帮助。 在这种情况下，可以采用轻量级估算方法快速生成对项目人力成本的高层级预测，在出现变更时容易调整预测;而详细的估算适用于采用准时制的短期规划。
|
| 第8章 项目质量管理 | 为引导变更，敏捷方法要求在整个项目期间频繁开展质量与审核步骤，而不是在面临项目结束时才执行。
后续回顾会议评估试验过程，确定新方法是否可行，是否应继续使用，是否应该调整，或者直接弃用。
|
| 第9章 项目资源管理 | 易变性高的项目得益于最大限度地集中和协作的团队结构,例如拥有通才的自组织团队。
|
| 第10章 项目沟通管理 | 尽量简化团队成员获取信息的通道，频繁进行团队检查,并让团队成员集中办公。
|
| 第11章 项目风险管理 | 从本质上讲，越是变化的环境就存在越多的不确定性和风险。要应对快速变化，就需要采用适应型方法管理项目，即:通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理。 在选择每个迭代期的工作内容时，应该考虑风险;在每个迭代期间应该识别、分析和管理风险。
|
| 第12章 项目采购管理 | 在敏捷型环境中，可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励。
|
| 第13章 项目相关方管理 | 为了开展及时，且高效的讨论及决策，适应型团队会直接与相关方互动，而不是通过层层的管理级别。客户、用户和开发人员在动态的共创过程中交换信息，通常能实现更高的相关方参与和满意程度。在整个项目期间保持与相关方社区的互动，有利于降低风险、建立信任和尽早做出项目调整，从而节约成本，提高项目成功的可能性。
|
表5-1 敏捷的痛点和解决痛点的可能性
| 痛点 | 解决痛点的可能性 |
| 团队目标或任务不明确 | 敏捷章程中目标部分--愿景、使命和使命测试 |
| 团队工作协议不明确 | 敏捷章程中关于一致性的部分--价值观、原则和工作协议 |
| 团队环境不明确 | 敏捷章程关于环境的部分--边界、承诺资产和前瞻性分析 |
| 需求不明确 | 帮助发起人和相关方制定产品愿景。考虑使用实例化需求、用户故事地图和影响地图来构建产品路线图。让团队和产品负责人一起来明确需求的期望和价值。逐步将路线图分解为具有更少具体需求的待办事项列表。 |
| 用户体验不佳 | 开发团队的用户体验设计实践应在早期就让用户经常参与。 |
| 估算不准确 | 通过分解故事来让故事变小。让整个团队使用相对估算进行估算。考虑通过敏捷建模或刺探来理解故事。 |
| 工作分配或工作进展不明确 | 帮助团队认识到要自我管理工作。考虑用看板面板查看工作流程。考虑利用每日站会，根据看板查看工作进展。 |
| 团队面临障碍 | 仆人式领导能帮助消除这些障碍。如果团队不知道他们都有哪些可选方案，就要考虑聘请教练。有时，团队或仆人式领导无法消除障碍，团队就需要上报故事。 |
| 由于产品待办事项列表不够完善，导致工作延误/超时 | 产品负责人和团队- -起研讨故事。为故事创建一-个准备就绪的定义。考虑分拆故事以使用更小的故事。 |
| 缺陷 | 考虑对特定环境有效的技术实践。它们可能是:结对工作、产品集体负责制、普适测试(测试驱动方法和自动化测试方法)以及稳健的完成的定义。 |
| 工作未完成 | 团队确定故事完成的定义，包括验收标准在内。另外，还要为项目补充发布标准。 |
| 技术债务(代码质量降级) | 重构、敏捷建模、普适测试、自动化代码质量分析、完成,的定义 |
| 产品复杂性过高 | 无论是软件项目还是非软件项目，都要常常鼓励团队思考:“最简单的有效方法是什么?”，并应用“简洁，即尽最大可能减少不必要的工作，这是一-门艺术”的敏捷原则。这样做将有助于降低复杂性。 |
| 团队合作过程进展缓慢或没有改善 | 在每次回顾中，选择的改进项目不要超过三个。让仆人式 领导帮助团队学习怎样整合这些待改进项。 |
| 前期工作过多导致返工 | 不要做过多的前期工作，而要考虑让团队通过刺探来学习。另外，在项目开始时衡量在制品(WIP), 看看哪些部分团队并不需要设计，只需要交付价值。缩短迭代，并创建一个稳健的完成的定义。 |
| 错误的开始，前功尽弃 | 让产品负责人成为团队不可分割的一分子。 |
| 产品待办事项列表杂乱无序 | 按价值排序，并考虑延迟成本按持续时间(CD3)和其他价值模型划分。 |
| 仓促/等待，不均匀的工作流程 | 计划要对应团队的能力，而不是超出能力所及。要求人员停止多任务，为一一个团队专注工作。请团队利用结对、群集或群体开发等方法，平衡整个团队的能力。 |
| 相关方要求无法满足 | 仆人式领导与这个相关方(可能是产品负责人) - -起工作。 |
| 意想不到或不可预见的延误 | 让团队更频繁地检查，使用看板面板检查工作流和在制品限制，了解需求对团队或产品的影响。也可以在障碍板上跟踪障碍和障碍消除情况。 |
| 孤立的团队，而不是跨职能团队 | 让项目人员作为跨职能团队自我组织。 使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队。 |
用户故事三段论：作为(XX角色),我想(XX功能),从而(实现XX价值) 最后一句话,就是在强调价值的重要性；
用户故事三属性：范围、重要性、估算； 前面两个由PO定义；估算由团队在sprint计划会上讨论、优化和调整。
还有第四个变量是质量，质量不能让步，又分为外部质量和内部质量；
• 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
• 内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
用户故事vs任务： 故事是可以交付的对客户有价值的成果；而任务是不可以交付的中间成果；
产品待办事项列表颗粒度一般只列到用户故事级别甚至更大一些；而拆分用户故事到任务不写在产品待办事项列表中。
可以在冲刺计划会上，由团队来进一部拆分，一来拆分工作的颗粒度和标准不同团队各不一样，有一定的随意性，其次PO不需要考虑到那个细节；
Sprint计划会的一些的成果：
sprint目标。
团队成员名单（以及他们的投入程度，如果不是100%的话）。
sprint backlog（即sprint中包括的故事列表）； ----- 故事交流，故事分拆任务；+技术故事；每个故事DOD; 故事估算；
确定好sprint演示日期。
确定好时间地点，供举行每日scrum会议。
Sprint 对外宣传
1. Sprint信息页面
+ 如何演示
2. Sprint Dashboard---仪表盘
3. Sprint Backlog 【最小单位，0.5理想人天，小的合并】
4. 坚持 “所有的Sprint都要结束于演示”
5. 坚持“所有的团队都要回顾”，回顾的白板
图中三列分别是：
Good：如果我们可以重做同一个sprint，哪些做法可以保持。
Could have done better：如果我们可以重做同一个sprint，哪些做法需要改变。
Improvements：有关将来如何改进的具体想法。6. 定义发布计划： 有时候，一次只计划一个sprint中要做的事情是不足的，尤其是签了固定价格合同后，不得不预先计划了，不然就会有无法按期交付的危险。
一般来讲，制定发布计划是在尝试回答这个问题：“最晚到什么时候为止，我们可以交付这个新系统的1.0版本？”
第一步定义验收标准
定义验收标准：
除了普通的产品backlog之外，产品负责人还会定义一系列的验收标准，它从合同的角度将产品backlog中重要性级别的含义进行了简单分类。
下面是验收标准规则的一个例子：
所有重要性>= 100的条目都必须在1.0版中发布。
所有重要性在50 - 99之间的条目应该在1.0中发布，不过也许我们可以在紧接着的一个快速发布版中完成这些。
重要性在25 – 49之间的条目也都是需要的，不过可以在1.1版中发布。 重要性< 25的条目都是不确定的，也许永远不会用到。
红= 必须在1.0版中发布（banana – pear）
黄= 应该在1.0版中发布（raisin – onion）
绿= 也许可以以后再做（grapefruit – peach）
所以如果我们在最后期限之前能够发布从banana到onion的所有条目，我们就是安全的。如果时间不够用的话，也许我们可以跳过raisin、peanut、donut、onion。Onion以下的东西都算是额外的了。第二步，估算
第三步 生产率估算，投入程度考虑，即一个sprint周期我们能完成多少个故事点，
第四步 综合各种因素，确定sprint计划，优化调整为发布计划
| 产品 BACKLOG（示例） | ||||||||||
| ID | Name | Imp | Est | How to demo | Notes | Track | Components | Requestor | Bug tracking ID | |
| ID | 名字 | 重要性 | 初始估算 | 怎样演示 | 备注 | 故事类别 | 模块/子系统 | 提出者 | JIRA库ID | |
| 1 | 存款 | 30 | 5 | 登录，打开存款界面，存入10欧元，转到我的账户余额界面，检查我的余额增加了10欧元。 | 需要UML顺序图。目前不需要考虑加密的问题。 | 优化 | ||||
| 后台系统 | ||||||||||
| 注： 用户故事要基于用户的角度来考虑，为用户带来价值，注意不要成为技术任务，如“给数据库添加索引” | ||||||||||
| 一个产品只能有一个产品待办事项列表和一个PO. | ||||||||||
价值流程图大致包括5个步骤:
1) 确认产品，客户和范围
2)流程图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。
估算流程步骤的持续时长和前置期持续时长(lead time durations)。前置期是指在发生前一项流程或者事件需等待的时长。
3)分析价值流程图来确认浪费存在的地方(比如前置期)和流程可完善的地方
(流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间)。
4) 通过分析，总结出一-份展示价值流应努力达到的前景或者目标的未来价值流程图。
5) 通过流程完善活动(即完善)或者其他方法来达到目标的一些工作。
传统的项目管理方法是在正式会议中评估风险，变化幅度和趋势，敏捷项目管理的风险评估、分析：
1. 关于风险和开放性问题的初始列表---风险和问题跟进表，在发布规划会议期间做初始列表；
2. 而敏捷是在迭代审阅会议中并合风险分析，变化幅度和趋势分析。在敏捷中，风险，变化幅度和趋势分析执行方法是运用信息发射源在迭代期间提示给所有团队成员，比如风险燃尽图，使用传统挣值管理（EVM）来衡量成本差额和调度差额（分别称为CV和SV）。
四步法：识别、评估（定量、定性）、响应、评审
识别：所有活动可以风险识别，输出风险登记册
评估：梳理活动经常干这个事情，其他活动也或多或少
响应：回避、减轻、转移、接受（站会跟踪，看板）
评审：回顾会议上进行
工具：风险板、风险日志、风险燃尽图、风险预测图
跟踪风险---》识别---〉定性分析---》定量风险---〉制定响应措施---》跟踪风险
站会回顾会---〉梳理会、计划会---》梳理会、计划会---〉计划会---》站会回顾会
二、敏捷风险登记册---公开第一位
用户故事估算后，对评估的结果做三角测量法进行复核
在做了几个估算以后，对估算结果做三角测量，具体做法如下
在估算一个故事时，根据这个故事与其他一个或多个故事的关系来估算，假定一个故事估算为4个故事点，第二个故事为2个故事点，把这2个故事放在一起考虑的时候，程序员都应该认可 4个故事点的故事是2个故事点的故事的2倍
其他3个故事点的故事的大小应该介于4个故事点的故事和2个故事点的故事之间。
如果上面的三角测量的结果不对，团队就应该重新估算。
TDD验收测试驱动开发的迭代迭代的4个步骤可简记为4个D：
1）Discuss讨论：敏捷团队和客户或者商业干系人详细讨论用户故事，包含用户故事应有和不应有的预期行为。
2）Distill提取：开发团队研习讨论中的条目并提取成可验证和确认这些行为的测试。提取流程中，整个团队应充分认识“完成”对用户故事的意义，这正是验收标准所在。
3）Develop开发：提取后，团队开发测试代码和产品代码以产生产品特性。
4）Demo示范：产品特性开发后，团队向客户或商业干系人展示以获得反馈。
Scrum的六个时间箱
在项目开始的时候，有发布计划会议，在这个会议中，定下来项目的总体基调，而接下来就是每一个迭代，通过迭代计划会议，每日例会，迭代评审会议，迭代回顾会议，不断实现增量，产生成果，交付给客户。
时间箱一：Sprint冲刺
Sprint的本意是指冲刺，在Scrum中，一个Sprint就是一个迭代，Sprint长度通常2-4周，它是一个时间箱，在项目进行过程中不允许延长或缩短Sprint长度。在Sprint中，ScrumMaster要确保没有任何影响Sprint目标的变更发生。团队构成和质量目标在Sprint中均保持不变。Sprint由Sprint计划会议、开发工作(需求分析、设计、开发、测试、质量控制等)、每日站会、Sprint评审会议和Sprint回顾会议等活动组成。Sprint一个紧跟一个进行，之间没有任何时间间隔。
其它的5个时间箱对应Scrum的5个仪式：
时间箱二：发布计划会议（Release Planning Meeting）----可选的
发布计划会议的目的是建立Scrum团队以及组织内的其他部门能够理解和沟通的计划和目标。发布计划会议需要回答以下两个问题：
- “我们如何以最佳方式将愿景转化为成功的产品？
- 我们怎样才能达到或甚至超越客户的满意度和投资回报？”
发布计划确定发布目标、具有最高优先级的产品Backlog条目、重大风险和发布所包含的全部特性和功能。另外， 发布计划会议确立大致交付日期和费用，如果没有任何变化就应当保持该日期和费用。组织可以检视开发进程，以每个Sprint为基础调整发布计划。
发布计划会议是完全是可选的。
如果项目开始的时候没有这个会议，那么这些工件的缺少将成为一个需要被移除的障碍，解决这个障碍便成为了产品Backlog中的一个条目。
Scrum以迭代的方式构建产品，每个Sprint中都会交付产品增量，通常价值最高、风险最大的部分先开发。产品增量随着Sprint交替而完成，每个增量都是整个产品的可交付一部分。当创造出足够多的有价值的、可供投资方使用的产品增量时，产品就可以发布了。
大多数组织已经有自己的发布计划过程，并且在大多数过程中的大部分计划已经在发布之初完成，而且也不会更改。在Scrum发布计划会议上确立一个整体目标和预期结果。发布计划会议通常不超过组织构建传统发布计划的15-20%时间。然而，Scrum发布在每个Sprint评审和计划会议上都执行准时（Just-in-time）计划，同时，在每日站会上执行每日准时（Just-in-time）计划。总的看来，Scrum发布可能比传统的发布计划耗费略多的工作。
发布计划会议需要为该发布做产品Backlog条目的估算和优先级排列。
发布计划会议可以说是项目的启动会议，在这个会议中，定下这个项目的基调。 这次会议的目的是，居于用户的需求已经优先级，通过发布计划会议，确定项目里程碑，发布的目标，团队成员，项目团队的规章制度，包括例会、计划会、评审会、回顾会的时间和要求。
1）开会的时间一般是项目启动开始的时候，时长2个小时
2）参会人员：Product Owner、Scrum Master、 开发团队、公司高层、客户等
3）开会议题：
- 第一，Product Owner 介绍项目背景，项目的目标，介绍团队成员，每个人团队成员自我介绍，大家互相认识；
- 第二，Product Owner讲述Product Backlog，对应的业务价值和优先级；
- 第三，Tech Lead和QA Lead做可行性及时间的评估，对于技术框架选型确认；
- 第四，团队针对Release Backlog和优先级达成一致；
- 第五，高层宣布项目正式启动，开始项目。
4）会议输出：
- 第一，规划到release的 Product Backlog 条目，优先级。
- 第二，各个 Backlog 条目的初略需求。
- 第三，Release里各个story的时间的评估。
- 第四，团队组成、人员安排、技术框架选型。
交付计划会议开完以后，就要开始工作，每个交付分成几个迭代，每个迭代开始就是迭代计划会议。
时间箱三：Sprint计划会议（Sprint Planning Meeting）
Sprint计划会议的产物是Sprint Backlog。对于一个月为周期的Sprint，计划会议的时间箱限定为8小时。对于较短的Sprint，计划会议一般安排整个Sprint周期的5%时间。Sprint计划会议的内容包括以下两个部分：第一部分，4小时的时间箱中需要确定该Sprint将要完成什么任务。第二部分，也是4小时的时间箱，团队研究在Sprint内如何构建产品增量。
Sprint计划会议包含两部分内容：“做什么”和“怎么做”。一些Scrum团队将这两部分结合起来。
- 第一部分，Scrum团队处理“做什么”的问题。
产品负责人给团队介绍最高优先级的产品Backlog条目，并一起决定接下来的Sprint中开发什么功能。
Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团 队的能力和以往的表现。
团队自己决定选择多少产品Backlog的条目，因为只有团队可以评估在接下来的Sprint内可以完成什么工作。
选定产品Backlog条目后，Sprint 目标也就明确了。Sprint目标为团队提供指导，使团队明确构建的产品增量的目的。Sprint目标是发布目标的子集。
例如，上一个Sprint的目标可能是：“通过一种安全、可重获的交易中间件实现客户账户修改功能的自动化”。
所以当团队工作时，就会紧记这个目标。为了达到这个目标，团队就需要实现该功能和技术。
- 第二部分，团队需要处理“怎么做”的问题。
在Sprint计划会议的第二个4小时时间箱中，团队需要弄清楚如何将“做什么”会议阶段选定的产品Backlog条目转化成完成的增量。
通常团队会先以设计展开工作，设计过程中，团队确定任务，这些任务就是将产品Backlog转化成可用软件的具体工作。
任务需要被分解，以便在一天之内完成。这个任务列表就是SprintBacklog。
团队通过自组织，并且是自己认领的方式分担任务，任务认领可以在Sprint计划会议上进行，或也可以Sprint中及时（Just-in-time）确定。
通常，Sprint计划会议上只设计出SprintBacklog的60- 70%。剩余部分后续完成，或者给出大体的估算并在Sprint中再分解。
产品负责人会参加Sprint计划会议的第二部分，为团队讲解产品Backlog条目，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商、确定产品Backlog。团队也可以邀请其他人员参加会议，以寻求技术和领域建议。新组建的团队常常在这次会议中第一次意识到：整个团队要么一起成功，要么一起失败，没有个体这个概念。团队同时认识到必须依靠自己。正因为意识到这一点，整个团队才逐渐自组织并形成自己的特色，真正成为一个团队。
在这个会议上，确认迭代包含的Story，这些Story时间、优先级，讲解需求，分配任务，对于成果交付标准达成一致。
1） 开会的时间一般为迭代开始第一上午，会议持续时间大概是8个小时。
2）参会人员：Product Owner、Scrum Master、 开发团队
- 第一，确定团队成员的Capacity， 需要去掉假期、会议的时间，一般8%的会议时间，2个星期大概有一天的开会时间。
- 第二，Product Owner跟团队确定这个迭代需要做的Story、优先级，Product Owner给开发和QA讲解详细的需求。
- 第三，开发团队确定技术框架、根据需求确定技术方案。
- 第四，开发、QA明确需求以后，开始认领任务。
- 第五，团队确定DoD， 统一完成的认识。
4）会议输出
- 第一，规划到迭代的Story条目、优先级、详细时间估算。
- 第二，开发，QA明确需求，确认技术方案。
- 第三，开发，QA认领任务
- 第四，团队Capacity
- 第五，团队完成的共识DoD
开完迭代计划会议，大家就开始进入了项目迭代阶段， 在迭代的每一天，都会开每日站会。
时间箱四：每日站会（Daily Scrum Meeting）
团队每天15分钟的检视和调整会议称之为每日站会。每日站会在各个Sprint都是在同一时间，同一地点进行，因为会议时间很短，通常，会议都是站立进行的。会议上，每个团队成员需要回答以下三个问题：
- 从上次会议到现在都完成了哪些工作？
- 下次每日站会之前准备完成什么？
- 工作中遇到了哪些障碍？
每日站会可以增强交流沟通、省略其他会议、确定并排除开发遇到的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。
ScrumMaster要确保团队举行每日站会，团队则负责召开会议。ScrumMaster指导团队执行规则来控制会议时间，并保证团队成员进行简短有效的汇报。ScrumMaster也要确保“鸡” 的角色不允许在会议上发言或以各种方式干扰会议。
每日站会不是进度汇报会议。这个会议是为那些将产品Backlog条目转化成为产品增量的人（ 团队）召开的。团队承诺实现Sprint目标和完成产品Backlog条目，每日站会对Sprint目标的进展的检视（三个问题）。紧随每日站会之后的一些解决问题的会议通常是对Sprint中的下一步工作进行调整，目的在于增加团队实现目标的可能性。这是Scrum经验过程中的重要检视和调整的会议。
第一，所有的团队成员知道各自的工作进展，这个可以为各自的合作提供基础，比如说前后端合作，开发、QA的合作，这样就不需要等，可以协商进度。
第二，得到问题的列表，这些问题都需要跟进，需要外部资源就需要Scrum Master去协调。
第三，更新任务板，得到最新的燃尽图，这样就知道任务实际运行与计划的差别，进而做出下一步行动。
每日例会需要大家准时参加，同时也必须参加，不能把自己的进度发给Scrum Master， 这样可以同步进度，不能发现问题，解决问题， 同时同事之间的协作如果没有沟通会降低效率。
时间箱五：Sprint评审会（Sprint Review Meeting）
Sprint结束时要举行Sprint评审会议，一个月的Sprint通常对应时长4小时Sprint评审会议。对于时间少于一个月的Sprint来说，该会议的时长不要超过整个Sprint的5%。
Sprint评审会议中，Scrum团队和利益干系人沟通Sprint中完成了哪些工作。然后，根据完成情况和Sprint期间产品Backlog的变化，他们确定接下来的工作。这是一个非正式会议，会议中进行功能演示，以促进下一步工作的互助与合作。
评审会议至少要包含以下因素：产品负责人确定完成了哪些工作和剩余哪些工作。团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。然后，团队演示完成的工作并答疑。产品负责人和与会人员讨论产品Backlog，并根据不同的速率计划出可能的完成日期。接着，整个团体就哪些工作已经完成，同时这对下一步工作有何意义进行探讨。Sprint评审会议为接下来的Sprint计划会议提供了宝贵的参考信息。
当迭代运行到最后一天，需要邀请Product Owner、Scrum Master、 客户开会，对迭代成果进行演示并接受评价，根据反馈结果，提出新的产品Backlog
1） 开会的时间一般为迭代最后一天下午，会议持续时间大概是4个小时。
2）参会人员：Product Owner、Scrum Master、 开发团队、客户、公司高层
- 第一，开发或者QA演示迭代成果，Product Owner检验迭代成果，检查是否完成迭代计划中的迭代目标，并且使用迭代成果。
- 第二，对于迭代的成果提出自己的意见和建议，把这些安排放入到迭代Story里面，更新产品的Backlog
- 第一，迭代成果，如果需要，Product Owner和客户同意，就可以发布了。
- 第二，问题列表，根据问题列表，更新产品backlog
时间箱六：Sprint 回顾会议（Sprint RetrospectiveMeeting）
在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint，回顾会议的长度一般为3小时（一说两小时），在会议上，ScrumMaster鼓励团队在Scrum过程框架和时间的范围内，对自己的开发过程进行改进，使下一个Sprint的效率更高、工作更容易。许多书籍都介绍了召开回顾会议的技巧。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的，和那些如果采用不同方法可以取得更好效果的条目。这些包括：Scrum团队、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。在Sprint回顾会议的最后，Scrum团队应该确定将要在下个Sprint中实现的有效改进方法。这些变化更适应于经验检验。
迭代完成以后，团队检视最近 Sprint 中有关个体、交互、过程、工具和他们的 Definition of Done 的情况如何。对于迭代的工作进行复盘总结，对于团队的工作进行反思，这样才能促进团队的能力提升，效率提升。
1） 开会的时间一般为迭代结束下午，会议持续时间大概是3-4个小时。
- 第一，围绕如下三个问题进行讨论：【a) 本次迭代有哪些做得好；b)本次迭代我们在哪些方面做得不好；c)我们在下次迭代准备在哪些方面改进；】
- 第二，团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。
- 第三，主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的地方以及持续跟踪计划，在会议中不讨论具体问题(如技术方案等)。
- 第一，将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。
- 第二，需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。
项目经理的核心价值观和能力
2184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
