面向服务的8个原则
服务可复用 不管是否存在即时复用的机会，服务被设计为支持潜在可复用。
服务共享一个正式契约 为了与服务交互，只需要共享描述每个服务信息交换术语定义的正式契约。
服务是松散耦合的 服务被设计为无需紧密的、跨服务的依赖而交互。
服务是底层逻辑的抽象 只有经由服务契约所暴露的部分服务对于外部世界是可见的。契约之外所表达的底层逻辑是不可见的，且与服务请求者无关。
服务是可组合的 服务可能组合其他服务。这允许表示不同粒度的逻辑，并促进复用及抽象层的创建。
服务是自治的 逻辑由服务所控制，并位于一个清晰的边界内。服务已经在这个边界内被控制，并且不依赖于执行其控制的其他服务。
服务是无状态的 服务应当不需要管理状态信息，因此能够其维持松耦合性。服务应当尽可能设计成无状态的，即便这意味着要将状态管理移至别处。
服务是可发现的 服务应当允许其描述被发现，并被人工和可能会利用其逻辑的服务请求者所理解。
这个8个面向服务的原则乍看很像我们熟悉的OOP啊，不过如果你把一个服务抽象成一个对象来看的话也就不难理解了。
下面介绍一下依据这8个原则构建的SOA的各个服务层：
1、连通性服务层
所谓的连通性是指对于原有系统的数据连通，由于原有系统不能提供一个具有通用性的数据服务，所以在连通性服务层的主要任务就是负责把原来已有的JDBC的，EJB的，webService的各种数据服务，封装成具有统一标准的java pojo控件，然后其它的就可以方便，简单的实现对数据服务的调用。
连通性服务层：
服务对象：需要获得数据的对象         如业务层、表示层等
提供服务：可以操作原有系统的数据层   如对一个sap服务器进行操作、对一个DB服务器进行操作邓
调用资源：原有系统的数据服务接口     如EJB、Hibernate，JDBC等
图1：
在这里值得一提的是bea在使用workshop对于连通性服务层创建，非常简单，完全图形化的方式，只需简单的鼠标拖曳，就可以实现服务控件的建立。
2、业务流程服务层
我们知道一般的业务系统都会有一些自由的业务流程的，那么如何让这些原有的业务流程来提供给SOA系统使用呢？
在bea专家给我们演示的demo中，我看到bea的做法是把每一个流程节点封装成了服务，这样，这些流程节点每个都可以成为一个向外提供服务的服务者了。
业务流程服务层：
服务对象：需要流程控制的对象         如其他业务层，表示层等
提供服务：业务流程控制               如从a入口进入后是应该去b节点还是应该去c节点
调用资源：通常是连通性服务层的服务  
图2：
在bea演示的时候对于业务流程服务层的构建依然采用的是图形化的方式，这里值得称道的是在使用图形化的过程中，bea的工具还可以支持对于服务的格式转换
3、服务中介层  
上面已经介绍了两种服务层了，在soa中这两层的调用不是简单的上下层关系。在实际项目中，也许有的需求是需要流程控制的，但是也许有些需求是直接要求展示数据的，那么如何处理这两种的需求呢。这里就是在soa中最重要的一个层了，服务中介层。很多人应该听过soa中service bus这个概念。我之前一直理解为服务总线仅仅是为客户端提供服务的，其实是不对的，实际上服务总线是一个用了穿起来各个服务层的，就好比是一个糖葫芦，服务中介层就是中间的那根棍子。
图3：
做为服务中介层来说，主要有两种服务，一种是应用服务；另外一个是代理服务，用来对应用服务进行代理封装的，是服务总线中向外暴露的服务。
4、表示层服务层
表示层服务主要和不同的客户端有关，bea在这里的讲述中由于时间紧张所以比较简单。重点还是在演示他们可视化得页面编辑。但是这里有点给我洗脑得就是，对于不同的客户端所提供的服务是直接可以使用的，比如判断一个用户名是否合法，表示层服务不是返回的true，false，而是直接返回，“该用户名可用”，“该用户名已被占用”这样的字符串。
关于表示层我就不再画图了，最后是一个整体的soa层次结构图：

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

一、根据发布目标分析需求，把需求分析成独立的故事，初步的分析可以是粗略的，随着需求的不断深入刻意对故事进行整合或者切割。

要注意的是分析出来的需求尽量在发布目标的范围之内，超出发布目标的需求应该尽量避免过深分析。

