Flow VS Agile

还是老话题，过程 VS 敏捷。

公司对项目过程有一定的要求，必须产出要求的Flow Documents。虽然没有强迫一定要上一个Flow的文档产出才能做下一个Flow文档，允许并行处理。但是还是有一定的依赖。

目前碰到的一个问题就是，Flow里要产出Software Develop Plan才可以到进行开发阶段。而公司和用户在工时上面又咬的很紧。真的很为难。其实按照过程控制来说，确实需要计划的比较准确才可以开始开发。但是按照敏捷的观点应该是越早动工越好，而不在于计划又多准确，计划时刻都是在变的。敏捷强调的是产出和价值，尽早做出用户可用的“东西”出来。目前只能抓紧评估以及与用户沟通，促使尽早进入Iteration。

第一次接触公司Product External Special文档。感觉有点像敏捷里的User Story，只不过比User Story更文档化一点，更规范一点。但我觉得都可以理解为是在做用户需求。这里我要做检讨，前期我做PES文档时没有很好的与客户沟通，只是在靠我自己的理解在编写PES，这是非常不好的。后面我会多跟客户沟通，更好的确定用户需求是什么。而且目前我正在尝试用User Story的方式去和用户沟通去理解需求，然后逐步添加到PES中去。

还有一点要注意的，因为项目前期做业务分析也做的不多，所以这里就非常必要把业务目标加进来，再则就是重要的业务流程。通过业务流程去理解用户场景、用户故事，更好的引导用户挖掘用户真正有价值的Story。

这里引入一个概念：软件需求的三个层次

1.业务需求

描述组织或客户的高层次目标，通常问题定义本身就是业务需求。业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。一般使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM后公司的客户满意度达到80％以上”就是一条组织愿景。这些最高级别的需求数量很少（2－5条）。

2.用户需求

用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值 ，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要的。用例、用户故事、特性等都是表达用户需求的有效途径。户需求层次上的重心转移到如何收集用户的需求上，即确定角色和角色的用例，需求分析是很难的，因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变的。

3.功能需求

系统分析员描述 开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。 这些需求记录在软件需求规格说明（Software Requirments Specification）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工 具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。