现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习Scrum和XP...
为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的朋友一起分享交流一下，希望对初学者有帮助。
敏捷开发(Agile
Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
Burn down
chart翻译为燃尽图或燃烧图，很形象，是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint
review、sprint
retrospective真是越琢磨越有味道的好东西，也因此很喜欢scrum这种方法，这些实践简单有效、经典！
燃尽图的样例如下：
在多线程并发编程中Synchronized一直是元老级角色，很多人都会称呼它为重量级锁，但是随着Java
SE1.6对Synchronized进行了各种优化之后，有些情况下它并不那么重了，SE1.6中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。
最近了解下基于 Token 的身份验证，跟大伙分享下。很多大型网站也都在用，比如 Facebook，Twitter，Google+，Github 等等，比起传统的身份验证方法，Token 扩展性更强，也更安全点，非常适合用在 Web 应用或者移动应用上。Token 的中文有人翻译成 “令牌”，我觉得挺好，意思就是，你拿着这个令牌，才能过一些关卡。
HTTP
是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。
解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的
ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie
里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie
，这样服务端会验证一个这个 Cookie
里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session
，这些 Session
可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的
Session 。
CAS（Central Authentication Service） 是
Yale大学发起的一个企业级的、开源的项目，旨在为 Web
应用系统提供一种可靠的单点登录解决方法（属于Web SSO）。
CAS开始于2001年， 并在 2004年 12月正式成为JA-SIG的一个项目。
1、 开源的、多协议的SSO解决方案；Protocols：Custom
Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0等。
2、 支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509
Certificates等；
3、 安全策略：使用票据（Ticket）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（Service
Ticket）；
5、
提供高可用性：通过把认证过的状态数据存储在TicketRegistry组件中，这些组件有很多支持分布式环境的实现，如：BerkleyDB、Default
、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS
TreeCache、JpaTicketRegistry、MemcacheTicketRegistry等；
6、 支持多种客户端： Java、 .Net、 PHP、 Perl、 Apache,
uPortal等。
1、三层是三层，MVC是MVC，它们毫无关系的。
1） 三层结构
三层是从整个应用程序架构的角度来分的三层（如果程序需要，还可以分多层）。三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题，为了使程序员更加专注的处理某阶段的业务逻辑。比如将数据库操作代码封装到一层中，提供一些方法根据参数直接返回用户需要的相应数据，这样在处理具体的业务逻辑的时候，就不用关心数据的存储问题了。
2）MVC
MVC是在应用程序（BS结构）的视图层划分出来的不同功能的几个模块。
MVC主要是为了解决应用程序用户界面的样式替换问题，把展示数据的 HTML
页面尽可能的和业务代码分离。MVC把纯净的界面展示逻辑（用户界面）独立到一些文件中（Views），把一些和用户交互的程序逻辑（Controller）单独放在一些文件中，在
Views 和 Controller
中传递数据使用一些专门封装数据的实体对象，这些对象，统称为Models。
3）小结
所以说MVC和三层毫无关系，是因为它们二者使用范围不同：三层可以应用于任何语言、任何技术的应用程序；而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突，可以同时存在，也可根据情况使用其中一种。
MVC模式的意思是，软件可以分成三个部分。
视图（View）：用户界面。
控制器（Controller）：业务逻辑
模型（Model）：数据保存
QPS（Query per second）
每秒查询量
TPS（Transaction per
second）每秒事务量
这是Mysql的两个重要性能指标，需要经常查看，和Mysql基准测试的结果对比，如果值过高，就要尽快处理了
QPS = Queries / Seconds
Queries 是系统状态值--总查询次数，可以通过 show status 查询得出
Seconds 是监控的时间区间，单位为秒
例如采样10秒内的查询次数，那么先查询一次Queries值（Q1），等待10秒，再查询一次Queries值（Q2）
QPS = (Q2 - Q1) / 10
mysql中没有直接的事务计数器，需要通过事务提交数和事务回滚数来计算
TPS = (Com_commit + Com_rollback) / Seconds
Com_commit、Com_rollback 的值通过 show status 查询得出
计算思路与 QPS 相似
在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。但是，所有的行为，所有的操作，最终施与的对象都是那些实体。这句话怎么理解呢？比如，我们执行填写操作，施与的对象必然是那些表单，最终产生的结果必然是形成一份完整的表单，表单就是那个行为施与的对象。再比如，我们执行查询操作，施与的对象必然是一个报表，最终产生的结果必然是查看到了这个报表的结果。这里的表单、报表，都是存在于系统的静态实体，它们中的大多数也最终以数据结构的形式持久化保存于系统的数据库中。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。
领域建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题：怎么才能保证建模的正确性？
这听起来是个合理的质疑，但实际上却不是那么有道理。首先我们需要明白建模的目的是什么？如果仅仅是为了描画问题，那么并没有什么对错之分——仅仅是立场和角度的差别；而如果是为了企业业务系统而进行建模，那么这个问题应该变为：如何保证模型能够支撑企业的运营？
我想用下面这个例子来简要的回答一下这个问题。
在开始分析和建模之前，我们需要知道企业业务系统的目的是什么；而企业业务系统的目的往往跟决策者或者管理的诉求相关。我们现在需要移情到一位管理者身上，看看他的诉求到底是什么。