敏捷开发总结

注：这篇随笔将会持续更新

前情提要：

　　为期 10 个工做日为一个迭代。第一，次日故事会与任务分解会，其后一天一故事，第五天交付少许故事，第十天完整交付，演示及总结。

相关环节的必要性：

　　大部分环节的设置其目的都但愿解耦，持续，并提升效率，此外：

　　故事会是但愿在持续的开发中减小沟通成本，首先开发者构思软件最终形态，设置分配具备完整性功能且有价值的故事内容，配合样图框架，让在场的每一个开发者了解每一个故事的核心，样图，并使思想造成统一。因为用户的需求不断改变，每次迭代都是进行一次形态的初生，重建与思想统一，最后开发者们权衡取舍。

参与：

　　用户表明，开发者等。

细节：

　　故事会须要提早准备规划，计时，邀请用户表明等。

　　软件首重价值，能够根据测试用例进行开发，因此故事的交付侧重功能，在有效的模块之间，采用 mock 造成联系，安全性校验等能够以负债形式记录留置下个迭代完善。

　　美工与开发者之间能够以“需求，限定与规格”文件形式，分开进行独立做业。

　　如何作到一天一故事：接口的定义要简单，参数少，但功能强大，多端统一。如有新的需求，尽可能原接口不变更，经过增长新的接口，或二次接口进行操做。

　　固然一个新的迭代避免不了新的负债和不断的填坑。

　　在设计软件时，要考虑不一样端的复杂与简单的权衡，以及后期发布版本对使用者的培训成本和难度。

　　演示，总结时遇到用户的异议，能够反驳或提出解决方案。

真实演进：

　　1.以上略有形式主义，因为迭代故事与考核挂钩，致使后来体系渐崩。

　　每一个团队的故事会，演示会，表明们再也不提出异议及促进点，团队自我封闭，缺乏交流，价值“分子”小，任务“分母”大，是考核等因素致使。

　　给领导洗脑是不存在的，推翻制度，暂时也不可能。

　　惟有团队打开封闭，促进交流，任务化为体现价值的大点，值才更有意义。

　　故事须要快速迭代并演示，技术不是问题，快速的演示才能有效的促进故事的演进，及时调整任务。

　　演示前交代背景，将故事的每一个场景列出来，而不是列出任务。

 

　　2.交付演示总结变化：咱们在研发软件时，可能遇到用户反馈不及时或用户量较少的状况。

　　一般咱们会借鉴市场上好的产品功能做为设计参考，然而殊不知产品为什么如此设计。

　　好比开发票：是选择已消费的开，仍是充值未消费的开？二者都有试用场合，当多用途，或多公司报帐时，选择已消费的开具发票。

　　敏捷开发中，每每须要快速的完成故事，并提供给用户使用起来，重点在用户的使用。

　　及早的投入使用，方能及早的获得反馈与新的迭代故事。

　　这样开发者就无需闭门造车，最后鼓捣出一个花样繁多却让用户难以理解，难以使用的产品。