设计师应该拥有的敏捷思维

敏捷基础知识

敏捷开发是一个灵活的开发方法，用于在一个动态的环境中向干系人快速交付价值。其主要特点是关注的持续的交付价值，通过迭代和快速用户反馈管理不确定性和拥抱变更。

敏捷概念

敏捷核心思维

• 价值驱动-关注高优先级目标、要事

• 适应变化-频繁的交付可见成果，频繁确认，确保交付正确的成果

• 自组织团队-目标驱动、共享责任

敏捷宣言

• 个体和交互 重于 过程和工具（Individuals and interactions over processes and tools）

• 可用的软件 重于 完备的文档（Working software over comprehensive documentation）

• 客户协作 重于 合同谈判（Customer collaboration over contract negotiation）

• 响应变化 重于 遵循计划（Responding to change over following a plan）

虽然右项也具有价值，但我们认为左项具有更大的价值。

更进一步的解读参见： http://www.tuicool.com/articles/ziqIN3Y

敏捷宣言遵循的原则

我们遵循以下原则：  

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

• 可工作的软件是进度的首要度量标准。

• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

• 以简洁为本，它是极力减少不必要工作量的艺术。

• 最好的架构、需求和设计出自自组织团队。

• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

Scrum 的价值观

• 承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。

• 专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。

• 公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。

• 尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。

• 勇气：（最缺的）我们需要勇气去迎接各种挑战，以及有足够的勇气去说NO。

问：敏捷开发中需求方和Product Owner是同一定义吗？通过敏捷的学习，发现不断会出现以下几个名词：需求方，业务方，PO，SM，ST，TL，这6个角色之间是否有重叠？

答：需求方和业务方比较类似，都是需求的发起方，属于业务方面的；

PO（Product Owner），SM（Scrum Master），ST（Scrum Team） 敏捷团队的三个角色；

TL（Tech Leader）本身就是 ST（Scrum Team）中的一员。

敏捷开发流程

强调事项

问：开发人员完成功能开发并自测后，是先交由测试人员测试，测试人员测试通过后，po来验收，还是po先对功能做基本验收，再交由测试细测？

答：这两个本身不冲突，可以在测试人员测试的环境上就同时在验收，建议先多基本功能验收，再交测试细测。

核心角色

• 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要确保在迭代回顾的时候，团队对此进行讨论，并切实采取措施避免同样或类似的事情再次发生。

• 迭代气味

同很多事物一样，但出现不期望的事情时，一定有很多这样或那样的征兆。我称这些异样的征兆为迭代气味，或者更直观地，迭代臭味。这些现象可以通过观察团队的每日站会（我称之为每天碰头会）而清晰地识别出来。

• 有团队成员缺席会议。每日站会是团队的会议，每个人都应该出席。

• 重复任务。当每日站会上，问那三个经典问题时，如果某个人每天的答案都是一样的话，那一定有问题，Scrum Master需要对此做一番调查。如果一名团队成员在某个任务上被block了，这个团队成员应该尽快寻求帮助。其他团队成员应该尽快帮助他解决问题。敏捷开发中，团队是一体的，是一损俱损、一荣俱荣的。

• 没有提出问题。如果每日站会上，团队没有提出什么障碍、问题，这时Scrum Master也要特别注意，尤其是当团队的燃尽图显示毫无进展时。

• 每次提出的问题都一样。与上述类似，如果一天又一天，团队提出的问题都一样时，Scrum Master就需要特别留心了。

• 领导安排任务。敏捷团队是自组织的团队。千万不要让领导或项目经理为团队成员安排任务，哪怕只有一次。

• 领导管理团队。与上面类似，团队需要领导来管理时，Scrum Master就一定要出面干预了。敏捷团队应该管理他们自己。

• 工作角色过于明确、行动起来不像个团队。如果某个团队成员提出了一个问题，而其他成员觉得这不是自己或者团队的问题。Scrum Master这时候要进行干预。敏捷团队是一个完整的集体，集体、共同为完成交付目标而责任均担。

总结

我们已经讨论了敏捷团队经常出现的几种现象，Scrum Master需要对这些现象格外留心，如果真的出现，要及时采取措施。

• 范围蔓延

• 遗留故事

• 迭代期间的项目变化

• 软件缺陷

• 迭代臭味

03、开发团队 

团队的职责：

• 一般由3-9个人组成的多样化跨职能团队，每个人都参与产品的设计、构建和测试

• 进行自我组织，确定采用哪种最佳方式来实现目标，共同决定如何规划、管理、执行和沟通工作

• 在项目向导范围内有权利做任何事情以确保达到Sprint的目标。

• 团队成员构成在sprint内不允许变化。

• 迭代规划

• 参加Sprint计划会，与ProductOwner共同确定迭代目标

• 将产品特性分解为一系列经过估算的任务，为达成迭代目标制定实施计划

• 每日检视和调整

• 参加每日站会，共同检视迭代目标的进展情况，

•根据当天工作情况调整计划

• 检视和调整产品与过程

