mcpField
C
cwm-tasks-generation

cwm-tasks-generation

github.com/happy-technologies-llc生产力4141 次安装2 天前更新
代码仓库

关于 cwm-tasks-generation

面向 ServiceNow CWM 项目经理的任务拆解技能，可将需求、用户故事或项目描述转为分层工作分解结构。涵盖估算、依赖、资源分配与里程碑设置。

主要功能

  1. 01将需求拆分为分层任务
  2. 02估算任务工时与持续时间
  3. 03定义任务依赖关系
  4. 04按技能和可用性分配资源
  5. 05设置里程碑与阶段关口

适用场景

  1. 01将已批准需求转为可执行任务
  2. 02拆解 Epic 或用户故事
  3. 03为新项目阶段规划任务
  4. 04项目重规划时调整计划

MCP 相关

通过 SN-Get-Record、SN-Query-Table、SN-Create-Record 和 SN-Update-Record 等 MCP 工具读取项目资料，并创建和配置任务。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/happy-technologies-llc/happy-platform-skills --skill cwm-tasks-generation

安装后在 Claude Code 中输入/cwm-tasks-generation确认已加载。

详细介绍

CWM 任务生成

概述

此技能介绍如何根据 ServiceNow CWM 中的需求、用户故事或高层项目描述生成结构化的任务分解：

  • 将需求分解为分层工作分解结构（WBS）
  • 创建项目任务，并估算工作量、工期和所需技能
  • 定义任务依赖关系（完成-开始、开始-开始、完成-完成）
  • 根据技能和可用性将任务分配给团队成员
  • 在适当的项目检查点设置里程碑和阶段关卡
  • 生成可并行执行任务的并行工作流

适用场景： 开始新的项目阶段、将已批准的需求转换为可执行任务、分解 Epic 或用户故事，或为重新规划而调整项目计划时。

前提条件

  • 角色： project_manager、program_manager 或 admin
  • 插件： com.snc.project_management（项目组合管理）或 CWM 工作区
  • 访问权限： 对 pm_project_task、planned_task 表具有写入权限
  • 数据： 已有项目记录，并且已定义需求或用户故事
  • 相关技能： spm/cwm-doc-generation 用于状态报告，spm/acceptance-criteria 用于定义完成标准

流程

步骤 1：分析源需求

检查输入的需求或用户故事，确定工作组成部分。

MCP 方法：

Tool: SN-Get-Record
Parameters:
  table_name: pm_project
  sys_id: [PROJECT_SYS_ID]
  fields: sys_id,number,short_description,description,planned_start_date,planned_end_date,project_manager,methodology

如果需求以故事或需求项的形式存储：

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: product=[PROJECT_SYS_ID]^state!=cancelled
  fields: sys_id,number,short_description,description,acceptance_criteria,story_points,priority
  limit: 50

分解框架：

需求类型分解方法
Epic / 功能分解为用户故事，再分解为任务
用户故事分解为实施任务（设计、构建、测试、部署）
技术需求分解为分析、实施、验证任务
业务流程分解为流程步骤，每个步骤成为一个任务
集成分解为设计、开发、测试、认证任务
步骤 2：定义工作分解结构

创建具有父子关系的分层任务结构。

PROJECT: [Project Name]
|
+-- Phase 1: [Phase Name]
|   +-- WP 1.1: [Work Package]
|   |   +-- Task 1.1.1: [Task]
|   |   +-- Task 1.1.2: [Task]
|   +-- WP 1.2: [Work Package]
|   |   +-- Task 1.2.1: [Task]
|   +-- Milestone: [Phase 1 Complete]
|
+-- Phase 2: [Phase Name]
|   +-- WP 2.1: [Work Package]
|   ...
步骤 3：创建阶段任务

构建顶层阶段容器。

MCP 方法：

