作者：sky8336
最近在阅读 aspice 开发流程，结合工作实际，很有感触。
如何看待 aspice
aspice 几乎涵盖了软件开发的方方面面，在软件开发过程中，有疑惑的地方都可以去 aspice 里去寻找灵感。
对于初创公司，应该以人为本。结合人的长处，来发挥每个人的主动性和热情，而不必因岗招人。
aspice 中要求输出很多工作产品，也就是文档。把握不好就成了形式主义。
我对待这些的态度，就是注重实际作用。比如系统需求文档。
可以后期补文档，那基本上就属于形式主义，最多有个备忘的作用了。
做任何事情都是有成本的，任何事情只有收益大于成本才值得去做。
aspice 的价值
那么有一个文档，为什么值得我们投入精力呢？
我主要看中一下几点：
切实为下一个阶段的工作提供输入，下一阶段工作以此为输入开展工作，就让工作有章法可循。比如系统需求为软件需求提供输入。
显性明确隐藏在各人脑海中的想法，把内容写下来，为讨论交流，提供一个基线。各利益相关方可以以此讨论，达成共识的会确定下来，以此减少对共识部分的重复讨论，将注意力集中在尚待解决的部分。
文档还起到追溯到作用，这就要求变更时，保证是从源头开始变更。只有清晰的需求，才能尽量减少由于讨论不足带来的盲目变更。变更就是成本。
文档应该方便以后迅速回忆起当时工作的一些信息，起到备份工作成果的作用。
文档一定不是目的，文档的目的一定要是方便内外部沟通、减少重复和浪费、减少歧义、减少因沟通不彻底带来的浪费，并且可以基于不同时间持续推进一件事情。如果文档不能带来收益，那就需要调整记录文档的方式。
没有工具支撑下的探索
工欲善其事，必先利其器。没有工具支撑，很多事情就会沦为最原始的低效模式。结合目前行业在用的 jira 等工具，我有意探索如何更好的贯彻一些理念，并且有一些自身的认识。
很多小公司或者个人，倾向于口头分配任务或沟通的的方式，这是因为简单，也就是最原始的方式，人人生而得之，这种方式没有太多探索的价值，受制于以下方面：
-
重复沟通现象多，意味着重复部分是浪费；
-
口头说完，往往遗忘，重要的事情无法被跟踪和追溯，无法为全局的状况提供查看视角。
-
有分歧，事情的推进变得困难。沟通记录往往是开辟道路的有效手段，达成共识的部分可以在文档中逐渐积累。但是口头沟通，就会存在信息同步和遗忘，理解歧义等带来的成本。
-
口头沟通，无法固化有价值的工作成果，也就无法有效重用以往优秀的成果。
-
口头沟通应该配合有价值的记录，当然，这依然是最原始的方式。
-
口头沟通，也应以终为始，正如写文档，在写之前，就应该有文档最终的样子，应该要给谁看，想表现出什么，怎么样更好的呈现。
aspice 实践
我在实践中，结合 jira 和借鉴互联网敏捷开发的经验。将一级需求作为 epic，二级需求作为 story。这两个层次的需求，从 PRD 中拆分而来，在描述中，指明对应章节。期间与产品经理反复沟通，达到什么目的，做到什么样子。
互联网团队的 feature 作为 epic，function 作为 story，我们在需求拆分时的颗粒度，以及工作的实质（指具体开发该功能还是集成供应商的代码）对需求结构化的颗粒度做了适当的调整，以在达到追溯目的和追溯的成本之间取得平衡。
在二级需求之下，我们开发团队结合软件架构文档，在每个需求之下，创建 RTM subtask，将完成某个需求的工作，拆分成多个便于开发执行的任务。测试团队，在二级需求之下建测试的任务，这个任务对应软件集成测试。二级需求可能分不到不同的开发模块。这里其实和 aspice 软件需求由软件集成测试来测并双向可追溯有些对应关系。
做这些期望达成的目的：
-
从需求拆分到任务拆分，可以由上自下拆分，并结合由下自上发现需求的遗漏。由上自下，提起来，可以从需求提到各个任务，像一颗倒置的树
-
jira 需求可以对应到 prd，产品经理可以追溯，开发人员可以顺着这棵树向上追溯到 prd
-
需求变更，可以顺着树，来传递影响。变更需要在 jira 上发起变更申请，以追溯
-
开发者的任务一目了然，开发的节奏以此来把控，实事求是，以最小成本来做最大成果。
-
开发者的工作透明化，让管理者知道大家做的成果，避免开发者做了许多，管理者一无所知的情况。
-
让开发过程更顺畅，有规可循，减少浪费。
-
更关注做正确的事，「要做对的事」
