注：这篇随笔将会持续更新
前情提要：
为期 10 个工作日为一个迭代。第一，第二天故事会与任务分解会，其后一天一故事，第五天交付少量故事，第十天完整交付，演示及总结。
相关环节的必要性：
大部分环节的设置其目的都希望解耦，持续，并提高效率，此外：
故事会是希望在持续的开发中减少沟通成本，首先开发者构思软件最终形态，设置分配具有完整性功能且有价值的故事内容，配合样图框架，让在场的每个开发者了解每个故事的核心，样图，并使思想形成统一。由于用户的需求不断改变，每次迭代都是进行一次形态的初生，重建与思想统一，最后开发者们权衡取舍。
参与：
用户代表，开发者等。
细节：
故事会需要提前准备规划，计时，邀请用户代表等。
软件首重价值，可以根据测试用例进行开发，所以故事的交付侧重功能，在有效的模块之间，采用 mock 形成联系，安全性校验等可以以负债形式记录留置下个迭代完善。
美工与开发者之间可以以“需求，限定与规格”文件形式，分开进行独立作业。
如何做到一天一故事：接口的定义要简单，参数少，但功能强大，多端统一。若有新的需求，尽量原接口不变动，通过增加新的接口，或二次接口进行操作。
当然一个新的迭代避免不了新的负债和不断的填坑。
在设计软件时，要考虑不同端的复杂与简单的权衡，以及后期发布版本对使用者的培训成本和难度。
演示，总结时遇到用户的异议，可以反驳或提出解决方案。
真实演进：
1.以上略有形式主义，由于迭代故事与考核挂钩，导致后来体系渐崩。
每个团队的故事会，演示会，代表们不再提出异议及促进点，团队自我封闭，缺少交流，价值“分子”小，任务“分母”大，是考核等因素导致。
给领导洗脑是不存在的，推翻制度，暂时也不可能。
唯有团队打开封闭，促进交流，任务化为体现价值的大点，值才更有意义。
故事需要快速迭代并演示，技术不是问题，快速的演示才能有效的促进故事的演进，及时调整任务。
演示前交代背景，将故事的每个场景列出来，而不是列出任务。
2.交付演示总结变化：我们在研发软件时，可能遇到用户反馈不及时或用户量较少的情况。
通常我们会借鉴市场上好的产品功能作为设计参考，然而却不知产品为何如此设计。
比如开发票：是选择已消费的开，还是充值未消费的开？两者都有试用场合，当多用途，或多公司报账时，选择已消费的开具发票。
敏捷开发中，往往需要快速的完成故事，并提供给用户使用起来，重点在用户的使用。
及早的投入使用，方能及早的得到反馈与新的迭代故事。
这样开发者就无需闭门造车，最后鼓捣出一个花样繁多却让用户难以理解，难以使用的产品。