敏捷开发相关知识整理

敏捷开发相关知识整理，内容有生命周期、敏捷、创建敏捷环境、创建敏捷环境、敏捷实践概述，一起来看吧！

敏捷开发

• 生命周期
  • 项目周期类型
  • 项目周期 类型对比
  • 如何选择 合适的生命周期
    • 1、没有哪个生命周期能够完美适用于所有的项目 2、每个项目都能在连续区间中找到一个点，根据背景特征， 实现最佳的平衡；
  • 敏捷生 命周期
    • 生命周期 的计划
      • 1、无论采用哪种项目生命周期，项目都需要计划，计划始终贯穿其中 2、每种生命周期都有计划要素； 3、不同生命周期不同之处并非在于计划是否完成，而在于完成多少计划已经何时完成；
      • 不同生命周期的计划
        • 1、预测型：在连续区间的预测，是计划驱动着工作，项目最终一次性交付最终产品
        • 2、迭代型：计划了原型和验证，
        • 3、增量型：计划交付整个项目后续部分，团队可以提前计划可交付成果的若干次连续交付或者一次只计划交付一个。
        • 4、敏捷性：频繁交付对客户有价值的各种子集。
• 敏捷
  • 1、敏捷：是一种思维的模式，它由《敏捷宣言》的价值观所界定，受《敏捷宣言》原则指导，并通过各种实践实现。
  • 2、敏捷思 维模式
    • 《敏捷宣言》 四大价值观
      • 探索更好的软件开发方法，身体力行的同时也帮助他人 由此我们建立如下的价值观
      • 价值观
        • 个体和互动（团队成员）
          • 高于流程和工具
        • 工作的软件（交付物）
          • 高于详尽的文档
        • 客户合作（与客户 强调互动、合作）
          • 高于合同谈判
        • 响应变化（拥抱变化）
          • 高于遵循计划
      • 尽管右项有其价值，我们更重视左项的价值（变相看待事情）
    • 12大原则 （理解后自语内容）
      • 1、交付价值
      • 2、拥抱计划
      • 3、短周期原则--变化、价值
      • 4、客户合作，在一起工作
      • 5、团队成员互动工作
      • 6、面对面沟通
      • 7、可用的软件是衡量进度的主要指标
      • 8、开发的可持续性（交付稳定性）
      • 9、对技术精益求精以及对设计 的不断完善将提升敏捷性
      • 10、做到简洁
      • 11、自组织的团队（个体与组织的互动）
      • 12、定期反省，调整团队行为；
    • 敏捷实践/方法
      • 敏捷方法：是囊括了各种框架和方法的涵盖性的术语
      • 复核《敏捷宣言》的价值观和原则任何方法、技术、框架、手段实践
      • 将敏捷方法和看板的方法视为精益方法的子集。因为它们都是精益思想的具体实例都反映了诸下的概念：“关注价值”“小批量”“消除浪费”
• 创建敏捷环境
  • 如何判定组织是否 符合敏捷组织特征
    • 1、管理层的变革意愿
    • 2、组织在员工认知、审核和评估的方式上做出改变的愿景
    • 3、集中或分散项目、项目集合项目组合管理职能
    • 4、专注短期预算和指标而不是长期目标
    • 5、人才管理成熟和能力
  • 组织结构对敏捷 环境的影响特征
    • 地理
      • 地理分散的项目组织可能在各种项目中阻碍工作进展一些挑战
    • 职能结构
      • 具有高度职能结构项目可能在组织内部协作方面遇到很大的阻力；
    • 项目可交付 成果的大小
      • 缩小项目可交付的成果激励部门之间的频繁的交流，因此带来更频繁 的交换以及组织内部更快的价值交换
    • 项目人员分配
    • 重采购型组织
  • 如何与供应商共赢
    • 多层结构
      • 通过将合同中更多变化因素隔离到单独的 文档中，将会简化修改工作并提高灵活性
    • 强调价 值交付
      • 里程碑和支付项目可以根据价值驱动 可交付成果来构建，以增强项目敏捷性。
    • 总价增量
      • 项目可以将范围分解为总价值微可交付的成果
    • 固定时 间和材料
      • 将整体预算限制为因定数量，允许客户在最初来计划的项目中纳入新的观点和创新。如果客户需要纳入新的观点，则必须管理给定能力，用新的工作来替代原有工作。
    • 累进的时 间和材料
      • 共担财务风险法
    • 提前取消方案
      • 如果敏捷供应商在仅完成一半范围时便可交付足够的价值，且客户不再需要另外一半范围，则不必支付这部分费用，
    • 动态范围方案
      • 对于具有固定预算的合同，供应商可为客户提供在项目特定点改变项目范围的方案。客户可调整功能以适应该能力
    • 团队扩充
      • 大多数协作合同方法是将供应商服务直接嵌入客户组织中。通过资助团队而不是特定范围，可以保留客户自行确定需要完成工作这方面策略的权力。
