敏捷(一)：敏捷概述
1、可确定的工作与高度不确定的工作
可确定的工作项目具有明确的流程，执行的不确定性和风险通常较低。
高度不确定的项目变化速度快，复杂性和风险也高。
传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。而敏捷方法的出现是为了在短时间内探讨可行性，根据评估和反馈快速调整。
2《敏捷宣言》及思维模式
2.1、敏捷宣言的四大价值观
个体及互动 胜过 过程和工具、可用的软件 胜过 完整的文档、客户合作 胜过 合同谈判、应对变更 胜过 遵循计划。
2.2、敏捷宣言的十二大原则
1、通过尽早持续交付有价值的软件来满足客户的需求；
2、欢迎对需求提出变更，即使在项目开发后期也不例外，敏捷过程善于利用需求变更，帮助可以获得竞争优势；
3、经常交付可用的软件，周期从几周到几个月不等，且越短越好；
4、项目实施过程中，业务人员与开发人员必须始终通力协作；
5、要善于激励项目人员，给与他们所需的环境和支持，并相信他们能够完成任务；
6、信息传达最有效的方法是面对面的交谈；
7、可用的软件是衡量进度的首要衡量标准；
8、敏捷过程倡导可持续的开发。发起人、开发人员和用户应该都够始终保持步调稳定。
9、对技术的精益求精以及对设计的不断完善将提高敏捷性；
10、简洁，即尽最大可能减少不必要的工作；
11、最佳的架构、需求和设计将出自于自组织团队；
12、团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
2.3、敏捷宣言价值观、原则和通用实践的关系
敏捷思维由价值观定义，以原则为指导，并在许多不同的实践中体现。
"敏捷方法"是一个囊括了各种框架和方法的涵盖性术语，指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。敏捷是一个总称。
敏捷方法和看板方法视为精益方法的子集，它们都是精益思想的具体实例，都反映了诸如以下概念：“关注价值”、“小批量”和“消除浪费”。
一般可通过两种策略践行敏捷价值观和原则，一种策略是采用正规的敏捷方法，它们为特意设计，经证明可达成期望的成果；第二种策略是，以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。使用时间盒创建功能，或者使用特定技术迭代优化功能。
最终目标不是为了敏捷而敏捷，而是为了向客户持续交付价值流，并达成更好的商业成果。
2.4、精益与看板方法
将敏捷和看板方法视为精益思想的衍生物。换言之，精益思想是一个超集，与敏捷和看板方法拥有共性。
敏捷与看板的重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持续改善等方面，目标都是为了实现最佳结果。
2.5、不确定性、风险和生命周期选择
项目不确定性的增加，返工的风险和使用不同方法的需求也会增加。为了减轻这些风险的影响，团队选择的生命周期要能够通过较少的工作增量解决项目的大量不确定性问题。
斯泰西矩阵：
使用迭代和增量的方法，在探讨迭代需求、频繁地交付增量时，团队会更容易适应变更，迭代和增量方法减少了浪费和返工。
方法具有的特征：非常短的反馈循环；频繁调整过程；重新进行优先级排序；定期更新计划；以及频繁交付。
通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本探索不确定性，降低风险，最大程度地实现商业价值的交付。
3、敏捷核心实践和原则
3.1、敏捷包括但不限于
在迭代中尽早演示交付的价值；
用户故事反映商业价值和优先级；
客户持续改进；
所有需求的验收测试；
回顾；
可持续的节奏或速度；
沟通；
高度可视化。
3.2、敏捷不包含什么
预先的设计和需求收集
项目完工预测；
死亡行军项目，项目团队为弥补估算差距无偿加班；
强迫使用工具；
自上而下的管理和控制；
大量文件，如状态报告、软件架构图、软件需求规则说明书。
敏捷益处
强调协同合作，团队授权、频繁过程演示；
轻量级，依靠白板，概要卡片和便利性工具；
吸引开发者的开发重点；
更快的上市时间和高优先级特征驱动开发声明周期；
关注，拉而不是推；
容易理解；
满足客户的需要。
4、敏捷里的"3355"-Scrum 角色 工件 活动
SCRUM整体框架视图：3种角色、5个会议、3个工件、5个价值观。
4.1、Scrum概述
Scrum是用于管理产品开发的单个团队过程框架。该框架包含Scrum角色、事件、工件和规则，采用迭代方法来交付工作产品。
4.1.1、Scrum流行的原因
Scrum提供简单和可证明的结果；
包含其他敏捷工程技术；
强调小型团队和团队授权；
欢迎需求变更；
允许单一来源的优先项目工作开展；
Scrum会议包括日常状态会议；
提供团队在冲刺阶段一个潜在的可交付增量承诺。
4.1.2、Scrum三大支柱
透明性：
过程或项目的各个方面必须对结果负责任，透明的；
运用信息发射源，让关键信息，如产品待办事项列表、冲刺待办事项、障碍、风险和项目进展对所有的利益相关者是透明的。
检视：
团队根据项目目标定期检查他们的绩效和进展；
不断寻找问题和计划的偏离。
调整：
基于观察期间的检查，采取必要的变更流程，避免问题再次放生，提高项目交付成功率。
4.2、Scrum角色
Scrum团队由5到9个团队成员组成。有三种类型角色：
产品负责人(PO)：产品负责人定义项目愿景、需求和优先级，对产品成功负责；
Scrum Master：负责团队、并移除障碍，帮助他们实现产品负责人所设定的目标；
开发团队：自组织、跨职能。协同工作，以确定如何最好的满足产品负责人的目标。
团队中有"鸡"和"猪"的角色，猪的角色包括scrum master、PO、team；"鸡"的角色是指团队成员以外的管理角色。
4.2.1、产品负责人
清晰的表达产品待办列表项；
对产品待办列表项进行排序，最好的实现目标和使命；
优化开发团队所执行工作的价值；
确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum团队的下一步工作；
确保开发团队对产品待办列表项有足够的理解。
4.2.2、Scrum Master
负责确保所有人都能正确的理解并实施Scrum，Scrum Master要确保Scrum团队遵循Scrum理论、实践和规则。
Scrum Master是服务型领导，帮助团队外的人员了解他们如何与Scrum团队交互是有益的。通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。
Scrum Master在期望设定和管理中扮演重要角色，以此创建高绩效团队。
Scrum Master职责：
在项目声明周期早期定义基本规则；
确保团队理解干系人期望；
同团队沟通项目愿景，有利于确保团队；
认识到他们的目标同项目总目标紧密一致；
以连贯的单元模式工作；
对愿景给予承诺。
Scrum Master制定的基本规则：
设定Scrum仪式的开始-结束时间；
保持对主题的专注减少分数；
会议期间杜绝中断；
允许团队成员特别是初级成员的言论自由；
在制定决策前应广泛搜集所有成员意见。
4.2.3、团队
有自主权选择如何最好的满足目标，并且为之负责。
4.3、Scrum三个工件
Scrum的工件以为不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调整的机会。
Scrum中的工件就是为了最大化关键信息的透明性。
4.3.1、产品待办列表(Product Backing)
产品需求列表；
产品负责人对该列表进行优先级排序；
待办事项列表中的条目以用户故事的形式呈现。
4.3.2、Sprint待办列表
产品待办列表的子表，只记录当前迭代的工作；
将用户故事拆分成任务，团队成员主动领取任务；
团队成员可以添加、删减或者更改迭代中任务。
4.3.3、产品增量
团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付；
每次交付的用户故事必须符合验收条件。
4.4、Scrum会议(5个会议)
4.4.1、冲刺计划会议
Scrumm团队的所有成员出席，在此次会议中，开发团队识别当前冲刺开发交付的产品待办事项中的故事。
会议时间箱：一个月的冲刺，会议时间8小时，4个小时用于选择故事和4个小时估算分配。
4.4.2、每日站立会议
由Scrum Master和开发团队参加，产品负责人可以自行选择是否参加。
每日战力会议是快速专注的会议，用来分享迭代或迭代进展。
每个团队成员就各自将要完成的任务对其他人做口头承诺。
会议内容：
昨天做了什么、今天将做什么，遇到了什么问题。
每日立会，只有猪的角色可以发言，鸡的角色不可以发言。
会议时间建议15分钟，每天同一时间同一地点。
4.4.3、冲刺评审会议(review)
由Scrum团队的所有成员参加。
开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。
Sprint评审会议的结果是一份修订的产品待办列表，确定很可能进入下个Sprint的产品待办列表项。
这个会议时间箱为一个月的迭代，4个小时，比冲刺计划会议的持续时间更短。
冲刺评审是在迭代末期进行的时间盒(有指定时间限制)会议，此时不断变化的解决方案展示给利益相关者，反馈得到收集。
该会议是：
针对冲刺末期召开；
被时间盒定义到四个小时，按月冲刺和较短的时间段；
冲刺评审会议由包括开发团队、产品负责人、Scrum Master，和企业的利益相关者的整个团队出席；
冲刺评审会议被团队通过录音、快照来展示产品。
冲刺评审的益处
进行常规冲刺评审会议有助于，产品根据利益相关者的需要在变化；任何反馈或升级在即将到来的冲刺或发布中被记录和强调；优先级排序的待办事项将被展示给利益相关者去评估是否能够满足他们的期望；逐步完善未来的项目计划。
冲刺评审的重要性
在一个2周冲刺的项目中，没有组织冲刺会议将导致项目进度落后于整整一个月，因为：
开发的需求没有满足利益相关者的期望；
为即将到来的冲刺所选择的需求，没有同利益相关者的需求保持一致。
4.4.4、冲刺回顾会议
Scrum团队所有成员参加，会议的焦点是对整个迭代进行回顾。团队就未来的迭代改进计划达成一致，会议时间框为一个月的迭代，3个小时，比迭代评审时间短。
所有的会议都会在每次迭代中重复。
冲刺回顾是针对迭代末期进行的时间盒(有指定时间限制)会议，目的是认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议：
针对冲刺末期召开；
被时间盒定义到3 ~ 4 个小时按月冲刺和较短的时间段；
由包括开发团队，产品负责人、ScrumMaster，和企业的利益相关者的整个团队出席；
在冲刺回顾中，团队将识别到他们做的好的领域以及有待改进的领域；
来自于回顾会议的反馈对实施持续改进策略和最大团队交付价值。
4.4.5、待办事项梳理
Scrum团队在冲刺中经常会面进行待办事项的梳理。
梳理和细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。该会议有助于：
增加新用户故事；
丢弃不相关的用户故事；
估算新增加的用户故事；
重新估算用户故事；
对用于故事进行优先级重排序；
史诗分解成更小的用户故事。
关键点：
梳理会议提供了调整估算范围的最佳时机；
利益相关者的期望通过对产品待办事项与时俱进的更新来管理；
已经完成优先级排序和更新的产品代办事项应该作为冲刺评审会议的一部分由利益相关者来评审；
来自于运营和维护问题的反馈需要被考虑，新需求必须添加到产品待办事项中；
识别出现有缺陷经过分析后，需要确保他们在梳理会议上被讨论。
5、敏捷中的术语
5.1、敏捷教练
掌握敏捷知识和经验人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。敏捷教练可以1是内部教练或外部教练，教练需要：
1、根不同团队共事时需要平衡视角，每个团队具有不同的进展节奏；
2、终于团队成员价值；
3、认识社会心理及团队复杂性；
4、开发方法进行非侵入型干预从而改变团队动力；
5、运用有效方法解决团队面临的问题；
6、学习真正需要什么才能让人们作为一个团队去工作。
5.2、仆人式领导
仆人式领导是一种团队赋权的方法，仆人式领导是通过对团队服务来领导团队的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
仆人式领导的作用是促进团队发现和定义敏捷，仆人式领导实践并传播敏捷。
仆人式领导按以下顺序从事项目工作：
1、目的
与团队一起定义目的，以便它们能1围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化。
2、人员
目标确立后，鼓励团队创建一个人人都能成功的环境。要求每个团队成员在项目工作中做出共享。
3、过程
不要计划遵循"完美"的敏捷过程，注重结果，若跨职能团队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。
4、特征
仆人式领导的特征：
提升自我意识；
倾听；
为团队服务；
帮助他人成长；
引导与控制；
促进安全、尊重与信任；
促进他人精力和才智提升。
5.3、优先级技术
5.3.1、MoSCoW技术
MOSCow技术是进行需求优先级排序的敏捷方法，需求基于以下方面进行排序：
Must：必须有，强制性需求；
Should：应该有 - 需求不强制，高度渴望；
Could：可以有 - 需求被满足会很好；
Won't：不会有 - 当下可以不去满足，将来可以加入。
在开始一轮时间箱前，会有一个新的Musts加入，这些可能是新的需求，或者现有需求被调整优先级进而转移称为Musts。
5.3.2、卡诺模型
根据产品属性及用户满意度来判断优先级。魅力属性 ....
5.3.3、权重
商业、效益等分析判断优先级。
5.4、Kanban 看板
看板在项目实施期间作为信息发射源运用，有助于相关干系人去了解冲刺或迭代的当下状态。
5.4.1、看板是一个跟精益和及时制生产相关的概念
任务被细分成断来反射关键活动；
故事是由索引卡或代表的便利贴来表示；
卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化；
看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。
5.4.2、kanban卡片
Kanban任务板上的每一张卡片就是kanban卡片；
Kanban卡片用来显示迭代过程；
Kanban任务板上的卡片呈现在开发周期的不同环节中移动的工作部件；
Kanban卡片反映所有需要被跟踪的事务；
在用户故事定义完整前，先关干系人需要对用户故事必须经历的部分进行评估。
5.4.3、简化的看板面板
简化的看板面板有3例：待完成、进展中、已完成。
任务卡片表示，卡片状态展示在其中一列的下方：
5.5、五问法
五问法是一种通过不断重复询问为什么来识别问题根据原因的技术。每个为什么的答案成为下一个为什么的驱动力。
确切来说，不是强制的使用五个为什么来什么到问题的根源，"五"只是一个指示性的数字。这种技术同鱼骨图结合起来使用提供一个问题解决可视化过程。
5.6、DoD 完成的定义
团队需要满足所有标准的核对单，只要可交付成果满足核对单才能视为准备就绪可供客户使用。
5.7、MVP
最小可交付价值；
最小可售单元；
最小可行性产品。
5.8、WIP(在制品)
在敏捷开发中，WIP限制决定了每种情况下的工作流可存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续交付通道中的瓶颈很容易辨别。
WIP限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少"将要完成"的工作量。
WIP限制鼓励的是 完成 文化，WIP限制可以让阻碍和瓶颈显而易见。
当有明确指示现有工作遇到瓶颈时，团队可聚焦在阻塞问题上尽快的理解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优化确保在最短时间内向用户交付有价值的增量，从而使得WIP限制称为敏捷开发中一个非常有价值的工具。
5.9、用户故事
