个人项目的项目管理生命周期

项目概述

项目

在我的 Web 开发生涯中，我曾启动过一些开源项目。在此期间，我在功能、维护和缺陷管理方面取得了不同程度的成功。我一直认为创建一个合适的项目是过度的，这意味着这些项目都没有遵循统一的标准。在我目前的项目v-chart-plugin中，我尝试了敏捷管理方法。当我演示下面的工作流程时，我很好奇其他人取得了什么样的成功。请在下方评论区分享。

项目概述

先简单介绍一下项目的规模：这是一个可定制的 Vue 组件插件，用于添加与 Vue 响应式数据绑定的图表和图形。我们计划开发大约十几个图表，支持多变量、目标跟踪、可自定义的小部件（标签、标题等），并通过 CSS 和 API 进行其他自定义。

我大约一个月前开始这个项目，目前处于 0.1 预 alpha 阶段，0.2 alpha 版本计划于 2018 年 11 月发布。目前我是唯一贡献者，但我一直在积极寻找其他贡献者。长期目标是开发一个稳定的插件，允许贡献者使用 API 集成他们自己的图表。这些图表可能会包含在未来的版本中，从而扩展可用的图表库。

项目

在项目启动之初，我决定遵循一些基本的 Git 最佳实践。这意味着不会直接推送到 Master 分支，所有功能都有各自独立的分支，所有新代码都将通过 GitHub 上的 PR 进行合并。为了组织这些内容，我在 GitHub 上为每个 bug、功能、增强功能等创建了一个问题 (Issue)，并相应地标记了它们。我还为这些类型的任务创建了一些待办事项/技术债务项目（例如常规优化、错误处理、文档）。这些也都进行了相应的标记。

每当我开始开发一个新功能时，我都会在 Git 中创建一个名为 issue-{x}-{short-description} 的分支。这样，我最终会得到一系列如下所示的分支：

然后，我可以单独处理每个分支，偶尔在其他功能完成后将更改从主分支合并回来。当该功能完成后，可以将它们推送回原分支，并通过 Github 上的 PR 合并到主分支。

为了管理项目，我将其分解为 Sprint 里程碑，每个较大的项目包含三个为期两周的冲刺。

最后，我将问题分配给每个冲刺。

这让我能够为每个功能设定截止日期，并让我专注于交付功能和解决问题。到目前为止，它运行良好，让我能够专注于单个功能或错误，而不会被所有未完成的项目压得喘不过气来。它也让我能够相当定期地发布变更。我担心的是，随着项目规模越来越大，可能会有更多人参与其中，这是否会扩大规模？它是否会因为围绕变更增加的流程而阻碍人们做出贡献？或者这种工作流程是否值得欢迎？