ldfgaar的博客

原创 源自5千余回顾会议实践的经验

一、回顾会议的问题：二、回顾会需要反思的问题：三、回顾会的DOD四、回顾会报告解决的问题：

原创 一篇文章解决项目生命周期选择的难题

适合于软件项目、软硬件项目、AI项目、大数据项目、区块链项目

原创 scrum检视

原创 度量体系建设（一）

一、度量目标二、控制三、改进目标四、度量属性。

原创 Devops能力成熟度模型（一）-----总体架构

Devops总体架构划分为五大部分，分别是过程、应用设计、安全风险管理、评估方法以及系统和工具构成完整的一体化。过程管理主要包括：1、敏捷开发管理2、持续交付3、技术运营三部分。

原创 代码分支模型

主流代码分支模型（git_flow）：

原创 scrum master的检视

从PO、团队、工程实践、组织级方面检视现状

原创 项目管理技能应用

十大知识域

原创 成长思维助力团队迎接新的挑战

团队专注于更好地完成工作、流程和计划的价值对您的公司和客户产生了立竿见影的积极影响。如果团队中的每个人都注意到他们提供的产品或服务中的弱点，并主动提出问题并提出解决方案，您就可以看到改进的道路。

原创 SAFe中的角色（二）

SAFe中的角色和团队

原创 来自深山老林问题

干的事情有什么价值，你有什么价值，目标有什么价值

原创 研发过程管理

1、开发测试过程中的问题2、代码流转3、4、5、6、7、8、9、10、11、

原创 效能指标分析（一）

研发效能解决的问题：研发效能金三角行业现状：公司实践研发效能地图靠谱需求：影响地图：需求-用户故事地图：需求-需求层次：需求-案例￥￥￥￥￥最小业务单元：独立上线运行和完成用户体验闭环需求-需求实例化：效能平台：效能逻辑：效能度量效能度量：效能度量--改进指标...

原创 SAFe可以带来什么（一）

1、四大核心：协调一致内建质量透明项目群执行2、三大会议：计划会议（两天-100人-三个月任务）会议演示检视和调整3、五大角色：大po、大sm、SA、bo、rds

原创 软件度量指标合集

度量合集在正常负载的情况下，响应用户的输入的平均响应时间必须控制在500～1250毫秒之间，超过1500毫秒会影响用户操作；在500毫秒以下，人的反应速度无法触及。

原创 如何开好一个软件类周会和周报

周会和周报是非常重要的“沟通平台”的部分，既可以给团队提供基本的“信息透明”，又可以有效推动重要问题的思考和讨论，让大家避免一头扎在细节工作中，而忘了抽身审视自己进而持续改进一、周会的类型1、全体会2、组长会3、三方会二、周会目的面对面地感受到项目当前的整体状态、重要问题、接下去的目标以及调整，更需要借此来对项目当前重要问题有一致的认识，有小幅度的讨论，并形成下一步工作事项。三、周会要点1、人数不超过10-15人，时长不超过1.5小时。2、项目经理事先的收...

原创 软件度量方法

1、软件度量的作用：评估正在进行中的项目的状态；跟踪潜在风险；在造成不良影响之前发现问题；调整任务和工作流程；评估团队的软件工作能力；2、软件度量的方法：1、直接测量，面向规模度量----代码行（LOC）、代码生产率（代码行/人/日）、每行代码的成本（费用/代码行、文档与代码比、代码出错率、）、2、间接测量，面向功能度量（FP）-----fp=ufp*tcf、生产率、平均成本、文档与功能点比、代码出错率、通过loc逆向计算功能点：3、缺陷的修改平均时间4、缺陷排除效率DR

原创 cmmi与敏捷

敏捷占软件开发的80%，cmmi给敏捷是否带来灾难。僵化的cmmi高成熟度实施套路是敏捷的天敌，灵活的高成熟度可以助力敏捷发展度量过程软件中描述了只有部分数据可以进行做统计。度量敏捷、基线模型敏捷、工具和过程敏捷...

原创 UI设计评审度量评价指导

1、UI交互设计的原则系统状态是否可见 系统是否符合现实世界的习惯 用户是否能自由地控制系统 统一与标准 错误防范 减轻低用户的记忆负担 灵活性和效率 美观简洁 帮助用户认知、了解错误，并从错误中恢复 帮助文档2、设计指标度量（sus）快速对SUS进行打分。然后就需要对每个题目的分值进行转换，奇数项计分采用「原始得分-1」，偶数项计分采用「5-原始得分」。由于是5点量表，每个题目的得分范围记为0~4（最大值为40）3、多角度问题分析4、UI设计评价 ...

原创 sprint回顾会

