19.捷拥抱变化

1.看板属于信息发射源，信息发射源提供有关项目构建的实时信息，使得信息在项目中更好地被相关方获得。精益画布是呈现在一张纸上的可视化简明商业企划书。敏捷发布规则主要目的是制定计划以向产品交付增量。渗透式沟通是信息在互相搭配工作的团队成员之间无意识地进行共享。

2.敏捷的办公环境设置原则，应该尽量让团队成员在同一个空间办公，并且提供方便信息交流的信息发射源。温馨而舒适的环境是在设计团队氛围时重点考虑的方面，他可以促进哟偶小沟通，提升创造力和激励团队成员。构建良好的敏捷团队氛围包括：团队成员的协作，减少非必要的干扰或分心，为信息发射源提供专用白板和墙面空间，为每日站会会议和其他会议提供空间、结对工作站，其他人性的措施如植物和舒适的家具。

3.在敏捷项目中，沟通提倡公开、透明、即时。每日站会是开发团队用来共享项目进展情况的会议。

4.用户故事代表客户需求的具体点，为客户增加价值，一般由三部分组成：作为一个xx角色，我需要一个xx功能，以便未能xx达到目的。用户故事是小而细粒度的，用户故事的合集是产品待办事项列表。

5.敏捷项目中，速度是指每一个迭代团队完成的故事点或故事数量的衡量。一个敏捷团队可根据稍前的速度记录来估算下一个迭代可完成的用户故事点数量。

6.敏捷参与式决策指的是团队参与决策制定的过程。目标是在项目中给项目社区提供具体实践去建立框架、分析和制定不同决策。参与式决策的主要目标是：促进目标和限制因素的清晰沟通，开放未开发的知识，发挥组织的创造力和洞察力，最典型方法就是“举手表决法(fist to five)”。

7.完成的定义(dod)：根据敏捷适应的特点，所有的决定应该是尽量晚，以便尽量多的考虑到环境的变化，所以故事的完成的定义是在每个迭代的迭代规划会议上，由产品负责人确定，作为团队成员这个迭代完成故事的验收标准。

8.最小可售功能(mmf)：可以从客户增加价值的最低交付需求。例如列表包含20个功能点，在迭代会议挑选5个，作为给客户交付的单个功能。

9.迭代速度是迭代完成的故事的总价值，没有到达100%就不算完成。

10.产品负责人需要收集客户和相关方的需求，并更新产品待办事项列表。在敏捷项目中，新的需求会在下个迭代的迭代会议上，根据价值的优先级考虑会不会优先完成，在迭代过程中，不会中断迭代。迭代待办事项列表是迭代中开发团队维护的工作，在迭代过程中一般情况不会纳入新的用户故事，也不归产品负责人负责。产品负责人不会参与每日站会。

11.敏捷项目需要小快频地迭代，而且需要尽量保证相关方在评审中的参与，以便获得反馈，以便适应环境的变化。

12.产品负责人的职责是负责联系客户，获得客户的最新反馈，维护产品待办事项列表，按照对客户的价值对故事进行排序，确保团队呢能够掌握对客户最优价值的工作。

13.每日站会由开发团队成员轮流表达3个问题：昨天做了什么？今天要做设么？遇到什么障碍或问题？所有的展开讨论，都在每日站会后，相关人员自组织单独完成。

14.在迭代评审会议上，团队成员依次演示本次迭代完成的功能，如果产品负责人确认通过，功能将会以可交付增量的形式纳入到产品中，如果未通过，会打回产品待办事项列表重新排序。

15.产品待办事项列表是一份按照客户价值优先级排序的需求清单，在整个项目过程中不断更新，一般随着项目的进行，信息逐渐清晰，而逐步细化。

16.敏捷拥抱变化是指，客户可以随意提交新的需求和想法，由产品负责人将其纳入到产品待办事项列表中进行价值优先级的排序，然后在每个迭代的规划会议上，由开发团队自组织挑选匹配团队速度的故事作为当前迭代的待办项。