Tool: SN-Create-Record
Parameters:
  table_name: pm_project_task
  data:
    project: [PROJECT_SYS_ID]
    short_description: "Phase 1: Requirements and Design"
    description: "Gather detailed requirements, create solution design, and obtain stakeholder approval"
    state: pending
    priority: 2
    planned_start_date: "2026-04-01"
    planned_end_date: "2026-04-30"
    top_task: true
    wbs: "1"

REST 方法：

POST /api/now/table/pm_project_task
Body: {
  "project": "[PROJECT_SYS_ID]",
  "short_description": "Phase 1: Requirements and Design",
  "description": "Gather detailed requirements, create solution design, and obtain stakeholder approval",
  "state": "pending",
  "priority": "2",
  "planned_start_date": "2026-04-01",
  "planned_end_date": "2026-04-30",
  "top_task": "true",
  "wbs": "1"
}
步骤 4：创建工作包和叶子任务

在每个阶段下创建详细任务。

MCP 方法：

Tool: SN-Create-Record
Parameters:
  table_name: pm_project_task
  data:
    project: [PROJECT_SYS_ID]
    parent: [PHASE_TASK_SYS_ID]
    short_description: "Conduct stakeholder interviews"
    description: "Schedule and conduct interviews with 8 key stakeholders to gather requirements for the new system"
    state: pending
    priority: 2
    planned_start_date: "2026-04-01"
    planned_end_date: "2026-04-05"
    estimated_work_duration: "3 days"
    assigned_to: [USER_SYS_ID]
    assignment_group: [GROUP_SYS_ID]
    wbs: "1.1"
    skill: "Business Analysis"

REST 方法：

POST /api/now/table/pm_project_task
Body: {
  "project": "[PROJECT_SYS_ID]",
  "parent": "[PHASE_TASK_SYS_ID]",
  "short_description": "Conduct stakeholder interviews",
  "state": "pending",
  "planned_start_date": "2026-04-01",
  "planned_end_date": "2026-04-05",
  "estimated_work_duration": "3 days",
  "assigned_to": "[USER_SYS_ID]",
  "wbs": "1.1"
}

各类需求的标准任务模板：

用户故事任务预估工作量所需技能
需求分析4-8 小时业务分析师
解决方案设计8-16 小时架构师/技术负责人
实施/构建16-40 小时开发人员
单元测试4-8 小时开发人员
集成测试8-16 小时QA 工程师
用户验收测试4-8 小时BA + 最终用户
文档编写4-8 小时技术文档撰写人员/BA
部署2-4 小时DevOps/管理员
步骤 5：定义任务依赖关系

在任务之间创建前置任务/后续任务关系。

MCP 方法：

Tool: SN-Update-Record
Parameters:
  table_name: pm_project_task
  sys_id: [TASK_SYS_ID]
  data:
    predecessor: [PREDECESSOR_TASK_SYS_ID]
    predecessor_type: "FS"

依赖类型：

类型代码含义示例
完成-开始FSA 完成后 B 开始设计完成后开始构建
开始-开始SSA 开始时 B 开始构建开始时启动测试
完成-完成FFA 完成时 B 完成构建完成时完成文档
开始-完成SFA 开始时 B 完成很少使用

常见依赖模式：

Requirements Analysis (FS) -> Solution Design (FS) -> Implementation
Implementation (FS) -> Unit Testing (FS) -> Integration Testing
Integration Testing (FS) -> UAT (FS) -> Deployment
Documentation (SS) -> Implementation (parallel start)
步骤 6：设置里程碑

在项目的关键检查点创建里程碑任务。

MCP 方法：

Tool: SN-Create-Record
Parameters:
  table_name: pm_project_task
  data:
    project: [PROJECT_SYS_ID]
    parent: [PHASE_TASK_SYS_ID]
    short_description: "MILESTONE: Design Review Approved"
    state: pending
    milestone: true
    planned_end_date: "2026-04-15"
    duration: "0"
    predecessor: [DESIGN_TASK_SYS_ID]
    wbs: "1.5"

建议的里程碑：