所谓的发布目标是确定了这个版本可以让用户满意的条件。

故事模式：做为（用户角色），我可以（做什么），以便（业务价值）。后面的业务价值在比较简单或者大家都比较明确的时候刻意不需要注明。

当前团队实践推行方法：

第一阶段,这个分析工作开始由PM进行收集，整理和分析。

第二阶段,当大家都为用户故事的方式接受以后，采用需求讨论的方式来明确和分析用户故事。

二、对分析的故事进行相对估计，估计出来的故事点是对用户故事和复杂度的无单位估计值，使用的数值大小本身没有绝对意义，只有相对于其他故事规模的相对意义。

比如，用户登录这个用户故事的估计值是2，那么做为同等开发规模的用户推出，这个用户故事的估计只也因该是2。

当前团队实践推行方法：

第一阶段，这个估计的工作暂时由ｐｍ来负责完成，但是由于一个人的估计肯定会有偏差，所以在估计完成之后需要进行调查来进行修正

第二阶段，用估计扑克会议来统一的对用户故事进行估计，当主持人拿出一个新的用户故事之后，大家给出自己对这个故事使用扑克打分，然后取出平均值，对差异较大的估计值要给出解释，来消除对用户故事的错误理解。估计扑克会议的实践不超过１个小时。

三、准备产品调查，对用户故事进行功能存在，和功能缺失性的产品调查，然后根据调查结果对用户故事进行划分，划分成３类，基本需求，线性需求，线性需求。

此外还有反对的需求，存在疑问的需求，无所谓的需求３种类型的需求，这些需求将根据进一步的发展进行确认。

当前团队的实践推行办法：

第一阶段，由ｐｍ发出调查问卷在参与到项目的开发团队，测试团队，技术支持团队来进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性

第二阶段，由ｐｍ发出调查问卷扩展到相关的用户群体中进行调查，然后汇总答案根据存在问题和缺失问题的答案，对用户故事进行定性

四、确定发布规划，首先要确定的是迭代周期的长度，以周为单位，然后估计出每个迭代周期团队的速度。然后可以从用户故事池中选择出合适的用户故事来填充到第一次和第二次的迭代周期中。其余的暂时可以先不用填充，随着每次迭代周期的完成来对发布计划进行更新。最后根据估计的速度和需要开发的故事来确定需要几个迭代周期，并最终有几个迭代周期来确定需要开发的时间周期。发布计划可以以功能来驱动进行，也可以以日期来驱动进行。

发布规划的特点，以月做为时间范围，规划对象是用户故事，估计的单位是故事点

当前团队的实践推行办法：

第一阶段，使用1周做为迭代周期，开始时团队速度使用估计的方式做出简单估计，根据每个周期结束后的团队速度再进行发布计划的调成。迭代周期内用户故事的完成暂时以开发完成做为标准。

第二阶段，使用2周做为迭代周期，可以使用原有的历史速度做为团队速度，多出的一周时间做为测试修复时间，迭代周期内用户故事的完成以测试完成，完整的功能提交做为标准，并在开发过程中熟练使用单元测试来进行确保功能的完整完成。

五、确定迭代规划，根据填充到迭代周期内的用户故事来分解成工作任务，工作任务包括设计工作，不同层次的开发工作，调试工作和测试工作等等具体的任务，然后对任务进行估计，这时候估计的单位以理想工作小时做为单位。比如，设计需要两个人小时，开发持久层需要1个人小时，调试持久层需要半个人小时，开发业务层需要2个人小时，调试中间层需要1个小时等等。。。

然后根据每个故事的人小时和这个迭代周期内参与的人数，以及每个人所能参与的实际有效时间（注意有效时间约为每天6小时，需要考虑到会议，讨论，头脑休息等非理想工作时间）来判断这个迭代周期的填充是否足够，如果不够则再加入一个用户故事，如果超出则移出一个用户故事到下一个迭代周期中。

迭代规划的特点，以周做为时间范围，规划对象是工作任务，估计的单位是理想小时

当前团队的实践推行办法：

第一阶段，使用速度驱动的方法来进行迭代规划，即确定了本次迭代的速度，然后选择用户故事扩展成任务，对任务进行估计。

第二阶段，使用承诺驱动的方法来进行迭代规划，即提出一个故事，把故事扩展成任务，对任务进行估计，让小组承诺是否可以完成这个故事，如果可以在迭代周期内完成则加入这个故事，如果不能完成则推迟到下一个迭代走起。

