使用 Issue 的正确姿势

Issue 是啥？它是 TAPD 一样的需求管理系统吗？

不是！

根据用法，Issue 可以起到不同的作用例如：

• 咨询和反馈
• 开源交流
• 需求整理，缺陷追踪
• 备忘

会话式开发 Conversational Development (ConvDev)

来回顾一下软件工程模型的历史：

软件开发模型	年代
瀑布（Waterfall）	1970s
迭代（Scrum）	1985s
敏捷（Agile）	2000s

总的来说，需求、编码、测试、发布的间隔是一步步缩短的。但无论 Scrum 还 Agile 还是 XP，仍然有很多时候不适用，特别是在复杂的大型项目和分布式的团队中。

主要的不足有以下几点：

• 过于专注，难以应对错综复杂的需求来源和需求分布 敏捷团队擅长集中力量完成一件事情，但如果系统中有多项工程，又互相依赖，敏捷的做法就必须将团队进行拆分，各自团队有不同的看板，分别汇总和处理来自四面八方的需求。如果项目的变动很快，这种拆分和拆分后沟通的过程会让管理者十分为难，间接增加了成本，牺牲了灵活性。
• 对基础组件不友好，难以处理零散的需求 在敏捷的过程中，强调结果呈现。这使得一些基础性的工作很容易被遗漏。此外，很多基础组件平时并没有很强烈的改进需求，偶尔有需求的时候，可能不足以唤起一次迭代。这使得这些零散（也可能很重要）的需求容易被忽略。
• 不透明，延续性差 敏捷团队由于倾向于去文档化和当面沟通，项目的思路、遇到的问题、所做的讨论很少被记录。当一个问题被重新打开时，项目成员（很可能是新人）缺少足够的资料了解事情由来。后来者找不到故事的梗概，就只能全靠代码猜测，如果项目代码再比较复杂，项目会非常难以维护。
• 对大型的分布式的团队不友好（特别是不同时区的），沟通成本高 无论是站立会还是日会周会迭代会，Scrum 和 Agile 团队都要求有效率的当面沟通。这一要求在跨团队任务时很难实现。特别有些异地合作的时候，团队成员往往处在不同时区，有不同的作息时间。这会让项目服务按敏捷的要求运作。

---

软件开发模型	年代
瀑布（Waterfall）	1970s
迭代（Scrum）	1985s
敏捷（Agile）	2000s
会话（Conversational）	2018s

• 利用 issue 来发起讨论

• 尽量公开讨论

• 尽量每个 issue 只关于一个问题，同一个问题，尽量归结到一起讨论

• 尽量齐全的引用

• 礼貌的关闭 Issue 不应该不提供原因，就将 issue 关闭 同时还要避免线下解决问题，如果线下解决了，应当将在 issue 里适度的增加描述，例如问题是如何被解决的。

• 善用 label 和 milestone