Agile敏捷

Agile敏捷，符合敏捷价值观和原则的开发方法，敏捷项目启动和规划，看板方法的好处。有需要的小伙伴可以下载收藏哦~

敏捷

• 概念
  • 敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。
  • 四大价值观
    • 1.个体和互动高于流程和工具。
    • 2.工作的软件高于详尽的文档。
    • 3.客户合作高于合同谈判。
    • 4.响应变化高于遵循计划。
  • 十二条原则
    • 1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
    • 2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
    • 3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
    • 4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
    • 5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
    • 6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
    • 7.可工作的软件是进度的首要度量标准。
    • 8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    • 9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
    • 10.以简洁为本，它是极力减少不必要工作量的艺术。
    • 11.最好的架构、需求和设计出自自组织团队。
    • 12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。
• 符合敏捷价值观和原则的开发方法
  • 1.Scrum
    • Scrum是以经验性过程控制理论(经验主义)为理论基础，主张知识源于经验，以及基于已知的东西做决定。
    • 适应型(敏捷)：Scrum框架
      • undefined
    • Scrum采用迭代、增量的方法来优化可预见性并控制风险。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个冲刺(Sprint) 。
    • 产品backlog
      • 用来管理产品需求和开发任务
      • 按照商业价值(或实现优先级)排序的事项列表
      • 列表条目的体现形式通常为用户故事
    • 在规划Sprint时，Scrum团队从产品Backlog中挑选最高优先级的需求，在Sprint计划会议上经过讨论、分析和估算得到相应的任务，并分配给具体的成员去实现。
    • 重要特征
      • 1.迭代式开发
        • 开发周期分成多个1-4周的迭代
      • 2.增量交付
        • 无论产品负责人是否决定真正发布它，增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。
      • 3.自组织团队
        • 有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。
      • 4.高优先级的需求驱动
        • 使用 Product Backlog 来管理需求
          • 需求是渐进明细的、 经过优先级排序的
          • Scrum 团队从 Backlog 最上层的高优先级的需求开始开发
        • 在 Scrum 中，只要有足够 1-2 个 Sprint 开发的细化了的高优先级需求就可以启动 Sprint 了
        • 在开发期间可以通过 Backlog 的梳理来逐步地细化需求
    • 一些工件概念
      • 1.Sprint--冲刺
        • 它是组成整个开发过程的一个短的迭代周期成为一次冲刺
        • 一个 Sprint 是指一个1~4周、有明确生产计划和产出的迭代周期
        • 组成部分
          • 1.Sprint 计划会议
            • 时间
              • 在新的迭代开始前进行
              • 一般来说， Sprint 时间 4 周， 会议时间为 8 小时； Sprint 时间 2 周， 会议时间为 2 小时。
            • 参会角色
              • 整个Scrum团队
                • 即产品负责人、主管、开发团队
            • 会议目的/内容
              • Sprint 计划会议回答以下问题:1.接下来的Sprint交付的增量中要包含什么内容?2.要如何完成交付增量所需的工作?
            • 会议具体形式
              • 1.需要完成哪些工作
                • 步骤1：由产品负责人向开发介绍排好顺序的产品待办任务
                • 步骤2：迭代中需要完成的产品待开发项数目由开发团队决定。
              • 2.如何完成工作
                • 步骤1：开发团队需要根据当前的“完成的定义”一起决定如何实现下个产品增量。
                • 步骤2：迭代计划会议最终需要Scrum团队对迭代需要完成工作的数量和复杂度达成共识。并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。
          • 2.每日站会
            • 时间
              • 每天进行
              • 15分钟以内完成
            • 参会角色
              • 整个Scrum团队
                • 即产品负责人、SM、开发团队
            • 会议目的/内容
              • 开发团队为接下来的 24 小时的工作制定计划
              • 范例
                • 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
                • 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
                • 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？
            • 每日站会中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。
          • 3.Sprint Backlog开发工作
            • 是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。
            • 迭代待开发项是由产品待开发项分解而来的一系列的项。
            • 是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。
            • 将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。
          • 4.Sprint 评审会议
            • 时间
              • 在 Sprint 快结束时举行
              • 对于一个月的 Sprint 来说，评审会议时间最长不超过4小时。对于时间较短的Sprint来说，会议时间通常会缩短。
            • 参会角色
              • Scrum 团队
                • 即产品负责人、主管、开发团队
              • 利益相关者
                • 比如客户或者高层领导
            • 会议目的/内容
              • 用以检视所交付的产品增量并按需调整产品待办列表
              • 根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。
              • 这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
              • 主要内容包括
                • 1.产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
                • 2.开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
                • 3.开发团队演示“完成”的工作并解答关于所交付增量的问题；
                • 4.产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标
                • 5.交付日期（如果有需要的话）；
                • 6.参会的所有人就下一步的工作进行探讨，然后Sprint 评审会议就能够为接下来的Sprint 计划
                • 7.会议提供有价值的输入信息；
                • 8.评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；
                • 9.同时，为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
          • 5.Sprint回顾会议
            • 时间
              • 在Sprint 评审会议结束之后，下个 Sprint 计划会议之前
              • 对于长度为一个月的 Sprint 来说， 时长不超过 3 小时
            • 参会角色
              • Scrum 团队
            • 会议目的/内容
              • 是Scrum团队检视自身并创建下一个 Sprint 改进计划的机会
              • 目的和内容
                • 1.检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
                • 2.找出并加以排序做得好的和潜在需要改进的主要方面；
                • 3.同时，制定改进 Scrum 团队工作方式的计划。
          • 并产出可交付的产品增量
        • 每个Sprint结束即可向需求方提交一次版本更新
          • 未完成的任务须退回到待办事项列表中
      • 2.Backlog--待办事项列表
        • 用来管理用户需求和任务，并通过及时梳理来响应需求变更
        • Scrum的产品Backlog是一个按照商业价值(或实现优先级)排序的事项(需求)列表，记录经过识别、分解和估算的用户需求和任务。
      • 3.Issue--事项
        • 经过识别解析得到的用户故事、开发任务、测试得到的BUG等等统称为事项(Issue)
        • 事项1：Story--用户故事
        • 事项2：Epic--史诗
        • 事项3：Task--任务
        • 事项4：Improvement--改进
        • 事项5：New feature--新特性
        • 事项6：Bug--缺陷
      • 4.Priority--事项优先级
      • 5.Burn-down Chart--燃尽图
        • 1.冲刺燃尽图
        • 2.交付燃尽图
      • 6.Fist-of-five--举手表决
        • 紧握拳头：不，我完全不同意。1 根手指：我非常担心。2 根手指：我想讨论一些小问题。3 根手指：我不完全同意但我可以接受意见通过而不须进一步讨论。4 根手指：我认为想法不错且愿意为其工作。5 根手指：想法棒极了，执行时我愿意带头。
      • 7.需求空间、开发空间和测试空间
        • 1.需求空间
          • 存放、描述项目所有待实现的需求，表现为Product Backlog，由PO主导并管理，所有团队成员可以参与梳理。
        • 2.开发空间
          • 包含项目正在开发实现的所有事项，表现为Sprint Backlog和 Scrum Board，在Scrum Master指导下由开发团队共同管理。
        • 3. 测试空间
          • 管理项目的测试计划和测试用例，是项目的一系列质量目标和验收标准，由 QA主导管理。
          • 当Sprint 开始后，QA根据User Story编写对应的测试用例，加入QA 空间；当开发人员提交到To QA 后，QA 根据测试用例执行测试，反馈测试结果。此外，还包括其他不同级别的测试计划和用例。
    • Scrum中的基本角色和职责
      • Pigs角色
        • 项目的实际参与者，必须直接对Story负责，必须在站立会中发言，说明完成的工作，将要的工作，遇到的困难等，即一般意义上的Scrum 团队。
      • Chickens角色
        • 项目的外围及外部成员，包括组织内各方面的领导、最终用户以及项目的其他利益相关者，也包括某些参与项目实施但不用对Story 负责任的外围成员。
      • Scrum团队(Pigs)
        • 概述
          • Scrum团队是跨职能的自组织团队。跨职能团队拥有完成项目全部工作所需的全部技能，不需要依赖于团队之外的人。自组织团队通过内部的决策机制来自我选择如何以最好的方式完成工作，而不是由团队之外的人来指导。
          • Scrum团队迭代、增量式地交付已完成的产品，借此最大化地从用户获得需求范围内的反馈，从而进行滚动式的需求细化，并努力避免后期返工。“已完成的产品” 表明每次交付给用户的产品必须是潜在可工作的，可以不完善、不细致但是至少必须是可以让用户上手体验的。
        • 1.Scrum Master (SM, 开发经理/实施经理)
          • 职责
            • Scrum Master负责保证所有人都能正确地理解并实施Scrum，确保Scrum团队遵循Scrum的理论、实践和规则。
            • 服务对象
              • 服务于产品负责人
                • 1.确保Scrum 团队中的每个人都尽可能地理解目标、范围和产品域;
                • 2.找到有效管理产品待办列表的技巧;
                • 3.帮助Scrum 团队理解为何需要清晰且简明的产品待办列表项; .
                • 4.理解在经验主义的环境中的产品规划;
                • 5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值;
                • 6.理解并实践敏捷性;
                • 7. 当被请求或需要时，引导Scrum事件。
              • 服务于开发团队
                • 1. 作为教练在自组织和跨职能方面给予开发团队以指导;
                • 2.帮助开发团队创造高价值的产品;
                • 3.移除开发团队工作进展中的障碍;
                • 4.按被请求或需要时，引导Scrum事件；
                • 5.在Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
              • 服务于组织
                • 1.带领并作为教练指导组织采纳Scrum;
                • 2.在组织范围内规划Scrum的实施;
                • 3.帮助员工和利益攸关者理解并实施Scrum 和经验导向的产品开发;
                • 4.引发能够提升Scrum团队生产率的改变;
                • 5.与其他Scrum Master一起工作，增强组织中Scrum 应用的有效性。
          • SM一般由组织任命
            • 一名优秀的SM能够同时受到团队内成员（Pigs）的支持和外部利益攸关方（Chickens）的信任。
            • 对内，SM充当团队的服务型领导者和敏捷教练员；对外，SM充当团队与利益攸关者沟通的桥梁，帮助他们了解、理解与支持团队工作，从而为团队屏蔽外部干扰并消除障碍。
        • 2.Product Owner (PO，产品负责人)
          • PO对代办事项列表的管理包括
            • 1.清晰地表述产品待办列表项;
            • 2. 对产品待办列表项进行排序，使其最好地体现工作优先级、目标和使命;
            • 3.优化开发团队所执行工作的价值;
            • 4.确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum 团队下一步要做的工作;
            • 5.确保开发团队对产品待办列表项有足够深的了解。
          • 产品负责人可以自行完成上述工作、与Scrum Master 一起完成 上述工作，甚或与整个开发团队共同完 成对Product Backlog的梳理，但是PO必须是Product Backlog的最终负责人。任何人想要修改Product Backlog,包括改变需求或优先级，必须经过PO来执行。没有人可以强迫团队按照另一套需求来工作。
        • 3.Scrum Team (团队)
          • 开发团队具有这些特点
            • 1.他们是自组织的。没有人(即使是Scrum Master) 有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量;
            • 2.开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能;
            • 3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作，他们都叫开发人员;
            • 4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析;
            • 5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
          • 开发团队包含完成产品开发所需的各类专业人员， 负责在每个Sprint 结束时交付潜在可发布并且“完成”的产品增量。 开发团队由组织组建并获得授权， 通过内部的敏捷决策机制（各种不同功能的会议） 自己组织和管理开发工作。
          • 产品负责人和 Scrum Master 角色不包含在开发团队人数中，但是Scrum Master 和 Product Owner 本身也可以从事开发工作， 这个时候他们也是开发团队的一员。
    • 需求解析与管理
      • 概述
        • 在Scrum中，用户需求被解析成Epic和Story，置于Product Backlog 中进行管理。Epic和Story并没有统一的划分标准，一般可认为Epic（史诗）是有一系列相互联系的Story（故事） 组成的故事集。 实践中，我们可以把系统模块识别为Epic，再从Epic中解析出足够细致的User Story。 或者说，我们用 Epic来描述需求范围， 用Story来定义需求明细。
        • 例如
          • Epic模块名称：费用管理
          • 费用管理的场景1Story：公司财务要实现费用科目限制
          • 费用管理的场景2Story：总部要实现不同区域部门的预算下放
          • 费用管理的场景3Story：区域员工要实现业务费用报销
      • 1.需求分析
        • 概述
          • 该过程需要全员参与，这有助于及时发现团队成员对同一个需求理解不一致的问题， 可以在很大程度上避免缺陷的引入，也有助于规避人力风险。
          • 全员参与的需求分析活动需要一个扮演导师角色的人带领大家去进行有效的需求分析，Product Owner需要承担起这个责任，Scrum Master可以为Product Owner如何胜任敏捷开发中的需求指导和 管理工作提供指导和协助。
          • 用户需求由 3 个要素组成
            • 需求描述
            • 需求优先级
            • 故事点(工作量)
        • 1.What or How
          • 需要强调： 需求分析是为了准确地描述问题， 而非寻求如何解决问题。
        • 2.需求描述： 完整、 合理、 一致和兼容
          • 敏捷提倡客户价值导向， 应当从客户价值角度描述， 就是描述客户想要什么， 而不是描述技术层面如何实现
          • 对于不合理的需求应该及时拒绝， 否则不仅浪费了团队资源， 系统上线后还可能给利益相关方带来损失
        • 3.确定需求的优先级
          • 确定优先级通常从 5 个方面考虑
            • 1. 经济价值
            • 2.所需成本
            • 3.学习和获取知识的重要性和数量
            • 4.风险
            • 5.客户需要
          • 一般PO都会选择采用风险-价值矩阵来评估需求优先级。
          • 需要完成的优先级排序
            • 1.相对高价值-高风险的需求
            • 2.高价值-低风险的需求次之
            • 3.低值-低风险的需求再次之
            • 尽可能推迟甚至避免开发低价值-高风险的需求
        • 4.估算Story Point
          • 即对需要做的事情或任务进行工作量的估算
          • 对工作量的估算应当以 User Story 为基础
            • Epic 的整体工作量体现在分解得到的 Story 的工作量的总和以及集成成本上。
          • 用户故事的工作量以故事点（Story Point）来衡量
            • 对工作量应当估算大小，而不是估算时间周期，使用相对估算，而不是绝对估算。
            • 在项目中，可以预设一个基准故事，例如，把实现用户认证页面的故事点定为1，以后每个用户故事都相对于“用户认证页面”这一故事来衡量工作量
      • 2.需求管理
        • 在敏捷实践中，对需求的管理有两种常见方法：完全解析和滚动解析。需求管理体现于一个重要活动： Product Backlog梳理
        • 1.完全解析
          • 完全解析后，项目的需求变得一目了然
            • 1. 需求优先级十分明确， 能够画出细致的路线图；
            • 2. 项目的工作量和工期能够较精确地估算；
            • 3. 能让团队形成项目一切尽在掌握中的自信。
          • 对于需求简单的小项目而言
            • 完全解析有助于全面、 完整地把握项目， 控制项目进度， 并且也比较容易梳理和保持 Product Backlog 的条理性
          • 对于复杂度规模的项目而言
            • 完全解析可能导致Product Backlog管理混乱。长长的Backlog 列表难以组织和梳理，难以对需求进行解耦和确定优先级。并且由于需求是涌现的，频繁的需求变更往往会加重 Backlog的混乱程度， 增加无效工作
        • 2.滚动解析
          • 滚动解析是将需求分解和增量交付有机结合起来。
          • 滚动解析是为了在保证需求的完整性、 合理性和一致性的前提下， 尽可能缩短需求定义和开发之间的时间间隔， 降低管理难度， 控制风险和成本。
        • 3.Product Backlog梳理
          • 该活动包含但不限于这些内容
            • 1. 保持产品待办事项列表有序；
            • 2. 把看起来不再重要的事项移除或者降级；
            • 3. 增加或提升涌现出来的或变得更重要的事项；
            • 4. 将事项分解成更小的事项；
            • 5. 将事项归并为更大的事项；
            • 6. 对事项进行估算。
          • 排序越靠前， 优先级越高， 描述和解析越细致
  • 2.极限编程(XP)
    • 是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。
  • 3.看板方法
    • 它是一种受到看板库存控制系统启发的敏捷方法，专门用于知识工作。拉式计划。
  • 4.水晶方法
    • 它是轻量级敏捷软件开发方法的集合，其重点关注特定情况的适应性。需要一系列轻量剪裁的策略、实践和过程，以匹配项目的独特特征。
  • 5.SCRUMBAN
    • 它是一种在团队选择Scrum作为工作方式时产生的管理框架，它以看板方法作为透镜从而审视、理解并持续改善其工作。
  • 6.功能驱动开发(FDD)
    • 它是一种从客户重视的功能角度出发的轻量级敏捷软件开发方法
  • 7.动态系统开发方法(DSDM)
    • 它是一种敏捷项目交付框架。倡导以业务为核心，快速而有效地进行系统开发。可以把DSDM看成一种控制框架，其重点在于快速交付并补充如何应用这些控制的指导原则。
  • 8.大规模敏捷框架(SAFe)
    • 它是一个集成模式的知识库用于企业范围的精益开发。
  • 9.大规模开发(LeSS)
    • 大规模敏捷开发是一种产品开发框架，它根据扩展指导方针扩大敏捷开发规模，同时保留原有的敏捷开发目的。
  • 其他方法
    • 持续集成
    • 结对编程
      • 主要指编程的结对工作。两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员(或导航员)。两个程序员经常互换角色。
    • 精益软件开发 (LSD)
      • 是软件开发领域的精益制造原理和实践它基于一套旨在满足质量、速度和客户定位要求的原理和实践。
    • 测试驱动开发 (TDD)
      • 测试驱动开发是先定义验收测试然后围绕这些测试实际模块、等级和功能，软件根据怎样会被接受这一前提而编写。当按此正确完成后，软件肯定能通过测试并被验收。
      • 它是在工作开始前定义测试的一种技术，它采用零缺陷的思维模式使工作进度能持续得到确认。在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码。
    • 行为驱动开发 (BDD)
      • 它是一种系统设计和确认实践，采用测试优先的原则和类似英语的脚本。BDD更加侧重设计，其要求在设计测试用例的时候对系统进行定义，倡导使用通用的语言将系统的行为描述出来，将系统设计和测试用例结合起来，从而以此为驱动进行开发工作。
    • 验收测试驱动(ATDD)
      • 它是一种协作制定验收测试标准的方法，用于创建交付前的验收测试(以终为始)。
    • Spike刺探（时间盒研究或实验）
      • 刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助
  • 这些开发方法都符合这些特征
    • 1.迭代式开发
    • 2.增量交付
    • 3.开发团队和用户反馈推动产品开发
    • 4.持续集成
    • 5.开发团队自我管理
