data-engineering-weekly-report

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Data Engineering Weekly / Sprint Status Report

数据工程每周/冲刺状态报告

Generates a compact, Epic-based status report for the Data Engineering team from Azure DevOps (project NLASTIC), then outputs it as markdown. Optionally save to a file or publish to a wiki.

Data source: Azure DevOps CLI (

az boards

). Use az boards iteration team list, az boards area team list, az boards query (WIQL), and az boards work-item show.

从Azure DevOps（项目NLASTIC）为数据工程团队生成一份简洁的、基于Epic的状态报告，然后以markdown格式输出。可选择保存到文件或发布到wiki。

数据源： Azure DevOps CLI（

az boards

）。使用az boards iteration team list、az boards area team list、az boards query（WIQL）和az boards work-item show命令。

Defaults

默认参数

Parameter	Value
Project	NLASTIC
Team	Data Engineering
ADO link format	`https://dev.azure.com/NCS-RnD/NLASTIC/_workitems/edit/{ID}`
Sprint board URL	`https://dev.azure.com/NCS-RnD/NLASTIC/_sprints/taskboard/Data%20Engineering/NLASTIC/{Iteration Name}`

Use these unless the user specifies otherwise.

参数	值
项目	NLASTIC
团队	Data Engineering
ADO链接格式	`https://dev.azure.com/NCS-RnD/NLASTIC/_workitems/edit/{ID}`
冲刺面板URL	`https://dev.azure.com/NCS-RnD/NLASTIC/_sprints/taskboard/Data%20Engineering/NLASTIC/{Iteration Name}`

除非用户另行指定，否则使用上述默认值。

Workflow

工作流程

1. Resolve current sprint

1. 确定当前冲刺

Run

az boards iteration team list --project "NLASTIC" --team "Data Engineering" --timeframe current --output json

From the response take the iteration path (and name/dates for the report header).

运行

az boards iteration team list --project "NLASTIC" --team "Data Engineering" --timeframe current --output json

。

从响应中提取迭代路径（以及报告标题所需的名称/日期）。

1b. Resolve team area path

1b. 确定团队领域路径

Run

az boards area team list --team "Data Engineering" --project "NLASTIC" --output json

From the response take the area path value (e.g.
```
NLASTIC\Data Engineering
```
). This is needed to scope the WIQL query to the team's items only.

运行

az boards area team list --team "Data Engineering" --project "NLASTIC" --output json

。

从响应中提取领域路径值（例如
```
NLASTIC\Data Engineering
```
）。这是将WIQL查询范围限定为团队专属工作项所必需的。

2. Get work items in sprint

2. 获取冲刺中的工作项

Run a WIQL query filtering by both iteration path and area path:

az boards query --wiql "SELECT [System.Id] FROM WorkItems WHERE [System.IterationPath] = '<iteration path from step 1>' AND [System.AreaPath] UNDER '<area path from step 1b>'" --project "NLASTIC" --output json

Important: Without the area path filter the query returns items for all teams in the project.

Collect all returned work item IDs.

运行一个同时按迭代路径和领域路径过滤的WIQL查询：

az boards query --wiql "SELECT [System.Id] FROM WorkItems WHERE [System.IterationPath] = '<iteration path from step 1>' AND [System.AreaPath] UNDER '<area path from step 1b>'" --project "NLASTIC" --output json

重要提示： 如果没有领域路径过滤，查询将返回项目中所有团队的工作项。

收集所有返回的工作项ID。

3. Batch get details

3. 批量获取工作项详情

For each work item ID, run:
```
az boards work-item show --id <ID> --output json
```
Note:
```
az boards work-item show
```
does not support
```
--project
```
or
```
--fields
```
flags — it uses the configured default org/project and returns all fields. Extract the needed fields client-side from the
```
fields
```
object in the JSON response.

Fields to extract:

System.Id

System.Title

System.State

System.WorkItemType

System.AssignedTo

System.Parent

System.CreatedDate

Microsoft.VSTS.Scheduling.RemainingWork

