产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（story），有时候也叫做 backlog条目。

 

注：对于产品backlog的理解不应该仅仅停留在用户故事层面，产品backlog本身来源于用户故事，体现的是用户能够感知的业务场景。但是产品backlog本身包含了更多的信息，包括优先级，估算，How to Demo(作为测试用例的原型)。产品backlog是有优先级，估算和初步测试的业务场景驱动的需求结合。是后面形成Sprint迭代计划的基础。产品backlog最好的方式就是借助于Excel进行收集，分类和整理。

 

Sprint计划会议非常关键，应该算是 Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个 sprint 甚至都会被毁掉。 举办 Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。这么说可能比较模糊。其实，Sprint 计划会议会产生一些实实在在的成果：

• sprint

原文:http://www.javaeye.com/topic/470476

 

一、项目启动（项目开工会）

• 了解项目干系人及其利害关系。
• 所有项目组成员是否到位，如到位则拿到项目开发人员的简历，详细了解每个开发人员的情况（可能会组织到客户方面试）。
• 根据项目需求规格列出项目功能列表，并根据开发人员技术等情况创建WBS。
• 根据项目时间、资源等情况规划项目初步开发计划（各里程碑时间点的粗略计划，每个时间段投入多少人力等）。
• 软硬件需求：版本控制服务器、数据库服务器、开发服务器、缺陷管理服务器、开发工具等。

会议目标：让整个项目组的成员相互认识，建立项目的工作关系和沟通关系，让大家明确团队的工作目标和项目当前的工作状态并一起审阅项目计划，找出项目的难点或可能出问题的环节；分配小组和个人的角色与责任，获得小组和个人的承诺。

参与人员:项目经理、项目总监、全体项目组成员、用户方领导、用户方参与人员、其它主要项目干系人。

 

实施建议：对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查

原文:http://server.zdnet.com.cn/server/2009/0518/1369159.shtml

 

上面都是在讲人的思维与智力，也就是大脑的运作，而当大脑做出了判断和决定，就需要去实施，反过来人不是只有一个脑袋，它需要一个身躯，为它供血供氧，如果这个身躯不够强壮，再好的脑袋也没用。因此，一个人的智慧离不开一个好身体，它包括了大脑的健全与体格的健壮，从这一点来说，我们可以认为一个人其实就是一个动态的架构。

 

当我们睡觉时，我们的心跳最慢，大脑处于休息状态，当我们在思考问题时，大脑将调用尽可能多的细胞为我们服务，当我们运动时我们的心跳加快，当我们需要静一静时，我们会坐下来一动不动，当我们要逃离危险时，我们的双腿将会能倒多快有多快，这难道不是一种动态的表现吗？所以我们的智慧就是建立在这样一个动态的基础上，即使是霍金，他的身体也不是死的，大脑也是随时处在动态之中。

 

没有一个健壮而高效的体格，很难相信可以在竞争的竞争中立于不败之地。

 

对于一个企业来说，信息分析的核心就在于数据中心，它是所有数据汇总的地方，一个体弱多病的人，大多也不能把他的智慧很好的

原文：http://hihitiger.javaeye.com/blog/392772

 

业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。 业务建模（Business Modeling）是一种建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。

 

注：参考RUP业务建模方法论: http://oa1.jmu.edu.cn/Rose/RUP/process/workflow/ovu_busm.htm

 

 

原文：http://server.zdnet.com.cn/server/2009/0518/1369158.shtml

 

前文讲到了感知的重要性，那么如何去有效的处理感知回来的资料以提取出有用的信息呢？这就需要内部的消化、吸收与提炼了。有很多人也能获取很多的感知的素材，但并不能得出丰富的信息，这就是智慧与否的另一个区别。智慧的人，会将得到的资料进行横纵联合的比较与分析，找出各种各样的规律，帮助自己做出更准确的判断，上文中有关对孩子考试成绩的态度就是一个最为简单的例子。企业也是如此。例如超市的主管可以去提取天气方面的数据与销售数据来对比，以分析出不同天气状态下商品的销售态势，从而可以根据天气预报来迅速的做出某种货源的调整，但一般人可能就想不到天气与销售之间的关系，从而与某种有用的信息失之交臂。再比如，还可以将即时路况信息附加到GPS中，以让导航更具智慧一样，放眼望去，这类潜在的充满智慧的思路不胜枚举。

 

我们常说的联想就是这种交错式的关联

关于企业的所存在的四种基本架构可以先参考该文章：
http://blog.sina.com.cn/s/blog_539e5cba0100fobf.html



在这里我们首先关注业务架构和应用架构，业务架构驱动应用架构，以体现流程驱动IT，这也是前面SOA咨询方法论的重点思想。SOA方法论的一个突出的贡献就是解决了业务架构和应用架构如何通过系统的方法进行集成的问题。可以参考我前面的关于SOA咨询方法论的描述。