• 敏捷项目启动和规划
  • 启动和规划过程
    • undefined
  • 1.编写章程
  • 2.建立初步Backlog
  • 3.建立公司地图
  • 4.用户公司及估算
  • 5.定义DoD(完成标准)
  • 6.发布Backlog
• 3355
  • 三个角色
    • 产品负责人、主管、团队
  • 三个工件(团队工作的对象)
    • 1.Product Backlog 产品待办事项列表（用户故事地图）
    • 2.Sprint Backlog 迭代待办事项列表（ To Do - Doing - Done）
    • 3.Product Increment 产品增量
      • 产品增量是 Sprint 完成的、 潜在的、 可发布的产品的组成部分
      • 在Sprint的最后，新的增量必须是完成的，这意味产品增量必须能用，而且达到了Scrum 团队定义的完成标准，增量必须达到可发布的状态。
  • 五个活动：有时候是0~4--五个有时候是1~5--五个有时候是1~4--四个
    • 5 种仪式（团队要执行的 5 个典型事件）
      • undefined
      • undefined
    • 0.Sprint(冲刺)
      • Sprint是Scrum的核心。Sprint 的持续时间一般可以选择1~4周，最长不超过一个月。整个开发过程中期间Sprint的长度保持一致。前一个Sprint 结束，后一个Sprint 就紧接着开始。
    • 1.Sprint 计划会
      • 在新的迭代开始前进行
      • 一般来说， Sprint 时间 4 周， 会议时间为 8 小时； Sprint 时间 2 周， 会议时间为 2 小时。
      • 主要人员
        • PO和团队
      • 会议目的/内容
        • Sprint 计划会议回答以下问题:1.接下来的Sprint交付的增量中要包含什么内容?2.要如何完成交付增量所需的工作?
    • 2.每日 Scrum 站会
      • 15分钟内完成
        • undefined
      • 主要人员：团队
    • 3.Sprint 评审会
      • 发生在 Sprint 接近尾声的时候
        • undefined
      • 主要人员：团队和客户
    • 4.Sprint 回顾会 (复盘会议)
      • Scrum团队进行回顾总结，识别出改进项，在下一个Scrum中进行实施。
      • 评审会议结束后可以开
      • 回归整个工作过程
        • undefined
      • 主要人员: Scrum主管，团队
    • 5.Backlog Refinement-待办事项列表的细化(产品梳理)
      • Product Backlog的梳理和渐进明细，可以发生在整个Scrum周期的任何时间
      • 主要人员: PO、外部需求干系人、架构师
  • 五个价值观
    • 勇气、专注、承诺、尊重、开放
• 看板方法的好处
  • 1.提高效率。检查每个任务，了解增值或非增值活动，然后清除非增值活动。
  • 2.团队成员专注力。限制在制品，使团队能够专注于当前工作。
  • 3.减少浪费。透明将会使浪费可视化，因而能够消除浪费。