里程碑触发条件阶段门标准
需求已批准已评审所有需求获得发起人签字确认
设计已完成已评审架构和设计通过技术评审
开发已完成已构建所有功能通过代码评审，单元测试通过
测试已完成已完成所有测试周期没有未解决的 P1/P2 缺陷
已做好上线准备已验证部署已获得相关方批准
步骤 7：估算工作量和工期

对每项任务应用估算技术。

估算方法：

方法适用场景方法说明
类比估算存在类似的过往项目与历史任务工期进行比较
参数估算工作量单位可量化将单位数量乘以每单位工作量
三点估算不确定性较高（乐观值 + 4*最可能值 + 悲观值）/ 6
专家判断工作内容新颖或复杂咨询主题专家进行估算

将估算应用到任务：

Tool: SN-Update-Record
Parameters:
  table_name: pm_project_task
  sys_id: [TASK_SYS_ID]
  data:
    estimated_work_duration: "16 hours"
    planned_start_date: "2026-04-07"
    planned_end_date: "2026-04-09"
    work_notes: "Estimate based on three-point: Opt=12h, Likely=16h, Pess=24h. PERT=16.3h"
步骤 8：分配资源

根据技能和可用性，将任务分配给团队成员。

MCP 方法：

Tool: SN-Query-Table
Parameters:
  table_name: pm_resource_plan
  query: project=[PROJECT_SYS_ID]^state=active
  fields: sys_id,resource,role,planned_hours,actual_hours,remaining_hours,start_date,end_date
  limit: 30

Tool: SN-Update-Record
Parameters:
  table_name: pm_project_task
  sys_id: [TASK_SYS_ID]
  data:
    assigned_to: [USER_SYS_ID]
    assignment_group: [GROUP_SYS_ID]
步骤 9：验证任务分解

检查生成的任务结构是否完整且可行。

验证清单：

TASK BREAKDOWN VALIDATION:
- [ ] All requirements have corresponding tasks
- [ ] No orphan tasks (every task has a parent or is top-level)
- [ ] Dependencies form a valid DAG (no circular dependencies)
- [ ] Critical path identified and reasonable
- [ ] All tasks have effort estimates
- [ ] All tasks have assigned resources
- [ ] Milestones placed at phase boundaries
- [ ] Resource loading does not exceed capacity
- [ ] Buffer/contingency included (10-20% of total effort)
- [ ] Task descriptions are clear and actionable

MCP 验证方法：

Tool: SN-Query-Table
Parameters:
  table_name: pm_project_task
  query: project=[PROJECT_SYS_ID]^assigned_to=NULL^milestone=false
  fields: number,short_description,wbs,state
  limit: 100
步骤 10：生成任务摘要报告

生成任务分解的摘要报告。

=== TASK BREAKDOWN SUMMARY ===
Project: [number] - [name]
Generated: [date]

STRUCTURE:
Phases: [count]
Work Packages: [count]
Tasks: [count]
Milestones: [count]

EFFORT SUMMARY:
Total Estimated Effort: [hours] hours
Total Duration: [days] business days
Critical Path Duration: [days] business days

RESOURCE ALLOCATION:
| Resource | Role | Allocated Hours | Utilization |
|----------|------|----------------|-------------|
| [name] | [role] | [hours] | [%] |

DEPENDENCY MAP:
[Task A] -> [Task B] -> [Task C] (Critical Path)
[Task D] -> [Task E] (Parallel Stream)

MILESTONES:
| Milestone | Date | Dependencies |
|-----------|------|-------------|
| [name] | [date] | [predecessor tasks] |

工具用法

工具用途使用时机
SN-Query-Table查找现有任务、资源和需求探索和验证
SN-Create-Record创建项目任务和里程碑构建任务分解
SN-Update-Record设置依赖关系、分配资源、更新估算配置任务
SN-Get-Record获取项目详细信息和单项任务记录收集上下文
SN-Get-Table-Schema查找 pm_project_task 字段初始设置