17.迭代回顾会议在每个迭代的最后，用来总结迭代的经验教训，制定改进计划，供未来迭代参考，更好地完成项目，讨论话题包括：从成功和失败中学习，比如总结高效或低效的方法；如何实施成功的行为，比如新的测试标准；如何停止消极的行为，比如用偏离团队认可的代码标准来指定迭代期限。

18.敏捷宣言强调，业务人员和开发人员需要在一起工作。可以是开发人员直接跟客户沟通，也可以是安排产品负责人跟客户对接。定期的评审，保持高带宽的沟通都是很好的获得客户反馈的做法。

19.价值流图，对于项目而言，没有产生直接的价值，对项目是一种浪费，需要采取行动，改进过程，把等待的时间用到其他产生价值的工作上，消除浪费。

20.限制在制品，如果一个团队不限制在制品，结果就是每个人都很忙，而且会出现瓶颈，并且不知道瓶颈在哪。

21.时间，预算和成本估算是敏捷中重要的制约因素。由于其接受变动的范围，敏捷方法的本质意味着它为固定的预算和进展提供很好的支持，但变动的范围使总成本的估算更艰难。总体来说，预算和进度的约束是已知的，但是这发生在项目初始阶段开始需要定义一组商定的基础产品功能前，固定的范围降低了敏捷团队提供提高的价值的创新趋向。敏捷合同包括：工料合同，不超过固定费用合同，奖励性合同(固定价加激励，成本酬金及奖励合同)。

22.敏捷合同三角形，进度和成本一般固定，范围工作量固定，但是功能可以随着项目的变化而进行等量地调整。

23.速度的急剧起伏，表明了项目过程中出现了问题，而这个问题，最好是由团队自组织解决，在敏捷团队中，提倡的是可持续的迭代，不能单纯使用最高速度也不能走另一个极端使用最低速度。

24.在敏捷项目中，团队是自组织的团队，相互协作，当遇到问题时，优先团队自组织解决，如果实在无法解决且影响太大，再考虑敏捷教练干涉或上报管理层，敏捷提倡开放透明的沟通。

25.迭代待办事项列表是一栏产品特征或者将在冲刺中完成的工作事宜，通常是在迭代里不变的，除非被重要客户要求变化了。

26.当项目的速度定的过高不能达成目标时，不能牺牲掉其他必要的敏捷实践，最合适的做法是通过协商，重新定义速度。

27.用会议收集信息的技术属于面对面的访谈，能够达到互动式的沟通，也有助于获得私密信息并得到相关方的真实想法。

28.客户合作胜于合同谈判，在敏捷项目中，如果因为环境的变化客户要求变更需求，时间和成本保持不变，范围在工作量不变的情况下，可以优先完成对客户更有价值的工作。联系商务的同事，与客户进行谈判，在考虑新增功能的同时，放弃一些和新增功能规模相同的次要的功能。

29.敏捷教练主要负责整个敏捷流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。主要与服务团队，教导团队，保护团队，引导敏捷的有效应用职能。作为敏捷教练，应该鼓励团队的开发人员直接和客户进行沟通。

30.阻碍是在每日站会上分享的，优先团队在站会后自组织解决。

31.持续地拥抱变化，目的是为了能够帮助客户创造更有价值的产品和功能。

32.在敏捷项目中，提倡尽早持续地交付可用的产品，尽早地帮助客户创造价值。自组织团队是敏捷开发团队的特点，但是要求是由全职的通才型专家组成，不会轻易变化和调整。产品待办事项列表作为反映客户需求价值优先级的产品工件，是随着环境和项目变化而调整的。

33.在敏捷项目中，计划强调刚刚好，也具备适应型的特点，根据项目的实际进展，敏捷计划分为：愿景-产品路线图-发布计划-迭代计划-每日计划五个层次。

34.自组织团队，强调团队自主的安排任务，分配工作，解决问题。与权力对等的是责任，在敏捷项目中，如果产品出现问题，对应的责任也应该是由开发团队来承担。

35.敏捷教练需要确保敏捷原则和理念在项目中的践行，包括每个人都明确自己的角色和职责，确保团队能够有序开展工作。

