每天积累一点，一年后你会发现，自己变化很大

RSA     这种算法1978年就出现了，它是第一个既能用于数据加密也能用于数字签名的算法。它易于理解和操作，也很流行。算法的名字以发明者的名字命名：Ron Rivest, AdiShamir 和Leonard Adleman。     这种加密算法的特点主要是密钥的变化，上文我们看到DES只有一个密钥。相当于只有一把钥匙，如果这把钥匙丢了，数据也就不安全了。RSA同时有两把钥匙，公钥与

1.组织关注焦点CMMI – 关注组织级过程能力，所有的项目和团队的产品或服务的开发都将从组织过程能力提高后受益。Agile – 焦点是项目和团队，即使组织不成熟，项目和团队仍然可以成功。    2.管理CMMI – 系统化的管理思想和模型应用，特别是集成了各种计划的项目管理，包括风险管理。Agile – 管理更多起的是教练作用以消除壁垒，敏捷的这种方法也可以延伸到大项

CMMI与敏捷最值得记住的几点讨论：1，CMMI与敏捷区别是管理成本占研发成本不同。管理成本高低无好坏之分，取决于企业业务能力与人员能力。2，CMMI 3级不是生命周期，而是建立学习组织，流程固化，降低学习成本。3，CMMI v1.3版本OPM（组织业绩管理）是应用实施解决方案对平衡计分卡的集成，过程改进是战略目标执行。例如：交付物缺陷下降5%，对组织有何作用才是关键4，敏捷四个价

敏捷开发, 谁不会呀, 不就是没文档, 出活快, 用户说啥都能改?下面是一个笑话,  王屋村的大牛说 -我最近转手接了一个活, 完事能挣四五万, 我拿过图纸一看, 不就是盖一烟囱吗? 我们是敏捷 (Agile) 的团队，要文档作甚? 马上开始干活！  都快盖好了， 客户来检查，把我打了一顿！我冤枉啊！

我曾是CMMI咨询师，离开“CMMI 咨询”这个圈子也有一、两年了，久不参加行业内的活动，很想了解行业动态。因此，上个月积极参加了软件行业协会的过程改进年会，见到过去的老同事，老朋友、老同行，非常高兴。其中，观看了一场辩论赛，收获不少，也由此引发了思考和困惑。  “敏捷开发”PK“CMMI”，从辩论赛的角度，还是很热闹的，唇枪舌战了一番。 “CMMI”一方因为大都是咨询师，口齿伶俐些，引经

SCRUM方法如下：SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程(Empirical Process)，而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程，因而可重复（Repeatable）执行并能产生预期的结果，并能通过科学理论对其最优化。经验性过程与之相反，应作为一个黑箱（Black box）来处理，通过对

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：◆ 个体与交互 重于 过程和工具（个体与交互：团队各个成员的能力与团队间的沟通）◆ 可用的软件 重于 完备的文档（以结果为导向）◆ 客户协作   重于 合同谈判（注重客户参与）◆ 响应变化   重于 遵循计划（敏捷要求有开放的工作环境，确保团队及时高效地进行沟通）

一位同志的心得： CMMI是重量型的开发方法，内容繁多，覆盖软件开发的方方面面。培训并不能让我对CMMI整体有一个很清晰的认识，但对CMMI强调的一些思想和方法，我觉得还是有收获。这里谈几点：1. CMMI强调过程标准化及最佳实践，认为最佳实践就是经验教训的积累，而我们经常想当然不加实践的认为某个最佳实践不适合我们，就随意修改，显示是违背了CMMI思想的。2. 杨老

摘要       笔者以自身实践的场景为例，对团队软件开发的各个模式（初级，CMMI，敏捷）进行了分析和对比。并对如何提高团队软件开发的效率提出了自己理解。目录团队初级开发阶段团队CMMI开发阶段团队CMMI+敏捷开发阶段敏捷开发FAQ 团队初级开发阶段场景1研究生导师王教授接到一个企业信息化的项目，是对一家中小型企业

敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。　　敏捷软件开发关注保持简洁的代码，经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程，例如瀑布式方法。　　敏捷宣言强调的敏捷软件开发的四个核心价值是：　　·个人和互动高于流程和工具　　·工作软件高于理解文档

去年股票和房市都比较低迷，今年房市和股市又热起来，而且房市不像股票是震荡的，它只涨不跌。我不怎么懂购房更不懂投资，所以在这里我并不是谈如何投资，而是从买房的视角来说说房屋与软件的关系，从买房的过程来解释一下需要从哪些大的方面来理解一个软件系统。　　在进行架构设计、以及创新的过程中，我们都很有可能去理解别人的软件系统。能否找到需要理解的软件系统以及能否很好的理解一个软件系统都是一个好的开发人

CMMI回顾 在80年代早期，在SEI的资助下美国空军成立了一项研究来分析为什么许多软件合同都会超出工期和预算。他们的结论是：糟糕的过程。由此，产生了CMM&CMMI。能力成熟度模型CMMI是一个过程改进方法和模型，它为组织提供了实现高效的软件交付过程所必需的基本元素，关注通过切实改进过程域的成熟度，实现过程改进的目标。它可以用来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们