Microsoft.VSTS.Scheduling.TargetDate

Microsoft.VSTS.Scheduling.StoryPoints

Microsoft.VSTS.Common.ClosedDate

Microsoft.VSTS.Common.StateChangeDate

Microsoft.VSTS.Common.Severity

Loop over all IDs. Run calls in parallel (e.g. 10 concurrent) to reduce latency.

针对每个工作项ID，运行：
```
az boards work-item show --id <ID> --output json
```
注意：
```
az boards work-item show
```
不支持
```
--project
```
或
```
--fields
```
参数——它使用配置的默认组织/项目并返回所有字段。从JSON响应的
```
fields
```
对象中提取所需字段。

需要提取的字段：

System.Id

、

System.Title

、

System.State

、

System.WorkItemType

、

System.AssignedTo

、

System.Parent

、

System.CreatedDate

、

Microsoft.VSTS.Scheduling.RemainingWork

、

Microsoft.VSTS.Scheduling.TargetDate

、

Microsoft.VSTS.Scheduling.StoryPoints

、

Microsoft.VSTS.Common.ClosedDate

、

Microsoft.VSTS.Common.StateChangeDate

、

Microsoft.VSTS.Common.Severity

。

遍历所有ID。并行运行调用（例如10个并发）以减少延迟。

4. Build Epic → Feature → User Story hierarchy

4. 构建 Epic → Feature → User Story 层级

The report is organized by Epic, not by team member.

From the batch result, separate items by System.WorkItemType into User Story, Task, Bug, Feature, Epic.
For each User Story, Bug, and Task in the sprint, read the System.Parent field from the details already fetched in step 3.
- If the parent ID is not already in the sprint results, fetch it:
```
az boards work-item show --id <parent_id> --output json
```
  .
- Run these calls in parallel where possible.
Walk the full parent chain upward — repeat fetching unknown parents until every chain reaches an Epic or a node with no parent. The chain can be 2–4 levels deep (e.g. Task → User Story → Feature → Epic). Fetch each level in a parallel batch before moving to the next.
Build the hierarchy: Epic → list of Features → list of User Stories/Bugs/Tasks in the sprint.
Collapse generic Tasks to User Story level. If a User Story's child Tasks all have generic/boilerplate titles (e.g.
```
implementation
```
,
```
planning
```
,
```
buffer
```
,
```
support
```
,
```
design
```
,
```
review
```
,
```
testing
```
,
```
documentation
```
— case-insensitive), report at the User Story level only and omit the individual Tasks from bullet lists. These Tasks still count toward status calculations (e.g. Feature effective status, remaining work) but are not shown as separate line items. If a User Story has at least one Task with a specific, meaningful title (i.e. not in the generic list), show all non-buffer Tasks as nested bullets under it.
Items whose parent chain never reaches an Epic (orphans):
- Items with
```
System.Parent = null
```
  (true orphans — no parent at all) — include them under the most relevant Epic section based on their title/context, or list them at the end of the report if no match.
- Items whose chain stops at a Feature or User Story that itself has no parent — same treatment.
- Bugs always go under the "Bugs" section regardless of parent chain.

报告按Epic组织，而非按团队成员。

从批量结果中，按System.WorkItemType将工作项分为User Story、Task、Bug、Feature、Epic。
针对冲刺中的每个User Story、Bug和Task，读取步骤3中已获取详情里的System.Parent字段。
- 如果父ID不在冲刺结果中，则获取该父项：
```
az boards work-item show --id <parent_id> --output json
```
  。
