误解1：同态加密还没有准备好用于商业用途 在同态加密第一次被理论化时，它还缺乏实用性。...误解2：任何信息都要被加密 同态加密支持加密处理，允许对加密和未加密数据执行加密搜索/分析。虽然加密操作可以在加密数据上运行，但在许多用例中，这种级别的保护是不必要的。...因此，投资者需要特别保护重要的信息，即查询内容和第三方数据聚合器提供的查询结果，从而确保他们的利益和意图永远不会暴露出来。...误解3：为了使用同态加密进行协作，需要把所有数据汇集到一起 同态加密的重要用例之一是在安全数据共享和协作领域。通过允许第三方安全地私下合作，为公私合作以及整个私营行业提供了前所未有的机会。...误解4：同态加密库=同态加密解决方案 同态加密库和HE-powered解决方案之间有着显著的区别。可以这样想：同态加密解决方案就是房子；同态加密库就是原始木材。
几位云计算专家来衡量一些关于云计算定价和成本的常见神话和误解，所有这些都倾向于重叠或支持总体上的误解，即“迁移到云端”是“降低成本”的同义词，因此这排在列表中的第一位。...误解2：成本和价值是一回事 OneNeck IT Solutions公司首席架构师Scott Morley表示，真正的投资回报率很难计算。...误解3：计算是付出唯一的代价 这是一个很大的问题，当云计算账单到来时，它也会导致人们只关注计算成本：运行机器的每小时成本，例如显然比购买和维护自己的服务器的成本大不相同。...专家建议：检查预测 为什么人们需要关注这些关于云计算的误解?这需要确保它们不会影响企业自己的云计算策略，或导致成本超支，或具有其他缺点。 精心策划是有效应对这些误解和神话的重要组成部分。...这种预测和规划可能并不总是这项工作中最重要的部分，但如果没有实施预测和规划的情况下，人们的神话和误解会更加恶化和发展。而那时企业的云计算成本可能会失控。
今天，我想和大家探讨一下一个在我们工作中经常出现的误解：敏捷是不提倡建模的。我希望通过这篇文章，我们可以一起解开这个误解，并理解敏捷和建模的真正关系。...敏捷与建模的误解 首先，我认为这种误解可能来自于对敏捷宣言中"可工作的软件胜过详尽的文档"的过度解读。有些人可能会认为，因为敏捷强调的是交付可工作的软件，而不是详细的文档，所以它是反对建模的。...然而，这种理解其实是不准确的。 敏捷与建模的真实关系 敏捷并不是反对建模，而是反对过度建模和不必要的文档。敏捷团队充分认识到，建模是理解问题和设计解决方案的重要工具。...然而，敏捷团队也认识到，过度的建模和过度的文档化可能会消耗大量的时间和资源，而这些时间和资源应该被用于开发可工作的软件。 因此，敏捷团队会尽量做到“足够”的建模。...结论 在此，我希望我们能正确理解敏捷和建模的关系。敏捷并不是反对建模，而是主张高效、恰当的建模。建模是一个有价值的工具，但它的价值取决于它如何帮助我们实现目标，即交付可工作的软件。
敏捷开发的实施要素如下：个体和交互：胜过过程和工具。可以工作的软件：胜过面面俱到的文档。客户合作：胜过合同谈判。响应变化：胜过遵循计划。...敏捷开发过程是一个增量的、迭代的过程，责任人、开发人员和用户要能够共同维持其步调稳定延续。实现敏捷的实际改进可以从以下方面入手：提高生产力。...通过更有效的沟通，敏捷方法可以提高生产力，同时高度响应不断变化的客户需求。提高软件质量。在敏捷环境中，开发和质量保证团队相互合作，旨在与客户密切合作，快速开发软件。...敏捷技术可评估和提高软件质量，同时提供更高的客户价值。提高交付可预测性。客户通常关心可预测性。他们要求团队善于制定并保持承诺，在每个周期结束时可靠地提供工作，测试和补救的代码。...有些实践知道其目标，但在整个团队推行可能会对工作方式造成较大影响，或者团队中的某些组织或个人不具备切换到新的实践方式上的条件，就采用并行的方式。敏捷管理研发工具可以协助团队更好地进行敏捷开发和管理。
为了理解敏捷和架构的关系，我们继续讨论第1部分曾经讨论的3个主要的方法：XP、Scrum和RUP。...2,Scrum 我们在第1部分中提到，Scrum是一个敏捷软件项目管理过程，其特征是面向团队和授权、固定周期的评审和调整，以及驱动组织变更以实现提高软件生产率的目标的过程。...此外，Scrum中的３个角色（开发者，产品主管和Scrum主管）都不承担特定的架构职责。相反，Scrum依赖于一条久经考验的敏捷宣言原则“最好的架构、需求和设计来自于自组织的团队”。...显然，当敏捷方法应用于可伸缩系统时，任何这样的误解都会引起系统性能的不一致（实用程序或性能缺陷）和系统间接口的不一致（设计缺陷）。反过来，本来可以避免的一些重构或重做工作就成为必须要做的事情了。...根据我们的经验，当团队采用更多的敏捷开发实践时，许多团队都很少依赖需求和架构约定（和更具扩展性的建模），这些需求和架构约定可能是他们以前方法中的“生命周期”早期阶段获取的。
因此，PMI提倡采用敏捷(Agile)的方法管理充满变动的项目，并从2011年开始正式推出 PMI Agile Certified Practitioner(PMI-ACP)认证，使项目经理能够具备快速应变的能力...区别 PMP更多的是项目管理框架，ACP会是侧重敏捷开发管理。 PMP学的是标准的项目管理知识体系，侧重理论知识。PMP算是项目管理的根基。 ACP主要学习敏捷方法和策略，侧重敏捷开发管理。...我认为，PMP和敏捷就不是一个可比的事情，敏捷更适合与瀑布开发模式对比。 ?...PMP核心理念 计划是项目实施的标尺和核心 管理干系人期望 防止镀金和范围蔓延 因为没有经过变更控制 风险意识 事情一定不会按照计划进行 敏捷的核心理念 客户和团队协作 客户给出反馈 开发过程切分为固定节奏的迭代...交叉的知识 PMP在第六版中，有部分是敏捷的知识，比如敏捷思维，看板方法，迭代，发布，backlog等。
敏捷相关方的参与和愿景规划 对于敏捷来说，相关方是可以包括任何与项目有关的人的。也就是说，不管是客户、用户、高层领导、甲方员工，只要是与我们要进行的项目有关联的人都是相关方。...从这也可以看出，不管是传统项目管理还是敏捷，和相关方的关系都是决定项目成功失败的一个重要方面。我们也需要将相关方的满意度作为一个关键项目目标来进行管理。...主要是这些相关方的重要性和影响程度，以及它们对项目的支持力度。...但是，敏捷章程对于项目的描述可能会更偏概要一些，项目目标是不可缺少的，收益的预期，验收标准和边界条件，问题和风险等等内容。...而更偏敏捷的内容是我们会指定关键的成功要素，制定初始的发布计划（里程碑），更重要的是，在敏捷章程中，我们要强调渐进明细的作用和团队的力量。剩下的内容，其实就和普通的 项目章程 差不多了。
最近和朋友谈起敏捷开发和瀑布开发模式，很多人认为敏捷开发是未来的项目实施的趋势，瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼，联想也在使用敏捷的方式实施一些项目。...但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。我之前参与过敏捷开发的项目，但当时比较“年轻”，认识不是很深刻，于是最近又补习了下和大家一起分享下我对敏捷和瀑布的感悟。 ?...问题发现的阶段越靠后，解决问题所需要付出的成本就更高。这样，就体现出来了敏捷对瀑布在这样的情景下面的优势。 时间和成本，看起来就是敏捷和瀑布在选择时主要考虑的两个方面。...未来能更好的指导未来的选择，下面还列出了更详细的敏捷和开发的优劣势。...，预期和实际完成的内容经常会有很大差异； 敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。
“ 2017年马上就要过去了，今年可谓是全球科技井喷式发展的一年，越来越多的超级科技出现在人们的视野中。宇宙沙盘今天就给大家盘点一下2017年那些刷爆眼球的科技神话。...” AI的强势崛起 人工智能（AI）在2017年是家喻户晓，无论你平时是不是关注这些，都阻止不了它们进入自己的视野中。 谷歌的Alpha系列AI是最先闯入我们的生活，也是最有名气的。...不仅仅是家中的物件，包括汽车和更多的外出所用设备，都会通过物联网连接在一起。 甚至在未来，我们生活中用到的所有东西，都将会统一链接在一起，做数据收集并统一管理使用。...相比人类，自动化的机器和智能程序更加不会出错，工作效率也更高。尤其是那些鼓噪、无趣、重复率高的工作岗位将是被这些代码和钢铁替代的最早一批。...3D打印成为制造业新奇迹 尽管因为枪械和武器的制造，3D打印曾一度被“打入冷宫”，但这依然不妨碍这项技术为全球的制造业带来的便利。
敏捷已成为企业的关键能力。正如谷歌和苹果公司现在所做的那样，客户需要改变的速度，新的法律和法规影响服务和引入流程，以及竞争对手可以轻松破坏您的业务，这会带来巨大的压力。...在更大的规模上组织敏捷 企业不仅仅是小团队的一系列本地开发项目。这些团队工作的难题必须以某种方式结合在一起。希望有一个未来的愿景，一个企业和IT战略，一个组织旨在实现的目标。...这就是企业架构的用武之地。 传统的企业架构具有相当自上而下的特性，您可以在实施之前制定广泛的计划。敏捷运动的重点在于适应变化和对“大型设计前沿”（BDUF）的抵制，恰恰相反。...两种方法都有其优点和缺点。传统的EA可能导致那些不知道如何与时俱进的缓慢而官僚的组织，而且只有一大群Scrum团队没有一些综合的，总体的方法可能会导致由敏捷孤岛组成的不连贯的IT环境。...相反，业务架构是这个等式中越来越重要的一部分：战略映射，基于能力的规划，价值映射，业务流程管理，精益六西格玛和其他与业务相关的学科仍然缺失。真正敏捷的企业需要的不仅仅是敏捷的IT。
最近两年里面发生了很多的事情，整个数据库领域的格局也有了很多的变化。所以在这里做一个回顾和展望。 SAP在努力的推行它的HANA战略，作为整个战略最为重要的一点，一切都以HANA作为核心。...SAP悄悄的开始了它的下一代UI的开发。...新的UI基于HTML5和javascript，算得上是WEB这一代的标准套路，好处是可以让SAP的组件很方便的迁移到网络上来，但是坏处也就意味着近30年内积累起来的各种组件都开始要进入淘汰的倒计时。...然而在我看来，现在在SAP的传统ERP市场上的潜在的敌人还很多，尤其是微软最近大手笔的收购Linkedin主要还是冲着Dynamics去的，这个当然CRM和Salesforce首当其冲，而ERP也未必会免得了后尘...所以SAP如果说因为HANA而搞进了Oracle的老巢，却被微软杀入自己的基本盘，得失之间是一件很难衡量的事情。 对于HANA的未来来说，最大的不确定因素是Vishal Sikka的离职。
敏捷架构通过协作，紧急设计，有意架构和简单设计支持敏捷开发实践。与敏捷开发实践一样，敏捷架构也可以设计可测试性，可部署性和可发布性。快速原型设计，领域建模和分散式创新进一步支持了它。...为了通过持续交付管道支持持续的价值流，敏捷架构： 随着时间的推移不断发展，同时支持当前用户的需要 避免与相位门和BUFD方法相关的开销和延迟 确保'系统始终运行' 突出紧急设计和意向性 采用整个价值流的系统视图...敏捷架构平衡了意图和出现： 故意架构 - 定义一组有目的的，有计划的架构策略和计划，这些策略和计划可增强解决方案设计，性能和可用性，并为团队间设计和实现同步提供指导。...引领精益敏捷转型 由于他们的知识和经验，建筑师经常受到开发社区的尊重和高度重视。因此，建筑师在任何SAFe转型中都发挥着关键作用。...建筑师是精益敏捷的领导者，因此，模型更精简的思维和操作方式，以便开发人员从他们的榜样，指导和鼓励中学习。它们实现了自主权并鼓励掌握增长开发社区的知识库和技能。
敏捷方法的核心思想在敏捷宣言中有阐述，这里引自敏捷宣言网站 agailemanifesto.org 敏捷软件宣言 我们通过身体力行和帮助他人来揭示更好的软件开发方式。...首先，它是参与软件开发的人写得“身体力行且帮助其他人”，另外敏捷方法对于价值和特定的一些技术一样关注。现在有很多敏捷方法：极限编程，Scrum, Crystal Clear和其他一些。...敏捷方法非常强调软件开发作为一个团队的行为，个人的创造性和贡献是成功的主要方面，因此给个人和协作的组织一个好的环境是关键。...比方说，有人关注过团队在楼里怎么分布的情况：如果需要协作的两个组在不同的楼层，他们的效率会低于办公室相邻的情况，在交流减少的情况下，交流存在误解的风险和在产品中的缺陷数量将显着提高。 可工作的软件。...想要关注于人与人之间交互，敏捷方法要求客户和用户都不迟疑地接受问题和讨论，一个核心的手段就是小的发布。把可工作但功能不全的系统展示给用户，给他们使用。
今天你敏捷了没有？“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流，往小了说是改进了开发方法，往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。...这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障。 二、离开敏捷工具，我们怎么敏？...从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲，文档让后续的工作效率更高。...但敏捷真的完全排斥文档吗？ 文档的时效性和灵活性远低于口头沟通，但却有它实在的好处。 1.空间上，文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。...2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。
TDD和传统测试 TDD和文档 测试驱动的数据库开发 通过敏捷模型驱动开发(AMDD)扩展TDD 为什么TDD ? 神话和误解 到底是谁在做这件事? 总结 工具 1. TDD是什么?...通过敏捷模型驱动开发(AMDD)扩展TDD TDD非常擅长于详细的规范和验证，但不擅长考虑更大的问题，比如总体设计、人们将如何使用系统或UI设计(例如)。...虽然有更大的系统，但我个人曾在涉及几百年工作经验的系统中工作过，很明显TDD适用于大型系统。 7. 神话和误解 关于TDD，有几个常见的神话和误解，如果可能的话，我想澄清一下。...表1列出了这些神话并描述了现实。 表1。解决围绕TDD的神话和误解。...它最多包含您的验证性测试工作，但是如图5所示，您还必须关注超出此范围的独立测试工作。有关敏捷测试策略的详细信息，请参阅敏捷测试和质量策略:事实胜于雄辩。
相对于 MVC 的历史来说，MVVM 是一个相当新的架构，MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出，并且应用在微软的软件开发中...MVVM 的作用和问题 MVVM 在实际使用中，确实能够使得 Model 层和 View 层解耦，但是如果你需要实现 MVVM 中的双向绑定的话，那么通常就需要引入更多复杂的框架来实现了。...第二点：对于过大的项目，数据绑定需要花费更多的内存。 某种意义上来说，我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是，这个缺点同时也被很多人认为是优点。...ReactiveCocoa 函数式编程（Functional Programming）和响应式编程（React Programming）也是当前很火的两个概念，它们的结合可以很方便地实现数据的绑定。...ReactiveCocoa 和 MVVM 不应该被神化，它是一种新颖的编程框架，能够解决旧有编程框架的一些问题，但是也会带来一些新问题，仅此而已。
而在敏捷中，更提倡的是面对面的沟通，而且在项目成员和客户之间，最好也是没有隔阂的就在一个地方办公，而且有什么问题都是直接能够用面对面的说话来交流的。 当然，这真的非常难。...给他们提供所需的环境和支持，并且信任他们能够完成工作 在敏捷中，人是整个项目成功非常重要的一个因素。而在传统的项目管理中，人则是一个工具。...在敏捷中，一个功能无法使用，也就意味着这个功能是没有交付的。这种情况下，进度标准就被清晰的定义为每个功能是否交付，而且只有两个选项，已交付和未交付。...把控每一个环节，消除浪费，对应到敏捷软件开发的实践中，就是测试先行、持续集成以及重构的综合应用。要知道，返工和严重的 BUG ，正是最大的浪费来源。...而在敏捷中，我们也非常重视这个反省的过程。因为我们的迭代速度快，所以有时候一些错误的构架和 BUG 确实是不可避免的，但是要拿出“勇气”，敢于“反省”和“重构”。
现在，MVC 已经成为主流的客户端编程框架，在 iOS 开发中，系统为我们实现好了公共的视图类：UIView，和控制器类：UIViewController。...在 MVC 这种设计模式中，我们发现 View 和 Model 都是符合这种原则的。...在创业做猿题库客户端时，iOS 和 iPad 版的 Model 层代码再次被复用上了。...当然，因为和业务本身的数据意义相关，Model 层的复用大多数是在一个产品内部，不太可能像 View 层那样开源给社区。...在我看来，Controller 里面就只应该存放这些不能复用的代码，这些代码包括： 在初始化时，构造相应的 View 和 Model。
解决敏捷和架构周围的神话 1.迈向敏捷架构 体系结构提供了构建系统的基础，体系结构模型定义了体系结构所基于的愿景。...虽然您不希望根据未来/神话要求过度构建系统，但考虑未来并没有任何问题。这是一个两阶段战略： 初始建模。做一些初步的架构，设想思考问题，探索关键概念，从而让你朝着正确的方向前进。...敏捷架构师有勇气专注于解决当今的问题并相信他们明天可以解决明天的问题（Beck，2000），以及认识到他们无法准确预测未来并因此选择不过度构建他们的架构的谦虚。 表1.比较常见和敏捷架构实践。...，将进行架构评审以验证您的模型 通过具体实验证明了架构 16.解决敏捷和架构周围的神话 我想通过解决一些与世界各地的组织合作时仍然遇到的常见神话来结束这篇文章。...敏捷者不做架构。我的希望是，这篇文章将把这个神话牢牢地放在一边。 您需要进行详细的前期架构建模。
今天你敏捷了没有？“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流，往小了说是改进了开发方法，往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。...这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障。 二、离开敏捷工具，我们怎么敏？ 一个误区：我们用了敏捷管理工具，就敏捷了 随着敏捷在行业内的不断融入，各种工具产品层出不穷。...从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲，文档让后续的工作效率更高。...但敏捷真的完全排斥文档吗？ 文档的时效性和灵活性远低于口头沟通，但却有它实在的好处。 空间上，文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。...敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。 我们敏捷了，不是不要文档了。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