对于业务架构，初看架构这个词容易理解为静态的事物，但是广义的业务架构一定是静态和动态分析的集成和融合，在分析过程中相互影响又相互促进。动态的信息即我们说的普通的价值链分析的思路，从企业端到端的高端流程到各个业务

原文:http://server.zdnet.com.cn/server/2009/0518/1369157.shtml

一个人的智慧来源于积累，不断的从外界获取知识，当掌握了足够的知识才有可能根据我们所获取的不同资料，去提炼出不同的信息，进而分辨哪些信息是对自己有利的，哪些信息预示着危险，哪些信息意味着机会，等等。这里我们要先明确一个概念，什么是信息？

我们平时所获取到的最初只是客观存在的事或物，它们以某种形式让我们所认识、了解和察觉，这种初次获得的东西就是一种资料，而信息就隐含其中，但需要我们予以挖掘。比如我们拿到一份电报，并且是加密的，此时这份电报对我们来说只是一份资料，只有当我们掌握了密码或破解的技术后，将电报翻译出来，我们才能说获得了其中的信息，当然这个信息也算是一种资料，只是经过提炼后的。

接下来，我们发现这份电报的内容是告诉你，你孩子的期末考试成绩和名次，那么其中的分数和名次就是另一种资料，或者说是数据。注意，这里引出了另一个概念——数据，数据是对某

当我们面对问题的时候，通过问题的初步分析往往会产生很多试探性的解决方案，在非结构化解决问题中我们必须要凭借经验多去尝试。但是更重要的是当某一个假设行不通的时候要懂得及时回头，寻找新的假设和路径。对于常见问题的解决，不应该去走偏门而应该多走主流的解决方案。而这里面又一个重点就是，当主流解决方案不通的时候，应该是创造条件和机会解决主流解决方案实现过程中的障碍，而不是去另辟新路。

理论派的看不起实践派，认为实践的东西没有深度，没有理论高度；实践派的看不起理论派，认为理论家的东西无法落地，不实用，也没有办法转化为真正的价值。而真正的理论和实践无所谓先后，只有是否真正的融通和相互促进。正如矛和盾，在互相竞争中不断的发展自我，企业很多时候更需要的是矛盾皆备，先有了锋利的矛的时候却在宣传自己的盾。

最近刚看了《神秘代码》和《2012》，都在讲世界末日，好莱坞的灾难片的视觉效果确实很震撼。而两部片子都涉及到了些宗教的内容，是不是有救世主我不知道，但是每个人确实需要不断的自我救赎，灾难面前唯一有用的是信仰。懂得灾难和痛苦，才更容易懂得当下，懂得感恩。

做一件事情的过程

关于问题，当我们对一件事情不清楚或者当我们对自己的决策无把握的时候如何处理？很多时候在没有开放和沟通的环境中基本是按着自己的理解做从而导致后续大量返工。所以首先是要去想问题和风险，要把问题暴露出来，先不要考虑提问的方式而是先形成问题意识，特别是类似Issue问题本身就是潜在风险。问题暴露出来后我们再来考虑如何更好的提问，如何去考虑下次遇到同样的问题是如何解决，如何逐步形成分析和解决问题的方法等。

关于日志，为什么要记录日志？日志应该记录到什么程度？我们首先要认识到个人的头脑是靠不住的，记录的目的究竟是什么？记录往往是思维的开始，有了记录才谈得上后续的思考和改进。随时随地的记录就是一个最容易学会的最好的一个习惯。有了记录，有了一段时间数据的积累，就谈得上如何更好的使用和分析记录的内容。记录的内容中哪些知识点，经验，技巧是可以复用的？哪些要进一步的进行分类，归纳和整理；我的时间究竟花在了哪些地方，原因是否是技能问题？

关于冲突，在没有开放的沟通环境的时候其实很难产生冲突。所以首先是开放和包容的团队文化，其次是对事不对人的沟通过程，最后是沟通本身也是要目标驱动，不是个人

原文:http://blog.csdn.net/CavenRan/archive/2009/10/30/4747964.aspx(稍作修改)

完整的做完一件事情后再开始做第二件

这条玉律在厨房里面的说法是：“在开始做下一道菜前，先把当前这道菜上给客户”。软件开发最大的问题是一大堆事情并发进行，因此其中的一些工作就不可避免地会在后期被丢弃，这就意味着努力被浪费。先专注于案例1；使它完全能够正常工作；运行相关的测试；书写与之关联的文档；嵌入所有相关的代码；然后才能开始下一个任务；

决不要允许构建失败

非常明显，这一条建议应该被包含在任何一个关于软件开发建议的列表中；如果一个程序员在嵌入前做了所有适当的预防措施，进行了足够的测试，是绝不会导致构建失败的；如果构建失败了，说明有人想走捷径；

在没有明白是哪个需求用例真正需要前，绝不去设计和实现一个类

当编写某个类的时候，你应该在脑海中有一个与之对应的需求用例，同时你应该只提供对这个需求用例来说是必需的方法。有时候程序