六、迭代开始，在迭代开始时召开迭代启动会，分配迭代周期内的用户故事和工作任务到个人，每个工作任务必须精确到个人，同一个用户故事的不同工作任务可以根据情况适当分配给不同的人来完成。

当前团队的实践推行办法：

第一阶段，任务分配给个人，通常一个故事的任务分配给同一个人。

第二阶段，任务分配给结对，通常一个故事的任务分配给同一个结对。

七、迭代进行，每日早对昨日完成的工作任务和问题进行汇报，并且同时计划今天需要完成的工作任务，对于迭代过程中的进度和问题进行及时的观察和调整，要求每个人完成某个任务之后要及时的告知整个小组知道（qq群的方式最为快捷）。

当前团队的实践推行办法：

第一阶段，由pm及时地对当日工作进行询问。并负责把遇到的问题跑出来进行解决。

第二阶段，小组成员主动地对已经完成的任务进行汇报，并及时把自己遇到的问题抛出来。

八、迭代结束，确认本次迭代完成的用户故事，对于完成一部分的用户故事计算到下一次迭代中。并对本次迭代的过程资产进行总结，形成FAQ方式的文档进行规整。

同时根据新的需求情况，资源情况，已完成功能的回馈，以及开发中遭遇的不确定性问题，对发布规划和迭代规划作出调整。

当前团队的实践推行办法：

第一阶段，使用学习网站，或者博客等方式对经验进行记录。

第二阶段，使用完善的skills对经验进行记录，可以方便的组织成培训文档，并方便的进行搜索，查找。

九、迭代测试，为了保证用户功能完整的提交，每个用户故事开发完成之后都要对该用户故事进行测试，然后在针对开发中出现的问题进行修复，以便完整的完成一个用户故事。

第一阶段：测试迭代周期和开发迭代周期分开。

每次迭代开始阶段由ｐｍ告知开发组需要开发的和修复的的用户故事，同时告知测试组本次迭代需要测试的故事，需要准备的故事，需要复测的故事。

并在分配任务时，把修复故事的工作规划到本次迭代中来。

每次开发完成的用户故事点算作本次迭代的速度

第二阶段：测试迭代周期和开发迭代周期合并。

每次迭代开始阶段由ｐｍ告知开发组需要开发的故事，同时这些故事也是测试组需要准备测试的故事。要求这些故事分解的工作任务中要包括测试工作和修复工作。

每次测试完成的用户故事点算作本次迭代的速度

十、发布结束，对本次发布中完成的用户故事进行会议总结：

１确定最终完成的用户故事，以及花费的迭代周期

２通过计算得到一个团队的人平均速度，这个速度做为下次发布规划的参考

３分析哪些用户故事的估计出现了失误，以及出现失误的原因是什么。

４最初的发布版本在市场上有了初步反馈信息之后，可以延长１个迭代周期用来做为发布版本的反馈收尾。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

问题的来源是帮一个朋友改数据库，要求是这样的，60个题目，总分是100分，正确答案的分值有2分的 1.5分，其中分值的排列关系是随机的，请问如何设置答对题目，使得答题总分刚好为一个数值，如82分
我的解决办法是：
用一个集合记录判断是正确的2分题，当发现期望总分和当前累加总分差值小于1.5时，因为最小单位是1.5，在2分集合中退出一个正确的2分，然后继续遍历下去
虽然后来用上面办法解决了这个问题，但是我觉得这个问题的解法不够通用，有很多问题，对这个问题扩展了一下，大家一起讨论一下
一维的：和上面的题目一样。用变量来描述一下这个问题
有m个元素，其中每个元素有1个value值，o,value的取值有x，y，z...,按照value值m个元素排列是随机的，问如何用一次遍历m，而得到n个元素，这n个元素的value总和是W
二维的：其实就是俄罗斯方块了，大家想象我们玩的俄罗斯方块是不是这个道理
有m个元素，其中每个元素有1个value值对，o,value的取值有x，y，z...，按照value值m个元素排列是随机的，问如何用一次遍历m，而得到n个元素，这n个元素的value中，v1
的总和乘以v2的总和是W
n维的：不知道用什么现实中的情况来描述了
有m个元素，其中每个元素有1个value值对，o,value的取值有x，y，z...，按照value值m个元素排列是随机的，问如何用一次遍历m，而得到n个元素，这n个元素的value中，v1
的总和乘以v2的总和乘以v3的总和...一直乘到vn的总和是W