什么时候算时机成熟呢？我们的经验是需要两点：一、团队有三名或以上的研发工程师；二、团队内有一名合适的Scrum Master。AD：WOT2015 互联网运维与开发者大会 热销抢票网易有道笔记负责人谈敏捷开发的实战经验：什么时候适合使用“敏捷开发”呢？我们的经验是需要两点：一、团队有三名或以上的研发工程师；二、团队内有一名合适的Scrum Master。

2001年2月，在软件开发各领域有所建树的17位大师联合发表了《敏捷软件开发宣言》，提出了敏捷开发这一概念，至此敏捷软件开发风靡世界，为无数软件开发项目所采用。而在所有这些运用敏捷开发获得成功的软件项目中，运用持续集成工具无疑成为一项最重要的最佳实践，因为它集中体现了敏捷开发的各项思想。 持续集成工具的意义 首先，它促进了项目团队的沟通与反馈。想想看，持续集成工具使每个人每天的劳动

参考：http://www.dubbo.io/Download-zh.htm

第二章：理性模型多数设计师会把所有的项线性相加，但线性方式不适合于衡量效用，因为边际效益会递减。（例如足够的电源插座是必要的，但过多的插座并不会提升总功能。但我们进行设计的时候，往往只是把数量简单相加）在每个决策点设计师都可以有多种选择，因此设计的过程可以看作在“设计树”中寻找可行且较好的路径。（因此可以在某种程度上画出决策树来帮助思考） TODO：尝试用思维导图来描述“设计树

Table of Contents1 持续交付和持续部署2 自动化测试2.1 功能测试2.2 部署测试2.3 性能测试3 环境(environment)3.1 自动化测试环境3.2 自动化环境和生产环境的相似度3.3 自动化构建过程的优化3.4 环境的创建和维护4 持续集成4.1 单个产品的构建流水线4.1.1 提交门限的概念4.1.2 构建流水

这是一本很有趣的书！虽然我无法认同作者的很多观点，但是毫无异议的是：他的观点很有启发性。作者的视角和论点覆盖了大部分技术管理者面临的问题，让你从“人”的角度考虑如何进行技术人员的管理。（原书的英文名就是 Managing Humans）这同样是一本很轻松的书，大可以“随便翻翻”的方式阅读。但是由于原书是由博客文章整理而成，所以整体编排和结构还是有些混乱。前边的文章用到很多在后半本书才出现的

最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量。        参考资料：《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》硝烟中的Scrum 和 XP火星人敏捷开发手册Scrum-Checklists维基百科：http://zh.wikipedia.org/wik

抽空学习了下敏捷开发，觉得跟自己的一些想法不谋而合，如果一个团队能实施ｓｃｒｕｍ，那效率一定非常高，非常适合移动开发，Ａｎｄｒｏｉｄ，ＩＯＳ，ＷＭ等小ｔｅａｍ开发一个ａｐｐ。希望对大家也有帮助，　　前期可能会觉得有点别扭，但是坚持下来，效果会非常不一样。你会发现，效果高很多，而且规范。　　产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成

现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习Scrum和XP... 为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的朋友一起分享交流一下，希

一、所用开发工具1.    Hudson: Hudson 是一种革命性的开放源码 CI 服务器，它从以前的 CI服务器吸取了许多经验 教训。Hudson 最吸引人的特性之一是它很容易配置：很难找到更容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的CI 服务器。Hudson 容易使用的第二个原因是它具有强大的插件框架 ，所以很容易添加特性，例如添加tomcat插件后，可以方将build

一本好书使您改变。它将改变您的思想，您看待问题的角度和方式，最终，它将改改您的行为。然而，所有具有重要意义的改变都不会是在一夜之间发生的，如果您相信这种变革必会发生，不妨朝着这个方向去努力，经常改变，每次改变一点点。                                                                                       

持续集成：构建-部署-测试-报告-----------------------------持续集成能够利用准专业测试人员“编译器先生”，不知疲倦、在项目前期发现缺陷，使得开发人员能够大胆地对系统划分模块、放心实施小迭代、尽早完成高质量的代码。数据证明，持续集成能够有效节省项目10%的工作量----------------------------->>>>>>>>>>>>>>>>>>

总评：《人月神话》作者Brooks写的书《设计原本》，觉得做架构师或者做设计工作的同学们都看看，真的很好，里面将设计提升为方法学、哲学的高度，而不是单纯讲案例、讲准则。当然个人认为有些内容是和设计本身没有太大的关联，可能和作者的工作内容有关而呈现出来的，但绝对值得一读： 印象比较深刻的论断： 。关于完整性：同一个系统的架构实际上不应该有多个架构师同时设计（每