36.在敏捷项目中，为了确保产品的方向符合客户的期望，需要尽早、持续地给客户演示和交付，获得客户的反馈，以便及时做出相应调整。

37.迭代规划会议强调根据环境和客户的需求变化来调整项目的工作事项。迭代评审会议评审迭代完成的功能并判断能否交付给客户。迭代回顾会议是总结团队的工作方式，确定改进计划。每日站会的目的是消除团队信息差，更好地了解整个团队工作情况。

38.每个用户故事的验收标准和测试标准都要在冲刺开始前确认好，在敏捷团队中不用使用需求跟踪矩阵。

39.crystal水晶根据项目实际情况调整做事情的方法，会有很多种不同的颜色，分别适合不同规模的团队和项目任务，水晶开发方法一个首要原则就是渗透沟通。dsdm动态系统开发方法就是敏捷的三角形制约，时间和成本固定，工作量固定，根据优先级来选择要做的事情，范围在变化。scrumban是一种在团队选择scrum作为工作方式时产生的管理框架，它以看板方法作为透镜从而审视、理解并持续改善工作。xp极限编程是一种基于频繁交付周期的软件开发方法，关注于团队凝聚力、沟通、代码质量和编程。

40.产品路线图，关于项目的可视化概述，不是产品功能的简要描述。发布计划是针对每个版本发布的功能描述。项目章程包含愿景、任务和成功的标准，为产品的设计目的提供概述并为测试者执行探索性的测试提供向导。项目数据表，用一页纸概括主要的商业和质量目标、产品功能和项目管理信息。

41.在敏捷项目中客户就是部门的代表或另一个小组。

42.团队建设有利于成员建立信任，提高团队绩效。

43.用户故事的编写应该遵循invist原则，而且对于复杂功能应该进行分解，并关注最有价值的部分，敏捷教练应该确保产品负责人懂得如何来安排产品待办事项列表使其达到最大化的价值。

44.在敏捷中，时间盒是很重要的概念，它在易变的工作环境中带来秩序和一致性，可以利用此方法评估结果，获取反馈，控制成本和风险。时间盒和具体的迭代时长有关系，比如一个月的迭代，评审会议为4小时，如果是2周的迭代，评审会议只需2小时。迭代评审会议上，产品负责人应该说明工作的完成情况，团队应该对所交付增量进行演示和答疑，还可以包括产品待办事项梳理，完成时间预测等等。

45.集体决策将功能包含进下一个发布版本的可行性是最好的选择，因为优先顺序、团队速率等都需要考虑。

46.代码重构是完善工作源代码的方法，以提高源代码的有效性，可读性，拓展性，可维护性和降低复杂性，通过重构，可在不改变外部行为的情况下，重构源代码来改良内部代码。

47.在迭代计划中，团队根据三部曲去设计迭代待办事项：团队分解大的或复杂用户故事为多元的，小的故事；团队把每个用户故事分解为开发任务；团队估计任务功力或周期，通常用理想时间。

48.在迭代规划会议上，一般由产品负责人来讲产品待办事项列表，团队来进行评估，进而建立迭代待办事项列表。

49.计划扑克是基于宽带德尔菲估算技能，也是以共识为基础的工作量估算技能，往往在故事点和开发用户故事中用来估算相对工作量，常见数列有斐波那契数列(0,1,2,3,5,8...)或(0,0.5,1,2,3,5,8,13,20,40,100)。计划扑克会议按如下进行：一位调停人，主持会议，不参与估算；产品负责人/管理人员对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票；每一位估算师抽取一张卡片来估算工作量；每人抽取一张卡片后，同时将他们的卡片翻转；持高或低估算的估算师各有一个机会作立场辩护；达成共识前，不断重复以上流程，持有用户故事的开发者往往拥有较高的可信度。

50.无法在规定时间盒内完成增量的特性开发，团队要和产品负责人一起处理问题，讨论范围的增减以及进度的相应变化。

51.计划在收获一些新内容时可以改变。