- 尽可能并行运行这些调用。
向上遍历完整的父链——重复获取未知的父项，直到每个链都到达Epic或无父项的节点。链的深度可能为2–4级（例如 Task → User Story → Feature → Epic）。在进入下一层级之前，并行批量获取每一层级的父项。
构建层级结构：Epic → Feature列表 → 冲刺中的User Story/Bug/Task列表。
将通用Task合并到User Story层级。如果某个User Story的所有子Task标题均为通用/模板化内容（例如
```
implementation
```
、
```
planning
```
、
```
buffer
```
、
```
support
```
、
```
design
```
、
```
review
```
、
```
testing
```
、
```
documentation
```
——不区分大小写），则仅在User Story层级进行报告，不在项目符号列表中显示单个Task。这些Task仍会计入状态计算（例如Feature的实际状态、剩余工作量），但不会作为单独的行项显示。如果User Story至少有一个Task的标题具有特定、有意义的内容（即不在通用列表中），则在其下方以嵌套项目符号显示所有非缓冲类Task。
父链从未到达Epic的孤立项：
- ```
System.Parent = null
```
  的项（真正的孤立项——完全没有父项）——根据其标题/上下文将其归入最相关的Epic部分，如果无匹配项则在报告末尾列出。
- 父链终止于无父项的Feature或User Story的项——处理方式同上。
- Bug无论父链如何，均归入**"Bugs"**部分。

5. Per-Epic analysis

5. 按Epic分析

For each Epic section:

Objective: Derive from the Feature/User Story titles and descriptions — summarize in 1-2 sentences what the team is trying to achieve in this area.
Feature effective status: A Feature's own
```
System.State
```
can lag behind its children. Determine effective status from children: if any child item (User Story/Task) is not Closed, treat the Feature as open. Only mark a Feature as done when all its children in the sprint are Closed.
Status indicator: Assess on/off track based on effective item states (after excluding Removed/Rejected):
- ✅ On Track — majority of items Active or Closed, no overdue items
- ✅ Done — all items in the Epic are Closed
- ⚠️ At Risk — items still New with significant remaining work, or limited progress
Exclude items with State =
```
Removed
```
or
```
Rejected
```
— drop them entirely from the report (do not count them in totals or list them).

Done this week: Items with State = Closed (use

Microsoft.VSTS.Common.ClosedDate

Microsoft.VSTS.Common.StateChangeDate

to confirm recency)

In progress: Items with State = Active or In Review
Next week: Items with State = New that are planned for upcoming work
Unplanned items: Items created during the sprint (compare
```
System.CreatedDate
```
to sprint start date). Tag as Unplanned in the report.

针对每个Epic部分：

目标：从Feature/User Story的标题和描述中提炼——用1-2句话总结团队在该领域的目标。
Feature实际状态：Feature自身的
```
System.State
```
可能滞后于其子项。根据子项确定实际状态：如果任何子项（User Story/Task）未关闭，则将Feature视为未完成。只有当冲刺中该Feature的所有子项均已关闭时，才标记Feature为完成。
状态指示器：根据有效项状态（排除Removed/Rejected状态）评估进度：
- ✅ 进度正常——大多数项处于Active或Closed状态，无逾期项
- ✅ 已完成——该Epic下的所有项均已关闭
- ⚠️ 存在风险——仍有New状态的项且剩余工作量较大，或进展有限
排除状态为
```
Removed
```
或
```
Rejected
```
的项——将其完全从报告中移除（不纳入总数统计或列表显示）。

本周已完成：状态为Closed的项（使用

Microsoft.VSTS.Common.ClosedDate

或

Microsoft.VSTS.Common.StateChangeDate

确认时效性）

进行中：状态为Active或In Review的项
下周计划：状态为New且计划在后续开展的项
计划外项：在冲刺期间创建的项（将
```
System.CreatedDate
```
与冲刺开始日期比较）。在报告中标记为Unplanned。

6. Identify risks

6. 识别风险

Infer from: items Overdue (TargetDate in the past), items still Active near sprint end, New with large RemainingWork, Critical/High severity bugs, unassigned items.

Format:

