- 1机器学习算法之命名实体识别（NER）详解_ner模型python
- 2目标检测标注原则_labelimg对于遮挡目标需要标注吗
- 3jquery 过滤子节点事件_jq排除掉子集的点击事件
- 4数据结构——算法竞赛中熠熠生辉的两朵金花—“栈“和“队列“_算法竞赛中会用到结构体吗
- 5排序算法小结
- 6艾永亮：通过微信和QQ的交互对比，谈超级产品是如何诞生的_微信与qq交互
- 7使用eNSP配置MGRE实验
- 8MapReduce集群的安装与部署_mapreduce安装部署
- 9Github-Action-Workflow-概念和基本操作_github workflows
- 10实战项目-用户评论数据情绪分析_设计一个评论的情绪分类网络,输入为长度不等的英文评论
我所参与的Agile实践总结_scrum po fo
赞
踩
谈起#敏捷#(#Agile#), 很多人非常推崇, 认为是提高团队交付能力的利器; 也有人不以为然, 认为徒有虚名, 换汤不换药, 今天就讲一讲我司的极致敏捷之旅, 在我司的不懈努力和大量付出之下, 敏捷水平有了极大提高,无论是团队交付能力, 还是团队的凝聚力, 代码水平,都有很大改善.
12-factor-app
就像12-factor-app重新清晰地定义了开发的12个基本要素, 使得开发Cloud应用有了清晰地开发方法论一样, 这里介绍的敏捷十五式, 也是富有实践性的敏捷经验的总结和升华, 富有实践经验和指导意义.
这十五个敏捷实践, 是本人在最近两年在工作中担任Scrum Master, 也就是项目组内的敏捷大师, 所一直参与和实践的, 是公司部门层面所推广的"敏捷从开始到卓越计划"的组成部分, 大概用了一年的时间,实现了大部分基本维度的卓越水平;例如, 我们在每个迭代都会在小范围内进行水平比较, 每个月都会和其他团队在大范围内进行打分和评比; 还有各种自评和同行评比,等等;可以说是充分践行了这些敏捷操作, 而且效果良好.
对于一个优秀和富有产出的团队而言, 基本上每个维度都可以拿到高分; 对于不是那么优秀的团队, 经过对这十五个维度敏捷的不断实践, 最终都能提升团队的产出, 战斗力, 使之成为一流的团队.
因此, 这十五个维度可以说是真正的敏捷实践, 值得每个团队去尝试和践行. 当然, 提升不是一蹴而就的, 需要一个相对长的过程, 团队需要耐心和恒心去完成这件事情.
敏捷开发十五式
Scrum 简介
我们团队采用的是敏捷技术是Scrum, 因此需要先对Scrum 有个基本理解.
Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。
在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。
Scrum团队总是先开发对客户具有较高价值的需求。
在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。
挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。
在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
SCRUM框架包括3个角色、3个工件、5个事件、5个价值
3个角色
- 产品负责人（Product Owner）
- Scrum Master
- 开发团队
3个工件
- 产品Backlog（Product Backlog）
- SprintBacklog
- 产品增量（Increment）
5个事件
- Sprint（Sprint本身是一个事件，包括了如下4个事件）
- Sprint计划会议（Sprint Planning Meeting）
- 每日站会（Daily Scrum Meeting）
- Sprint评审会议（Sprint Review Meeting）
- Sprint回顾会议（Sprint Retrospective Meeting）
5个价值观
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
如何进行Scrum开发？
- 首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
- Scrum Team根据Product Backlog列表，做工作量的预估和安排；
- 有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
- Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
- 在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
- 做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
- 当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
- 最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
十五个敏捷实践--敏捷十五式
整体而言, 敏捷十五式有如下十五个实践,涵盖了工作中的方方面面, 同时, 在这十五个维度之下, 每个维度又分为5个水平阶段, 这样就形成了15X5的矩阵结构
一 、和产品负责人密切合作(Engaging the Product Owner)
在敏捷中, #产品负责人#(#Product Owner#, PO) 就是整个开发的'指挥棒'和指挥官,通过展示，计划，进度和团队会议来支持定义和优先级.
Product Owner
从上面的图中, 我们可以看出, 产品负责人,也就是PO的责任是很多也很重的.Scrum称其为产品负责人而不是产品经理是有原因的。产品负责人拥有产品的全部所有权，而不仅仅是管理小队的用户故事。作为产品所有者，这也意味着利益相关者应尊重产品所有者的决定。
作为产品所有者，产品所有者面临不断变化的困境，始终处于困境之中。 PO应该听谁的？他/她可以拒绝首席执行官的要求吗？在产品待办事项列表中，哪个先行？技术债务，架构，技术卓越性，功能，缺陷？ PO如何管理他/她的日常日程？产品负责人应如何支出预算？产品负责人应该优化什么？流量还是价值？ PO应该使用什么度量标准？良好的Sprint目标看起来如何？精益用户体验和设计思维如何帮助产品负责人？
这些都是PO 需要回答的问题.
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 团队不了解谁是产品负责人 | 利益相关者意识到产品负责人的责任 | 产品负责人参与验证工作的定义 | 关于如何协同工作的可见和书面协议（就绪定义，完成定义，MVP范围，角色和职责等） | 产品负责人完成培训 |
| 产品负责人不参与工作计划 | 确定了产品负责人 | 产品负责人可能并不总是与团队保持联系，而是抽出时间回答问题并根据需要提供指导 | 明确定义采购订单需要参加的敏捷仪式以及何时发生 | 明确角色和职责 |
| 利益相关者主管不了解PO的职责 | 产品负责人参与了初始工作的定义 | 产品负责人参加大多数敏捷仪式 | 产品负责人出席所有展示 | PO和团队的行为与定义的角色和职责保持一致 |
| 产品负责人在交付后或展示期间进行审查工作 | 与小队执行初步的PO评估并同意采取行动以改进 | 产品负责人会定期地检查,进行跟踪和重新评估 | 清晰的升级路径 | |
| PO会定期整理和优先处理积压的订单。 | 维护和重新访问的协议，例如在工作方式，团队中或PO内发生变化时 |
二、 用户故事(USER STORIES)
用户故事, 也就是#User story#, 是一系列待开发的产品特性和功能点), 是用户需求的体现和清晰表达.
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
用户故事模板
用户故事的INVEST 原则和SMART 原则:
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 工作定义不明确或不够结构化 | 项目范围已映射到比较大的产品特性上 | 对于当前版本
| 相关的利益相关者（分析师，开发人员，测试人员，主题专家）参与了故事的定义，估计和阐述 | 不断改进估算方法 |
| 使用详细的规范文档获取工作需求 | 使用产品特性( feature)来从高层次地描述工作，并用于计划和进度跟踪 | 对于将来的版本：
| 为每个故事定义并同意接受标准 | 明确的验收标准，完成的定义和就绪的定义 |
| 没有把工作分解为有意义的组成部分,并没有这样的考虑或者尝试 | 功能优先进入发布计划 | 故事总是可以在迭代中完成。 | 使用Gherkin语言来描述明显的,有价值的输出 | |
| 估计与当前发行版相关的所有故事，从而使发行版燃尽。 | 用户故事可以在迭代中很好地完成–在迭代中没有观察到“迷你瀑布”。 | |||
| 故事得分(story point)不是时间的代名词，而是对工作量，复杂性，风险等的抽象度量 | 用户故事符合I.N.V.E.S.T. 原则（独立，可协商，有价值，可估计，小型和可测试）。 |
三 、迭代计划(Sprint Planning)
迭代计划会议(#Sprint Planning#)是敏捷中的重要会议, 用来确定一个迭代的目标, 在会议上通过协作确定，定义和计划工作和可交付成果.
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 不存在计划（发布或迭代） | 较大的发行版分为几个较小的部分 | 一些关键的利益相关者（赞助人，企业主和指导委员会成员）参加了发布的定义和发布 | 所有主要利益相关者（赞助商，企业所有者和指导委员会成员）都参与发布定义和启动 | 使用历史速度作为迭代计划中的关键输入 |
| 在交付之前，计划是在没有团队输入的情况下创建的 | 发布计划和迭代计划由项目经理/迭代经理定义，核心团队的参与有限 | 团队可以看到发布和迭代计划，但其他人可以完成（例如PM或IM） | 迭代计划由团队完成并拥有 | 在发布和迭代计划中都可以观察到持续改进 |
| 计划基于一个主要版本，不考虑较小的增量版本 | 发布和迭代计划未进行调整以反映不断变化的优先级。 | 测量并报告计划中与交付中的差异。 | 发布计划得到积极维护，并准确反映了团队当前对工作，时间安排，资源，依存关系等的理解。 | 发布计划清晰可见，在关键仪式（例如，展示台）上展示，推动强有力的对话并不断调整。 |
| 计划中与交付中的差异没有得到一致的衡量或报告。 | 由于计划的工作与交付的工作有所不同，因此未对发布计划和迭代计划进行调整。 | 滑块(Sliders)用于通知计划 |
四、 站会(Stand-ups)
站立会议(stand up), 又称每日例会, 是在迭代期间定期的团队协作会议，团队成员之间用来共享进度，识别风险并提出阻碍进度的问题.
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 没有定期的团队机会分享工作进度 | 举行独立会议，但不定期 | 站立会议定期举行，但通常由迭代管理器/项目经理或其他主持人发起（否则就不会发生） | 站立会议很少会被任何核心团队成员错过，无论出席人数如何，会议仍然会举行 | 团队成员愿意提供帮助，并同意使其脱机以进行进一步的讨论。 |
| 通常情况下，会议可能会很长，与会人员的参与度有限 | 核心团队的出勤可能是断断续续的 | 在每次会议上，所有核心团队成员都会回答以下三个问题：“上次见面后我做了什么”，“下一次见面前我打算做的事情”，“阻碍我或可能阻碍我的事情” | 核心团队成员在回答3个问题时使用可视墙并指出他们正在做的工作 | 团队成员标记当天要进行的工作交接，并确保收件人准备好接收卡。 |
| 会议参加者被迫或有义务参加，而不是意识到会议的价值并自愿参加 | 团队成员的更新仅关注状态，对风险或问题的了解有限 | 地理位置遥远的团队成员通过电话参加站立会议 | 会议之前更新工作墙 | 团队成员彼此保持联系，以应对工作失败和延误。 |
| 团队成员不清楚正在进行的工作或阻碍进度的问题 | 地理位置遥远的团队成员感觉正常地包含在“站立训练”中，并且能够查看和听到进度更新 | 团队成员可以自我维护站立的简短性和规则。 | ||
| 团队成员通常会执行其他报告以突出显示已完成的工作 | 在站立期间识别出的阻止者和挑战已分配给所有者，以便可以消除障碍 关注结果而不是谈论活动 | 向团队讲话/不向迭代管理器更新。 | ||
| 可以观察到清晰的精力和紧迫感 |
五、展示会议(Showcases)
展示会议是一个迭代里面成果的展示,团队将他们到目前为止所做的工作展现给利益相关者或潜在的最终用户或业务用户的面前, 展示成就并听取意见和建议.
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 不定期举行的展示柜不一致 | 主要版本发布后举行的展示 | 展示会在迭代之后和发布之前定期进行 | 一致地举行和参加 | 倾听利益相关者的反馈并从中学习，并根据此新信息对下一步进行调整 |
| 部署后需要反馈 | 发布时要求提供反馈 | 该演示主要针对利益相关者。 | 审查已完成的工作并讨论下一步的工作 | 吸引合适的受众：所有对产品感兴趣的人，尤其是关键利益相关者 |
| 团队正在为产品负责人而不是利益相关者进行演示 | 一些利益相关者参加 | 请求的反馈和积压的变更请求 | 整个团队都参与进来 | 由PO领导的用户和执行干系人 |
| 收集并验证指标 | 利益相关者详细和验证的指标 | 随着采用率的提高共享度量标准和变更计划 | ||
六、回顾反思会议(Retrospectives)
回顾反思会议,Retrospective meeting, 在我们的实践里是一个迭代的最后一个会议, 是团队内成员的自我反思和提升, 在这个会议上, 团队成员在一起,畅所欲言,或者围绕一个特别的主题展开讨论, 用于识别问题和解决方案, 这种团队活动是敏捷中团队不断地持续改进的基础.
Scrum Retrospect meeting
Scrum Retrospective meeting
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 没有使用持续改进实践来发展工作实践 | 进行回顾，但不能定期举行 | 定期进行回顾，并会采取行动 | 核心团队始终如一地参加回顾会议，他们为具体的适应/行动做出了积极的贡献 | 所有Retros都有可衡量的改进 |
| 决策是即时做出的，缺乏事实依据 | 回顾活动的定义不明确 | 回顾通常由同一个人负责 | 上一次回顾反思会的选中的决策行动都已经完成 | 优先将行动项分配给所有者-并进行良好跟踪 |
| 在不了解问题的情况下实施解决方案 | 没有采取行动或没有采取行动 | 回顾反思会的出席者的人数不一致 | 决策基于事实，解决了问题的根本原因，很少需要重新考虑 | 回顾包括对指标和敏捷仪式（在迭代过程中发生）的审查 |
| 实施后的审核是反馈的唯一来源 | 有一种“经历动作”的感觉 | 使用根本原因分析(RCA)来制定决策，但通常会重新考虑决策 | 在部落和子域级别进行回顾后分享改进成果 | |
七、以客户为中心(Being Customer Centric)
整个敏捷活动中, 要始终专注于给客户提供良好的体验.
Being Customer Centric
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 没有收集客户反馈的结构方法 | 最终用户有提供反馈的明确方法 | 最终用户提供定期反馈，并使用洞察力计划未来版本 | 最终用户是扩展团队的一部分 | 最终用户在整个项目生命周期中提供反馈 |
| 偶尔的反馈不会传达给开发人员 | 反馈会反馈给开发人员，但不会直接来自最终用户 | 最终用户通过专用渠道提供直接反馈并请求新功能 | 最终用户的反馈可以在系统内捕获 | 最终用户参加展示 |
| 客户/最终用户不是整个团队的一部分 | 没有工具来跟踪功能使用情况 | 最终用户对功能的使用情况可通过一些工具进行跟踪 | 团队拥有适当的机制来听取用户的直接反馈 | PO或班组成员遮蔽用户以更好地了解他们的体验 |
| 根据用户反馈开发新功能并确定其优先级 | 有关系统使用情况的详细指标和用户反馈可为PO决策和计划提供依据 | |||
八、记录指标(Recording the Metrics)
指标, 度量标准(Metrics), 是保持正确方向前进的关键，以获得正确的结果并快速，轻松地做到这一点。
Recording the Metrics
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 指标未记录 | 确定重要指标 | 团队了解指标的价值以及他们如何帮助学习和改进流程。 | 团队只评估真正重要的事情。 | 能够自动加载指标 |
| 团队不喜欢或不在意指标 | 指标由团队手动记录 | 指标具有明确的客户 | 开发团队专注于：速度(velocity)，吞吐量(throughput)，同时进行的工作(WIP)，从待办到部署的时间（Backlog+WIP），Sev1，Sev2，Sev3… | 有一个确定的,固定的地方来展示指标 |
| 团队不知道哪些指标可以有效提高生产力 | 指标更明显 | 运营团队：吞吐量(throughput)，WIP，Sev1，Sev2… | NPS /客户/团队满意度调查 | |
| 指标具有很高的展示性 | 指标以复杂，自动化和动态的方式呈现。 | |||
九、待办需求管理(Backlog Management)
Backlog原来的意思是积压件, 在软件开发中一般指还没有实现的用户需求, 这些用户需求也会被收集和管理起来,并会根据PO的意愿进行优先级排序;有效的工作优先顺序可确保始终交付最大的业务价值，从而最大程度地提高投资回报率
Backlog 管理中的MoSCoW原则:
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 管道(Pipeline)/待办需求(backlog)不存在 | 存在Backlog | 待办事项的估算使用反映工作量，复杂性，风险等的相对比例。 | 权衡滑块(Trade-off sliders)被所有人理解，并用于指导有关时间，成本，范围和质量的决策 | 连续交付项目中的3个月积压 |
| 存在一些Backlog，但是没有适当的标准或流程来对积压进行优先级排序和管理 | 建立了一个根据时间/精力来估算积压项目的过程 | 待办事项按价值和风险以及工作来确定优先级。 仅包括定义为就绪的故事。 | 优先考虑与团队以外其他工作的依存关系，并将其包括在计划中 | 在基于发布的项目中，积压订单预计将达到下一个交付里程碑 |
| 使用Backlog项目估算值定期进行计划 | 认识到与团队以外其他工作的依赖关系，并做出了一些努力将其纳入确定优先级的过程中 | 每个功能都有可量化的业务价值 | 待办事项的故事“准备就绪”至少进行了2次迭代 | |
| 对于范围，时间，成本或质量之间要权衡的内容，没有达成共识,没有权衡滑块(trade-off sliders) | 可以通过速度（Scrum）或周期时间（看板）来跟踪传递速率 | 透明，大小合理的史诗和故事 | ||
| 一队一积压 |
Trade-off sliders, 是敏捷中一个有用的小工具, 用来在时间/成本/质量等因素方面对一个用户需求进行平衡.
十、工作展示墙(Walls of Work)
物理的工作展示墙, 就是在一个墙面上展示工作的各种信息和指标; 使用展示墙, 可以跟踪工作进度并进行工作成功的可视化, 以创建透明度和共同理解.
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 项目信息存储在访问受限的位置 | 存在代表项目信息的基本隔离墙，所有团队成员和利益相关者都可以访问 | 信息保持准确，足以描述当前的工作，积压，风险，问题和总体进度 | 作品的优先级，大小，当前状态和所有权真实反映了现实 | 任何班组成员都可以走路和谈论展示墙中的工作 |
| 并非所有利益相关者都可以访问项目信息 | 信息被间歇性维护 | 所有工作活动都贴在墙上，例如,所有超过4小时的工作活动 | 信息会定期更新，团队成员互相负责 | 墙壁上的图像和信息,会根据团队不断变化的需求而定期更改。 |
| 信息不维护或不准确 | 团队为向参观者展示所使用的可视化管理工具而感到自豪，这也解释了团队的工作方式 | 工作积压显示至少一个月的即将进行的工作 | 驻地团队的物理墙 | |
| 团队定期围绕展示墙墙进行协作 | 远程团队成员可以查看和更新项目墙 |
十一、指标的利用(Use of Metrics)
对于前面收集的指标信息, 必须合理地使用起来.工作软件是进度的主要衡量标准。
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 未记录敏捷指标 | 指标由团队记录，但看不到任何价值，也不是对话的起点。 | 将指标视为实现卓越的途径 | 度量标准被对话所围绕：它们不仅是数字，而且是有关影响团队的流程和障碍的对话的起点 | 团队正在使用其指标向展示期间的利益相关者解释进度 |
| 团队不知道什么指标对他们衡量项目健康状况很重要 | 团队指标没有客户，任何人都不会有效地使用它。 | 团队确定对他们来说是重要的测量 | 持续使用指标 | 数据驱动的动作 当团队持续错过目标时发出警告信号 |
| 手动可用性和性能监控 | 度量标准不由团队成员使用，而是由外部人员（如经理）使用 | 对环境进行检测以检测任何问题（例如性能问题，网络问题）并自动发送通知 | 用作Retros的输入 | 所有团队成员都可以解释趋势并使用度量标准进行改进 |
| 发生问题时，将手动通知操作人员 | 很少有用于性能和可用性监视的工具 | 整个团队都可以使用具有性能和可用性数据的仪表板 | ||
| 系统提供问题的反应性通知 | 分析用于分析趋势并预测潜在问题 | |||
| 自动优化生产环境以立即符合客户使用模式 |
十二、迭代0 (Iteration 0)
迭代零是初始迭代,用来确认后续的目标, 并为后续的目标做相应的准备.
零冲刺也称为零迭代。 下面列出的活动将使团队为冲刺1做好准备。这是开始的一种准备。
Backlog/需求：这些是团队将在即将到来的sprint中构建的产品需求。产品负责人和技术架构师需要在此处紧密合作，为团队准备积压的工作。产品负责人应该为发布计划做好准备，以便团队可以从产品的角度可视化采购订单的愿景。
- Product Onwer对产品的愿景
- 产品负责人应准备好发布计划
- 冲刺计划的准备
- 需求至少冻结到冲刺1和2
- 冲刺1和2的优先级
- 关于完成定义的决定
基础架构准备就绪：没有基础架构，团队将无法在任何事情上取得进展。因此，高度依赖于系统，软件，许可证，环境等。DeliveryManager需要与基础利益相关者合作才能完成这些任务。
- 网络要求
- 如果涉及多个位置，则进行连接
- 最低环境准备度；从团队开始至少需要开发和QA环境
- 已安装所有软件的系统就绪状态
- 后勤要求，例如电话，视频会议等
- 所有工具启动并运行
设计/架构：高级架构管理计划，该计划从技术架构师那里讨论未来产品的技术架构。下一步将是将架构师计划转换为架构解决方案，即开发人员的编码平台。
- 高级基础架构应已准备就绪
- 决定编码框架并为团队做好准备
- 关于工具和IDE的决定
- 编码标准和流程
- 审查程序
- 自动化测试框架准备情况
团队准备：根据资源计划创建团队。在冲刺0的第一天，您不需要整个团队。但是，您必须使团队准备好为即将到来的冲刺配置的培训，工具和系统。
- 招人
- 团队加强
- 每个角色的R＆R
- 每个开发人员和测试人员还将使用所有必需的软件使系统就绪
POC：开发人员和测试人员应使用某种类型的POC为sprint 1做好准备，在这里他们将实际进行编码和测试。这项练习非常重要，这样他们才能使sprint富有成效。从sprint 1开始，团队将开始提供工作软件。
培训：培训将使团队为开发/测试做好准备。这些培训对于项目成功至关重要。我还建议将这些培训记录下来，以备将来使用。录制的会话将在新员工的提升期间使用。
- 领域
- 技术的
- 建筑学
- 开发框架和流程
- 测试框架和过程
- 工具
项目管理计划(PMP)：就项目流程而言，全面的项目管理计划将是项目团队成员的圣经。敏捷的PMP文档不同于传统的PMP。这里的关键项目是测试和缺陷管理计划。您应该清楚地写下项目中的测试过程。什么样的测试？哪个环境将用于哪个测试？有多少种缺陷？团队将如何修复缺陷？测试策略应回答所有这些问题。
- 敏捷管理计划
- 测试管理计划
- 测试策略
- 测试计划
- 范本
- 性能测试
- 安全
- 缺陷管理计划
- 持续整合过程
- 风险登记册
每个角色的角色和职责，例如Scrum主管，项目经理，敏捷教练，交付经理，开发人员，质量检查，赞助商等
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 团队未使用迭代0 | 专注于人员和流程 | 专注于交付支持 | 专注于准备 | 专注于高能效 |
| 组建团队 | 基础设施到位 | 团队从迭代1开始，他们需要有效交付所需的一切 | 把准备的Backlog做到下一个迭代 | |
| 了解角色和责任 | 定义和实施DevOps管道 | 弄清指标：成功对我们来说是什么样？ | 由有天赋的迭代管理者领导 | |
| 了解项目愿景，目标 | 讨论和调试工具 | 工作分解：创建一个“准备就绪”的Backlog（建议进行2次迭代的工作） | 回顾整个其他实践 | |
| 建立社会契约 | 做出任何关键的技术决策 | |||
| 组织工作场所（物理和虚拟） | 定义了高级架构。 | |||
| 确定团队的日程表 |
十三、测试驱动开发(Test Driven Development)
TDD是为了使代码更清晰，简单且无错误。
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 团队在编写代码后不知道TDD实际是什么，也不编写单元测试 | 团队知识渊博，突破了解TDD的基础知识 | 有足够的自动化测试可以检测到严重缺陷，并可以快速，自动地进行预防 | 在通过与之相关的自动化单元和验收测试之前，不会认为任何工作已完成 | 内置于“完成”的定义中 |
| 团队在开发完成后主要依靠手动测试来发现缺陷 | 团队开始使用TDD，但结果尚不满意，因为这需要时间 | 集成测试环境的配置速度很快，而且大多是自动化的。 | 全面的自动化测试套件是通过TDD / ATDD（验收TDD）创建的，并由开发人员和测试人员共同维护 | 团队中的软件测试工程技能，用于帮助TDD |
| 团队能够在编写相应的代码之前编写单元测试 | 团队练习“测试驱动的错误修复”： | 团队监视和管理过程中的工作，并小批量交付工作 | TDD覆盖了85％的代码 | |
| 团队能够编写轴向使测试通过失败的代码 | 发现缺陷后，编写纠正缺陷的测试 | 团队能够为宏观功能制定计划的单元测试的“路线图”（并在必要时进行修改） | 团队能够“测试驱动”各种设计范例：面向对象，功能，事件驱动 | |
| 团队能够将复合程序功能分解为一系列要编写的单元测试 | 持续部署能力可实现业务创新/试验 | |||
| 团队能够从现有的单元测试中排除可重复使用的元素，从而产生针对特定情况的测试工具 |
十四、测试自动化(Test Automation)
自动化跟踪和管理不同测试的过程.
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| 测试在开发和单元测试（DCUT）之后进行 | 测试用例符合给定用户故事，史诗，场景，用例等的接受标准 | 有足够的单元测试自动化来有意义地实现与多个每日构建的持续集成。 | 测试（回归，功能接受，单元测试，系统和集成）是自动化的，并根据需要执行 | > 80 %的测试用例是自动化的，并且涵盖了所有功能场景 |
| 测试环境是手动设置的 | 开发人员在提交代码之前执行自己的“个人构建”并运行自己的单元测试 | 某些功能和验收测试是自动化的，足以进行冒烟测试。 | 测试环境处于变更控制之下 | 内置在CI / CD管道中 |
| 测试是手动的 | 在变更控制下创建测试数据，并自动将其部署到适当的测试环境中 | 可以自动重新创建任何版本的测试环境 | 使用工具和监视（SonarQube或类似软件） | |
| 进行测试只是为了确保功能满足指定要求（即，以客户为中心） | 自动将针对构建的失败测试报告并记录给所有者 | 可以通过自动创建故障环境来重现测试故障 | 内置于“完成”的定义中 | |
| 团队监视代码覆盖范围以进行测试，并确保其适用于他们的应用程序 | 从PO级别开始使用Gherkin开始定义 | |||
| 根据应用程序的技术堆栈性质精心定义的测试策略 | ||||
| 触摸旧版代码时，我们会花一些时间来涵盖自动测试范围 |
十五、开发-安全-运营(DevSecOps)
从一开始就考虑应用程序和基础架构的安全性.
从本质上讲，安全代码DevOps既是一种软件工程文化，又是一种结合到一个简单概念中的最佳实践。 它寻求将软件开发（Dev），安全性（Sec）和操作（Ops）统一为一个统一的流程，最终与您的独特业务保持一致。
DevOps 与DevSecOps的不同:
| 初始阶段 (Initiating) | 实践阶段 (Practicing) | 转型阶段 (Transforming) | 优良阶段 (Scaled) | 卓越阶段 (brilliant) |
| Squad已完成SecDevOps培训 | Squad已完成安全培训–建立对安全主题的意识（OWASP Top 10等） | 端到端功能测试完全自动化。 | 用户管理是具有适当安全限制的自助服务。 | 外部渗透测试 |
| 安全性的作用与该团队之外的特定团队隔离。 | 针对所有代码，OpenSource漏洞分析嵌入在CI / CD管道中。 | 威胁建模可告知安全要求，并在应用程序进行任何重大更改时保持最新状态。 | 秘密是在平台的各个部分之间创建/共享的，而无需人们进行设置/交互。 | 从漏洞自动恢复。 |
| 意识到时将应用安全漏洞补丁。 | 在开发和测试环境中部署的交互式应用程序安全测试（IAST）。 | 嵌入在CI / CD管道中的静态和动态应用程序安全测试（SAST / DAST），用于所有新代码和旧代码。 | 持续运营环境 端到端的代码自动部署 | |
| 用户管理是手动完成的，并且可以通过人与平台之间的信息交换来共享秘密，而无需考虑对这些秘密的最低特权访问。 | 嵌入在CI / CD管道中的静态应用程序安全测试（SAST），用于所有新代码。 | 内部渗透测试 | ||
| 代码或配置中的所有硬编码机密都是已知的，并以域执行官批准的风险记录在案 正在使用非战略性SCM。 | 用户管理是通过自动化使用一组固定的用户类型完成的。 | 内置信息安全。 这包括源代码控制存储库，容器注册表，持续集成和连续部署（CI / CD）管道，应用程序编程接口（API）管理，编排和发布自动化以及运营管理和监视。 | ||
| 机密通过安全方法存储/传递。 人们不需要秘密就可以使用秘密，但可以在必要时让人们看到秘密。 | 如果无法解决安全问题，请中断构建。 | |||
| 对于旧代码，所有重大问题都将在120天内解决。 | 网络隔离开发环境。 | |||
| 部署了Web应用程序防火墙（WAF），以提高弹性和响应能力。 | 具有集成构建环境的战略性源代码管理环境。 | |||
| 战略性源代码管理环境（例如企业级github） | 连续操作允许随时随地进行自动修补。 | |||
敏捷实践十五式的实施
对于上述敏捷实践, 我们是分阶段逐步实施的, 首先在最开始做一次自评, 定义一个初始分数, 然后每一个月, 都会专门抽取一个时间来根据这十五项进行自评, 并把分数和之前的分数进行比较.
下图展示了对于这十五项实践, 2019年三月时候各个团队的状态:
下面是经过一段时间实践之后, 在2020年五月的团队状态:
可以看出经过一年的努力, 各个团队的进步和成绩.
敏捷成熟度的增长
对于敏捷团队, 有一个敏捷成熟度可以来衡量:
下图可以展示出, 在采用了这些敏捷实践之后, 各个团队敏捷成熟度的增长:
部门敏捷成熟度整体的增长:
好了, 关于敏捷就写道这里吧, 有什么问题或者疑问,建议, 欢迎不吝赐教.