52.分散办公的最大挑战是复制集中办公团队的面对面沟通，渗透式沟通及隐性知识所带来的好处，常常使用视频会议，基于web的会议引导，在线调查应用，及时通讯和voip，基于展示的应用。交互式白板等。

53.风险暴露是指产品概率和损失规模，风险暴露=风险发生可能性*损失时间规模。

54.通过探测的方式，快速试错，可以明确新技术在新环境下的可用性，降低风险。

55.在敏捷项目中，迭代的变化情况和趋势分析，对于这些变化和趋势分析的评估，一般在迭代评审会议上，由产品负责人进行说明。

56.产品负责人最终确认工作是否达到验收标准。

57.需要知道当前迭代的团队承诺状态，既是项目当前的完成情况，而燃起图和燃尽图是进度跟踪的管理工具。

58.持续集成是指频繁的将代码集成到主干，它的好处是快速发现错误和防止分支大幅度偏离主干。持续集成的目的是让产品可以快速迭代，同时还保持高质量。它的核心措施是代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。“持续集成并不能消除bug，而是让他们非常容易发现和改正”。

59.冲刺计划会议在敏捷架构里，冲刺计划时间限定在8小时之内，迭代周期为4周，对应冲刺规划时间为8小时，2周则按比例为4小时。

60.结对编程，通过两名开发人员共同工作的方式，促进程序员自身能力的提升。

61.流(过)程裁剪，敏捷注重适应性，而不是全面性，当启动一项新敏捷开发工作时，项目团队应该决定它的敏捷方法。

62.速率是用来衡量团队在每个迭代中的生产能力，从以往迭代中完成的用户故事数来估计团队的生产能力，单位可以是小时数，天数，点数，糖豆数等，用最后几个迭代的平均速度比较准确体现下个迭代速度。

63.人物角色能够快速辨识关键干系人及他们的利益所在，被创建的任务可以以真人参考，也可以是多个用户的混合，并且被创建的任务能够体现用户的典型性。既然用户故事中任务角色包含了一般用户，那么也应该将不一般的用户包含进去，应该使用用户故事中任务角色这个工具。

64.相对权重，则是通过考虑功能所带来的正面益处和缺乏它所产生负面影响的排序方法，依赖于专家判断。moscow方法，是将需求功能按必须做的，应该做的，可以做的，不要做的进行分类。虚拟货币，通过给参与估计排序者与项目价值相同的虚拟货币，让参与这使用这些货币给功能进行排序。卡诺分析，将客户功能需求按惊喜，满意，不满意，无关紧要进行分类。

65.当客户的需求有变化时，我们就要审查dod，看当时是怎么定义的，只要需求不变，就不用考虑和审查dod，但是一旦发生变化，就要重新进行审查。

66.团队开发的增量无法满足业务需求，可以要求产品负责人与团队增加沟通反馈频率，因为产品负责人是站在客户角度，是对客户需求最了解的，与团队更频繁的互动可以提高开发成果满足需求的可能性。

67.决定用户故事优先级的两个因素：商业价值和成本，以最低的成本实现最高的商业价值，平衡高商业价值和资源需求量大的故事。

68.刺探，基于风险的刺探是团队研究某个问题而进行的快速的概念验证活动，基于风险的刺探也常用来测试陌生的或全新的技术，在深入采用这种技术之前，探测的结果能够避免陷入太深。

69.在敏捷中，之前出现的问题已经在回顾会议上确定了解决方案，但是又再次出现，最可能的原因是没有采取行动，因此可以制定相应的行动计划来监督行动过程。

70.过去的回顾会议没有成效，不代表着取消回顾会议，而要确保回顾会议达成的事项需要得到执行，可以通过对达成的事项进行优先级排序，对于还没有解决的问题可以不在回顾迭代会议上再次提出，可以暂时关闭。

71.敏捷教练要为团队创造安全感，有了安全感，团队才会自由发表观点，成为自组织团队。

72.敏捷对待项目外部变化的原则是适应和调整，出现外部依赖干扰正常执行的情况时，可以首先思考如何动态调整任务，比如调整先后顺序，核心是团队保持学习和敏锐的适应能力。

