分类: 未分类

  • 我写了一个「提肛助手」,因为99%的人根本不知道怎么做凯格尔运动

      凯格尔运动(提肛)有多重要?

      对男性来说,它是最被低估的「核心力量训练」。盆底肌是支撑膀胱、直肠的「底盘」,强化它可以改善排尿控制、提升性功能、预防

      中年以后的前列腺问题。

      对女性来说就更刚需了——产后漏尿、盆腔器官脱垂、核心稳定性,都和这块肌肉密切相关。产科医生、康复师反复强调要做,但从来没

      人教你怎么做。

      问题来了:绝大多数人的凯格尔运动,根本做错了。

      你可能正在用腹部代偿、憋气、用臀部发力,甚至不知道自己到底收紧的是哪块肉。

      所以我写了这个工具——提肛助手(tgang-helper)。一句话介绍:傻子也能练对。

      它会做什么?

      – 男女分离,科学分级:男性和女性的盆底肌发力感受完全不同,课程分开设计,分入门/进阶/强化三个等级,从感知定位到极限耐力

      ,循序渐进。

      – 看着就能做:训练时有一个会呼吸的大圆环——收紧时缩小变红,放松时扩大变绿。旁边还有一个动画小人,用高亮告诉你该用哪里发

      力,收缩方向有箭头指示。你一看就知道该怎么做。

      – 闭眼也能跟练:全程中文语音播报,「收紧」「放松」「休息一下」自动提醒,不用盯着屏幕。

      – 开摄像头纠正姿势:如果你打开姿势检测,浏览器会用 AI(MediaPipe Pose)实时检测你站着还是坐着、有没有驼背、耸肩、身体

      歪斜。全程纯本地运行,摄像头画面不上传到任何服务器。当检测到你持续姿势不对,系统会把姿势数据(不是图像)发给 DeepSeek

      获取纠正建议,然后用语音告诉你:「肩膀有点紧张,放松下沉」。

      – 打卡和统计:训练记录保存在本地浏览器,热力图日历 + 周统计图,直观看到自己的坚持。

      技术上说几句

      纯前端应用,Next.js + TypeScript,姿势检测用 MediaPipe Pose,动画用 Framer Motion + SVG,AI 建议通过 API Route 代理调

      DeepSeek。没有后端数据库,所有数据本地存储,隐私友好。

      最后说句真心话

      盆底肌训练是最被低估的「隐形健身」,它不像练腹肌那样肉眼可见,但对生活质量的影响远超你的想象。每天 8

      分钟,坚持两周,你就能感受到变化。

      来试试吧:https://tgang.dimeng.icu  如果觉得有用,分享给需要的朋友。有些话题虽然不好意思聊,但值得被认真对待。

  • 从入门到精通:Cypress 前端自动化测试实战指南

    在前端开发中,自动化测试是保障项目质量、提升开发效率的关键环节。而 Cypress 作为一款现代化的端到端(E2E)测试框架,凭借其简洁的 API、实时重载、时间旅行调试等优势,成为越来越多前端开发者的首选工具。不同于传统测试框架的繁琐配置,Cypress 开箱即用,既能满足新手快速上手的需求,也能支撑复杂项目的测试场景。本文将从入门认知、环境安装、基础使用,到进阶精通,一步步带你吃透 Cypress,结合具体示例帮你快速落地实践。

    一、入门认知:什么是 Cypress?

    Cypress 是一个专为现代 Web 应用设计的端到端测试框架,它不仅是一个测试工具,更是一套完整的测试解决方案,涵盖了测试编写、运行、调试的全流程。与 Selenium 等传统框架相比,Cypress 具有以下核心优势,也是它能快速出圈的原因:

    • 浏览器原生运行:测试代码与应用代码在同一浏览器环境中执行,无需额外的驱动程序,避免了跨环境兼容问题,能更真实地模拟用户操作体验。
    • 实时重载 + 时间旅行:修改测试代码后,测试会自动重新运行;同时支持回放测试的每个步骤,可查看每个操作对应的 DOM 状态、网络请求,快速定位问题。
    • 自动等待:智能等待元素加载、网络请求完成,无需手动编写 sleep 等待语句,大幅减少测试用例的不稳定性(默认等待4秒,可自定义配置)。
    • 丰富的 API 与断言:内置强大的选择器、操作命令和断言方法,支持 DOM 元素、网络请求、Cookie 等多种场景的验证,语法简洁易懂。
    • AI 辅助能力:提供 AI 驱动的测试生成、自愈能力,可通过 Cypress Studio 录制用户操作生成测试代码,减少手动编写成本。

    适用场景:前端项目的端到端测试(模拟用户真实操作流程)、组件测试、接口测试,尤其适合 React、Vue、Angular 等现代前端框架开发的项目。

    二、环境安装:3步搞定,开箱即用

    Cypress 的安装非常简单,核心依赖 Node.js(建议版本 ≥14.17.0),无论是新建项目还是已有项目,都能快速集成。以下是详细安装步骤,覆盖 Windows、Mac、Linux 全系统。

    2.1 前置条件

    确保本地已安装 Node.js 和 npm/yarn/pnpm(任意一种包管理器),可通过以下命令验证:

    # 验证 Node.js 版本
    node -v
    # 验证 npm 版本
    npm -v

    若未安装 Node.js,可前往 Node.js 官网 下载安装(建议选择 LTS 长期支持版)。

    2.2 安装 Cypress

    有两种安装方式,根据项目场景选择即可:

    方式1:新建测试项目(从零开始)

    # 1. 新建项目文件夹并进入
    mkdir cypress-demo && cd cypress-demo
    # 2. 初始化 package.json(一路回车即可)
    npm init -y
    # 3. 安装 Cypress(开发依赖)
    npm install cypress --save-dev
    # 或使用 yarn/pnpm
    yarn add cypress --dev
    pnpm add cypress --dev

    方式2:集成到已有前端项目

    直接在已有项目根目录执行安装命令即可:

    npm install cypress --save-dev

    2.3 启动 Cypress

    安装完成后,通过以下命令启动 Cypress 可视化界面:

    npx cypress open

    首次启动时,Cypress 会自动初始化项目结构,生成默认的配置文件和测试示例,同时会下载 Cypress 核心应用程序(若下载失败,可参考下方常见问题解决)。启动成功后,会弹出 Cypress 可视化控制台,选择「E2E Testing」即可开始编写测试用例。

    2.4 常见安装问题解决

    若出现「The Cypress App could not be downloaded」错误,通常是网络或镜像问题,可通过以下方法解决:

    # 1. 配置国内镜像(临时生效,仅当前命令行)
    # Windows(cmd/PowerShell)
    set CYPRESS_DOWNLOAD_MIRROR=https://npmmirror.com/mirrors/cypress/
    # Mac/Linux(终端)
    export CYPRESS_DOWNLOAD_MIRROR=https://npmmirror.com/mirrors/cypress/
    # 2. 清除缓存并重新安装
    npx cypress cache clear
    rm -rf node_modules package-lock.json
    npm install

    三、基础使用:编写第一个测试用例

    启动 Cypress 后,我们先熟悉其项目结构,再编写第一个测试用例,快速感受 Cypress 的便捷性。

    3.1 Cypress 项目结构(核心目录)

    初始化后,项目根目录会生成 cypress 文件夹,核心目录结构如下:

    cypress/
    ├── e2e/          # 端到端测试用例存放目录(核心)
    │   └── example.cy.js  # 默认示例用例
    ├── fixtures/     # 测试数据文件(如 JSON 格式,用于模拟接口数据)
    ├── support/      # 支持文件
    │   ├── commands.js  # 自定义命令(封装重复操作)
    │   └── e2e.js     # 全局配置(如导入依赖、设置全局变量)
    ├── screenshots/  # 测试失败时自动生成的截图
    └── videos/       # 测试运行时自动生成的录屏(无头模式下生效)

    核心配置文件:cypress.config.js(项目根目录),用于配置基础路径、浏览器、等待时间等,默认无需修改,后续可根据需求自定义。

    3.2 编写第一个测试用例(实战示例)

    我们以「访问百度首页,搜索 Cypress 并验证结果」为例,编写第一个测试用例,步骤如下:

    步骤1:新建测试文件

    cypress/e2e 目录下,新建 baidu-search.cy.js 文件(测试文件后缀必须为 .cy.js,Cypress 会自动识别)。

    步骤2:编写测试代码

    测试代码的核心结构是 describe(测试套件)和 it(测试用例),结合 Cypress 内置命令完成操作和断言,代码如下(含详细注释):

    // 告诉 Cypress 这是它的测试文件(可选,用于语法提示)
    /// <reference types="cypress" />
    
    // 测试套件:描述一个功能模块(如「百度搜索功能」)
    describe('百度搜索功能测试', () => {
      // 测试用例:描述一个具体的测试场景(如「搜索 Cypress 并验证结果」)
      it('访问百度首页,搜索 Cypress,验证搜索结果', () => {
        // 1. 访问百度首页(cy.visit() 用于导航到指定 URL)
        cy.visit('https://www.baidu.com')
        
        // 2. 定位搜索输入框,输入「Cypress」(cy.get() 用于定位元素,type() 用于输入内容)
        // 这里通过 ID 定位搜索框(#kw 是百度搜索框的 ID)
        cy.get('#kw').type('Cypress')
        
        // 3. 定位搜索按钮,点击搜索(click() 用于点击元素)
        cy.get('#su').click()
        
        // 4. 断言:验证搜索结果中包含「Cypress 官方网站」(should() 用于断言)
        cy.contains('Cypress 官方网站').should('be.visible')
        
        // 额外断言:验证当前 URL 包含「wd=Cypress」(确认跳转到搜索结果页)
        cy.url().should('include', 'wd=Cypress')
      })
    })

    步骤3:运行测试用例

    重新启动 Cypress(npx cypress open),在可视化控制台中找到 baidu-search.cy.js,点击即可运行测试。运行过程中,你会看到:

    • 浏览器自动打开,逐步执行测试步骤(访问百度、输入内容、点击按钮);
    • Cypress 控制台左侧显示每个步骤的执行状态(绿色表示成功,红色表示失败);
    • 测试完成后,若所有断言都通过,测试用例会显示「PASSED」。

    小贴士:测试过程中,可点击控制台左侧的步骤,查看该步骤对应的 DOM 状态(时间旅行功能),快速调试问题。

    3.3 基础命令速查(高频使用)

    Cypress 的命令简洁直观,以下是基础使用中最常用的命令,结合示例记忆更高效:

    命令功能描述示例
    cy.visit(url)导航到指定 URLcy.visit(‘https://www.baidu.com’)
    cy.get(selector)定位 DOM 元素(支持 ID、类、属性等选择器)cy.get(‘#kw’)、cy.get(‘[data-testid=”btn”]’)
    cy.type(text)向输入框输入内容cy.get(‘input’).type(‘Cypress{enter}’)({enter} 表示按回车)
    cy.click()点击元素cy.get(‘button’).click()(force: true 可强制点击)
    cy.contains(text)定位包含指定文本的元素cy.contains(‘登录’)
    cy.should(assertion)断言元素状态或属性should(‘be.visible’)、should(‘have.value’, ‘Cypress’)
    cy.reload()重新加载当前页面cy.reload(true)(强制重载,忽略缓存)

    四、进阶精通:解锁 Cypress 高级用法

    掌握基础使用后,我们需要学习 Cypress 的高级用法,解决复杂测试场景(如接口模拟、代码复用、跨环境测试、CI/CD 集成),真正实现“精通”并落地到实际项目中。

    4.1 接口测试与网络请求模拟

    Cypress 不仅能测试页面交互,还能直接测试接口,或模拟接口返回数据(避免依赖真实后端环境),核心命令是 cy.intercept()(拦截网络请求)和 cy.request()(发送请求)。

    示例1:直接测试接口(GET 请求)

    describe('接口测试示例', () => {
      it('测试获取用户列表接口', () => {
        // 发送 GET 请求
        cy.request('GET', 'https://api.example.com/users')
          .then((response) => {
            // 断言接口状态码为 200
            expect(response.status).to.eq(200)
            // 断言返回数据是数组
            expect(response.body).to.be.an('array')
            // 断言返回数据长度大于 0
            expect(response.body.length).to.gt(0)
          })
      })
    })

    示例2:模拟接口返回(拦截请求,无需依赖真实后端)

    先在 cypress/fixtures 目录下新建 users.json(模拟接口返回数据):

    [
      { "id": 1, "name": "张三", "age": 25 },
      { "id": 2, "name": "李四", "age": 28 }
    ]

    然后编写测试用例,拦截接口并返回模拟数据:

    describe('接口模拟示例', () => {
      it('模拟获取用户列表接口', () => {
        // 1. 拦截 GET 请求,指定返回 fixtures 中的数据
        cy.intercept('GET', 'https://api.example.com/users', { fixture: 'users.json' }).as('getUsers')
        
        // 2. 访问需要调用该接口的页面(假设页面加载时会请求用户列表)
        cy.visit('/user-list')
        
        // 3. 等待接口请求完成(as 定义的别名,用于关联拦截的请求)
        cy.wait('@getUsers')
        
        // 4. 断言页面中显示模拟的用户数据
        cy.contains('张三').should('be.visible')
        cy.contains('李四').should('be.visible')
      })
    })

    4.2 代码复用:自定义命令与测试钩子

    实际项目中,很多测试步骤会重复(如登录、退出、导航到指定页面),通过自定义命令和测试钩子,可大幅减少重复代码,提升测试用例的可维护性。

    4.2.1 自定义命令(封装重复操作)

    cypress/support/commands.js 中定义自定义命令,全局可用。示例:封装登录命令:

    // cypress/support/commands.js
    // 定义登录命令,接收用户名和密码参数
    Cypress.Commands.add('login', (username, password) => {
      cy.visit('/login') // 访问登录页
      cy.get('input[name="username"]').type(username) // 输入用户名
      cy.get('input[name="password"]').type(password) // 输入密码
      cy.get('button[type="submit"]').click() // 点击登录按钮
      cy.url().should('include', '/home') // 断言登录成功,跳转到首页
    })

    在测试用例中直接调用自定义命令:

    describe('首页功能测试', () => {
      // 调用自定义登录命令,无需重复编写登录步骤
      beforeEach(() => {
        cy.login('admin', '123456') // 每个测试用例执行前先登录
      })
      
      it('验证首页显示用户名', () => {
        cy.contains('欢迎您,admin').should('be.visible')
      })
      
      it('验证首页菜单显示', () => {
        cy.get('#menu-home').should('be.visible')
        cy.get('#menu-user').should('be.visible')
      })
    })

    4.2.2 测试钩子(控制测试流程)

    Cypress 提供 4 个常用测试钩子,用于控制测试用例的执行顺序,减少重复操作:

    • before():所有测试用例执行前,只执行一次(如初始化测试数据);
    • beforeEach():每个测试用例执行前,都执行一次(如登录、访问页面);
    • afterEach():每个测试用例执行后,都执行一次(如清除缓存、退出登录);
    • after():所有测试用例执行后,只执行一次(如关闭浏览器、清理测试环境)。

    示例:结合钩子和自定义命令,优化测试流程:

    describe('用户管理功能测试', () => {
      // 所有用例执行前,初始化测试数据
      before(() => {
        cy.request('POST', 'https://api.example.com/init-test-data')
      })
      
      // 每个用例执行前,先登录
      beforeEach(() => {
        cy.login('admin', '123456')
      })
      
      // 每个用例执行后,清除当前页面缓存
      afterEach(() => {
        cy.reload()
      })
      
      // 所有用例执行后,清理测试数据
      after(() => {
        cy.request('POST', 'https://api.example.com/clear-test-data')
      })
      
      it('新增用户', () => {
        // 编写新增用户的测试步骤(无需重复登录)
      })
      
      it('编辑用户', () => {
        // 编写编辑用户的测试步骤(无需重复登录)
      })
    })

    4.3 数据驱动测试(多场景批量测试)

    当测试场景相同、仅输入/输出数据不同时(如登录失败的多种场景:账号为空、密码为空、账号密码错误),可使用数据驱动测试,通过循环批量执行测试用例,避免重复编写代码。

    示例:测试登录失败的多种场景:

    describe('登录失败场景测试', () => {
      // 测试数据:数组形式,每个元素是一组输入和预期结果
      const testData = [
        { username: '', password: '123456', expectMsg: '请输入用户名' },
        { username: 'admin', password: '', expectMsg: '请输入密码' },
        { username: 'admin', password: 'wrong', expectMsg: '账号或密码错误' }
      ]
      
      // 循环测试数据,生成测试用例
      testData.forEach((data) => {
        it(`输入${data.username}/${data.password},提示${data.expectMsg}`, () => {
          cy.visit('/login')
          cy.get('input[name="username"]').type(data.username)
          cy.get('input[name="password"]').type(data.password)
          cy.get('button[type="submit"]').click()
          // 断言错误提示
          cy.contains(data.expectMsg).should('be.visible')
        })
      })
    })

    4.4 跨环境测试与配置优化

    实际项目中,会有开发、测试、生产等多个环境,通过 Cypress 配置文件,可快速切换测试环境,无需修改测试代码。

    示例:修改 cypress.config.js,配置多环境基础路径:

    const { defineConfig } = require('cypress')
    
    module.exports = defineConfig({
      e2e: {
        // 基础配置
        setupNodeEvents(on, config) {},
        // 不同环境的基础路径(可通过命令行参数切换)
        baseUrl: config.env.environment === 'test' 
          ? 'https://test.example.com' 
          : 'https://dev.example.com'
      },
      // 全局等待时间(默认4秒,可自定义)
      defaultCommandTimeout: 5000
    })

    通过命令行切换环境:

    # 测试环境运行测试
    npx cypress run --env environment=test
    # 开发环境运行测试
    npx cypress run --env environment=dev

    4.5 CI/CD 集成(自动化测试流水线)

    将 Cypress 测试集成到 CI/CD 流水线(如 GitHub Actions、Jenkins、CircleCI),可实现“代码提交后自动运行测试”,提前发现问题,保障代码质量。以下是 GitHub Actions 和 Jenkins 的简单示例。

    示例1:GitHub Actions 集成

    在项目根目录创建 .github/workflows/test.yml 文件,配置如下:

    on: [push] # 代码推送时触发测试
    jobs:
      cypress:
        runs-on: ubuntu-latest
        steps:
          - name: 拉取代码
            uses: actions/checkout@v4
          - name: 安装 Node.js
            uses: actions/setup-node@v4
            with:
              node-version: '16'
          - name: 安装依赖
            run: npm install
          - name: 运行 Cypress 测试(无头模式)
            uses: cypress-io/github-action@v6
            with:
              build: npm run build
              start: npm start

    示例2:Jenkins 集成

    1. 安装必要插件:NodeJS Plugin、HTML Publisher Plugin;

    2. 新建 Jenkins 任务,配置源码管理(关联 GitHub/GitLab 仓库);

    3. 构建步骤添加“执行 shell”(Linux)或“执行 Windows 批处理命令”,输入如下命令:

    # 安装依赖
    npm install
    # 运行 Cypress 测试,生成测试报告
    npx cypress run --reporter junit --reporter-options mochaFile=results/test-results-(hash).xml

    4. 构建后操作:配置测试报告展示,方便查看测试结果。

    4.6 调试技巧与最佳实践

    4.6.1 调试技巧

    • 时间旅行:测试运行时,点击控制台左侧的步骤,可回放该步骤的 DOM 状态,查看元素属性和网络请求;
    • 调试语句:在测试代码中添加 debugger,测试运行到该语句时会暂停,可在浏览器开发者工具中调试;
    • 日志输出:使用 cy.log('日志内容'),在控制台输出自定义日志,方便定位问题;
    • 截图/录屏:测试失败时,Cypress 会自动截图;无头模式运行时,会自动录屏,可在 screenshotsvideos 目录查看。

    4.6.2 最佳实践

    • 使用 data-testid定位元素,避免依赖 ID、类名(避免因样式修改导致测试失败);
    • 一个测试用例只测一个功能点,避免“大而全”的用例(失败时可精准定位问题);
    • 避免手动添加 cy.wait(1000)等待语句,依赖 Cypress 的自动等待机制;
    • 使用 fixture 管理测试数据,避免硬编码在测试代码中;
    • 定期清理测试用例,删除过期、冗余的用例,保持测试套件的简洁性。

    五、总结与进阶方向

    到这里,你已经掌握了 Cypress 的核心用法:从环境安装、基础测试用例编写,到接口模拟、代码复用、CI/CD 集成,足以应对大部分前端项目的自动化测试需求。Cypress 的优势在于“简单、高效、易调试”,无需复杂的配置,新手也能快速上手,同时其强大的高级功能,也能支撑复杂项目的测试场景。

    进阶方向建议:

    • 深入学习 Cypress 组件测试(测试 React/Vue 组件);
    • 探索 Cypress Cloud 功能,实现测试结果可视化、并行测试、AI 辅助调试;
    • 结合实际项目,搭建完整的自动化测试体系(接口测试 + 端到端测试 + CI/CD 集成);
    • 学习 Cypress 插件开发,扩展其功能(如集成测试报告、自定义断言)。

    自动化测试的核心是“提升效率、保障质量”,Cypress 只是工具,关键在于结合项目场景,编写高效、稳定、可维护的测试用例。多动手实践,多踩坑调试,才能真正精通 Cypress,让它成为你前端开发中的“质量守护者”。

  • 一个人真正变强的七个迹象,中三个就很了不起

    真正的强大是重新爱上自己

    1.你开始为自己的选择负责,而不是依赖他人

    2.你能坦然说出“我不知道”或者“我需要帮助”

    3.你越来越懂得欣赏自己的特质,并发挥他们积极的一面

    4.你不再美化没有走过的路,欣然接纳自己的局限

    5.你允许自己有消极情绪,不再责备自己

    6.你学会了为“小小的胜利”庆祝,大大方方地骄傲

    7.你不再靠别人的评价确认自我价值,拥有了清晰的“自我坐标”

  • 中项背记内容

    立项管理

    项目可行性研究内容:

    1、技术可行性分析;

    2、经济可行性分析;

    3、社会效益可行性分析;

    4、运行环境可行性分析;

    5、其他方面的可行性分析;

    项目可行性研究阶段:

    1、初步可行性研究;

    2、详细可行性研究;

    项目建议书的内容:项目的必要性、项目的市场预测、项目预期成果(如产品方案或服务)的市场预测、项目建设必需的条件

    整合管理

    整合管理常见的问题?

    1、没有制定项目管理计划;

    2、没有制定有效的范围和需求管理子计划;

    3、没有制定合理的整体变更流程及需求变更控制流程;

    4、对客户的需求获取不充分;

    5、需求分析工作不充分,缺乏需求定义环节,没有定义出需求规则说明书;

    6、缺乏需求验证环节,没有请客户代表一起进行需求评审;

    7、没有求得干系人对需求的承诺;

    8、没有求得干系人对需求的一致理解;

    9、没有有效的管理变更控制;

    10、未能做好进度管理,范围变更时没有充分评估对进度等其他方面的影响,导致进度延误;

    11、范围没有管好,导致不断的范围蔓延

    项目整合变更控制流程?

    1、变更申请;

    2、对变更的初审;

    3、变更方案的论证;

    4、变更审查;

    5、发出通知并实施;

    6、变更监控;

    7、效果评估;

    8、变更收尾;

    项目整合变更控制流程常见的问题?

    1、没有制定项目变更控制流程,或者没有遵循项目变更控制流程;

    2、没有成立变更控制委员会,或类似的组织形式来控制项目的变更;

    3、未做好变更相关的配置管理工作,导致版本混乱;

    4、变更口头提出,未进行书面记录;

    项目章程主要内容:

    项目目的;高层次需求、高层级项目描述、边界定义以及主要可交付成果;可测量的项目目标和相关的成功标准;整体项目风险;总体里程碑进度计划;预先批准的财务资源;关键干系人名单;项目审批要求;项目推出标准;委派的项目经理及其职责和职权;发起人或其他批准项目章程的人员的姓名和职权

    项目管理计划的主要内容:

    范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、风险管理计划、采购管理计划、干系人参与计划、范围基准、进度基准、成本基准、变更管理计划、配置管理计划、绩效测量基准、项目生命周期、开发方法、管理审查

    在变更中的配置管理活动?

    项目收尾?

    范围管理常见问题

    1、没有编制范围管理计划和需求管理计划/独自一人编制不妥;

    2、没有全面收集干系人需求/未对需求进行跟踪;

    3、没有编制范围说明说/独自一人编制不妥;

    4、制订范围说明书的依据不充分;

    5、没有创建WBS;

    6、创建WBS工作没有相关关系人的参与/独自一人创建WBS不妥;

    7、WBS的创建没有遵循相关原则/多人负债同一工作包/工作包时间过长或过短;

    8、没有形成范围基准/范围基准未经确认;

    9、没有形成范围确认工作/范围确认未贯穿于项目始终;

    10、没有进行范围控制工作导致问题频发/范围控制没有走变更控制流程;

    11、项目经理管理经验不足,可见未提前进行好相关的培训工作;

    规划范围管理的输出:范围管理计划+需求管理计划

    范围基准:批准的范围说明书、WBS、WBS词典

    WBS分解原则:

    1、WBS必须是面向可交付成果的;

    2、WBS必须符合项目范围;

    3、WBS的底层工作应该支持计划和控制;

    4、WBS中的元素必须有人负责,而且只由一个人负责;

    5、WBS应控制在4-6层;

    6、WBS应该包括项目管理工作,也要包括分包出去的工作;

    7、WBS的编制需要所有(主要)项目干系人的参与;

    8、WBS并非是一成不变的

    范围说明书的内容:

    产品范围描述、可交付成果、验收标准、项目的除外责任、项目需求、假设条件、制约因素

    WBS分解步骤:

    1、识别和分析可交付成果及相关工作;

    2、确定WBS的结构和编排方法;

    3、自上而下逐层细化分解;

    4、为WBS组件制定和分配标识编码;

    5、核实可交付成果分解的程度是否恰当

    范围确认和质量控制的区别与联系?

    需求文件的主要内容包括?

    1、业务需求

    (1)、可跟踪的业务目标和项目目标;

    (2)、执行组织的业务规则;

    (3)、组织的指导原则

    2、干系人需求

    对组织其他领域的影响;对执行组织内部或外部团体的影响;干系人对沟通和报告的需求

    3、解决方案需求

    功能和非功能需求;技术和标准合规性需求;支持和培训的需求;质量需求;报告需求;

    4、项目需求

    服务水平、绩效、安全和合规性等;验收标准

    5、过度需求

    6、与需求相关的假设条件、依赖关系和制约因素

    需求跟踪矩阵的主要内容:

    1、业务需要、机会、目的和目标;

    2、项目目标;

    3、项目范围/WBS可交付成果;

    4、产品设计;

    5、产品开发;

    6、测试策略和测试场景;

    7、高层级需求到详细需求。

    缩短工期的方法:

    赶工;快速跟进;使用高素质的资源或经验丰富的人员;缩小活动范围或降低活动要求;改进方法或技术;加强质量管理,减少返工。

    赶工和快速跟进的区别?

    资源平衡和资源平滑的区别?

    总时差和自由时差的区别?

    三点估算公式:

    te期望时间;to乐观时间;tm是最可能时间,tp是悲观时间

    贝塔分布(最乐观时间+4*最可能时间+最悲观时间)/6

    三角分布:(最乐观时间+最可能时间+最悲观时间)/3

    标准差公式:σ=(tp-to)/6

    挣值分析:pv计划价值 ev是挣值 ac实际成本

    etc 完工尚需估算 bac完工预算 eac 完工估算

    成本偏差 cv=ev-ac

    进度偏差=sv=ev-pv

    成本绩效指数cpi=ev/ac

    进度绩效指数spi=ev/pv

    非典型偏差etc=bac-ev

    典型偏差:etc=(bac-ev)/cpi

    完工估算:eac=ac+etc

    完工偏差:vac=bac-eac

    为了按计划(bac)完成,必须维持的效率:

    完工尚需绩效指数:tcpi=(bac-ev)/(bac-ac)

    为了按当前完工估算(eac)完成,必须维持的效率:

    完工尚需绩效指数tcpi=(bac-ev)/(eac-ac)

    质量管理常见问题:

    项目经理质量管理经验和能力不足;

    项目的软件研发人员不应该兼任项目质量管理人员;

    没有依据本项目的相关资料制订质量管理计划/不能依据个人经验制订;

    没有生成质量测量标准;

    质量控制应该贯穿全过程,不应该在X月才开始检查;

    没有进行质量审计;

    没有对项目成员开展质量培训;

    项目经理没有对质量检查中发现的问题进行记录;

    针对发现的不符合项,没有采取正式的纠正及改进措施,也没有跟踪纠正及改进措施的落实情况

    资源管理常见问题

    没有制定资源管理计划;

    没有制定团队章程;

    资源管理计划没有明确团队的角色职责导致后期出现纠纷/问题;

    没有为核心岗位设置AB岗,导致项目进度滞后;

    估算活动资源不到位/没有产出项目的资源需求;

    没有及时组织有效的团队建设情况;

    缺乏培训,或培训占用太多精力;

    没有及时发现冲突,或没有进行良好的冲突管理;

    没有控制资源,设备未按时归还;

    团队阶段:形成、震荡、规范、发挥、解散

    冲突发展的阶段:潜伏、感知、感受、呈现、结束

    冲突解决办法:合作/解决问题;强迫/命令;妥协/调解;缓和/包容;撤退/回避

    团队章程的内容:团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南、团队共识

    沟通和干系人管理常见问题

    1、识别干系人不全面;未识别干系人;

    2、未编制沟通管理计划/干系人参与计划;

    3、独自编制干系人清单不妥,应全体人员共同制定;

    4、干系人沟通方式单一,只采用电子邮件/会议方式;

    5、与各个干系人之间的沟通方法和频率不合理;

    6、监督干系人参与不到位,项目经理发现干系人参与项目不积极后,未采取有效行动;

    干系人等级册没有持续更新;

    与高层沟通不力;

    沟通渠道数:M=n*(n-1)/2

    沟通方法:互动沟通、推式沟通、拉式沟通

    权力/利益方格:

    高 令其满意 重点管理

    权力

    低 监督(花最小精力) 随时告知

    低 利益 高

    风险管理常见问题

    未制定风险管理计划/独自编制风险管理计划不妥;

    根据自己经验制定风险管理计划不妥;

    风险识别未贯穿项目始终;

    风险登记册不应该由一人编制/不应该靠经验来编制;

    没有进行风险定性分析/未进行风险排序;

    没有进行风险定量分析;

    风险应对措施不够全面;

    风险监控不到位/出现了新的风险未及时更新风险登记册;

    依据自己经验制定应对计划不妥,应依据定性风险分析的风险值开展定量风险分析排序后,制定风险应对计划;

    没有进行风险审计/风险再评估。

    风险管理计划的内容:风险管理策略、方法论、角色与职责、资金、时间安排、风险类别、干系人风险偏好、风险概率和影响、概率和影响矩阵、报告格式、跟踪

    SWOT分析:优势、劣势、机会、威胁

    风险登记册的内容:已识别风险的清单、潜在风险责任人、潜在风险应对措施清单

    消极风险应对策略:规避、转移、减轻、接受

    积极风险应对策略:开拓、提高、分享、接受

    合同的内容:标的内容和范围;项目的质量要求;项目的计划、进度、地点、地域和方式;项目建设过程中的各种期限;技术情报和资料的保密;风险责任的承担;技术成果的归属;验收的标准和方法;价款、报酬及其支付方式;违约金或者损失赔偿的计算方法;解决争议的方法;名词术语解释

    配置管理常见问题

    没有编制配置管理计划;不应独自一人制定配置管理计划;

    项目经理不应兼职配置管理员,应该配备专职的配置管理员;

    配置库权限设置存在问题,不能给所有项目组成员开放全部操作权限;

    没有建立配置库;

    没有给所有的配置项进行配置标识;

    配置控制没有做好/配置的变更没有走配置管理流程;

    配置项在开发库修改后未经评审就放入受控库中;

    版本管理存在问题,配置项更新后版本号并未更新;

    没有做好配置审计工作;

    没有及时进行配置管理回顾与改进;

    没有对成员进行配置管理培训;

    配置管理员/项目经理经验不足;

    配置项状态分为:草稿、正式、修改

    配置库分为:开发库、受控库、产品库

    配置审计分为:功能和物理

    配置管理活动包括:制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、配置管理回顾与改进

    配置控制流程:变更申请、变更评估、通告评估结果、变更实施、变更验证与确认、变更的发布、基于配置库的变更控制

    ITTO

    输入:

    项目章程、项目管理计划、项目文件(风险登记册、干系人登记册、问题日志、变更日志)、工作绩效数据、事业环境因素、组织过程资产

    工具与技术:

    数据收集、数据分析、数据表现、检查、会议、专家判断、审计、决策、项目管理信息系统、人际关系与团队技能

    输出:

    变更请求、工作绩效信息、项目管理计划更新、项目文件更新(风险登记册、干系人登记册、问题日志、变更日志)、组织过程资产更新

  • 软考知识点

    智能制造能力成熟度等级:一级(规划级)、二级(规范级)、三级(集成级)、四级(优化级)、五级(引领级)、

    开始规划,核心业务;单一业务数据共享;跨业务数据共享;核心业务精准预测和优化;持续优化和创新。

    现代化服务:1、基础服务2、生产和市场服务3、个人消费服务4、公共服务

    先进制造业与现代服务业的融合表现出结合型、绑定型和延申型。

    消费互联网以个人为用户,以日常生活为应用场景

    本质是个人虚拟化,增强个人生活消费体验

    智慧城市发展成熟度等级:一级(规划级)、二级(管理级)、三级(协同级)、四级(优化级)、五级(引领级)、

  • 世界,您好!

    欢迎使用 WordPress。这是您的第一篇文章。编辑或删除它,然后开始写作吧!