1. 何为敏捷
敏捷是基于一种不确定性较高，未来环境难以预测的背景下产生的一种管理理念，这种理念并不意味着应该丢弃传统的管理方法中的一些方法而是应该以快速传递价值给客户为目标进行管理，只要某个方法能加速我的价值传递就应该使用。
敏捷宣言
- 个体和互动高于流程和工具；
- 工作的软件高于详细的文档；
- 客户合作高于合同谈判；
- 响应变化高于遵循计划。
以上价值观并不是右边不重要，而是认为左边更重要。
十二原则
客户为主：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
拥抱变化：欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
短迭代交付：要不断交付可用的软件，周期从几周到几个月不等，且越短越好
业务参与：项目过程中，业务人员与开发人员必须在一起工作。
以为人本：要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
面对面沟通：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
成功导向：可用的软件是衡量进度的主要指标。
保持节奏：敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
追求卓越：对技术的精益求精以及对设计的不断完善将提升敏捷性。
简单务实：要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
团队自组织：最佳的架构、需求和设计出自于自组织的团队。
持续改进：团队要定期反省如何能够做到更有效，并相应地调整团队的行为
2. 敏捷生命周期
预测型——类似传统的瀑布型
迭代型与增量型
敏捷型
四种生命周期的区别
3. 敏捷团队
自组织
大量个体基于简单规则的互相作用，无需中央调控，能够涌现出整体上的新秩序
组建高绩效团队
主要特点
具备合适技能和积极性的人员
主要特征
敏捷教练——仆人式（服务式）领导
特点
职责
敏捷团队激励
马斯洛需求理论
金字塔五层：生理需求、安全需求、爱与归属 的需求、自尊需求、自我实现需求。只有低层次满足了才会产生高一层级的需要
赫兹伯格双因素理论
激励因素：来自工作条件本身，能带来满意、成就，例如：重视、成就、个人成长
保健因素：是必须的但是不能给予激励，缺少它会导致不满意，例如：地位、工作安全、薪水等
敏捷项目团队需要保健因素去建立最低水平的团队绩效。同样，激励因素决定团队是否能实现高绩效
大卫动机理论
| 主要激励因素 | 对应类型人的特征 |
| 成就 | 愿意承担可能的风险去完成目标 |
| 社交 | |
| 权力 |
4. 敏捷实践
精益软件开发（LSD）
精益 7 原则
极限编程（XP）
一种基于频繁交付周期的软件开发方法，一种开发哲学，基于以下五大价值观
测试驱动开发（ADD）
Scrum
Scrum流行的原因
三大角色
产品负责人——告诉团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理
Scrum Master——引导团队建立团队规则，维护团队和指导团队外部成员遵守团队规则，移除团队障碍
开发团队——执行冲刺，包括：每日检视和调整、梳理产品列表、冲刺规划、检视和调整产品与过程
三大工件
产品待办列表：一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源
冲刺待办列表：一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划
产品增量：一个Sprint完成的所有产品待办列表的总和，以及之前所有Sprint所产生的增量的价值总和
五大会议
产品待办事项梳理——为即将到来的冲刺做准备，并对事项进行分解和估算
每日站立会议——检查冲刺目标的进度，并检视完成冲刺待办列表的工作进度趋势
冲刺评审会议——产品负责人说明待办项列表的完成和未完成；开发团队讨论冲刺期间做得好的、碰到的问题及解决方法
冲刺回顾会议——Scrum团队检视自身并创建下一个Sprint改进计划的机会
Scrum实施流程
5. 敏捷工具
用户画像
PERSONA七要素
P代表基本性(Primary)：指该用户角色是否基于对真实用户的情景访谈；
E代表同理性(Empathy)：指用户角色中包含姓名、照片和产品相关的描述，该用户角色是否引同理心；
R代表真实性(Realistic)：指对那些每天与顾客打交道的人来说，用户角色是否看起来像真实人物；
S代表独特性(Singular)：每个用户是否是独特的，彼此很少有相似性；
O代表目标性(Objectives)：该用户角色是否包含与产品相关的高层次目标，是否包含关键词来描述该目标；
N代表数量性(Number)：用户角色的数量是否足够少，以便设计团队能记住每个用户角色的姓名，以及其中的一个主要用户角色；
A代表应用性(Applicable)：设计团队是否能使用用户角色作为一种实用工具进行设计决策
可以用来克服项目成员在产品开发过程中的若干难题
需求分析阶段：确定产品功能以及用户行为的优先级，辅助场景设计，让产品更为聚焦。
产品设计阶段：协助与项目成员以及利益相关者进行沟通交流，就设计意见达成共识和承诺。提高设计效率。
用户调研阶段：许多其他的用户研究环节对于用户的招募以及研究内容确定都需要依据persona。
产品策略阶段：明确市场推广方向、预估市场规模，更准确地为产品做决策以及定位市场
用户故事
三要素
3C原则
交谈（Convertsation）：用户故事背后的细节来源于和客户或产品负责人的交流沟通
确认（Confirmation）：通过验收测试用户的故事被正确完成
六个特性-INVEST
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的
确定用户故事优先级
相对优先级=价值/工作量 估算每个故事的价值和工作量，计算相对优先级。
应该有（Should have）：很重要但是短期内有替代方案的功能，如果没有时间约束，此类功能是强制性的
可以有（Could have）：没有时间就可以在发布中不予考虑的功能
卡诺Kano模型：有时候基础型需求部分实现就可以了，尽可能多的完成期望型需求，确定少量兴奋型需求。
估算——对交付计划产品所需要的成本、进度、投入或者技能进行的预测
敏捷估算基础
估算让团队可以了解项目规格，计算ROI和IRR，形成项目执行许可的基础。
敏捷团队基于产品负责人的投入来估算需求，Scrum Master进行保守估算。
敏捷估算在整个项目期间进行。在项目逐步完善中更多信息出现，团队定期评估新需求。
准确性和精确性
敏捷估算致力于准确性而非精确性，因为实现精确性让估算过程拉长并且昂贵
故事点：描述一个用户故事及其相关努力总体规模的测量单元
- 任务规模-故事规则取决于以下因素：复杂性、投入量、风险大小
- 相对价值-故事点是规模的相对测量，绝对值不是很重要。
- 估算-估算运用基准来完成，相对值被运用。
- 选取最小故事估算价值为一个故事点。
- 选取中等规模故事分配5个故事点。
故事点估算的步骤
- 用户故事拆分为更小的功能，并确保每个故事具有投资属性。理想情况下，每个故事应该由1个人占用不超过2天的时间完成。
- 确定团队达成共识的故事作为基线，创建它的故事点价值。
- 将所有其他故事卡片同基线故事对比。
- 每次迭代末期，将故事点同故事卡片上记录的校准。
- 故事点之类比估算故事点估算可以通过对比来有效完成
估算规模敏捷评估旨在合理预测估算，不追求精确
宽带德尔菲
- 团队选择：选择负责估算的专家团
- 启动会议：计划启动会议去说程序和落地规则
- 个人准备：允许团队成员针对每个任务个人收集初始估算
- 估算会议：实施一系列迭代步骤组成的估算会议
- 配置任务：收集个人估算，编译最终清单
- 任务评审：评审估算程序、最终任务清单和假设的结果
- 每个团队成员收到有编号的卡片，如果需要数字可以延伸；
- 产品负责人朗读每个故事卡片并回答团队问题；
- 每个团队成员评估故事所需投入以及运用相对尺码给故事分配点；
- 当Scrum Master要求时，每个人必须同时举起写有他们估算的数字卡；
- 如果这里有差异，团队成员要解释估算偏高或偏低的原因；
- 讨论后，团队成员重新估算直到达成一致
2418
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