呵呵，也许是我孤陋寡闻，上面这个题可能早有算法了，希望知道的朋友能告诉我一声：）

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

这篇文章不是用来讲mingle的使用方法的，是来发表使用mingle一个月的使用感受。
由于mingle的操作十分简单，方便，有兴趣的同学可以自己下载一个并可以参考官网的flash。
官网地址：http://studios.thoughtworks.com/mingle-project-intelligence

基本感受：
Anything is card!所有操作都是基于卡片的，也就是说一个项目的基本构成单位就是story card，而基于这些卡片方便的展示、管理、统计都是很方便的。

优点：
1、操作简单，修改属性，拖曳卡片，过滤查找，都是几个简单动作就可以完成的，而且由于大量的使用ajax，用户感受很好
2、项目自定义性强，可以针对卡片添加你想要控制的任何信息，这样由于不同的项目就会有各自不同的主要关注点，你就可以把主要精力集中在相应的关注点。这样就不会所有项目都是千篇一律的属性，而实际上很多属性都是对于当前项目无用的信息（MS的project虽然强大，但是我却很不喜欢用它）。这是很 agile的做法，需要什么才用什么。
3、项目模式的重用，可以把当前项目的模板导出做为一个case来提供给另一个项目参考，或者可以直接重用。这样就实现了部分项目经验的传递与共享。
4、可以把你最期望关注的定制过滤条件使用固定的view展示出来，比如说我当前关注是5.5版本的卡片信息，就可以直接定制成一个tab view让每个访问者都看到
5、grid的展示方式让你了解卡片更加直观，比如我现在想知道当前迭代周期内每个人的卡片状态，就可以使用grid的方式来展现

6、通过简单的mql语句可以订制你需要统计的基本图形。

一些缺点：
1、内存恐怖，之所以用恐怖这个词是因为确实很难想象一个安装文件只有几十m的安装文件运行起来就吃了我400m内存（都是ruby惹的祸），而且还是访问用户只有1-2个的情况下，要不是我刚升级到2G内存，那我绝对不会使用mingle的。
2、讨厌的Description：不是所见即所得编辑器，很不友好，甚至在导出然后导入的时候经常出错。因为mingle一般在公司内部服务器使用，期望能够加入粘贴图片的功能，毕竟用附件的方式很不方便。
3、mql--虽然我也没想出更好的进行统计展现的方法，但是，用一个工具又要学一个语言确实让我觉得有些不舒服。
4、不完善的导入导出，data的导入导出是基于excel的，但是但是为什么要多一个复制-粘贴的动作呢？很多余的说。。。
PS：一个小技巧
如何变相突破5人的限制。这里的方法不是破解，而是出于一种agile的管理想法，我觉得让开发者来每天登陆mingle然后更新属性和状态是一种不给实现功能带来实际价值的做法。而且要把这种工作交给开发者来做的话无疑是加大了开发者的负担。所以我的mingle中只有两个用户，一个是我自己，一个是 guest，我每天来更新所有卡片的工作状态，而guest是给团队成语甚至我的老大来了解当前进度的。然后再给卡片增加一个developer的属性，用来保存每个开发者的名字（这个就没有限制了吧，呵呵，希望TW看到这个技巧不会哭笑不得）。

好了，这就是我这一个多月的mingle实用感受，欢迎大家提出更好的工具，对于工具的选择上我一向是绝对agile的。

下篇预告：mock还是build——关于TDD环境的选择            时间：2007-09-12

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

前些天对需求讨论确定后开始制定计划安排。
根据最近对agile的一些体会我这次制定计划是这样的：

1、根据需求的功能点定义，把需求纵向切割成一个个较为独立的story，然后把这个story归入到计划中。
解释：对于一个story来说，所有的分析、设计、实现都是由一个开发者来完成的。当然在开始实现前对于一般的设计都是要一起讨论的
这时候story可以确立的基本属性有：title（标题）description（描述）

2、我把story收集好之后，根据需求的复杂度和优先级作了一个初步的分析，然后再和资深的developer做一次沟通，大概预估以下每个story需要花费的时间，然后根据老大给我的时间要求把story分成了两个iteration
这时候可以确定的story属性有：Iteration（迭代周期）  Priority（优先级） Release（发布版本） Status（状态） PlanSize（计划时间）