• 创建敏捷环境
  • 敏捷PMO的 特点与职责
    • 特点
      • 1、敏捷PMO为价值驱动型： 所有项目都应该在适合的时间为合适的受众提供合适的价值
      • 2、为面向创新型
      • 3、为多学科
    • 职责
  • 项目经理角色 -仆人式领导
    • 1、从团队的中心转变成为团队和管理人员提供服务。 2、充当仆人式领导，其工作重点转变为引导需要帮助的人，促进团队的合作，保持与相关方的需要一致。 3、鼓励将责任分配给团队成员，分配给那些需要掌握完成任务所需知识的人
    • 仆人式领导的职责
      • 1、促进作用 2、消除组织障碍 3、为他人贡献铺路
    • 职责表现
      • 1、教育相关方，使其了解为什么要敏捷以及如何敏捷
      • 2、通过指导、鼓励和帮助为团队提供支持
      • 3、通过技术项目管理活动，如量化风险分析来帮助团队
      • 4、庆祝团队的成功，为团队与外部团队提供合作提供支持，并起到桥梁作用
  • 成功敏捷团 队的特征
  • 团队常见成员
  • 敏捷团队章程
    • 仆人式领导可以与团队一起决定处理其他行为。
    • 团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们作为团队的最大能力。
• 敏捷实践概述（下）
  • 迭代敏捷团队常用衡量工具
    • 燃尽图 （未完成）
      • 实线落于虚线说明进度落后，
    • 燃尽图 （已完成）
    • 速度
      • 1、本次选代中实际完成功能的故事点大小的总和;。 2、让团队得以通过观察历史表现来更准确地规划下阶段的能力。
    • 看板
      • 内容
        • 1、本次选代中实际完成功能的故事点大小的总和;。 2、让团队得以通过观察历史表现来更准确地规划下阶段的能力。
        • 核心三大原则：可视化、限制在制品、管理流动
        • 引入看板不需要改变任何流程，只让流转规则可视化，让每个人的分工透明化，不会给团队带来新的负担;
        • 通过看板的可视化，让团队决策的可视化，当我们关注看板反馈出来的“味道”时，很容易让成员理解团队的决策以及要解决的问题;
        • 看板活动不需要增加额外的角色。现有的团队成员就足够完成
        • 在看板方法中，完成工作比开始新工作更为重要。从未完成的工作中无法获得任何价值，因此团队将协作实施和遵从在制品(WIP)限制，让整个系统中的每份工作得以“完成”
      • 衡量的指标
  • 单团队敏捷实践
  • 多团队敏捷实践
• 敏捷实践概述（上）
  • scrum框架
    • scrum中3355
      • 3中角色
        • PO产品负责人 product owner
          • 1、客户代表 2.定义所有产品功施 3、决定产品发布的内容以及日期 4、对产品的投入产出负责 5、根据市场变化对需要开发的功能排列优先顺 6、合理的调整产品功能和选代顺序 7、认同或者拒绝选代的交付
        • 教练sm scrum master
          • 1、起到救练的职责 2、领导团队完成Scrum的实践以及体现其价值 3、排除团队遇到的困难 4、确保团队的胜任其工作，并保持高效的生产 5、使得团队紧密合作，使得团队个人具有多方面职能的工作能力 6、保护团队不受到外来无端影响
        • 团队 dev team
          • 1、经典团队拥有5-9人团队 2、成员都是多面手: 一程序员测试员,用户经验设计,等等。 3、团队成员都全职工作 - 特殊职能可以例外(例如,数据库管理员) 4、团队自我组织和管理 5、团队关系在一个迭代中应该是固定的， 个人的职能可以在新迭代开始时发生调整
      • 3种工件
        • 产品
          • 产品待办事项 product backlong
            • 1、产品需求的列表 2、包含业务需求、技术需求、NFR等 3、理想情况下，每一个待完成的工作都将对客户产生价值 4、PO对该列表进行优先级排序每个迭代开始前，优先级排 序还需要再度修正 5、待办事项列表中的条目以用户故事的形式呈现
        • 迭代
          • 迭代事项列表 sprint backlog
            • 1、Product Backlog的子集，只记录当前选代的工作 2、将用户故事拆分成任务，团队成员主动领取任务 3、团队成员有共同的迭代目标，为交付可工作的成果而努力 4、团队成员可以添加、制减或者更改选代中的任务 5、选代列表中的任务进行了估算，剩余工作量的估计每天需要更新
        • 产品增量
          • 潜在的可交付产品增量
            • 1、团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付 2、每次交付的用户故事必须符合验收条件 3、每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事
      • 5种仪式
        • 产品梳理会议
        • 迭代
        • 迭代计划
          • -第一个阶段:选取用户故事，确定选代目标PO与团队一起从Product Backlog中选择待完成的用户故事 第二个阶段:拆分任务，创建迭代backlog团队拆分和确认任务，给出工作量估算
        • 每日站会
          • 1、属性 - 每天都会开 -15分钟结束 - 站着开会 2、不是为了解决问题 -所有相关的人被邀请 -只有Scrum Master、Product Owner， Dev Team能够在会上发言 3、避免无关的讨论
        • 评审会议
          • 1、团队需要演示所完成的迭代工作 2、典型的做法是使用演示形式展示新功能或者底层 架构的实现 3、非正式的 2小时的提前准备 不需要正式演示文档 3、整个团队都需要参加 4、邀请所有关注产品的人参加
        • 迭代回顾会
          • 1、哪些工作良好 （应该继续保持) ? 2、哪些得不好《应该停止) ? 3、哪些可以改进《就被按忧先排序的改进的行动达成共识) ?
      • 5种价值
        • 5种价值：勇气、承诺、专注、开放、尊重
        • 三个支柱
          • 透明、适应、检视