第一部分 在最近的一次Scrum聚会上，Ken Schwaber 和Jeff Sutherland谈到技术和设计的死亡。虽然这两个概念本身不是新的，Ken和Jeff发现的关于它们的许多特征（我认为）属于独创而深刻的见解。此外，他们还概述了一些有用的图表，公司或部门可以用它来显示软件产品的“健康”状况。我本来打算写一篇文章，讨论这些图表指示的含义以及图表所需的数据。不过，我想为此引用说明

1.组织关注焦点CMMI - 关注组织级过程能力，所有的项目和团队的产品或服务的开发都将从组织过程能力提高后受益。Agile - 焦点是项目和团队，即使组织不成熟，项目和团队仍然可以成功。2.管理CMMI - 系统化的管理思想和模型应用，特别是集成了各种计划的项目管理，包括风险管理。Agile - 管理更多起的是教练作用以消除壁垒，敏捷的这种方法也可以延伸到大项目管理中

CMMI等级过程域中文名称过程域英文名称过程类型第2级已管理级7个过程域需求管理Requirements Management工程项目规划Project Planning项目管理项目**Project Monitoring

一、CMM的基本框架 1．CMM的设计思想     任何软件开发和软件企业的发展都离不开软件过程，而软件过程必然要经历一个从不成熟到成熟，从不完善到完善的发展过程。它不是一朝一夕就能成功的，需要持续不断的对软件过程进行改进，才能取得最终的成效。CMM就是根据这一指导思想设计出来的。为此，模型必需满足如下四点对企业的指导作用： 1）为了正确和有序地引导软件过程活动的开展，要建

1. Snapshot版本代表不稳定、尚处于开发中的版本 2. Release版本则代表稳定的版本 3. 什么情况下该用SNAPSHOT?      协同开发时，如果A依赖构件B，由于B会更新，B应该使用SNAPSHOT来标识自己。这种做法的必要性可以反证如下：       a.如果B不用SNAPSHOT，而是每次更新后都使用一个稳定的版本，那版本号就会升得太快，每天一

过程应该包括三方面的内容1.定义任务之间关系的规程和方法2.有技能、受过训练的，以及有积极性的人员3.工具和设备过程是一系列为达到既定目标的思维，态度，条件，实践。包括工具，方法，资源和人。1.广义的过程是一个维系。程序，人员，技术这三方面的总体。2.窄义的过程就是其中的程序3.过程是目标驱动的，是以绩效为目标的。4.流程是任务驱动的，是为规范任务的步骤的。成熟

能力成熟度模型（Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM） 　　什么是能力成熟度模型 (Capability Maturity Model)CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行

很多人认为软件质量是软件是否存在 Bug，是否性能高，安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于某个（或某些）人的价值；价值是指创造利润，又或是降低成本。总的来说，软件质量是软件的灵魂和存在意义。敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论，敏捷开发是追求高质量软件的方法论和过程。本文将和大家一起探讨软件质量的含义，以及敏捷开发中如何进行高质量软件的

在软件开发中，我们经常会遇到类似这样的问题     我们所理解的东西无法和用户想要的达成一致，所以用户提出的要求，经过项目经理、分析师，最后到程序员的就已经被篡改的面目全非，所以，经过程序员们日以继日的努力，终于做出来完全不是用户需要的程序了，于是我们不得不继续夜以继日的修改，终于在放弃了代码的质量、放弃了休息、加班加点的工作后，用户勉勉强强的接受了我们随时都可能奔溃的系统。

最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量。        参考资料：《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》硝烟中的Scrum 和 XP火星人敏捷开发手册Scrum-Checklists维基百科：http://zh.wikipedia.org/wik

敏感的人会发现，在近来的业内报纸杂志上，"CMM"这个普通的字母组合越来越多地被提及，而"M o to rala（中国）通过了CMM五级认证"、"鼎新通过了二级"之类的新闻也竞相被各媒体报道。一时间，CMM烁烁生辉，仿佛笼罩在舞台的聚光灯之下。　　那么，CMM是什么呢？　　在上个世纪六十年代，软件业出现了软件危机。即软件项目经常无法按期完成，软件工程费用超支，软件质量难于控制而且维护费用高

一、敏捷是“一个”过程敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。敏捷的价值观如下：个体和交互 胜过 过程和工具　　可以工作的软件 胜过 面面俱到的文档客户合作 胜过 合同谈判　　响应变化 胜过 遵循计划　　由价值观引出的12条敏捷原则：　　1、我们最优先要做的是通过尽早的、持续的交付有价值

http://blog.youkuaiyun.com/truewaylee/archive/2006/05/20/746232.aspxhttp://blog.youkuaiyun.com/yourlin/archive/2006/10/09/1327570.aspx http://blog.youkuaiyun.com/eaglezhang/archive/2007/07/30/1717171.aspx

华为方会提供一份CRS（客户需求）和SOW（工作任务书），华为方派人过来进行需求培训，这时该项目的测试组长也要参与到项目需求的培训和评审，也就是测试工作应该从需求开始介入。　　项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。　　《测试计划》编写完成后需要进行评审

说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了，这个东西并不是神器，实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。大家都知道，创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。我们公司是这样一个状况，有