73.迭代回顾会议的价值是提醒团队和干系人专注于回顾会议行动项。

74.风险燃尽图罗列了影响项目成功且与每项需求相关的各种风险，随着项目不断推进和功能的完成开发，项目风险将会不断减少，所以要确保项目成功可以让干系人更易于获取项目信息并了解影响项目成功的风险。

75.敏捷强调团队的互助协作，但前提是个人能够有一定的技能帮助他人，也就是通用人才。为了避免出现孤岛现象，应该鼓励团队成员成为通才专家，并鼓励个人学习新技能。

76.动态系统开发方法(dsdm)三个主要阶段：初始项目活动，项目周期活动，结束项目活动。项目生命周期五个阶段：可行性研究，交易研究，功能模型迭代，设计和建立迭代，安装启用。

77.看板的核心理念是通过限制在制品，减少周期时间，让工作快速流动起来，以便尽早交付产品增量。

78.额外提出的故事，应该在本次迭代外，更新到产品待办事项列表中，再按照价值优先级，考虑需不需要在下一个迭代中完成。

79.测试是每个迭代日常工作的一部分使用自动化测试实现日常快速和稳健的测试。每次代码集成都伴随着自动化测试，使得错误能被立即发现。对于开发过程中不断出现问题，最有效的解决办法就是不断评审不断测试，而实际做法是通过快速构建和10分钟自动化测试，这样便于及时发现问题，而不是等一个版本出来时才发现。

80.增加浮动时间，并降低产量，将导致速度降低。

81.风险是反向价值，应该由产品负责人将这个故事添加至产品待办事项列表，进行价值的优先级排序，还应该与相关方一起讨论。

82.战线比较长的项目应该采取渐进明细的规划方法，先规划总体的发布计划，在规划近期的迭代计划。每日计划是迭代计划制定后需要制定的每天的详细计划。

83.发现与解决问题的步骤：收集数据——分析原因——采取行动。

84.刺探，是在不确定的环境下，做的一个实验验证可行性，和评估工作量没有关系。对于新技术的不确定性，团队可以创建一个探针故事，以探索该技术的可行性。

85.估算用户故事规模的工具是故事点和理想时间。理想时间代表时间量，即不受会议，个人生活，非工作日或其他拖延、阻碍和分心的干扰的情况下，相对于待办事项列表中其他的用户故事，单独个人建立，测试和发布用户故事所花的时间。

86.敏捷倡导专注的价值观，认为人在一段时间内做一件事最有利于提高项目绩效，产出成果，如果一名开发人员在多个项目间工作是不妥当 的，应该保证每次在一个项目中工作，可以要求管理层确保该开发人员一次只能在一个项目中工作。

87.在迭代期间，团队需要持续获得产品负责人的反馈，以确保工作在正确的方向上。产品负责人主要负责确定产品的功能和达到要求 的标准，维护产品待办事项列表，指定软件的交付的内容，同时有权力接受或拒绝开发团队的工作成。

88.情商 –识别、评估和影响我们自己、其他人和团体的情绪的能力。管理敏捷团队，保持灵活领导 力的有效方式就是持续提升我们自身的情商（自我认知、自我控制、社会认知和社会技能）。要建立和维持好的团队氛围，提高团队绩效，需要你能够洞察多方需求及情绪的能力，也就是情商。

89.待办事项优先级排序，风险的高低与价值的大小进行优先排序，高风险且高价值的任务得到最优先执行。 风险和价值，两个维度分到四个象限：高风险、高价值的任务 ；低风险、高价值的任务 ；低风险、低价值的任务 ；高风险、低价值的任务（尽量避免，如果实在纳入进来，就放到最后处理）。

90.迭代遵守时间盒的概念，在既定的时段内进行相应的工作和活动，如果时间结束但计划工作没有完成，停止正在做的工作并将未完成的工作移到下一时间盒。 一个迭代结束时，未完成的故事点先要放回产品待办事项列表，产品负责人和团队重新评估其优先级，按优先级顺序决定下个迭代待办事项 列表，但这个故事点不一定会是优先级最高的。