我们认为 Sprint 回顾是我们 Scrum 过程中非常重要的一部分。Sprint 回顾会在每个 sprint 结束时进行，通常是在 Sprint 演示之后的星期五。这个一小时的会议帮助我们从团队中获得关于过去 sprint 的正面和负面反馈。通过收集、优先排序和讨论团队每个成员的反馈，我们继续开展具有积极影响并消除消极行为的活动。在 Sprint 回顾前一天，我们的 Scrum Master 会发送一份表格，从团队的每个成员那里收集以下反馈：你喜欢这个 sprint 的两件事。 你不喜欢这个

原创 sprint演示会议

在每个 sprint 结束时，我们都有一个 sprint 演示会话。我们通常将演示安排在 sprint 的最后一个星期五。我们为演示预订了一个小时，但是，平均需要大约 40 分钟。所有团队成员都必须参加。sprint 演示对我们来说是最激动人心的 Scrum 活动之一，因为每位演示者都感觉自己就像舞台上的摇滚明星，其目标是进行有趣且有趣的演示。 我们提前宣布了我们将要演示的用户故事集。该演示由用户故事的作者执行，该作者通常是开发人员，有时是测试此功能的质量保证工程师。作者在一个共享的大屏幕上演示了各种使

原创 如何执行冲刺sprint

当计划会议结束时，Scrum Master 将计划好的用户故事从积压工作拖到冲刺板上，并为每个故事创建适当的任务。当板准备好后，冲刺开始。如果可能的话，每个人都可以自由地从最上面的泳道接受一项开放的任务并开始工作。我们尝试为每个团队成员只保留一项任务。但是，有时开发人员可能会拿卡片进行调查，但仍在从事开发任务。提示我们将未分类的卡片放在棋盘的顶部。在这个泳道中，我们添加了我们认为在冲刺期间完成的重要错误和任务。这条泳道帮助我们密切关注与任何用户故事无关的重要活动。 我们有两条泳道专门用于支持每.

原创 冲刺计划sprint

sprint周期及参与人员Sprint 计划活动是我们 Scrum 活动的重要组成部分。我们在每两周 sprint 开始时都有计划会议。我们将整个团队召集在一起，包括 QA 工程师、UX 设计师、支持工程师、技术作家和营销经理，讨论我们希望为即将到来的 sprint 采用的用户故事。在计划会议开始之前，Scrum Master 打印用户故事并将它们固定到物理板上。团队的每个成员都会检查每个用户故事的描述，以积极参与规划讨论。计划会议分为两部分：业务和技术。业务部分专门讨论业务范围。Scrum

原创 基于scrum的估算

依据用户故事数量估算我们在 Scrum 流程中引入了#NoEstimates方法。我们不是使用估计和花费时间来计算燃尽，而是根据我们在每个 sprint 中完成的用户故事的数量来跟踪我们的进度。这种方法背后的主要概念是，我们的 sprint 目标是交付一组用户故事，而我们需要完成多少任务才能实现这一目标并不重要。这种方法的好处是它减少了在每个计划会话期间估计用户故事和任务所花费的时间。但是，这需要团队一定的经验和纪律。我们添加了一个简单的规则来帮助我们从这种方法中受益：完成任何任务都不能超过两天

原创 产品待办事项列表（product backlog）

产品规划会在我们的例子中，产品待办列表是我们计划构建的一组功能。在 YouTrack 团队，我们每年至少进行一次全面的规划会议。我们在办公室召集整个团队几天，从不同的角度讨论我们的计划：我们的客户想要什么，从我们的角度来看什么是重要的，以及我们认为哪些工作很酷。我们根据产品使命和公司目标验证这些要点。优先级我们创建了一个我们计划工作的主要方向的列表，并为每个子系统定义了一组必备、重要和好用的特性。必备功能在列表中排在首位，重要且值得拥有的功能优先级较低。我们还考虑了我们需要开发的最小功能集，以

原创 Scrum 角色

Scrum 转型的第一步是定义谁将担任每个核心角色。PO在scrum团队中，产品负责人负责确定产品待办事项中的问题的优先级并决定我们下一步做什么。产品负责人密切关注，以确保我们的产品目标和使命满足客户的需求，而开发团队则找到实现这些目标的最佳技术解决方案。在 YouTrack 团队中，产品负责人角色由团队负责人担任。然而，当团队成员认为用户故事很重要时，他们有权向PO提出提高用户故事的优先级，当然，要提供强有力的理由来支持它。承担着利益相关者的角色可以直接访问客户反馈。我们的目标是创造一个既..

原创 在 YouTrack 中进行 Scrum实践

我们对 Scrum 的目标和期望：构建一个快速移动的迭代过程。 分享每日状态更新。 提高集体代码所有权。 在短时间内持续提供更新。 切换到更短的发布周期，最好是每两周一次。 改善我们的团队协作和进度可视化。 在开发的早期阶段获得反馈，以便能够立即做出反应。 变得足够灵活，可以即时修改功能。以下是我们在 Scrum 转型期间采取的主要步骤：定义了基本的 Scrum 角色。 创建并优先处理我们的产品 backlog 。 确定的估算和计划程序。 配置了我们的 Scrum 板。 安排了第