3、当我确定了在当前迭代周期需要完成的story之后，我就会在开发小组内部召开一个小讨论，罗列出这个迭代周期内有哪些功能需要完成，然后由大家自己选择感兴趣的story
在选择story的同时可以经过讨论确立的属性有：developer（开发者）

至此一个迭代发布版本的粗略计划，一个迭代周期的详细计划就已经出来了。

but，当我把这个计划提交给我老大的时候，他们提出了几个问题：
1、一个功能纵向开发，如何知道开发者每天的工作任务，如何知道他现在是在做设计和还是在做开发
2、以前的开发是有一个专门负责实现设计和后台接口实现，一个专门负责调用接口和前台实现，这样由一个人开发后，有些人可能会在模型和接口的实现上因为经验不足而造成失误
3、让一个人独立开发一块功能，是不是破坏了项目组内部的协作机制，是否会让开发者感觉到他是孤独的
4、如何考察一个开发者的工作是否饱和？

对于上面的问题，我经过思考和讨论后给出了这样的回答：
1、每天都会由我发起一个简短的状态了解，了解每个story的进度，是在分析，是在设计，设计还是在实现了我都会对story做一个记录
2、一个人纵向开发也许会经验不足造成接口不够全面，但是由于是他一个人开发，他可以方便的根据自己需求来修改接口。而且两个人在横向开发时会有一些沟通交流问题而造成成本增加。（实际上在完全的agile中是由两个人结队开发，而且通常的组合是一个经验丰富的带一个经验少的）
3、在功能开发时，无论是分析，设计，还是实现发现问题都可以立即举手进行讨论。可以说只要有问题就是团队一起解决的。
4、这其实是只如何对开发者进行工作量考核了，我觉得从敏捷的角度来看考核的问题比较简单，就是你最终实现的完整功能（因为只有完整的功能才能给产品带来价值）所花费的时间和预期时间的差值。比如说一个story预期是6点（两点为一天）完成，结果你用3点就做完了，那么你的考核点就是+3，但是这还没完，当测试后发现这个功能点出现一次bug，你的考核点就要扣除1点，这样最终的考核点就是2点。

经过和老大的讨论之后，他们觉得以功能story来分配的方法和以前已工作任务来分配的方法是有些难以控制的，但是还是同意我开始在项目组试行（这里要赞一下我老大的开明态度）

最后提一下我用于agile项目管理的工具，相信很多人都猜到了，就是mingle

下篇预告：mingle使用小记    时间：2007-9-11

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

周五开需求讨论会，当讨论到其中一个需求功能点的时候我提出了这样一个问题：
这个需求在文档之中只表明了what，而没有说明who和why，所以我希望能够说明另外两个基本要素
在我开来，一般一个需求都包含三个基本要素what who why
what  是指这个需求的内容是什么
who   是指这个需求是由谁提出的
why   是指这个需求提出的目的是什么

当时我的老大在听完我的提问后，略为的思索（估计是认为我的问题是指这个需求是由哪个客户提出来的，为什么而提）了一下回答说："我们做的是产品而不是项目，希望你能够明白产品与项目之间的区别".当时由于在讨论会上，我们没有再这个问题上再过多久就缠下去。

会后老大找到我，并给我解释了一下项目和产品之间的区别：
项目：由客户提出具体的需求来，开发人员只需要根据客户的具体需求来实现就可以了，而且当开发过程遇到需求不明确的情况时可以直接询问客户得到具体的需求回复。
产品：客户提出一个模糊的需求，甚至是市场部或产品部自己挖据出一个模糊的需求，然后探索性的进行开发，在产品发布后给客户试用并让客户提出意见，客户通常的意见是他觉得哪块不好。而开发者就要自行寻找不好之处的解决方案，并且在下一个发布版本中实现出来，如果客户说好，那么意味解决方案是成功的，如果客户说不好，那么需要再次改进相关功能。总而言之，就是开发者需要替用户去揣摩他们想要什么，用户只会说好或者不好（就好像大家都说不好的windows，呵呵）。

这样看起来这样比较的话项目和产品在需求分析上的差别很大，甚至产品的需求都无法找到who和why了。其实不然，狭义的理解需求当然who和why这两个要素实际上是出于用户角度，但是从我们要实现的软件来说，一个具体实现的功能必然具备3w要素，不然是不可能被实现出来的。就拿上面的例子来说，那个需求功能点的提出者就是我们的老大，至于他提出的目的就是为了让用户使用起来更加方便顺手。

