在数字化转型热潮下，各家企业都想建设中台，那么中台是怎么发展起来的?本文为你一一解答这些问题。2019 年春夏之交，领导送了我一本钟华老师的《企业 IT 架构转型之道：阿里巴巴中台战略思想》。不过我决定不按套路来写本文，先给出学习总结中最最精华的部分，给那

所谓敏捷，就是软件的开发维护要具有较高的灵活性，目前市场上的相关快速开发平台均是以敏捷性作为指导思想，进行软件基础框架的搭建。信息技术的发展，为中小企业同大企业在同一起跑线上竞争创造了有利条件。同时，相关应用配置完成可立即部署，大大缩短了开发的调试期，降低

做软件开发的同鞋可能都或多或少的听说过敏捷开发，但是实际采用这种开发模式的项目场景可能就比较少了，今天针对敏捷开发能实际解决的问题做一个基本的介绍，让有兴趣的小伙伴能对敏捷开发的内涵有个基本的认识。硬体世界的突破与发展速度逐渐趋缓，软体世界的需求扶摇直上，

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。流程管理员主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强

严格地把软件项目开发分割成多个阶段：需求分析、要件定义、基本设计、详细设计、编码、单体测试、结合测试、系统测试等。瀑布式把所有开发人员定义为流水线上的工人，所有人都只能接触自己工作范围内的东西，所以对客户需求理解高低不一，这种情况下编码人员比设计人员对需求

工作流管理联盟提出了一个工作流参考模型，约定了工作流系统的体系结构、应用接口及特性，主要目的是为了实现工作流技术的标准化和开放性。下面简要介绍系统中的各个部分，并对参考模型中的五类接口进行描述。它们是针对应用程序的，工作流管理系统无法对它们进行访问。过程定

严格地把软件项目开发分割成多个阶段：需求分析、要件定义、基本设计、详细设计、编码、单体测试、结合测试、系统测试等。瀑布式把所有开发人员定义为流水线上的工人，所有人都只能接触自己工作范围内的东西，所以对客户需求理解高低不一，这种情况下编码人员比设计人员对需求

作为软件开发人员不可避免的涉足软件过程管理，无论是管理者还是实施者都是过程参与者。当我们要向外行解释软件开发是怎么回事，通常来通过一个比方比如说建房子，这就是“隐喻”，当我们工作中遇到问题的时候，怎么深刻地正确地来理解和认识我们软件工作的本身，你潜意识里认

知识多了自然可以解决问题，经历多了自然也可以积累经验，但是在一个只出现10年的领域，还有一堆只工作了10多年的年轻人中间，必然有一天会遇到从来没有人解决过的问题，这时候怎么办呢？掌握了心法就能解决所有问题，这比知道一千零一个问题的答案更加重要，因此会先用三

如果不给他们点温柔的刺激，我们的大多数团队都会跳过回顾，直接进行下一个 sprint。包括重要事件和决策等。

前两篇文章介绍的是 搜集故事和编写估算，本篇文章接着前面的文章往下说，有了story（故事）之后如果对故事进行估算。故事点估算可以很好的满足上面的特点的估算方法。完美工作日就是理想工作日，一天8个小时内一直在编码没有任何其他的情况。当然现实情况可能不太相同

三次迭代是敏捷项目开发管理周期中的一个阶段，到达这个阶段时，项目已经成功的在某些问题上调整过2次。起初，一次小规模的需求收集、开发、测试和用户反馈，形成一次完整的迭代，之后，基于第一次中获得的信息，第二次迭代启动。这阶段通常会在一个较短的时间段内完成，例如

就是下一次迭代的需求）。每次迭代开发过程中，SE的主要任务之一是为下一次迭代开发准备好Story。会随时更新，以反映客户需求的变化，但是，当前迭代正在开发的Story一般不允许变更。捷重要实践之一是：当开发团队确认承诺任务后，SE在此迭代期间不可以添加新的

在开始实施Scrum之前，除了需要对所有涉及到的人进行培训之外，另外一项重要工作就是选择一个适合自己的Scrum工具。很多关于敏捷的论文或教科书都提到了白板和Excel电子表格。但白板与Excel电子表格明显不能满足一个注重过程资产的软件项目的要求。白板虽

敏捷开发过程有很多：XP, SCURM, CRYSTAL, ASD, FDD……近两年以来，越来越发现，这些过程没有好与不好，之后是否适合。第一个层面是是否适合中国的大环境；实施的结果往往是我们某种程度的敏捷了，但是并不是XP。CRYSTAL的要求非常松散

敏捷开发的确要求我们只针对眼前的功能进行设计和开发，但是这并不是不要我们统筹全局。只考虑眼前，而不关注未来，会造成设计不足，导致后期变化难以适应。太看重未来，看得太远，会产生设计过度，用现在的成本来换取未来未知的变化，也是得不偿失的。合理的设计就是要满足现

1是否提供了完整的Story？2是否提供了单元测试报告？3单元测试覆盖率是否达到90％?是否对单元测试未覆盖的地方组织了讨论分析并找到了原因?是否采取了相应的改进措施？4是否完成了源代码的PCLint/FindBugs？7是否对新增和修改的源代码100％组

第一部分我们介绍了持续集成的概念以及价值，这个部分我们来介绍持续集成的工具。持续集成的工具现如今也是百花齐放，各有千秋，接下来我们主要介绍一下目前主流的持续集成工具。我们将从以下几个方面来进行介绍;增量构建，人工强制构建，

敏捷开发有各种形式，其中的一种叫做Scrum。本文将详细阐述Scrum的开发方式。在此不讨论其他敏捷开发形式，一方面因为我对Scrum更熟悉些，另一方面我认为Scrum是比较实用，相对来说更有项目价值的一种开发方法。下面就我个人在项目中的经验谈一下这种开发

由于使用scrum开发，每天的开发进度都记录在xplanner上面。我好久都没有写周报了，没有周报，也算是省了一点事情。不需要每个周末再回忆自己一周都做了些什么事情。假如公司的文档能够使用类似sns的方式，自动刷新项目中其他人更新的文档。估计就方便很多了。