> **Risk:** [#ID Title](link) still Active — may carry over to [Month].

Place risks as a single blockquote line under each Epic section (not separate tables).
Focus on carry-over risk: items that are still Active and likely to spill into the next sprint/month.

从以下情况推断：逾期项（TargetDate已过期）、冲刺末期仍处于Active状态的项、剩余工作量大的New项、Critical/High严重程度的Bug、未分配的项。

格式：

> **风险：** [#ID 标题](链接) 仍处于Active状态 — 可能顺延至[月份]。

将风险作为单个块引用行放置在每个Epic部分下方（不使用单独表格）。
重点关注顺延风险：仍处于Active状态且可能顺延至下一个冲刺/月份的项。

7. Produce the report

7. 生成报告

Use the Report template below. Keep it compact — use inline bullet lists, not heavy tables. Every work item ID must be a clickable ADO link.

使用下方的报告模板。保持报告简洁——使用内联项目符号列表，避免复杂表格。每个工作项ID必须是可点击的ADO链接。

8. Send / share (optional)

8. 发送/分享（可选）

Output in chat: Always include the full report in the response.
Save to file: Default path:
```
Data_Engineering_Weekly_Report_YYYY-MM-DD.md
```
in workspace root.
Wiki: If the user wants it in Confluence/Azure Wiki, use the appropriate CLI or API.

在聊天中输出：响应中始终包含完整报告。
保存到文件：默认路径：工作区根目录下的
```
Data_Engineering_Weekly_Report_YYYY-MM-DD.md
```
。
Wiki发布：如果用户希望发布到Confluence/Azure Wiki，使用相应的CLI或API。

Report template

报告模板

The report must be compact and scannable. Use bullet lists for completed/planned items (not tables). Use tables only for bugs (where severity column adds value). Every ID is a clickable link. Assignee shown as first name only in italics.

markdown

undefined

报告必须简洁易读。已完成/计划项使用项目符号列表（不使用表格）。仅在Bug部分使用表格（严重程度列有附加价值）。每个ID都是可点击的链接。经办人仅显示名字并以斜体呈现。

markdown

undefined

Data Engineering — Weekly Report | [Week date range]

数据工程 — 每周报告 | [日期范围]

Sprint: Sprint name link ([Start] – [End]) | [X] of [Y] stories closed | [N] Features closed this week

冲刺： 冲刺名称链接 ([开始日期] – [结束日期]) | 已关闭 [X]/[Y] 个User Story | 本周已关闭 [N] 个Feature

1. #ID Epic Name — Short Label ✅ On Track / ⚠️ At Risk / ✅ Done

1. #ID Epic名称 — 简短标签 ✅ 进度正常 / ⚠️ 存在风险 / ✅ 已完成

Objective: [1-2 sentence summary of what we're trying to achieve in this area]
Done this week:
- #ID Feature Title — Feature
  - #ID Child US/Task Title (SP:N) — Assignee
  - #ID Child US/Task Title (SP:N) — Assignee
- #ID US Title (SP:N) — Assignee
In progress:
- #ID Title — Assignee (contextual note)
Next week:
- #ID Title (SP:N) — Assignee

Risk: #ID Title still Active — may carry over to [Month].

目标： [1-2句话总结该领域的工作目标]
本周已完成：
- #ID Feature标题 — Feature
  - #ID 子User Story/Task标题 (SP:N) — 经办人
  - #ID 子User Story/Task标题 (SP:N) — 经办人
- #ID User Story标题 (SP:N) — 经办人
进行中：
- #ID 标题 — 经办人 (上下文说明)
下周计划：
- #ID 标题 (SP:N) — 经办人

风险： #ID 标题仍处于Active状态 — 可能顺延至[月份]。

2. #ID Epic Name

2. #ID Epic名称

(same structure as above)

（结构同上）

Bugs - [N] High-Severity Open

Bugs - [N] 个高严重程度未解决Bug

Done this sprint:
- #ID Title — Assignee
- #ID Title — Assignee
In review:
- #ID Title (severity) — Assignee (contextual note)
Open:

ID	Title	Sev	Assignee	Note
#ID	title	Medium	name	Unplanned

View sprint board

---

本冲刺已完成：
- #ID 标题 — 经办人
- #ID 标题 — 经办人
审核中：
- #ID 标题 (严重程度) — 经办人 (上下文说明)
未解决：

ID	标题	严重程度	经办人	说明
#ID	标题	Medium	名字	Unplanned

查看冲刺面板

---

Formatting rules

格式规则

Clickable links: Every work item must be a markdown link with ID and title inside the link text:

[#ID Title](https://dev.azure.com/NCS-RnD/NLASTIC/_workitems/edit/ID)

. Example:

[#12 NYG - Nlastic Yaml Generator](https://dev.azure.com/NCS-RnD/NLASTIC/_workitems/edit/12)

Assignee: First name only, in italics: Michael, Yair, Tomer, Sari, Tzvi
Story points: Inline as
```
(SP:N)
```
— omit if not set

Sprint header: Include a one-line sprint summary after the title:

**Sprint:** [name](board-url) ([Start] – [End]) | [X] of [Y] stories closed | [N] Features closed this week

Numbered Epic sections: Epics are numbered sequentially (
```
## 1.
```
,
```
## 2.
```
, etc.) with status indicator on the heading:
```
✅ On Track
```
,
```
⚠️ At Risk
```
, or
```
✅ Done
```
.
Completed Features in "Done this week": Show the Feature as a parent bullet with
```
— _Feature_
```
label (the work item type). Indent child User Stories/Tasks as nested bullets below it, each with
```
— _Assignee_
```
.
Completed User Stories (no Feature parent): Show as individual bullet points with
```
— _Assignee_
```
Next week items: List as individual bullet points under
```
- **Next week:**
```
Contextual notes: Add brief context in parentheses after the assignee when relevant — e.g.
```
(moved to Daher from Bar)
```
,
```
(in second review round)
```
,
```
(review scheduled for next week)
```
. These help readers understand the current state beyond what ADO status shows.

Risks: Use blockquote (

) under each Epic section — format as:

> **Risk:** [#ID Title](link) still Active — may carry over to [Month].

Unplanned items: Bold tag
```
**Unplanned**
```
in the Note column for bugs or in-line for stories
Bugs section heading: Use
```
## Bugs - [N] High-Severity Open
```
(show count of high-severity open bugs). Sub-sections use
```
- **Done this sprint:**
```
,
```
- **In review:**
```
,
```
- **Open:**
```
.
No "Type" column in tables — the context makes it clear
No long descriptions — title is sufficient
Buffer items: Items titled "buffer" (case-insensitive) are capacity placeholders — exclude them from bullet lists and tables.
Generic-task collapsing: When a User Story has only generic Tasks (titles like
```
implementation
```
,
```
planning
```
,
```
buffer
```
,
```
support
```
,
```
design
```
,
```
review
```
,
```
testing
```
,
```
documentation
```
), display only the User Story — do not list individual Tasks. This keeps the report at the right level of abstraction and avoids noise from boilerplate task breakdowns.
Tables only for: open bugs list (where severity column adds value)

可点击链接：每个工作项必须是markdown链接，链接文本包含ID和标题：

[#ID 标题](https://dev.azure.com/NCS-RnD/NLASTIC/_workitems/edit/ID)

。示例：

[#12 NYG - Nlastic Yaml Generator](https://dev.azure.com/NCS-RnD/NLASTIC/_workitems/edit/12)

。

经办人：仅显示名字，以斜体呈现：Michael、Yair、Tomer、Sari、Tzvi
故事点：以内联形式
```
(SP:N)
```
呈现——未设置则省略

冲刺标题：标题下方包含一行冲刺摘要：

**冲刺：** [名称](面板URL) ([开始日期] – [结束日期]) | 已关闭 [X]/[Y] 个User Story | 本周已关闭 [N] 个Feature

。

编号Epic部分：Epics按顺序编号（
```
## 1.
```
、
```
## 2.
```
等），标题中包含状态指示器：
```
✅ 进度正常
```
、
```
⚠️ 存在风险
```
或
```
✅ 已完成
```
。
本周已完成的Feature：作为父项目符号显示，附带
```
— _Feature_
```
标签（工作项类型）。其子User Story/Task作为嵌套项目符号缩进显示在下方，每个项目符号附带
```
— _经办人_
```
。
已完成的User Story（无Feature父项）：作为单独的项目符号显示，附带
```
— _经办人_
```
下周计划项：在
```
- **下周计划：**
```
下作为单独的项目符号列出
上下文说明：相关时在经办人后添加简短上下文（括号内）——例如
```
(从Bar移交至Daher)
```
、
```
(处于第二轮审核)
```
、
```
(审核计划于下周进行)
```
。这些说明有助于读者了解ADO状态之外的当前情况。

风险：使用块引用（

）放置在每个部分下方，格式为：

> **风险：** [#ID 标题](链接) 仍处于Active状态 — 可能顺延至[月份]。

计划外项：在Bug的说明列中使用粗体标签
```
**Unplanned**
```
，或在User Story行内标记

Bug部分标题：使用

## Bugs - [N] 个高严重程度未解决Bug

（显示未解决的高严重程度Bug数量）。子部分使用

- **本冲刺已完成：**

、

- **审核中：**

、

- **未解决：**

。

表格中无需"类型"列——上下文已明确说明
无需长描述——标题已足够
缓冲项：标题为"buffer"（不区分大小写）的项是容量占位符——从项目符号列表和表格中排除。
通用Task合并：当User Story仅包含通用Task（标题如
```
implementation
```
、
```
planning
```
、
```
buffer
```
、
```
support
```
等）时，仅显示User Story——不列出单个Task。这使报告保持合适的抽象层级，避免模板化任务分解带来的冗余信息。
仅以下场景使用表格：未解决Bug列表（严重程度列有附加价值）

Checklist before delivering

交付前检查清单

Current sprint resolved via az boards iteration team list.
Team area path resolved via az boards area team list.
WIQL query scoped by both iteration path and area path.
All work items in iteration loaded (parallel fetches, batched if >200).
Epic → Feature → User Story hierarchy built via parent resolution.
Sprint header with story/feature closure counts included.
Report organized by numbered Epic sections (not by team member).
Each Epic has: objective, status indicator (✅/⚠️), done/in-progress/next-week items, risks.
Unplanned items identified and tagged.
All work item links use
```
[#ID Title](url)
```
format (ID and title inside the link text).
Completed Features shown as parent bullets with child items nested below.
User Stories with only generic Tasks (implementation, planning, buffer, support, etc.) reported at US level — Tasks omitted.
Contextual notes added where relevant (reassignments, review status, etc.).
Report is compact — bullet lists, not heavy tables.
Risks placed as blockquotes under each section in
```
still Active — may carry over
```
format.
Bugs section uses "Done this sprint" / "In review" / "Open" sub-sections.
If user asked to "send" or "save", file written or wiki updated.

通过az boards iteration team list确定当前冲刺。
通过az boards area team list确定团队领域路径。
WIQL查询同时按迭代路径和领域路径限定范围。
已加载迭代中的所有工作项（并行获取，若超过200个则分批处理）。
通过解析父项构建了Epic → Feature → User Story层级。
包含带有User Story/Feature关闭数量的冲刺标题。
报告按编号Epic部分组织（而非按团队成员）。
每个Epic包含：目标、状态指示器（✅/⚠️）、已完成/进行中/下周计划项、风险。
已识别并标记计划外项。
所有工作项链接均使用
```
[#ID 标题](url)
```
格式（链接文本包含ID和标题）。
已完成的Feature作为父项目符号显示，子项嵌套在下方。
仅包含通用Task（implementation、planning、buffer、support等）的User Story在User Story层级报告——省略Task。
已添加相关的上下文说明（重新分配、审核状态等）。
报告简洁——使用项目符号列表，避免复杂表格。
风险以块引用形式放置在每个部分下方，格式为
```
仍处于Active状态 — 可能顺延
```
。
Bug部分使用"本冲刺已完成" / "审核中" / "未解决"子部分。
如果用户要求"发送"或"保存"，已写入文件或更新wiki。