深入核心的敏捷开发：ThoughtWorks五大关键实践
肖然 张凯峰
价值驱动的精益研发转型实录
愿景：打造招行端到端的精益研发管理体系，价值驱动、质量为先，以行业领先的科技能力驱动创新与变革。
• 目标：更高的产品质量，更快的交付速度，更好的客户满意度，更高的研发效能，建立生机型文化氛围。
• 原则：价值驱动，质量为先；快速响应，高效执行；尊重信任，紧密协作；持续改进，追求卓越。战略上，“愿景-目标-原则”，层层分解、保持统一；战术上，“领域-实践-定制选择”，针对每一个跨职能交付团队的痛点和目标，定制选择合适的开发模式和实践（含管理实践和工程实践）
ThoughtWorks敏捷开发的四大经济价值
通过更快将产品和服务投入市场提升营收
• 通过缩短新客户导流的周期加速营收的产生
• 减少维护遗留系统的成本
• 减少新开发系统的维护成本
ThoughtWorks敏捷开发的核心原则：价值驱动与技术卓越。
基于统一迭代节奏的全功能团队基于Story的需求及范围实时管理基于持续集成和测试前置的质量内建基于效能和周期时间的持续改进基于客户深度参与的统一团队
一些比较普遍的原则如下：
• 迭代站会不超过15分钟
• 需求澄清每次不超过一个小时
• 展示会一个小时以内
• 回顾会不超过两小时
ThoughtWorks敏捷开发管理体系
• 需求管理：包含从需求澄清到需求最终实现的整个生命周期。
• 技术管理：包含开发、测试技术的选择和运用。
• 质量管理：包含开发过程中的质量管理及软件交付前的质量保障。
• 迭代管理：包含开发团队迭代运作规则及纪律。
敏捷宣言到底有几句
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划虽然右项也具有价值，但我们认为左项具有更大的价值。
敏捷实践 需求管理“天才就是99%的汗水+1%的灵感”和“知识就是力量”，这两句作为名言警句流传至今，但如果你只记住了这两句，恐怕无法正确理解爱迪生和培根当时想要表达的意思，因为它们都有后半句：）
1.“天才是百分之一的灵感，加上百分之九十九的汗水，但那百分之一的灵感是最重要的，甚至比那百分之九十九的汗水都要重要。”
2.“知识就是力量，但更重要的是运用知识的技能。”
关于估算开发人员与客户思维
一个很重要的因素在于开发人员普遍缺乏客户思维。
当接到一个新的需求，无论是初次提及，还是后续反馈，首先要思考的是为什么会有这个需求产生，它解决了什么问题，提供了什么价值
如果开发人员拥有客户思维，就应该在真正行动之前，考虑多个可能的方案、权衡其中的优劣，及时向客户阐明这些方案的利弊；根据对需求的理解，以及客户提供的更多信息，给出具有可 *** 作性的建议。对于一些经验丰富的开发人员来说，给出有价值的建议早就成为了他们的工作习惯，这也正是能体现他们更具专业性的行为之一。
所以，任何时候想做估算时，都应当非常清楚哪一项决策需要依赖这个估算。如果你找不到这样一项决策，或者那个决策并不是那么重要，这就是一个信号：此时做估算是在浪费时间。当你找到这样一个决策时，那要知道问题的上下文是什么，为什么估算会很重要。同样还要搞清楚期望的精度和准确性。
估算本身并无好坏之分。如果你不用估算就可以有效地工作，那就这么干。如果你需要一些估算，那就要确认你很清楚估算在决策时起到的作用。如果估算会影响到重大的决定，那就尽可能做出最好的估算
一定要小心那帮告诉你任何时候都要做估算，或者从来不需要估算的人。任何关于估算用法的争论，都要遵从于敏捷的原则，即针对你特定的上下文，决定你该采用的什么样的方法。
需求风险的坏味道和对策
一个优秀的项目管理者首先需要做的是让客户完全了解你的工作量估计系统是如何工作的，并不断强调你的工作量估计是合理、公平和有效的。
尽可能靠近决策者做系统决策人
系统是各种概念建立关联关系的结果，一个优秀的系统决策人需要对以下决定产生影响。
• 是否应该引入新的概念。
• 是否应该将某一概念变复杂。
• 是否应该建立新的关系。
• 是否应该将某一关系变复杂。不要给选择
是努力让客户认为你所给出的几乎是最优选择，就算再选，也应该是优、次优、最次选择这样的方式，而不应该是同等权值的盲目拍板。给管理结果而非解决方案
切记，不是因为东西难就不做，也不是因为东西简单就做，而是思考一个需求对于整体结果的影响。建立游戏规则
讲不清楚的需求很可能是没价值的 如果讲都讲不清楚，今天讲不清楚、明天讲不清楚，即使写100页文档，也还是讲不清楚。大多数情况，都是没价值的需求，不如推迟决策。
软件项目规模估计，怎么估？
做事所花费的时间总是比你预期的要长，即使你的预期中已经考虑了侯世达定律。
估计者的估算的点数是否能代表团队估算的点数？
在估计的过程中，至少要引入新手，能够从不同经验的角度来看待同样的问题，使估计不会过分“乐观”。是否有故事卡片之外的工作时间没有考虑到？
回复电子邮件（沟通成本）
• 面试（内部耗损）
• 参加会议（包括内部会议，比如站会、retro、code diff、技术研讨会议和客户沟通会议等）
• 为当前发布提供支持（上线支持）
• 培训？（内部的）
• 任务之间切换／被人打断（程序员出栈入栈的消耗……）
• 修复bug（一定会有bug，一定会花时间修……）
• 写各种文档（对于比较看重文档的客户，这一部分会占用不少的时间）故事卡的需求是否清晰呢？
集体估计可以缓解因为个人能力不同所引发的单点偏差，不同开发成员对某个需求从不同角度进行的阐述，也容易让大家对需求有更全面的理解，也易于发现潜藏在需求中的风险。
《敏捷估算与规划》介绍了两种基本的方法：理想人天法和故事点法。
◆ 点之殇
如果1个点＝2天，那么故事点和传统项目管理中的“人天”有什么区别？使用效能的初衷真的是作为敏捷团队生产率表现的小鞭子吗？
效能是敏捷软件开发中有时会用到的一种产能规划工具。它的计算是根据持定时间间隔周期中完成的工作量来计算的，时长是在项目开如时确定下来的。）
即：效能= Σ（单次迭代中完成的Story所分配的故事点数）[V1]
质量内建如果我们希望有效的使用“均衡器”，前提是我们要意识到Story的故事点是相对的，原始点值本身并不重要，重要的是点值的相对大小。在“一个点大概等于两天”这样的描述下，我们则无法体现这种相对性。
基于主干的开发
关于TDD单元测试
我们可以总结出写单元测试的两个动机：驱动（如TDD）和验证功能实现
1驱动和验证功能实现。
2保护已有的功能不被破坏。单元测试最常见的套路就是Given，When，Then三部曲。
• Given：初始状态或前置条件
• When：行为发生
• Then：断言结果测试即文档，既然是文档，就应该明确描述待测方法的行为，而不是陈述一个例子。
第二是测试完备性。因为省事省心并且回报率高，我们更乐于写happy path的代码。
TDD
TDD（测试驱动开发）是一种驱动代码实现和设计的过程。我们说要先有测试，再去实现；保证实现功能的前提下，重构代码以达到较好的设计。整个过程就好比演绎推理，测试就是其中的证明步骤，而最终实现的功能则是证明的结果。
一旦进入红、绿、重构的节（guai）奏（quan），开发人员根本停不下来，仿佛遁入一种心流状态
工期紧，时间短，写TDD太浪费时间。
• 业务需求变化太快，修改功能都来不及，根本没有时间来写TDD。
• 写TDD对开发人员的素质要求非常高，普通的开发人员不会写。
• TDD推行的最大问题在于大多数程序员还不会“写测试用例”和“重构”。
• 由于大量使用Mock和Stub技术，导致UT没有办法测试集成后的功能，对于测试业务价值作用不大。
• ……
技术人员拒绝TDD的主要原因在于难度大、工作量大以及mock的大量使用导致很难测试业务价值等。
关于CRTDD的核心是先写测试并使用它帮助开发人员来驱动软件开发
首先是先写测试，这里的测试并不只是单元测试，也不是说一定要使用mock和stub来做测试。这里的测试就是指软件测试本身，可以是基于代码单元的单元测试，可以是基于业务需求的功能测试，也可以是基于特定验收条件的验收测试。
其次是帮助开发人员，主要是帮助开发人员理解软件的功能需求和验收条件，帮助其思考和设计代码，从而达到驱动开发的目的，所以TDD包含两部分：ATDD与UTDD。
ATDD（Acceptance Test-Driven Development），验收驱动测试开发，首先BA或者QA编写验收测试用例，然后Dev通过验收测试来理解需求和验收条件，并编写实现代码直到验收测试用例通过。
UTDD（Unit Test-Driven Development）：单元驱动测试开发，首先Dev编写单元测试用例，然后编写实现代码直到单元测试通过
超越“审，查，评”的代码回顾
代码回顾（Code Review）应该是软件开发团队“共同学习、识别模式和每日持续”的过程，而不是带有“审，查，评”等令人感到紧张气氛的过程。
代码回顾的目的，是团队成员聚在一起共同学习，而不是相互“挑错”。
团队成员通过阅读最近编写的测试代码和生产代码，来一起识别“好模式”和“反模式”，既是团队成员之间相互学习的过程，也是团队整体达成编写整洁代码共识的过程。
在代码回顾的过程中，完全可以不提谁是代码的作者，而只提“好模式”和“反模式”，这样能让作者放松心态，更好地接受合理的建议。
好模式和反模式，其实就是编程的好习惯和坏习惯。代码回顾应该侧重于识别编程习惯，而不是找bug。
一方面要像上面讲的那样，不“审，查，评”，不针对作者去找bug来去除“挑错”的紧张气氛，营造“识别模式”来“共同学习”的环境，吸引团队成员长期参与；另一方面，也需要将每日代码回顾的时间控制在半小时以内。
不做代码审查又怎样
代码审查所暴露出的问题本质上就是如何权衡沟通的成本和收益问题。
相比于测试金字塔中的UI－Service－UT，Iteration Planning Meeting—Code Review—Pair programming”就可以类比成沟通金字塔，和测试金字塔一样更靠近金字塔顶端的（例如迭代计划会）沟通频率越低，成本越高，但越接近业务；越靠近金字塔底端的（例如结对编程）沟通频率越高，成本越低，越接近实现。
日本剑道有个心诀，叫“守破离”：“守”，最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界；“破”，基础熟练后，试着突破原有规范让自己得到更高层次的进化；“离”，在更高层次得到新的认识并总结，自创新招数，另辟出新境界。
关于PAIR敏捷实践之提前验收
提前验收实际上是践行了宣言的第一条：个体之间的合作，而且合作比流程更重要。提前验收同时也体现了反馈在敏捷开发中的作用，及时的反馈能够尽早纠正工作的偏差，让我们能够一直朝着正确的方向前进
极限编程中的“极限”（Extreme）是指将我们认同的有效软件开发原理和实践应用到极限，如“如果集成测试很重要，那就要在一天中进行多次集成，并且反复进行回归测试”，所以我们要做持续集成。结对编程在提出时更多的是强调“如果代码评审很好，那么我们就一直进行代码评审”，所以我们要做结对编程。
结对编程的好处
培养新人，促进沟通，提升团队整体能力。更好的知识共享和信息交流，促进团队协作。促进团队成员的沟通，提升团队凝聚力。
关于看板领航员和驾驶员（Driver-Navigator），键霸出没，请小心驾
这里需要提及极限编程的另一实践：测试驱动测试。结对双方可以一个人编写失败的测试，一个人写实现通过测试；然后交换角色，不断循环。
这是驾驶员和领航员的一种具体表现方式，其中一方使用鼠标，是领航员；另一方使用键盘完成代码的编写，是驾驶员。确定开发任务列表定期交换小伙伴可持续的结对工作多给新人机会勇敢加勇敢反馈不是所有的场景都适合结对
关于retro看板和利特尔法则
利特尔法则的公式是这样的：平均吞吐率=在制品数量／平均前置时间
最短的前置时间和最大的平均产能不可并存，在“平均每人手头有一件事”的时候，在制品数量稍微小一点，可以达到最短的前置时间，在制品数量稍微大一点，可以达到最大的产能。至于各个组织如何选择，要看自己的需求。
关于站会高效回顾会议的七步议程
设定上下文（Context）最高指导原则
最高指导原则为“无论发现什么，我们完全理解并且相信每个人在当时状况下，基于他的能力和资源，做出了最大的努力。”热身活动
选择一个最适合团队的破冰游戏。在建设一个团队时，我们推荐那些旨在分享名字或喜好等信息的活动。测定环节
测定（check-in）是用来测量参与者对设定内容和会议本身的感受。主题
主题（Main Course）是整个会议的核心部分，它的目的是探索持续改进的方法和手段。它可以由一个或多个部分组成，也会依时间而定。筛选下一步
根据布鲁斯·塔克曼（Bruce Tuckman）的团队发展阶段模型，团队发展一般要依次经历以下几个阶段：
• 组建期
• 激荡期
• 规范期
• 执行期
• 休整期
在采用任何一个实践的时候，我们都要经常思考下面几个问题。
• 它的出现是为了解决什么问题？
• 这个问题现在还存在吗？
• 有没有更好的解决办法？
关于showcase敏捷不是遵循“最佳”实践，而是要搞清楚实践在什么环境下解决什么问题，然后再合理地对实践进行裁剪和改进，这样才能保持敏捷力！
什么是展示会（Showcase）？指的是开发团队把开发好的功能演示给客户的产品负责人（Product Owner，PO）等业务相关人员看，以获取他们的反馈，它是敏捷开发流程中的一个实践，一般的频率是一个迭代一次，也可以根据项目具体情况做调整。
敏捷团队 团队的精进之道准备工作没做好没有上下文铺垫
着急忙慌地准备好一逐条过AC
正确做法：以功能为单位演示企图覆盖所有路径
正确做法：只演示最关键路径。过多提及跟演示功能无关内容
正确做法：只提及要演示的功能。认为展示仅仅是BA或QA的事情
正确做法：人人都可以展示不熟悉的新人负责展示
正确做法：展示前先充分了解系统和业务
我们认为，软件开发中的一切问题，根本上都是人的能力问题。如何发展每个成员才是问题的关键。如果成员没有进步，始终是治标不治本的。所以我们采用的一切实践，不管是以前曾采用的还是以后会采用的，核心目的都只有一个：发展人的能力。
团队的精进之道就是把交付过程中的一切活动都看作能力建设，把整个团队构造成促进每个成员成长的生态系统。
基础技术团队实践三个角色
PO从职责上讲拥有Product Backlog，负责决定哪些功能进、哪些功能不进以及优先级是什么。换句话说，PO负责产品的方向。 如果PO不需要对产品的成败负首要／主要责任，那么他／她关于backlog的范围和优先级的决定是不可信任的
Scrum Master的使命就是把自己做没，不是做媒，是做没。
因为Scrum Master按照定义，从根本上来说就是一个教练的角色，教会团队自组织、教育PO、教育开发团队、教育组织里其他干系人。评价教练的唯一标准就是被教的人不再需要他／她了。所谓自组织其实很简单，就是不去干预。如果团队在众多内部关于流程／活动／角色／职责等事情上需要Scrum Master的干预，则离自组织还很远。
好的代码应该要有设计的痕迹：简单粗暴地还原业务或多或少给未来埋坑。在我们团队，大部分微观代码设计源自我们自己定制的一套领域模型设计套路。套路里要有每个工程师对每个特性的精心设计，同学们的设计原则是可以设计得不完美，但不能不思考设计；
不要低估了编写自动化测试的难度：检验代码好坏的一条标准就是，是否很容易对这块代码添加有效的自动化测试。
团队管理自动化测试
持续集成／持续发布
分支策略
代码回顾
站会
技术讨论
回顾会议
IPM迭代计划
拜神
初入管理往往会陷入两个误区：集中控制管理和微观管理
仅仅告知团队成员说话的时候不要看你或者当你不存在是虚伪的，这种所谓的建议在实际 *** 作层面毫无意义。敏捷教练给我的建议是，你不妨缺席几天站立会议
需要团队管理者首先要做到信任和放手
作为团队管理者，不能仅仅关注团队这一次把事情做对了，关键是，团队通过自己的成长持续的把事情做对，以致做得更好。
团队管理的终极目标是打造一个“自组织”的团队，
团队敏捷转型的三个阶段技术领导者需要扮演三种重要的角色：技术决策者、流程监督人和干扰过滤器。
他要制订适合该项目要求的技术方案。
其次，他要保障交付顺利开展
他还要管理和提升团队的能力。
只有方案、交付、能力三者有很好的协同，项目和团队才能健康成长。
敏捷转型的开始是瀑布式开发，我把这个阶段定义为Agile 0，根据我们的敏捷成熟度模型（AMM）里提及的最终形态定义为Agile 5，期间会经历三个阶段。
阶段一（Agile 0～1）：建立敏捷流程，缩短交付周期
教练主要采取以下行动。
• 培训，现场指导，需求梳理这个阶段主要培养的目标，是Scrum Master或者类似的角色，让他们能了解敏捷流程的运作方式，并能带领团队在教练不在场的情况下，依然按敏捷流程运作
阶段二（Agile 1～3）：引入技术实践，质量内建，减少返工
这个阶段的主要目标，是提升开发人员的质量意识，从而提升开发阶段产出的质量水平，减少后续环节的返工。
这个阶段培养的主要目标就是开发，建立开发的质量意识，帮助开发写出更好的代码，培养开发处理复杂问题的能力。同时开阔团队视野，让团队成员了解更多的技术，学习如何利用新技术提升自己效率。阶段三（Agile 3～5）：提升价值交付效率和响应力
在这个过程中，文化贯穿始末。因为团队能力变强，所以更容易建立业务和技术团队的信任，形成信任文化；因为团队养成了自我改善的习惯，所以更容易形成学习型文化；因为大家有信任、有能力，所以会打破原来的控制型文化，培育出创新型文化。这些文化的建立，能更好帮助企业在未来保持良好增长。
其实是行为改变思想，再通过思想影响行为的过程，当团队中的人员能力慢慢提升，思想也在随之改变，所有人都能对什么是正确的事作出更好的判断，继而走向持续改进的道路。所以如果定义团队转型成功，我认为就是帮助团队建立起了一群能自己做持续改进的自组织特性团队。
团队要经历这三个阶段必然是
◆ 敏捷转型过程中的必然挑战
典型问题是传统管理方式跟敏捷价值观之间的冲突，
传统绩效考核的三个目标如下。
提升员工个人的能力。
提升组织产出。
决定涨薪和升职。
如何破局？
作为管理者，你也能够知道谁做得好，谁做得不好，所以作为管理者，在践行敏捷价值观和原则的同时，照样可以适配传统的绩效考核来得到结论。
1 从考核个人绩效转移为考核团队成效；以产品的好坏来评价团队表现。
2 从横向比较员工绩效转移为纵向比较个人成长；对于个人的成长，企业应该定义清楚每个角色的胜任力模型，从而帮助员工设定自我提升计划，而不进行员工之间的横向比较。
3从长周期考核转移到及时反馈与调整；缩短反馈周期有利于及时改进，相互反馈有利于增进成员之间信任和理解。
工程师文化与KPI文化管理者要积极转换思维，参与一线工作，贡献到实际项目中去。
通过参与一线工作，改变传统方式中与团队站在对立面的尴尬境地，更有利于建立信任
通过参与一线工作，更加深入地观察团队成员的表现，从而及时提出反馈和改进意见定期跟员工一对一沟通，明确团队需要的胜任力
在此过程中明确团队需要的胜任力，听取员工心声，及时反馈，指引方向；更重要的是要收集员工对自己的反馈，及时调整自己的行为。
透明“考核”过程，全员参与。尝试每月开展一次类似于360°反馈的茶话会，团队轮流分享自己在过去一个月的成长与进步、还存在的不足、面临的挑战，开诚布公的分享自己开心的不开心的事情。鼓励建立敏捷文化，身体力行。
引导团队坚持每个迭代回顾
可视化所有产品度量指标。
可视化团队成员贡献
积极与自己的领导明确敏捷价值观和原则，积极争取自主权，影响其他管理者。
工程师文化的前提条件
信任：领导和产品负责人对工程师绝对的信任是工程师文化的最基本条件
敏捷实施卓越的技术领袖存在：
技术列为KPI：
技术创新
可以更简单更有效地完成一个业务任务。团队激励不单纯以业绩为主的技术的创新，比如：谷歌每个工程师都有20%的时间可以用于研究自己喜欢的技术，而不是跟谷歌相关的业务。
技术决策权大：尊重技术决策的前提就是信任技术决策，而不是简单粗暴地说：“为什么完不成？随便叫一个程序员就可以完成。
技术数据可视化：可视化技术相关数据包含圈复杂度、测试覆盖率、重复率等等，对数据好的工程师给予掌声
分享多会议少：宁愿少开会掰扯这个应该谁做，也要多听技术高手讲一个技术细节，大家都应该沉下心来沉淀一下自己的专业知识。
敏捷实施的主要目的：缩短周期、提高质量和满意度
• 缩短开发周期（69%）
• 提高质量（60%）
• 提升用户满意度（49%）
• 提高人员的能力（30%）
• 增强协作（43%）
• 减少工作量，提高产能（32%）
• 产品创新（17%）
• 改变管理方式，让成员更有参与感（34%）
• 其他（4%）
敏捷的项目管理：追求最大价值的成功最后，敏捷企业应考虑采取以下措施：
• 简化流程
• 投入自动化
• 确保领导参与
• 建立改进目标
• 让组织文化和绩效管理更符合敏捷理念
他认为唐僧师徒可以被看作敏捷中的全功能团队：团队有共同的目标“取到真经”；他们历经了九九八十一难，好比九九八十一个迭代，每次打怪成功都是完成了一次交付；在不断迭代的过程中，这个团队不断地收集反馈、持续改进，一步步地完成了最后的目标。
项目成果的交付和团队能力的提升，这是项目经理在项目管理中最希望达成的目标。传统项目管理的定义是：“在有限资源限定的条件下，实现或超过设定的需求和期望。”一句话概括了传统项目管理的铁三角：需求是范围，资源包括时间和成本。
我们越来越多地发现敏捷项目管理中有着至关重要的一环，人，也就是我们的团队。价值是人创造的，是为人服务的，很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人，是以创造力、洞察力和对客户的感知力为核心特征的，我们相信这样的团队能创造最大的价值。
◆ 用户故事
用户故事（User Story）是敏捷开发的基础，它从用户的角度来对需求进行描述。软件开发是为了实现产品的商业价值，满足用户需求。只要需求足够明确，所有人都了解其具体内容，团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。
用户故事体现了用户需求以及产品的商业价值，同时定义了一系列验收条件（Acceptance Criteria，AC）
一个用户故事通常包括三个要素。
• 角色：谁要使用这个功能。
• 活动：需要完成什么样的功能。
• 商业价值：为什么需要这个功能，这个功能带来什么价值。
估算和迭代计划
估算的价值体现在可以帮助你做出重大决策时
当团队在为工作排定优先级、制定迭代计划时，业务分析师需要知道每个用户故事的成本，团队成员需要知道每个用户故事的价值
迭代会议和功能演示
迭代会议（IPM）通常发生在每个迭代的第一天，团队成员一起制定迭代计划。
功能演示（Showcase）是敏捷开发流程中的又一个实践，通常发生在每个迭代的最后一天，目的是演示可工作的软件。
站会和用户故事开卡
昨天完成的工作；
• 今天计划做的工作；
• 面临什么阻碍，需要什么帮助；
• 自己手头用户故事的进展，是否存在技术风险。当人们坐着开会的时候，会议的时间会被无形中拉长
团队成员都要参加站会，轮流主持，谁迟到了都不等，仪式感很重要。
• 站会的时候，每位团队成员围绕故事卡进行更新。介绍一种有意思的实践，使用Token，也就是使用一个实物作为“令牌”，准备发言的人首先取得“令牌”，发言完成后将“令牌”传给下一个人。令牌要醒目，可以是毛绒玩具，也可以是一顶帽子。用户故事开卡（Story Kick-off）指的是在每个用户故事开发之前，要确保BA、DEV和QA对用户故事理解一致。
代码审查和回顾
代码审查（Code Review）是指开发团队在完成每天代码之后，聚在一起评审当天的代码，
回顾（Retrospective）的目的是通过新的沟通形式唤起大家对团队的集体意识，指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈，可以保证团队关心生产力和效率，了解自身的不足，这将成为团队持续改进的起点。
最大程度的可视化
敏捷里面的自组织团队其实是敏捷的结果，而不是先决条件。实施敏捷的过程也是打造自组织团队的过程
团队目标不一致
团队成员不熟悉
• 基于敏捷实践，创造更多的沟通机会，比如回顾会议、代码审查和站立会议。通过不断创造这样的沟通机会让团队成员配合更默契。信息发布不顺畅
• 共享信息，制定沟通计划。
• 最大程度的可视化。行为心理学研究认为：21天以上的重复就会形成习惯。任何一个动作，重复21天就会变成习惯性的动作；任何一种想法，重复21天或者重复验证21次，就会变成习惯性的思维方式；任何一种信念或者有益的实践，经过团队持续验证，它一定会成为团队的信念和实践。
scrum四个会议剑道中有这样一个心诀：守、破、离。
• 守：最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界。
• 破：基础熟练后，试着突破原有规范让自己得到更高层次的进化。
• 离：在更高层次得到新的认识并总结，自创新招数，另辟新境界。
也谈精益对于“做什么”，即下个Sprint要做什么，某种程度上是不需要开发团队参与的。PO应该根据干系人的输入，从业务优先级上选出下个Sprint的Backlog。这个过程可称为IPM（iteration planning meeting）
称为IKM（Iteration Kickoff Meeting），在本Sprint开始时进行，主要目的是PO和开发团队对这个Sprint的目标进行交互，解释、答疑和达成共识。
这个错误的点就是关注每个人都干了啥，今天要干啥。站会对团队成员就成了一项考核，考核你工作量饱不饱满。每个人都挖空心思表明自己没闲着，说完自己的就完事，也不管别人的。
那么站会正确的关注点是什么？进度、障碍、新知及是否要进行调整。关注的是接力棒，而不是运动员。
站会是向整个团队报告进度，目的是寻求帮助，提供新知，为可能的任务调整提供真实的输入。站会是以天为周期的PDCA环中重要的一步，负责检查和提出行动建议。
评价站会效果的唯一方式是，会后有没有根据会上的信息做出相应调整。
如果站会后没有调整，说明站会极有可能是无效的
没什么可说的。只要回顾会议有效果，其他问题再大都是小问题。当回顾会议没有效果的时候，问题就大了
站会／回顾／评审会议，都涉及调整。开完会后没什么调整，这个会就白开了。
精益六西格玛
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）