回到项目还是产品的标题上来，其实无论项目还是产品都是为了给最终用户提供一个可以工作的具体功能，那么只要是一个具体功能，它就必然满足需求的3W要素，只不过有些需求的提出者是最终用户，而有些需求的提出者有可能是市场人员、产品人员、甚至是开发人员。

最后加一点点小小的体会，曾经有一段时间，我为了做好开发，去察看了各种各样如何作何需求的资料，写过大大小小各种各样的需求文档，但是到了最后实现的过程中，总是能发现需求文档当中的种种不足。最终这种困惑是在接触agile之后给我解决的，其实需求文档的目的是为了通过沟通把具体的需求让开发人员知晓，不要出现我需要汽车你给我造出火车这样的问题出来。这里最重要的问题不是文档，而是让开发人员知道他具体要开发什么东西，至于文档只能当作再沟通当中为了辅助记忆的一个附加产物。而在现实过程中，我们往往使用文档进行沟通，因此在现实中我们往往能够感觉到文档的种种不足。结果为了解决这种不足，我们采取的方式是增加文档项，让需求文档变得越来越庞大，也越来越在难以维护，甚至需要各种各样的链接索引，甚至当需求发生变化时，我们发现维护文档的成本已经远远高于实现本身了。。。

所以我现在在讨论需求的时候以3w问题做为基础，弄清楚实现出的功能最终是什么样子（当然还有优先级啊之类的功能点属性），然后把一些难于记忆的要点做一些记录，这个记录甚至是没有格式的。然后做成卡片。。。。呵呵，也许你知道我要说什么了，你想的没错，就是它——Story Card

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

NativeException: org.postgresql.util.PSQLException: ERROR: column "sequence_catalog" of relation "sequences" does not exist: INSERT INTO sequences ("sequence_catalog","sequence_schema","sequence_name","data_type","numeric_precision","numeric_precision_radix","numeric_scale","maximum_value","minimum_value","increment","cycle_option","name","last_value") VALUES(NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'project_7_card_numbers',NULL)

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

终于获得了期待已久的mingle了，简单使用之后真的有惊叹的感觉，没有让我失望。而且还超出了我的想象（内存的耗用也超出了我的想象，300m，太夸张了，我觉得这是mingle在正式版之前需要重要解决的一个问题）

我主要简单试用了mingle的3个工程模板（Agile hybrid，XP，scrum），从体验来说，mingle本质都是基于story card的管理了，3个模板只不过是对story的不同展现方式，重要的是mingle中的storycard是可以根据需要定制不同的属性，所以mingle的核心是story，建立好story的模型，如何对story进行管理和展现，就是mingle的事情了。而且mingle的UI感觉非常好，只要是我想到的动作，它都能有最简单操作方式。

好了，mingle的马屁拍了一大堆，下面我想讲讲我对Agile hybrid模板中属性的理解，希望其中有理解错误的地方大家能够帮我指正出来

Agile hybrid story card property:
名称                                                     含义             
Card added in                                       story是在哪个迭代周期加入进来的，用于标示卡片的迭代周期
Customer Signoff Done in Iteration        客户要求在那个迭代周期之前完成，一般指story的交付时间
Deleted in Iteration                                在哪个迭代周期删除（具体用意不清，是指被用户取消了吗？）
Development Done in Iteration               在哪个迭代周期开发完成
Functional Area                                     功能区块，如UI，资源管理，后台进程之类的等等
Iteration Scheduled                                预定在那个迭代周期中实现
Narrative Done in Iteration:                  （猜测是指在哪个迭代周期被补充完整）
Original Estimate:                                  原始估计（）耗费的基本资源点数，以小时/人为单位
Planning Estimate:                                 计划估计（）耗费的基本资源点数，以小时/人为单位
Priority:                                                优先级    Critical紧急的/Essential基本的/Nice to have最好能完成/Not essential非本质的
QA Signoff Done in Iteration：            QA 标记在哪个迭代周期完成
Release:                                               状态     
[new/open/Narrative started叙述开始/Ready for Development准备开发/Ready for Testing准备测试/Ready for Showcase准备展示/Ready for Deployment准备发布/Deleted/Complete]             

我觉得奇怪的这些属性只用于迭代周期相关的很多，但是没有一个是关于人的，比如说卡片添加者，卡片开发者，卡片测试者，是不是计划驱动的方法就不需要人了呢，还是这仅仅是一个example的模板，呵呵，反正不关怎样我至少会加上一个developer的属性的。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师