Issue Driven Development
#Issue Driven Development#Agile developmentISSUE
这个是最重要的地方
issue主要包含什么.
尽可能不从host floor上面删除东西, 如果是逻辑改变, 那么要使用!! 中划线语法进行删除, 这样可以让人一目了然.
typo fix 或者 text decoration, 才可以直接修改.
kanban
用了github很久发现其实github issue可以帮助我们解决很多问题，但是也会带来很多问题，比如其中一个就很重要。我们如何确定开发进展, 并不是每一次我们都能很清晰的在大脑进行一次拓扑排序的.
那么这时候我们就需要借助kanban工具, 上面我有提到kanban这种东西我是推荐使用trello, 功能少, 刚刚好.
其实只要多一个工具就等于加大了一次复杂程度, 所以需要从流程上去简化他, 那么这时候就很简单了,
流程是这样: 由 PM 建立kanban, 然后由 repo leader 确定 dev, dev 开发完毕后由 repo leader 来merge pull request, 最后由 QA 将kanban移动到 完成栏.
所以我们的整个业务逻辑按照抽象等级就分成了三层
| level |
|---|
| kanban |
| issue |
| code commits |
details
commit your code
- 小步提交，并且尽可能的在任何commit中refer相关的
issue, 在有所改变的时候尽可能的comment in issue. - 如果
commit超过3次，还没有refer任何issue，那么这时候你就要小心了。很可能你做的已经开始超出控制了. - commit要按逻辑提交, 并在log里面解释容易混淆的逻辑.
Big Changes
当遇到项目级别的大型重构时候, 则需要进行1-2天的调整, 那么这时候就需要 repo leader 提前一周确定好改变方案, 然后选定一天进行 refacotr. 而 =dev=们则需要做好准备进行修修补补了.
benefits
code is document, issue is the structure.
我们都经历过太多只有代码, 没有文档的痛苦. 就好比扔给你你一大堆线团, 然后告诉你这其实是一个毛衣, 你不能搞乱其他花纹的基础上, 再织一个花纹上去.
很幸运的是, 如果你严格采用IDD的话, 那么doc一般对于新手而言并不是什么困难的问题, 一个新程序员从 kanban 开始就有一个大体的开发过程, 然后对应到issue里面, 很容易就可以把握清楚功能点和细节.
overview
程序员比较容易失去大局观, 而产品经理很难控制开发的进度, 那么kanban和issue结合就很容易估计项目的复杂程度, 软件复杂程度估计本来就是一个比较复杂和困难的任务. 这时候就需要 repo leader 去估计项目和issue的粒度了.
keep host floor up-to-date.
可能突然会有一个更好的主意, 突然发现昨天的功夫都白费了. ok! 很好, 这太正常不过了, 我们并不能保证我们每天都按照正确的方向走, PM 不能, BD 不能, 更不要提对着机器的 dev 了.
对, 那么一定要comment 在下面, 然后 repo floor 一定要保持是最新并且最好就是一眼就能看出来想做什么, 做了什么.
overview
从开发的角度来看:
issue 大概可以分成三类：
enhancement
这个种类比较多。 比如不那么显式的feature，或者是一个暴露bug的测试, 或者是refactor。这都算是enhancement流程比较类似，但是不太一样。 如果开发发现一个好的enhancement, 如果比较小, 那么可以直接顺手提交一个commit 并且在log中表明是enhancement. 如果开发发现一个比较大的enhancement, 那么需要打开一个issue, 由=repo leader=去决定排期和开发计划.
bug
比较规范的流程是：
1. 首先用户或者PM发现了一个bug，推送给相关PM
2. PM确认bug后，按照bug issue规范，发起一个 kanban. 然后 repo leader issue with bug tag ， assign 给 repo leader
3. repo leader 确认并comment描述细节, update issue host floor assign to dev.
4. dev 分析具体细节并建立todo或者拆分issue, 描述开发思路和过程. 即时comment, 并即时refer issue.
feature
比较规范的流程是：
1. 首先PM酝酿并在kanban提出需求，跟 repo leader 讨论.
2. 由 repo leader 发起 issue with feature tag 并关联到 kanban 上面.
3. dev 分析具体细节并建立todo或者拆分issue, 描述开发思路和过程. 即时comment, 并即时refer issue.
4. 开发完毕后, dev 发起 pull request.
5. repo leader merge pull request, 然后 assign 给 QA
6. QA 确定没有问题后, 移动kanban到=完成=.