配置 GitHub 项目

了解项目范围和所有权对于 GitHub Projects 和 Azure Boards 之间的成功协作至关重要。 在本单元中，我们将探讨定义项目边界和职责的关键注意事项。

项目范围和所有权决策

组织与用户项目 - 决策矩阵：

因素	组织项目	用户项目
团队协作	多团队跨职能工作	个人或小型团队试验
治理	正式审批流程，审核线索	轻量级快速迭代
能见度	企业范围的透明度	个人或有限的可见性
访问控制	基于角色的权限，企业 SSO	个体控制
生命周期	长期生产工作负荷	原型、学习、测试

最佳做法建议：

• 将组织项目用于生产应用程序和共享服务
• 利用用户项目进行概念证明和个人学习
• 在选择范围时考虑数据管理和符合性要求

项目创建工作流

对于组织项目：

1. 导航到 GitHub 上的组织主页
2. 在组织导航中单击 “项目 ”
3. 在“新建项目”下拉列表中选择新建项目
4. 根据工作流需求选择适当的项目模板

针对用户项目：

1. 单击你的虚拟形象→ 你的项目
2. 在下拉菜单中选择新建项目 → 新建项目
3. 选择符合项目目标的模板

项目模板选择指南：

Template	用例	主要功能
团队积压工作	冲刺规划，功能开发	故事点、冲刺周期
功能	产品路线图，发布规划	里程碑、依赖项
Bug 分类与优先级评定	问题管理，质量保证	严重性、优先级、状态跟踪
Blank	自定义工作流，专用流程	完全自定义灵活性

项目文档和通信策略

自述文件和说明最佳做法：

1. 进入您的项目
2. 单击右上角的设置菜单（三个点）
3. 选择 “设置”
4. 创建全面的项目文档：

项目说明框架：

• 目的：明确项目目标和范围声明
• 利益干系人：关键团队成员、赞助商和决策者
• 成功条件：可衡量的结果和验收标准
• 时间线：关键里程碑和交付预期

自述文件内容结构：

# Project Name

## Overview

Brief description of project goals and context

## Getting Started

Prerequisites and setup instructions

## Workflow Guidelines

- Issue creation and labeling standards
- Review and approval processes
- Communication protocols

## Team Information

Contact details and responsibilities

示例企业自述模板：

# Customer Portal Enhancement Project

## Project Overview

Modernize customer self-service portal to improve user experience and reduce support ticket volume by 30%.

## Key Stakeholders

- **Product Owner**: Name (email@company.com)
- **Tech Lead**: Name (email@company.com)
- **UX Designer**: Name (email@company.com)

## Success Metrics

- Page load time < 2 seconds
- User satisfaction score > 4.2/5
- Support ticket reduction of 30%

## Workflow Standards

- All features require design review before development
- Security review mandatory for user-facing changes
- Performance testing required for all releases

战略工作项规划和管理

问题创建和组织策略

初始项目设置工作流： 当新项目初始化时，它会提示你添加项。 这是建立项目基础的机会。

战略问题创建方法：

1. 从史诗和主题开始：创建代表主要功能或计划的高级工作项
2. 细分为用户情景：从用户角度定义特定的可测试功能
3. 添加技术任务：包括基础结构、测试和部署工作
4. 规划依赖项：确定阻止关系和关键路径项

问题模板最佳做法：

功能问题模板：

## User Story

As a [user type], I want [functionality] so that [business value].

## Acceptance Criteria

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Definition of Done

- [ ] Code review completed
- [ ] Unit tests written and passing
- [ ] Integration tests updated
- [ ] Documentation updated
- [ ] Accessibility review completed

## Dependencies

- Links to related issues or external dependencies

## Technical Notes

Implementation considerations and architectural decisions

单击加号（+）以根据项目计划系统地添加更多问题。

工作项层次结构和组织：

• Epics：主要功能或项目
• 功能：可交付功能
• 用户情景：特定面向用户的功能
• 任务：技术实现工作
• Bug：需要解决的缺陷和问题

高级问题分类示例

企业项目的标记策略：

类别	标签	Purpose
优先级	priority:critical、priority:high、priority:medium、priority:low	资源分配和计划
类型	type:feature、type:bug、type:technical-debt、type:research	工作分类和报告
团队	team:frontend、team:backend、team:qa、team:design	所有权和责任
地位	status:blocked、status:in-review、status:needs-info	工作流状态管理
发布	release:v2.1、milestone:q1-2024	发布计划及跟踪

高级项目配置和管理

安全性和访问管理

单击右上角的菜单（三个点），导航到项目设置。

访问控制最佳做法：

Role	权限	用例
管理员	完全项目控制，设置管理	项目所有者、技术主管
写入	创建/编辑项目，管理工作流	开发团队成员
阅读	查看项目内容，添加注释	利益干系人，QA 团队
无访问权限	无法查看项目	外部用户，受限数据

企业安全注意事项：

• 为所有项目管理员启用双重身份验证
• 定期访问评审和权限审核（每季度推荐）
• 与企业 SSO 和标识管理系统集成
• 用于合规性和安全监控的审计日志记录

自定义字段和工作流配置

战略自定义域设计：

业务价值跟踪：

• 工作量估算：故事点或时间估计
• 业务优先级：客户影响或收入潜力
• 风险评估：技术复杂性或依赖项风险
• 合规性要求：安全性、辅助功能、法规需求

常见的企业自定义字段示例：

字段名称	类型	值/选项	Purpose
业务价值	选择	高、中、低	优先级和 ROI 分析
Effort	编号	1-13 （菲博纳奇序列）	冲刺规划和工作量
组件	选择	前端、后端、数据库、API	技术所有权和专业知识
客户细分	选择	企业、SMB、个人	功能目标和验证
发布目标	日期	特定日期	里程碑和依赖项规划

自动化和工作流优化：

• 根据拉取请求状态设置自动状态转换
• 为关键更新和阻碍因素配置通知
• 建立评审周期和审批工作流
• 为停滞的工作项实施升级过程

持续改进和分析

项目健康监测：

• 跟踪速度趋势和团队容量利用率
• 监视从创建问题到完成的周期时间
• 确定瓶颈和流程改进机会
• 定期回顾和工作流调整

集成检查点：

• 每周项目同步会议，其中包含利益相关者更新
• 每月流程评审与优化会议
• 季度战略一致性和目标评估
• 年度项目治理和安全审核

有关项目的详细信息，请参阅：

• 项目快速入门 - GitHub Docs。
• 创建问题 - GitHub Docs。