91.看板实践中的队列补充会议类似于敏捷里的冲刺计划会议，用来计划下阶段的重点工作，包括障碍处理。评审会议上讨论在迭代期间遭遇到什么问题以及问题是如何解决的，回答“完成”的工作。发布计划在项目开始阶段进行，发布产品愿景，创建计划，与项目执行期间的障碍处理无关。

92.在产品评审会议上，客户查看产品演示，并且确认后续的工作重点，即待办梳理，产品负责人应该与客户一起确定待办事项列表优先级，确保按照价值进行优先级排序。

93.累积流图中显示的是交付周期、待办事项规模、剩余待办事项、周期时间和在制品。

94.高绩效团队的两个主要特点，一是工作方式自组织；二是设定挑战性目标，以实现绩效为根本目的。

95.“信息共享" "知识共享：知识共享对于大规模敏捷项目来说是一个重要的机制，知识共享会议需要同目标一样被清晰地定义，团队参与必须监 控去确保知识流转按照一个结构化方式进行。

96.随着项目的推进，迭代能够提供关于真实进展的强有力的证据，这时可以利用完成迭代的速率来判断实际绩效并估计未完成部分，当跟踪了 多次迭代的速率以后，就能够估计完成一个项目需要多长时间。

97.要防止问题的再次发生，需探究问题的根本原因，并积极采取措施。

98.迭代遵循时间盒的概念，时间盒是指针对某件事或某个目标，给定一个固定的可用时间，这个时间原则上不能缩小也不能放大，人们需要在这个给定的时间内尽全力去达成目标。在项目中，所有迭代具有相同的时长，保持时长一致可以帮助衡量开发团队的表现，并能更好地计划每次新的迭代。

99.在团队合作中取决于团队和项目是衡量团队绩效的有效标准，这种标准必须能在团队中能准确定义“正确的行为”，绩效测量也应该对团队中的特定情况进行定制分析。

100.只有产品负责人有权决定项目范围的变更。项目的进度目前已经落后，如果进行范围裁剪则必须要与产品负责人取得联系。

101.遇到风险，通常需要做两件事：曝光，刺探。在冲刺计划会上对风险进行全面识别风险，再找出解决方案属于风险应对过程。

102.在敏捷初期激励团队实现高绩效的有效方式是来自干系人尤其是客户或高层的反馈，如果可以看到功能/问题被更快更好地实现/解决，有助于群体推动实施敏捷。

103.没有价值的工作的优先顺序在产品待办列表里是比较低的，但是保持了需求的完整性（功能需求和非功能需求）。非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括安全性、可靠性、互操作性、健壮性等。所以非功能性需求不能直接进 行删除。

104.敏捷项目中，速度是指对每一迭代团队完成的用户故事点或故事数量的衡量。一个敏捷团队可根据稍前的速度记录来估算下一个迭代可完成 的用户故事点数量。

105.不同时区不同区域的敏捷团队鼓励使用在线合作工具，可以进行充分沟通，促进透明式沟通，在线看板是一种良好地远程协作工作。

106.会议的促进者主要职责是搭建平台，邀请众人共创，自己如果需要表达观点可以在其他人发言之后补充。

107.对于新技术、新框架的使用，可以专门安排一个需求条目进行研究，将该条目加入产品待办事项有助于区分优先级。

108.scrum 框架为团队提供了检查和适应的平台，是 scrum 中非常重要的活动。

109.头脑风暴法又称为自由思考法或集思广益会，用于在短时间内获得大量创意。在回顾会议上采用头脑风暴的方式可以获得尽可能多的想法，并处理该问题。

110.风险是之前已经记录到风险登记册中的，而负责干系人并未解决，通过提醒负责干系人风险的定性和定量影响，及时获得解决，简单的等待或者停止迭代开发工作都不是正确的选择，督促负责人及时解决才是最优的。

2021-10-22   21:29:18  记

须知少时凌云志，曾许人间第一流。