•参加Sprint评审会，向PO和干系人演示当前迭代完成的产品成果，用来指导下一步的计划

•参加Sprint回顾会，检视和调整自己的Scrum过程和技术实践，进一步改善团队使用Scrum来交付业务价值的方法

Tech-Leader

关键活动

以下活动的召开，SM要负责控制活动流程和时间。

干系人，这里是指除了Scrum团队之外的其他人，包括但不限于需求方，boss，依赖方，使用方等。

01、需求准备会  

目的

让团队明确接下来关注的功能，逐个澄清需求，并达成一致理解。

会前准备工作

• PO做好了用户故事拆分

• 用户故事优先级得到确认

• 每个用户故事编写好

• 原型、UI/UX设计好

• 验收准则，PO和QA结对完成

• PO在准备用户故事中，可以有开发人员协助

• PO、运营、UI/UX、QA、技术代表对用户故事达成了一致认可

过程

• PO提前把用户故事分享给团队成员(用户故事必须在JIRA中管理，做资产沉淀）

• 会议中，可以把每个用户故事打印出来(JIRA可以打印）

• 团队成员仔细阅读和理解每个用户故事(Timebox控制）

• 每个人提出自己的问题，PO答疑解惑

• 确保大家达成理解一致，可以开发

• 如果PO未准备好，团队先做一些技术故事(重构、CodeReview等），减少返工和浪费。

02、Sprint计划会 

目的

团队承诺下一迭代的计划，估算故事点

过程

• PO讲解准备好的按价值优先级 排序 好的用户故事，用户故事的实现依赖性已清晰；

• 团队进行估算，TechLeader进行指导和平衡 ，估算过程中PO要随时去澄清需求，质疑团队的估算；

• 技术故事在迭代前准备好，临时的技术任务，每个迭代团队需要预留时间进行处理;

敏捷估算

团队估算一般在 敏捷计划会的时候进行，开发团队随时可以向PO提问，PO需要回答相应的问题，同时向团队成员的估算发出质疑。在讨论过程中，Scrum Master要维护活动秩序，不要让大家讨论跑题了，也不要深入研究代码编写细节，这些是实际开发是再去解决的问题；还有一点很重要，那就是鼓励所有人都发言，千万不要让老手们或强势的人控制了局势。

下面这张图非常清晰的描述差别，故事点的目的是更客观，团队人员的能力相对稳定，这样一个迭代能做的故事点也就相对稳定，因此速率也就相对稳定。

敏捷估算要点小结：

• 找一个团队共同认可的基准作为参照

• 相对估算，使用故事点作为单位，故事点是一个相对倍数。

• 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人/天，人/时无关。

• 敏捷估算关注团队的速度，不关注单个人的速度。

• 通过总规模和团队速度，推算周期。

03、每日站会 

目的：

以人为中心

• 昨日完成情况

• 今日计划完成

• 问题求助，信息同步

以任务为中心

• 每张卡的状态与计划

• 每张卡的障碍与风险

• 信息同步

技巧：

• 遵守站会时间纪律，每天10点，建立团队的工作协议，迟到如何面对，站会到岗情况，SM 发到 Just Do IT 微信群；

• 一般在每日站会更新任务板。每个人会一边描述，一边移动任务板上对应的即时贴。如果他讲的是一个未经计划的条目，那他就新写一张即时贴，贴到板上。如果他更新了时间估算，那就在即时贴上写上新的时间，把旧的划掉。

• 有些团队规定每个人在会议开始前更新任务板。这个做法也不错。你只要定好规则，坚持执行就行。

• 每人发言。如果人多，时间不好控制，建议拿一个小 工具 做令牌，令牌传到谁手里，谁发言，并挪动任务卡状态。

• 问题沟通，如果5分钟内可以解决，在站会中讨论完毕。如果5分钟不能解决，先记录在卡上，防止遗漏。站会后跟相关人员单独召开后续会议来解决问题。

• 站会时长最好在15分钟内结束

• 临时增加的任务，及时在可视任务版中建卡，进行合理的安排。

• 不爱说话的成员，ScrumMaster引导，慢慢有自信敢于在大家面前讲话，不断鼓励他们。敏捷推动大家不断提高沟通交流能力。对那些说的太多或跑题的人，ScrumMaster也要提醒他们。

• Product Owner也说说，因为Product Owner的工作进度比开发团队领先让大家也了解后续的需求动态。

• 需求方可以不定时参加站会，了解团队，回答问题，分享后续产品规划。

• 有依赖团队的任务卡，可以让依赖团队代表成员参加站会，跟踪依赖团队的任务，交错站会。

04、Sprint评审会  

目的

PO及干系人验收迭代成果，指导下一步计划

准备条件

• 关键干系人要参加,提前通知；

• 干系人了解需求和用户故事；

• 干系人了解用户故事验收条件；

• 演示人员，演示内容及环境准备；

• 演示反馈记录落实；

过程

• 可以让团队成员轮流演示，提高大家积极性和露脸机会，获得成就感；

• 开发人员演示各自做的功能；

• 可能的话,让干系人试一下产品；

• 演示反馈记录可以轮流来记录，会后讨论演示反馈的修改；

05、Sprint回顾会

目的

鼓舞士气,发现改进点,使团队在接下来更有效且高效地交付价值。

无论我们发现了什么，考虑到当时的已知情况，个人的技术水平和能力，可用的资源，以及手上的状况，我们理解并愿意相信：每个人对自己的工作都已全力以赴。

不是考核和批判，对事不对人

流程

• 安全度检查

• 买一些零食(推荐,效果很好)

• 回顾上次回顾会议 Action 执行情况

• 本次回顾 -  每个人写纸条，找共性

• 出后续 Action, 及 Owner

安全度检查

• 为了达到回顾会议的目的和积极效果,会议组织者有必要在会议开始之前做一次“检查”，确保团队所有成员真正认为在这个会议上的任何发言都不会影响到个人声誉与绩效,不会受到鄙视等,即“在这个会议上发言是安全的”。

我什么都不准备说 , 我觉得不安全

我不会说太多 , 我会更多的让别人说

我会主动说一些 , 但是大部分话题难以启齿

我几乎可以无所不谈 , 但是个别话题会有所保留

完全没有问题 , 我可以无所不谈

• 对于一个成熟的Agile团队来说,一段时间后做一次Safety check是非常 必要的。对于一个不成熟的Agile团队,最好每次都做Safety check.

工件

01、Product Backlog 

• 由Product Owner负责管理和维护

• 特点：DEEP

◦ Detailed 合适的详细程度

◦ Emergent 涌现式的

◦ Estimated 经过估算的

◦ Prioritized 排列好优先顺序的

• Product Backlog的条目（PBI）包括：

◦ 功能性需求-通常用user story描述

◦ 非功能性需求

◦ 技术改进点

◦ 需要解决的问题-确定解决方案后可能拆分为具体的任务

◦ 验收条件

PBI 的 INVEST 拆分原则：

02、 Sprint Backlog

• Product Backlog 体现的是多周或者多月的工作，是一个短期迭代无法实现的。Scrum团队需要在Sprint计划会上对迭代目标达成一致。

• 开发团队会将每个需要完成的PBI分解为一组任务，这组任务和对应的PBI组成了Sprint Backlog。

• 开发团队需给出完成每项任务所需工作量的估算值。

• Sprint Backlog由开发团队负责管理和维护。

03、产品增量

产品增量是Scrum中非常重要的工件，因为产品增量才是最终交付给客户的内容。因此每个Sprint团队必须交付产品增量，以符合如下原则：

• 交付的产品增量必须是高质量的。也就是说每个产品增量是潜在可以发布的。

• 交付的产品增量符合团队的完成定义（Definition of Done）

• 产品负责人（或客户）能够接受产品增量

另外，产品增量也是团队进展的一个标识。开发团队通过不断地交付产品增量，给团队本身和利益相干人以信心，促使产品最终发布。团队进展还有其他常用的标识是燃尽图和任务板。一般使用燃尽图和任务板时，是为了使当前的进度公开给更多的其他团队或干系人。

完成定义，指的是当产品增量完成的时候，必须是团队成员共同理解的完成，而不会出现歧义，并且产品增量需要是高质量的，潜在可以发布的。也就是说，当产品负责人要发布当前的产品增量的时候，马上可以发布出去。完成的定义，是团队根据团队当前的情况，共同协商制定的，共同同意并理解的。还有，完成的定义也不是一成不变的，随着时间的推移，团队倾向于更加严格的定义，比如把更多的内容添加到完成定义中。

04、燃尽图

• 由开发团队负责管理和维护；

• 是在迭代过程中可视化进度的一种方式，表示达成目标过程中所完成的工作量；

• 在迭代执行期间的每一天，开发团队要更新每个未完成任务的工作工作量估算，体现所有未完成任务的剩余工作总量，以此形成燃尽图；

• 燃尽图按天来更新；

• 迭代完成后发布；

工程师文化

作为互联网企业，高速的企业发展离不开我们的IT工程师们和设计师们，几乎每个项目的启动都需要IT工程师和设计师的参与，那么我们希望IT工程师们和设计师是怎样的一群人呢？

我们希望的“工程师文化”具有如下特征：

• 对专业的认同和自身作为专业人士的归属感非常强烈；

• 以获得专业成就为荣耀，靠专业特长获得大家的尊重和认可；

• 对经自己手出品的产品怀有荣辱感，并作为展现才华的唯一途径；

• 存在不影响工作的“极客”现象，乐于追求创新和完美的原因仅仅是因为有趣或值得别人的尊重；

• 一切以解决问题为导向的工作文化，一个人的地位、声誉、威望全都归结到一点上——你在多大程度上能够解决问题；

• 大家信奉的只有一条：“实践是判断真理的唯一标准。”吹得再天花乱坠，未经实践检验，都会被怀疑。 Talk is cheap, show me the code.

• 永不满足。总有可以改进的地方，总有可以优化的地方，总有可以完善的地方。