来源:网络 作者:佚名
敏捷基础知识
敏捷开发是一个灵活的开发方法，用于在一个动态的环境中向干系人快速交付价值。其主要特点是关注的持续的交付价值，通过迭代和快速用户反馈管理不确定性和拥抱变更。
敏捷概念
敏捷核心思维
• 价值驱动-关注高优先级目标、要事
• 适应变化-频繁的交付可见成果，频繁确认，确保交付正确的成果
• 自组织团队-目标驱动、共享责任
敏捷宣言
• 个体和交互 重于 过程和工具（Individuals and interactions over processes and tools）
• 可用的软件 重于 完备的文档（Working software over comprehensive documentation）
• 客户协作 重于 合同谈判（Customer collaboration over contract negotiation）
• 响应变化 重于 遵循计划（Responding to change over following a plan）
虽然右项也具有价值，但我们认为左项具有更大的价值。
更进一步的解读参见：
敏捷宣言遵循的原则
我们遵循以下原则：
• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自自组织团队。
• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
Scrum的价值观
• 承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。
• 专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。
• 公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。
• 尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。
• 勇气：（最缺的）我们需要勇气去迎接各种挑战，以及有足够的勇气去说NO。
更多敏捷知识可参见Scrum中文网
敏捷开发流程
强调事项
核心角色
• Product Owner负责敲定要开发什么、以什么顺序开发
• Scrum Master负责指导团队在通用的Scrum框架上建立并遵循自己的过程
• 开发团队负责确定如何交付Product Owner要求的产品
01、ProductOwner
PO的职责：
• 确定产品的功能，为团队澄清产品需求
• 决定发布的日期和发布内容
• 为产品的profitability of the product (ROI)负责
• 根据市场价值确定功能优先级
• 每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）
• 根据验收标准，接受或拒绝接受开发团队的工作成果
02、ScrumMaster
ScrumMaster的核心职责：
• 保证团队资源完全可被利用，并且全部是高产出的；
• 和Product Owner紧密地工作在一起，及时地为团队成员提供帮助；
• 肩负在团队中的敏捷推广工作，让团队按照敏捷的做法来运作，保证开发过程在Scrum框架下按计划进行；
• 维护和提高团队士气和氛围，保证各个角色及职责的良好协作；
• 协调解决团队开发中的障碍；
• 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
对于任职SM，我们希望你具备以下特征：
• 对敏捷感兴趣，能够主动进行敏捷推广，有意愿在敏捷领域深入发展；
• 主动性强，积极承担相应职责，并努力做到最好，不等不靠；
• 沟通影响力强，敢于发表个人意见和提问，能够有效影响他人观点；
• 执行力强，能够推动事情落地，并及时解决问题。
Scrum Master需要保持警惕的几件事
• 在Scrum的推行过程中，Scrum Master是团队的保护者，也是团队严格、认真遵循Scrum流程、实践和原则进行开发的教练。
• 欣然面对需求变化，即使在开发后期也一样。
• 遗留的用户故事
有时候，在一个迭代结束时，某个用户故事只完成了一部分，这样的用户故事被称为“遗留故事”。这是前次迭代没有完成的工作，通常会被自动添加到下一个迭代中，继续开发。但千万别这么做。
• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
对客户来说，在上一次迭代进行中，Product Backlog中的最有价值需求可能会发生变化。在上一次迭代中被认为是最有价值、优先级高的需求，随着外部环境的变化，可能会出现变化而降低了价值和优先级。如果我们自动将这些未完成的工作放入下一次迭代，有可能我们所做的工作并不是最有价值、优先级高的需求。
Scrum中，Product Owner的责任之一是维护Product Backlog，确保Product Backlog中的用户故事，都是经过了严格、认真的评估，是已经按照对客户的价值高低而拍好了顺序和优先级的。
所以，对于前次迭代没有完成的故事，Scrum Master要鼓励团队对未完成的用户故事进行分析，从中找出没有完成的原因，并在回顾会议中进行分析，拟定改进措施。同时，要从中学会如何在单次迭代中完整地完成用户故事，而不是只完成一部分。
Scrum Master要确保这些用户故事被重新放入Product Backlog，和Product Owner一道，对这些用户故事重新进行价值评估并排序。这样，下一次迭代规划时，团队拿到的就是一份完整的、经过了价值评估的、排好了顺序和优先级的Product Backlog。因而，下次迭代选中的工作，也都是对用户最有价值的需求。
当用户故事只是部分完成了但其优先级仍然是最高的，可以基于剩余的工作，对用户故事重新估算。基于团队的“速度”来决定团队在单次迭代中到底能完成多少工作，而不是只完成一部分。
• 迭代期间出现变化
通常情况下，迭代期间出现的变化与“范围蔓延”类似，因而处理措施也基本相同。Scrum Master务必要竭尽所能地与Product Owner 就迭代期间如何完成用户故事达成一致，确保团队不受外界干扰。
项目进行期间，务必要避免出现大规模、批量的需求变更。出现这样的变更，肯定会影响整个迭代进程。那最好的处理措施可能就是，立刻停止当前的迭代，重新审视、梳理Product Backlog。该增加新故事就增加，该删除无效故事的就删除。等整个Product Backlog重新梳理完成后，重新开始迭代开发。
Scrum Master一定要确保，团队当前手头的工作，对客户来说，是最有价值、优先级最高的。
• 软件缺陷
发现软件缺陷（Defect、Bug）是不可避免的。
当在在线系统中发现缺陷时，要立刻停掉手头的工作，优先修复软件缺陷。直到发现的缺陷修复了之后，再继续之前的工作，或者开始新的工作。
当修复了缺陷之后，还有做两件事情：
其一，进行一次根本原因分析，以确定这些缺陷是如何从最初的工作中遗漏出来的。这种缺陷在PMI-ACP中被称之为遗漏缺陷，又称逃逸缺陷。
其二，对当初的工作疏忽或不足进行改进，以弥补工作中的漏洞，避免同样或类似的缺陷再次出现。
敏捷团队并不以延长工作时间而获得更多产出，我们时刻聚焦于软件质量，以减少不必要的重复、返工的数量而提高生产率。但发现软件缺陷时，我们要立刻修复缺陷。如果某个用户故事还有很多已知的缺陷没有修复，那最好不要把这样的用户故事算作完成。如果团队低估了完成工作所需要的时间，Scrum Master要确保在迭代回顾的时候，团队对此进行讨论，并切实采取措施避免同样或类似的事情再次发生。
• 迭代气味
同很多事物一样，但出现不期望的事情时，一定有很多这样或那样的征兆。我称这些异样的征兆为迭代气味，或者更直观地，迭代臭味。这些现象可以通过观察团队的每日站会（我称之为每天碰头会）而清晰地识别出来。
• 有团队成员缺席会议。每日站会是团队的会议，每个人都应该出席。
• 重复任务。当每日站会上，uimaker，问那三个经典问题时，如果某个人每天的答案都是一样的话，那一定有问题，Scrum Master需要对此做一番调查。如果一名团队成员在某个任务上被block了，这个团队成员应该尽快寻求帮助。其他团队成员应该尽快帮助他解决问题。敏捷开发中，团队是一体的，是一损俱损、一荣俱荣的。
• 没有提出问题。如果每日站会上，团队没有提出什么障碍、问题，这时Scrum Master也要特别注意，尤其是当团队的燃尽图显示毫无进展时。
• 每次提出的问题都一样。与上述类似，如果一天又一天，团队提出的问题都一样时，Scrum Master就需要特别留心了。
• 领导安排任务。敏捷团队是自组织的团队。千万不要让领导或项目经理为团队成员安排任务，哪怕只有一次。
• 领导管理团队。与上面类似，团队需要领导来管理时，Scrum Master就一定要出面干预了。敏捷团队应该管理他们自己。
• 工作角色过于明确、行动起来不像个团队。如果某个团队成员提出了一个问题，而其他成员觉得这不是自己或者团队的问题。Scrum Master这时候要进行干预。敏捷团队是一个完整的集体，集体、共同为完成交付目标而责任均担。
总结
我们已经讨论了敏捷团队经常出现的几种现象，Scrum Master需要对这些现象格外留心，如果真的出现，要及时采取措施。
• 范围蔓延
• 遗留故事
• 迭代期间的项目变化
• 软件缺陷
• 迭代臭味
原文出处可参见：
03、开发团队
团队的职责：
• 一般由3-9个人组成的多样化跨职能团队，每个人都参与产品的设计、构建和测试
• 进行自我组织，确定采用哪种最佳方式来实现目标，共同决定如何规划、管理、执行和沟通工作
• 在项目向导范围内有权利做任何事情以确保达到Sprint的目标。
• 团队成员构成在sprint内不允许变化。
• 迭代规划
• 参加Sprint计划会，与ProductOwner共同确定迭代目标
• 将产品特性分解为一系列经过估算的任务，为达成迭代目标制定实施计划
• 每日检视和调整
• 参加每日站会，共同检视迭代目标的进展情况，
•根据当天工作情况调整计划
• 检视和调整产品与过程
•参加Sprint评审会，向PO和干系人演示当前迭代完成的产品成果，用来指导下一步的计划
•参加Sprint回顾会，检视和调整自己的Scrum过程