最佳实践

  1. 将任务分解为 8-40 小时——小于 8 小时的任务会增加管理开销，大于 40 小时的任务则缺乏可见性
  2. 采用动词-名词命名——使用“设计数据库架构”，而非“数据库架构”
  3. 涵盖所有工作类型——不要遗漏测试、文档、部署和评审任务
  4. 增加缓冲任务——为未知因素预留 10-20% 的应急时间
  5. 定义“完成”标准——每项任务都应有明确的完成标准
  6. 尽量减少依赖关系——依赖越少，安排日程的灵活性越高
  7. 确定关键路径——明确哪些任务会直接影响项目结束日期
  8. 平衡资源负载——避免给任何一位团队成员分配过多任务
  9. 与团队共同评审——与实际执行工作的人员确认估算和分配
  10. 对分解结果进行版本管理——修改前保存基线，以便进行比较

故障排查

问题原因解决方法
任务未汇总到父任务未设置父项引用确认子任务的 parent 字段指向正确的父项 sys_id
工期计算不正确未配置工作日历检查项目工作日程；确认使用的是工作日还是日历日
循环依赖错误任务 A 依赖任务 B，而任务 B 又依赖任务 A检查依赖链；移除或重构循环引用
资源分配过多同一人被分配了时间重叠的任务错开任务日期，或重新分配以平衡工作量
WBS 编号有缺口创建任务的顺序不正确创建所有任务后，重新排列 WBS 编号
里程碑显示了工期未将工期字段设为零更新里程碑任务，将 duration=0 且 milestone=true

示例

示例 1：Web 应用开发

需求：“构建一个客户自助服务门户，包含账户管理、工单提交和知识库搜索功能。”

生成的拆解：

Phase 1: Design (2 weeks)
  1.1 UX Research & Wireframes - 24h - UX Designer
  1.2 Technical Architecture - 16h - Architect
  1.3 API Design - 12h - Tech Lead
  1.4 Design Review - MILESTONE

Phase 2: Development (4 weeks)
  2.1 Account Management Module - 40h - Developer A
  2.2 Ticket Submission Module - 32h - Developer B
  2.3 KB Search Integration - 24h - Developer A
  2.4 UI Implementation - 40h - Frontend Dev
  2.5 Code Complete - MILESTONE

Phase 3: Testing (2 weeks)
  3.1 Integration Testing - 24h - QA Engineer
  3.2 UAT Execution - 16h - BA + Users
  3.3 Performance Testing - 12h - QA Engineer
  3.4 Test Complete - MILESTONE

Phase 4: Deployment (1 week)
  4.1 Production Setup - 8h - DevOps
  4.2 Data Migration - 12h - DBA
  4.3 Go-Live - MILESTONE
示例 2：系统集成项目

需求：“将 ServiceNow ITSM 与 Jira 集成，实现事件双向同步。”

生成的拆解：

Phase 1: Analysis (1 week)
  1.1 Map field mappings SN <-> Jira - 8h - BA
  1.2 Define sync rules and conflict resolution - 8h - Tech Lead
  1.3 Requirements Signed Off - MILESTONE

Phase 2: Build (3 weeks)
  2.1 Configure IntegrationHub spoke - 16h - Developer
  2.2 Build ServiceNow-to-Jira sync flow - 24h - Developer
  2.3 Build Jira-to-SN webhook handler - 24h - Developer
  2.4 Error handling and retry logic - 12h - Developer
  2.5 Integration Complete - MILESTONE

Phase 3: Validate (1 week)
  3.1 End-to-end sync testing - 16h - QA
  3.2 Edge case and error testing - 8h - QA
  3.3 Validation Complete - MILESTONE

Phase 4: Rollout (3 days)
  4.1 Production configuration - 4h - Admin
  4.2 Historical data sync - 8h - Developer
  4.3 Go-Live - MILESTONE

相关技能

  • spm/cwm-doc-generation - 根据项目数据生成状态报告
  • spm/acceptance-criteria - 为任务定义验收标准
  • spm/agile-story-generation - 根据需求生成用户故事
  • spm/project-insights - 分析项目绩效指标
  • spm/planning-summarization - 汇总规划数据

评论

支持 Markdown