保险IT微服务架构培训讲义.pptVIP

残酷现实 客户是逐步发现他真正要的东西 开发人员逐步发现如何开发产品满足客户需求 在这个过程中随时可能发生变化 美好愿望 客户知道自己要的是什么 开发人员知道如何开发来满足客户需求 在开发过程中需求不会发生变化 期望客户一开始就想清楚他们真正要的东西是不现实的。 我们应当通过不断的向客户交付可用的产品，启发客户逐步的发现真正的需求。 我们认识到 预期需求 实际需求 价值 时间 适应变化，认清“客户是逐步发现真正需求” 适应变化，小批量是快速交付的关键 我们首先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 ——摘自敏捷软件的十二个原则 在需求响应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率更高。 在资源利用率相同的情况下，批量越小，交付周期更短。 减小批量不仅带来缩短交付周期，而且还带来提高质量、促进创新、降低管理成本、更高的效率等其他好处，大幅提升商业价值。 减少批量的好处 资源利用率 交付周期 大批量 中批量 小批量 Source：Craig Larman 减小批量 1.减少排队 3.缩短交付周期 2.加快反馈 4.增强质量 5.改善创新 6.降低管理成本 7.更高的效率 $$ 排队理论：小批量与缩短交付周期、人员有效产出的关系 适应变化，利用多层次反馈不断调整以逼近目标 结对编程 单元测试 持续集成 站立会议/回顾会议 客户验收 对代码质量的反馈 对单元功能的反馈 对团队运作的反馈 对系统功能的反馈 对客户需求的反馈 利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整自身行为，并逐步逼近靶心 多层次反馈手段 信息时代，我们需要快速的响应和交付，未来业务的敏捷依赖于IT的敏捷 DevOps（Development和Operations的组合词） 是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或实践。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地敏捷、频繁和可靠。 * * * * * * 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 * * 迭代交付 将一R版本分为多次迭代。 通常情况下，一次迭代的持续时间为2至4周。 对每张故事卡都作估算。 按照客户需求对故事进行排列，并按迭代对故事进行计划。 和团队所有成员召开会议，讨论故事，进行估算，达成一致。 * * * * * 高度重视反馈 尽管管理者一直强调质量的重要性，但在实践中发现我司的开发人员大多数以进度优先，究其原因其实很简单，进度是马上看得到的东西，如果进度延迟，主管给员工的压力马上体现出来，在传统瀑布模型下，质量的反馈需要等待很长的周期，质量不能马上形成压力。 迭代开发的一个明显优势就是快速将真实的质量反馈回来，有助于形成质量优先的氛围和树立没有质量的进度，是虚假的进度的导向，从而保证质量管理建立在真实，可工作的产品的基础上。 快速反馈的另一个明显的优势就是非常有利人员的技能增长，人如果总是在最终失败的体验中是不能成长的，最好成长的过程是经过失败后马上能改进，获得快速成功，（以往的CMM项目即使在项目末进行总结，经验不能马上被利用，这就是迭代促人进步的优势所在），在迭代开发中，一轮迭代发现自己做的不足，没有关系，下一次迭代立刻就有改进的机会，只要你认真对待每一次反馈，充分把每一次反馈当做改进的机会，团队就能在不断开发的过程中成长。 反馈在迭代开发实践中无处不在，可利用的反馈机制： 1. 持续集成结果； 2. 特性片测试结果； 3. 阶段回顾会议； 4. system acut 。。。 因此，是否能充分利用这些反馈机制是区分老开发模式和新开发方法的重要标志。 2017保险IT 微服务架构 Elvis Zhang 2016年10月 保监会发展改革部副主任罗胜在“2016中国互联网保险大会”上表示，大数据可能带来保险产品、作业、组织、监管模式的改变。在大数据的支撑下，风险可以更精细划分，保险作业更深更广融地入具体场景，即所谓场景保险。 保险产品可以更加碎片化；保险公司采取更多甚至全部在线的作业流