对aspice开发流程的一点思考

最近在阅读aspice开发流程，结合工作实际，很有感触。
1.如何看待aspice ？
aspice 几乎涵盖了软件开发的方方面面，在软件开发过程中，有疑惑的地方都可以去aspice里去寻找灵感。
对于初创公司，应该以人为本。结合人的长处，来发挥每个人的主动性和热情，而不必因岗招人。
aspice 中要求输出很多工作产品，也就是文档。把握不好就成了形式主义。
我对待这些的态度，就是注重实际作用。比如系统需求文档。
可以后期补文档，那基本上就属于形式主义，最多有个备忘的作用了。
做任何事情都是有成本的，任何事情只有收益大于成本才值得去做。
那么有一个文档，为什么值得我们投入精力呢？
我主要看中一下几点：

1. 切实为下一个阶段的工作提供输入，下一阶段工作以此为输入开展工作，就让工作有章法可循。比如系统需求为软件需求提供输入。
2. 显性明确隐藏在各人脑海中的想法，把内容写下来，为讨论交流，提供一个基线。各利益相关方可以以此讨论，达成共识的会确定下来，以此减少对共识部分的重复讨论，将注意力集中在尚待解决的部分。
3. 文档还起到追溯到作用，这就要求变更时，保证是从源头开始变更。只有清晰的需求，才能尽量减少由于讨论不足带来的盲目变更。变更就是成本。
4. 文档应该方便以后迅速回忆起当时工作的一些信息，起到备份工作成果的作用。
5. 文档一定不是目的，文档的目的一定要是方便内外部沟通、减少重复和浪费、减少歧义、减少因沟通不彻底带来的浪费，并且可以基于不同时间持续推进一件事情。如果文档不能带来收益，那就需要调整记录文档的方式。

没有工具支撑下的探索
工欲善其事，必先利其器。没有工具支撑，很多事情就会沦为最原始的低效模式。结合目前行业在用的jira等工具，我有意探索如何更好的贯彻一些理念，并且有一些自身的认识。
很多小公司或者个人，倾向于口头分配任务或沟通的的方式，这是因为简单，也就是最原始的方式，人人生而得之，这种方式没有太多探索的价值，受制于以下方面：
1.重复沟通现象多，意味着重复部分是浪费；
2.口头说完，往往遗忘，重要的事情无法被跟踪和追溯，无法为全局的状况提供查看视角。
3.有分歧事，事情的推进变得困难。沟通记录往往是开辟道路的有效手段，达成共识的部分可以在文档中逐渐积累。但是口头沟通，就会存在信息同步和遗忘，理解歧义等带来的成本。
4.口头沟通，无法固化有价值的工作成果，也就无法有效重用以往优秀的成果。
5.口头沟通应该配合有价值的记录，当然，这依然是最原始的方式。
6.口头沟通，也应以终为始，正如写文档，在写之前，就应该有文档最终的样子，应该要给谁看，想表现出什么，怎么样更好的呈现。

我在实践中，结合jira和借鉴互联网敏捷开发的经验。将一级需求作为epic，二级需求作为story。这两个层次的需求，从PRD中拆分而来，在描述中，指明对应章节。期间与产品经理反复沟通，达到什么目的，做到什么样子。
互联网团队的feature 作为epic，function作为story，我们在需求拆分时的颗粒度，以及工作的实质（指具体开发该功能还是集成供应商的代码）对需求结构化的颗粒度做了适当的调整，以在达到追溯目的和追溯的成本之间取得平衡。
在二级需求之下，我们开发团队结合软件架构文档，在每个需求之下，创建RTM subtask，将完成某个需求的工作，拆分成多个便于开发执行的任务。测试团队，在二级需求之下建测试的任务，这个任务对应软件集成测试。二级需求可能分不到不同的开发模块。这里其实和aspice 软件需求由软件集成测试来测并双向可追溯有些对应关系。
做这些期望达成的目的：
1.从需求拆分到任务拆分，可以由上自下拆分，并结合由下自上发现需求的遗漏。由上自下，提起来，可以从需求提到各个任务，像一颗倒置的树
2.jira 需求可以对应到prd，产品经理可以追溯，开发人员可以顺着这棵树向上追溯到prd
3. 需求变更，可以顺着树，来传递影响。变更需要在jira上发起变更申请，以追溯
4. 开发者的任务一目了然，开发的节奏以此来把控，实事求是，以最小成本来做最大成果。
5. 开发者的工作透明化，让管理者知道大家做的成果，避免开发者做了许多，管理者一无所知的情况。
6. 让开发过程更顺畅，有规可循，减少浪费。
7. 更关注做正确的事，“要做对的事”