本周可以成为开会周，白天基本上在会中度过，读书计划继续，继续完善敏捷故事的思维导图
周五和sc讨论需求调研文档，增加故事转化环节，争论的一个焦点是是否需要写故事，因为对于调研人员特别是sc，按照故事方式输出，工作还是非常巨大的。大家更喜欢的是以前的方式：结合系统的功能，输出半方案半需求的文档。
从我自身以前去现场调研过几次的经历看，输出这种文档确实是最方便和快捷的，毕竟我们对自己的功能比较了解，从功能角度写需求文档非常顺手，其中有一个项目当时调研回来后的输出是execl，excel中直接描述需要研发的功能点。
但是从故事的角度去看这个问题，会发现故事描述有很大优势：明确使用者，明确要实现的价值，故事和故事之间独立，故事可以直接分层次和优先级。 比如以前的一个预收租费的需求点，完全可以分成十几二十个不同的独立的故事。
本周读书比较要点：拆分故事时要求封闭，避免持续和发散的故事。
