敏捷方法强调适应而非预测

敏捷宣言：

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

敏捷十二个原则

极限编程XP

scurm：产品backlog、计划会议、master、owner、站立会议等。

团队组织与管理

人力资源规划：识别和记录项目角色、职责、所需技能以及报告关系，并编制人员配备管理计划的过程；

项目团队建设：根据项目人力资源规划，通过有效手段获得项目所需人员，组建项目团队的过程；

项目团队建设：提高工作能力、促进团队互动和改善团队氛围，以提高项目绩效的过程；

项目团队管理：跟踪团队成员的表现，提供反馈，解决问题并管理变更，以优化项目绩效的过程。

人员的选择

应该考虑团队中的技术、经验和个性是否整体均衡；

选择性格互补的成员组成的团队可能比仅仅根据技术能力选择成员的团队更有效率；

团队的领导力来自于成员的尊重，而不是名义上的头衔；

团队的概念

团队是由若干人组成的一个整体，他们具有互补的技能，对一个共同目的、绩效目标及方法做出承诺并彼此负责。

设定具有挑战性的团队目标；

营造一种支持性的环境（沟通交流、团队学习）；

团队成员的自豪感；

让每一位成员的才能与角色相匹配；

正确的绩效评估；

绩效评估是通过对团队成员工作绩效的考核与评价，反应团队成员的实际能力和业绩以及对某种工作职位的适应度。多维度，多维评价体系。

项目沟通管理

沟通是为了达到一定的目的，将信息、思想、情感在个体或群体之间进行传递或交流的过程。

沟通是为了交换有价值的信息和获得对方的理解支持。

沟通是你被理解了什么而不是说了什么。

Brooks法则：向一个进度延迟的软件项目增加人员可能会使其进度更加延迟。

口头沟通：谈话、讨论、演讲、汇报、谈判、会议等

肢体语言：面部表情、手势、眼神、姿态、仪表等

书面沟通：合同、报告、会议纪要、报表、备忘录、便条等

电子沟通：电话、email、bbs、blog、即时通讯、协作工具等

项目沟通管理是为了确保项目信息及时且恰当地收集和传递，对项目信息的内容、传递方式和传递过程等进行的管理活动。

项目团队内部的沟通：职责、协调、状态、授权；任务分配清晰。项目启动会、成员进度汇报会、项目进展会；设置沟通期望；及时、公开、恰到好处。

与管理层和客户的沟通：和谁进行沟通，为什么沟通；需要什么类型的信息；详尽程度和频率如何；沟通的目标是什么；采用何种方式沟通比较好。

项目启动会议（至关重要）

目标：项目概况（范围与目标、总体进度、方法和程序）；确定项目人员的角色和任务；确立团队的工作模式。

形式：重大项目（精心准备、集中1-2天；前期介绍与建立基本规则）；一般项目（简单有效；回顾项目范围与成员相互自我介绍）。

建立基本规则：计划决策、追踪决策、管理变动决策、关系决策。

项目计划会议（通常在每一阶段开始时）

制定当前阶段的项目计划；将工作任务明确分配给项目成员

项目阶段进展会议（每月或每季度一次）

向项目干系人和高层管理者汇报项目进展；解决需要高层管理者支持的问题

项目组工作例会（每日或每周一次）

通报项目组成员的工作进展；了解成员在工作中遇到的困难，并寻找资源解决；确定后续的工作计划。

scrum团队角色

产品负责人：定义产品需求；确定产品发布计划（时间+内容）；对产品收益负责；确定需求优先级；调整需求和优先级；验收迭代结果。

Scrum主管：直接管理项目（明确任务状态和变化）；帮助团队定制冲刺计划；组织每日站立会议等会议；引导团队正确应用敏捷实践；确保团队功能完备富有效率；促进团队紧密协作；排除团队遇到的障碍；保护团队不受打扰。

团队：一般5-9人；团队是跨职能的；成员是全职工作；自组织和管理；合作完成冲刺开发工作；保证每一次冲刺的成功。

自组织团队：团队被授权自己管理他们的工作过程和进度，并且团队决定如何完成工作：

团队决定谁做什么，即任务的分配；

团队决定如何做，如何实现目标，即团队做技术决策；

团队需要在确保目标的前提下制定团队内的行为准则；

团队有义务保持过程的透明性；

团队监督和管理他们的过程和进度；

scrum制品

产品订单product backlog：是从客户价值角度理解的产品功能列表：动态演变的。

功能、缺陷、增强等都可以是产品订单项；

整体上从客户价值进行优先级排序。

·优先级、风险和利益

迭代订单sprint backlog：是从开发技术角度理解的迭代开发任务：

简单环境：可直接把产品订单项分配到迭代中；

负责环境：可把一个产品订单项分为web/后台…硬件/软件…程序/美工…等开发任务。

可工作产品working software：是可交付的软件产品

可交付应视不同情况提前设定和选定交付标准；

正式产品可能包括使用文档，在新产品开发初期可能只需要交付勉强看到效果的产品。

用户故事：作为用户，从用户角度去理解的产品。

任务白板：晴雨表。

燃尽图：反应剩余工作量和时间的关系

scrum活动

迭代计划会议sprint planning：选择和估算本次迭代的工作项：需求分析+框架设计

每日战力会议daily scrum meeting：日常评估每日工作，更新任务版和燃尽图

上次例会后完成了什么；遇到了什么困难；下次例会前计划做什么。

迭代评审会议sprint review：向最终用户展示迭代的工作成果：有团队展示有可能发布的产品增量；允许所有参与者尝试由团队展示的新功能；用户对团队演示的产品功能进行反馈。

迭代回顾会议sprint retrospective：反思迭代；畅所欲言；关注1-3个关键问题；跟踪闭环。

scrum规划

发布规划：

定义用户故事并进行优先级划分；

估算规模以及评估团队开发速度；

制定发布计划；

迭代规划：

确定迭代目标并选择用户故事；

将用户故事分解和细化到任务；

对故事和任务进行时间估算；

用户故事：从用户角度对功能的简要描述

格式：作为一个<角色>，可以<活动>，以便于<价值>

角色：谁要使用这个功能

活动：需要执行什么操作

价值：完成操作后带来什么好处

独立性：避免故事之间存在依赖

可协商：不必须实现书面合同或者需求

有价值：对客户用户有价值

可估算：可预测故事的规模，估算开发时间

短小：10个理想人天内可完成，至少在一个迭代内完成

可测试：

敏捷估算：

故事点：相对度量单位

理想时间：绝对度量单位：一般为有效工作时间的60-80%