okokwukai

        public DataSet itemseach(DateTime da1, DateTime da2)
        {
            DataSet myset = new DataSet();
            SqlConnection mycnn = new SqlConnection(Properties.Settings.Default.HappyHISConnectionString);
            SqlCommand logcmm = new SqlCommand("select itemname as 项目名称 ,sum(itemvalue) as 合计 from 收费记录 where chargetime >= cast('" + da1.ToString() + "' as datetime) and chargetime <=cast('" + da2.ToString() + "' as datetime) group by itemname", mycnn);
            SqlCommand detailcmm = new SqlCommand("select itemname as 项目名称,...... from 收费记录 where chargetime >= cast('" + da1.ToString() + "' as datetime) and chargetime <=cast('" + da2.ToString() + "' as datetime)", mycnn);
            mycnn.Open();

            SqlDataAdapter logadp = new SqlDataAdapter();
            logadp.SelectCommand = logcmm;
            logadp.Fill(myset, "收费项目");

            SqlDataAdapter detailadp = new SqlDataAdapter();
            detailadp.SelectCommand = detailcmm;
            detailadp.Fill(myset, "明细");

            myset.Tables[0].TableName = "收费项目";
            myset.Tables[1].TableName = "明细";
            DataColumn logcol = myset.Tables["收费项目"].Columns["项目名称"];
            DataColumn logdet = myset.Tables["明细"].Columns["项目名称"];
            DataRelation logrela = new DataRelation("收费项目", logcol, logdet, true);
            myset.Relations.Add(logrela);
            mycnn.Close();

            return myset;

        }

        public DataSet docitemseach(DateTime da1, DateTime da2)
        {
            DataSet myset = new DataSet();
            SqlConnection mycnn = new SqlConnection(Properties.Settings.Default.HappyHISConnectionString);
            SqlCommand logcmm = new SqlCommand("select doctor as 医生,itemname as 项目名称 ,sum(itemvalue) as 合计 from 收费记录 where chargetime >= cast('" + da1.ToString() + "' as datetime) and chargetime <=cast('" + da2.ToString() + "' as datetime) group by doctor,itemname order by doctor", mycnn);
            SqlCommand detailcmm = new SqlCommand("select doctor as 医生,itemname as 项目名称,...... from 收费记录 where chargetime >= cast('" + da1.ToString() + "' as datetime) and chargetime <=cast('" + da2.ToString() + "' as datetime)", mycnn);
            mycnn.Open();

            SqlDataAdapter logadp = new SqlDataAdapter();
            logadp.SelectCommand = logcmm;
            logadp.Fill(myset, "收费项目");

            SqlDataAdapter detailadp = new SqlDataAdapter();
            detailadp.SelectCommand = detailcmm;
            detailadp.Fill(myset, "明细");

            myset.Tables[0].TableName = "收费项目";
            myset.Tables[1].TableName = "明细";

            DataColumn[] logcol = new DataColumn[2];
            DataColumn[] logdet = new DataColumn[2];

            logcol[0] = myset.Tables["收费项目"].Columns["医生"];
            logcol[1] = myset.Tables["收费项目"].Columns["项目名称"];
            logdet[0] = myset.Tables["明细"].Columns["医生"];
            logdet[1] = myset.Tables["明细"].Columns["项目名称"];

            DataRelation logrela = new DataRelation("收费项目", logcol, logdet, true);
            myset.Relations.Add(logrela);
            mycnn.Close();

            return myset;

        }

这是个多年前在网上看到的小短文，记不得作者了，晚上要看球了，工作一天也累了放松一下，到我的杂文区整理出了这个短文，感觉不错，就贴上来了。

        宇宙诞生之前，没有时间，没有空间，也没有物质和能量。大约150亿年前，在这四大皆空的“无”中，一个体积无限小的点爆炸了。时空从这一刻开始，物质和能量也由此产生，这就是宇宙创生的大爆炸。

　　刚刚诞生的宇宙是炽热、致密的，随着宇宙的迅速膨胀，其温度迅速下降。最初的1秒钟过后，宇宙的温度降到约100亿度，这时的宇宙是由质子、中子和电子形成的一锅基本粒子汤。随着这锅汤继续变冷，核反应开始发生，生成各种元素。这些物质的微粒相互吸引、融合，形成越来越大的团块，并逐渐演化成星系、恒星和行星，在个别天体上还出现了生命现象。然后，能够认识宇宙的人类终于诞生了。
　　这幅大爆炸图景，是目前关于宇宙起源最可能的一种解释，被称为“大爆炸模型”。大爆炸理论诞生于20年代，在40年代由伽莫夫等人进行补充和发展，但一直寂寂无闻。直到50年代，人们才开始广泛注意这个理论，不过也只是觉得它很好玩，并不信服。人们更愿意认为，宇宙是稳定的、永恒的。
　　但是，越来越多的证据表明，大爆炸模型在科学上有强大的说服力。我们不得不相信，宇宙有一个开始，也将有一个终结。它产生于“无”，也终将回归于“无”。 宇宙：可有始，可有终？
　　在人类历史的大部分时期，有关创世的问题，一向是留给神去解决的。宇宙起源于何处？终点又在哪里？生命如何产生？人类怎样出现？对这些疑问，许多宗教都能给出一份体系完备的答案。至于上帝从哪里来，这种问题是不该问的。

　　直到最近几个世纪，人们才开始学着把神撇开，以超越宗教的角度，去思考世界的本源。这样一来，就有一个重大的原则性问题需要解决：宇宙是永恒存在的，还是有起始的？

　　这两种说法长久以来一直困扰着科学家、哲学家和神学家，对于普通人来说，更是难以理解。假设宇宙在时间上没有起源，即过去一直存在，那么宇宙的年龄就是无穷大了。无穷大这个概念，一听就让人头昏脑胀：既然是已经过去了无穷久的时间，我们的“现在”又是什么呢？而如果说宇宙是有起始的，那么它就是从“无”中突然产生的了，这最初的一刹那，又是怎样呢？
 　　凭着人类在短暂的生命中获得的常识，实在是很难想明白这些东西。不过，我们可以从科学上寻求一些佐证。大爆炸模型的一个基本假设是宇宙的年龄有限，这个说法令人信服的直接理由，来自物理学中一条最基本的定律——热力学第二定律。这条科学史上最令人伤心绝望的定律，冥冥中早已规定了宇宙的命运。
 　　简而言之，第二定律认为热量从热的地方流向冷的地方。对任何物理系统，这都是众所周知并且显而易见的特性，毫无神秘之处：开水变凉，冰淇淋化成糖水。要想把这些过程倒过来，就非得额外消耗能量不可。就最广泛的意义而言，第二定律认为宇宙的“嫡”（无序程度）与日俱增。例如，机械手表的发条总是越来越松；你可以把它上紧，但这就要消耗一点能量；这些能量来自于你吃掉的一块面包；麦子在生长的过程中需要吸收阳光的能量；太阳为了提供这些能量，需要消耗它的氢来进行核反应。总之宇宙中每个局部的嫡减少，都须以其它地方的嫡增加为代价。
 　　在一个封闭的系统里，嫡总是增大的，一直大到不能再大的程度。这时，系统内部达到一种完全均匀的热动平衡状态，不会再发生任何变化，除非外界对系统提供新的能量。对宇宙来说，是不存在“外界”的，因此宇宙一旦到达热动平衡状态，就完全死亡，万劫不复。这种情景称为“热寂”。
　　宇宙正在缓慢地、但坚定不移地走向这无法抗拒的命运，几代智者为此怀疑人类的存在是否有意义。暂且撇开这种沮丧的情绪，作一个简单的推理，我们就可以发现，宇宙不可能有无限的过去。很简单，如果宇宙无限老，那它早就已经死了。以有限速率演变的东西，是不可能永远维持下去的。换句话说，宇宙必然是在某个有限的时间之前诞生的。

大爆炸：有推论有根据

　　第二定律明示了宇宙有起始，但这个重要推论竟然被19世纪的科学家忽略了，它只是在后来成为大爆炸模型的佐证。该模型的提出，是基于20世纪初的天文观测。
　　20年代，天文学家埃德温·哈勃注意到，不同距离的星系发出的光，颜色上稍稍有些差别。远星系的光要比近星系红一些，即波长要长一些，这种现象被称为“哈勃红移”。它说明，各星系正以很高的速度彼此飞离。一列火车快速驶远时，它的汽笛声听来会沉闷很多，因为声波相对于我们的频率变低、波长变长了，这就是多普勒效应。把声波换成光，产生的效果就是红移。哈勃对众多星系的光谱进行研究后确认，红移是一种普遍现象，这表明宇宙正在膨胀。
　　 这一发现，奠定了现代宇宙学的基础。
         如果宇宙正在膨胀，那它过去必定比较小。如果能把宇宙史这部影片倒过来放，我们势必会发现，在过去的某个时刻，所有的星辰都是聚合在一起的。这个时间大概是100多亿年前，要准确推断它比较困难。
　　另外，宇宙膨胀的速度会随时间发生变化，这与引力有关。万有引力作用于字宙中一切物质与能量之间，起到刹车的作用，阻止星系往外跑，从而使膨胀速度越来越慢。在诞生初期，宇宙从高密度状态迅速膨胀，随着时间的推移，体积越来越大，膨胀速度越来越小。将这个过程向回追溯到宇宙创生的那一刻，可以发现当时宇宙体积为零，而膨胀速度为无限大。这就是大爆炸。
　　大爆炸是空间、时间、物质与能量的起源。这些概念都不能外推到大爆炸之前。大爆炸之前发生了什么、是什么引起了大爆炸，这些问题在逻辑上就是没有意义的。那以前所有的，只是“无”。
　　以上所述仅是旁证，似不足以令大多数人信服。如果150亿年前发生了一场大爆炸，如此惊天动地的力量是否在今天的宇宙结构上留下了某种印迹？于是，有一阵子，科研人员热衷于寻找宇宙创生的遗迹，劲头赛过当年的宗教考古学家寻找伊甸园。亚当和夏娃的文物是一样也没发现，原初宇宙最重要的遗迹倒真给找出来了，这就是微波背景辐射。
 　　按照大爆炸理论，最初的几分钟里，宇宙是一个炽热的火球，到处充满温度高达几十亿度的光辐射。由于此时的宇宙处于热动平衡中，这种辐射具有独特的光谱特征，称为“黑体谱”。1965年，贝尔电话公司的两位物理学家彭齐亚斯和威尔逊偶然发现，宇宙确实浸润在一种热辐射之中。这种辐射以相同的强度从空间各个方向射向地球，其温度约为3K，谱线具有完美的黑体谱特征。微波背景辐射的发现，是对大爆炸模型最有力的支持。
　　知道了今天宇宙背景辐射的温度，就很容易推算出，宇宙诞生后约1秒钟各处的温度约为100亿度。在如此高温下，不仅我们熟悉的物质无法存在，连原子核也会被撕得粉碎。宇宙只能是一锅由质子、中子和电子等构成的基本粒子汤。
　　随着这锅汤变冷，核反应发生了。中子和质子很容易聚合在一起，产生由两个质子、两个中子组成的氦核。计算表明，氦核形成的过程持续了大约3分钟，形成的氦约占宇宙物质总质量的四分之一。这个过程用完了所有的中子，余下的质子就成了氢原子核。
　　因此，大爆炸模型预言宇宙应当由大约25％的氦和75％的氢组成，这与天文测量结果极为符合。最初三分钟里形成的氢与氦，构成了宇宙中99％以上的物质。形成行星和生命的丰富多彩的重元素，只占宇宙总质量的不到l％，它们大部分是在恒星内部形成的。
　　根据推断，宇宙的形成距今约100～200亿年。　　

生命：既永恒又无恒

　　天文观测表明，各种天体的年龄均小于200亿年，这与大爆炸理论契合得非常好。我们的地球大概是50亿年前形成的，人类出现的时间更短得不值一提。宇宙现在还算得上年轻，担忧末日的来临，对单个人来说是十分无聊的事。然而，为全人类的命运想一想这个问题，还是有必要的。
　　按照大爆炸模型，宇宙在诞生后不断膨胀，与此同时，物质间的万有引力对膨胀过程进行牵制。如果宇宙的总质量大于某一特定数值，那么总有一天宇宙将在自身引力的作用下收缩，造成与大爆炸相反的“大坍塌”。如果宇宙总质量小于这一数值，则引力不足以阻止膨胀，宇宙就将永远膨胀下去。
　　在非常遥远的将来，比如1亿亿亿年以后，所有的恒星都燃烧完毕，茫茫黑暗中，潜伏着一些黑洞、中子星等天体。宇宙的尺度已经膨胀到如今的1亿亿倍，而且还在扩张下去。在这个系统里，引力虽不足以使膨胀停止，但会不露声色地消耗着系统的能量，使宇宙缓慢地走向衰亡。黑洞在霍金效应的作用下释放出微弱的辐射，最终全都以热和光的形式蒸发掉。足够长的时间之后，连质子这样稳定的基本粒子也衰变、消亡了，宇宙最终变成一锅稀得难以置信的汤，其中有光子、中微子，越来越少的电子和正电子。所有这些粒子都在缓慢地运动，彼此越来越远，不会再有任何基本物理过程出现。
　　这是寒冷、黑暗、荒凉而又空虚的宇宙，它已经走完了自己的历程，面对的是永恒的生命，抑或永恒的死亡。这种情景，差不多就是“热寂”了。
　　如果引力足够强大，宇宙终有一天开始收缩，又将如何呢？在大尺度上，收缩过程与大爆炸后的膨胀是对称的，像一场倒放的电影。收缩的过程起初很缓慢，随后越来越快。在转折点过后，宇宙的体积开始缩小，背景辐射温度上升。漆黑寒冷的宇宙变成一个越来越热的熔炉，生命无处可逃，全都被煮熟烤焦。最后，行星、恒星也毁灭了，分布在如今浩瀚空间中的物质被挤进一个很小的体积内，最后三分钟来临了。
　　温度变得如此之高，连原子核也被撕毁，宇宙又成了一锅基本粒子汤。然而这种状态也只能生存几秒钟的时间。随后，质子和中子也无法区分，挤成一堆由夸克构成的等离子体。在最后的时刻，引力成为占绝对优势的作用力，它毫不留情地把物质和空间碾得粉碎。在这场与大爆炸的“暴胀”相对的“暴缩”中，所有的物质都因挤压不复存在，一切有形的东西，包括空间和时间本身，都被消灭。

　　这就是末日。它是一切事物的末日。大爆炸中诞生于无的宇宙，此刻也归于无。无数亿年的辉煌灿烂，连一丝回忆也不会留下。

许多年前，dBase使我对关系型数据库以及利用数据库完成应用系统开始有了许多认识，随着技术的发展，OO技术开始从数据描述转向了对业务的描述，对我来讲，用OO描述业务比数据描述要更加灵活，同时也带来了一些复杂性以及维护的困难，后来大师们从架构上开始完善OO，我理解ORM也是这时期的解决方案的内容之一吧。
可现在的问题出在哪？高校的老师们目前的能力还只是用数据来描述业务，如果没有数据库，我想他们怕是不知所措了，所以教出来的学生也一样离不开用数据描述业务的基本思路 ，所以才有许多高校的教授们总是喜欢先看看数据结构，如果从中分析不出业务来，他们就会一头雾水。
ORM也是一种发展中的技术，如何在开发过程中适应不断变化的需求，如何使设计的架构也能承受这种变化，我想只会用数据结构去描述业务规则，是不会满足这些要求的。

今天在blog上下了一个日程表，世界杯终于来了，想想第一次看世界杯还只是录像，那时任课代表，手中有电教室的钥匙，很N呀，很受师哥们崇的，当时的情景现在都有些模糊了，今天的球迷真幸福呀（但迷中国队的除外:<）。

未将对象引用设置到对象的实例。

[没有相关的源行]

[NullReferenceException: 未将对象引用设置到对象的实例。]
            MapStateManager.AppStateManager.GetMapObj(String mapAlias) +31
            MapStateManager.AppStateManager.SaveState() +42
            _Default.Page_UnLoad(Object sender, EventArgs e) +11
            System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +15
            System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +34
            System.Web.UI.Control.OnUnload(EventArgs e) +2065532
            System.Web.UI.Control.UnloadRecursive(Boolean dispose) +267
            System.Web.UI.Page.UnloadRecursive(Boolean dispose) +20
            System.Web.UI.Page.ProcessRequestCleanup() +40
            System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +154
            System.Web.UI.Page.ProcessRequest() +86
            System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +18
            System.Web.UI.Page.ProcessRequest(HttpContext context) +49
            ASP.default_aspx.ProcessRequest(HttpContext context) in c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\d8e8a4a2\33210ac3\App_Web_-y-moa2u.0.cs:0
            System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +154
            System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64
            

        MapInfo.Styles.TextStyle _textSymbol = new MapInfo.Styles.TextStyle();
        _textSymbol.Font.ForeColor = Color.Red;
        _textSymbol.Font.Size = 8;
        LabelLayer txtlayer = new LabelLayer();
        myMap.Layers.Add(txtlayer);
        LabelSource source = new LabelSource(MapInfo.Engine.Session.Current.Catalog.GetTable("Animation"));
        source.DefaultLabelProperties.Caption = "显示";
        source.DefaultLabelProperties.Style = _textSymbol;
        txtlayer.Sources.Append(source);

概述：

目前一些软件开发团队，特别是中小型团队，由于在低成本模式下运行，加之对软件过程管理的不尽规范，在团队建设上只重视代码开发，不重视设计，只重视编程技术，不重视需求分析、架构设计等技术，只重视开发过程，不重视测试过程，只重视任务，不重视风险等问题，是许多软件公司不能很好的以高效率模式开发出稳定可靠的软件产品的重要原因。

       软件产品的开发，技术路线确定以后，团队组织以及过程管理就成为团队领导人的核心工作内容，项目负责人一般情况下也是技术决策人，这种角色的兼任对中小团队来说也是有效的，但问题出现在项目负责人大多都是优秀程序员出身，对软件技术有着很高的热情，但对项目管理以及更高层次上的团队建设方面就显得有些能力不足。这也会造成一些软件开发的高手做出来的产品却不尽如人意的尴尬局面。

       其实在工作中，以公司的现有条件以及技术特点，在目前一些成熟的模型基础上建立个有公司自身特点的团队建设基本原则以及实施办法，执之以恒的加以贯彻执行，对公司产品目标的形成，公司核心技术的形成，公司核心团队的形成都会产品重大的影响。

具有一定普遍意义的风险：

在许多项目开发或产品开发中，失败的原因一般有以下几类，一是功能及性能没能满足应用的需求；二是需求变化导致项目成本的增加；三是技术水平不足导致项目成本的增加；四是团队出现重大变动，导致研发过程不能正常继续。

功能及性能方面：一般来说，功能及性能方面主要是需求目标没能得到充分重视，特别是性能、安全以及部署等非功能性需求；对核心业务本身，需求分析过程中是被关注最多的，但如何理解这些核心业务，如何用正确的架构完成核心业务的实现，这期间如果控制不当，也会产生许多导致成本增加、工期延长等许多不确定性结果。在需求分析阶段，对需求没有系统的过程控制，带来的风险是非常大的，这往往会成为项目失败在技术上的最先出现的原因；虽然所有的软件团队对需求分析都非常重视，但如果在方法及管理过程中不能有效的控制与管理，也很难避免由于需求阶段存在的风险给整个产品或项目带来严重的问题，几乎所有的中小型软件团队都会有过类似的经历。

需求变化：需求变化是当前软件产品或项目必需适应的，为了具备这个适应能力，除了在架构设计方面要考虑到系统的可维护性，可扩展性以外，对需求的变更管理及相应的风险评估经实践证明是比较有效的管理手段，在这方面技术与技术管理同样重要，缺少哪个环节，都会给产品或项目带来可能导致项目失败的隐患。

技术水平不足：在沈阳地区具有一定的普遍性，目前沈阳市软件开发人员资源并不丰富，大多数优秀开发人员都流向了北京、上海等行业发达地区，其它比较好的开发人员基本上都在大型企业中，根据近两年的经验，能在社会中用招聘方式组建的研发团队，即要有一定的实践经验，同时要保障在同一平台下工作，其质量很难达到快速开发的目的，即使是存在了许多年的团队，也会随着技术人员的流动对团队技术水平带来许多的不确定性；如何能有效的吸引高素质高水平程序员，如何有效的培养高忠诚度的核心员工以及如何有效的利用外部资源，这是目前大多数软件开发团队所面临的重要课题。

团队出现重大变动：这是个比较极端的情况，但却会经常发生，在对2003-2004两年政府项目就多次出现了因为项目团队中人员流动多大，导致项目无法进行的情况（如省民防办、新闻出版局等），这也是一个不容忽视的风险。

要有效的规避风险，在其变成问题前采取有效的措施，是风险管理的主要任务，这里并不做具体的风险评估，只是由于在团队建设方面存在的一些不完善，会成为这些风险（甚至不只是这些）存在的原因，所以才显得重要，其实说到底，就是软件产品不可能是小作坊式的开发方式能完成的，是否具备完善有效的控制能力，规避由其所带来的质量与可靠性方面引起的风险是关系到团队生存的大事。

团队模型的完善：

团队模型是软件开发队伍建设的基础，一个结构合理的团队，虽然不能保证项目一定成功，但却是保障产品长期稳定的保持高质量、高可靠性的基础。

这里所建议的团队模型，参考了敏捷开发和CMM、MSF等重要模型，并在实践中应用了两年以上，应该说是一个有效的中小团队模型；这个模型本身不是固定不变的，它应结合不同时期，不同团队的特点，加以完善，提高其可行性与有效性。

团队模型中的重要概念：

团队的基本构思：

为了弥补传统项目小组自上而下的层次结构的一些不足，研发团队应是小型、跨学科的小组，在这样的小组中成员们共同承担各项职责，权衡彼此间能力差异，以便将主要精力集中到手头上的工作中。他们拥有共同的项目前景，以部署产品为中心，坚持高标准的质量和沟通，保持乐意学习的心态。本文描述了小组中的各种角色群，以及他们的目标和职能领域。同时提供了指导，以便根据产品规模和复杂性来保障一个高效的团队。

清晰的责任，共同的职责：

将工作进行中需要共同承担的职责和确保工作如期完成需明确的工作责任结合起来。

团队模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点，但是没有哪个个人能够完全代表所有的不同质量目标。为了解决这一问题，把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。

在小组内部，每个角色通过对小组本身负责（也对他们各自所属的组织负责）实现该角色的质量目标。在这种意义上，每个角色都对最终解决方案质量的一部分负责。小组成员之间共同承担职责（根据不同小组角色指派）。角色之间是相互依赖的，有以下两个原因：首先，就其必要性而言，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，如果每个角色都了解全局情况，那么小组的效率会更高。这种相互的依赖性会鼓励小组成员对由他们负责的直接区域以外的工作做出评论和贡献，以确保小组所有的知识、能力和经验能够被应用到产品的构造里。项目的成功属于所有的小组成员；他们共同分享一个成功的项目所带来的荣誉和回报，他们也同时希望，即使是一项不太成功的项目，也能做到全心投入并从中吸取教训以完善他们的专长。

赋予小组成员权力：

在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。类似的，未来客户也能够认为小组将会兑现其承诺，并进行相应的规划。在最坏的情况下，小组也应该尽快地告知客户项目出现了哪些延迟和变化。

赋予小组成员权力，让其承担指派的承诺。这种授权包括向小组成员提供进行工作所需的各种资源；负责制定决策以有效影响队员的工作；理解队员的权力界限，并不断增加各种可用途径来处理越权问题。

准备好向其他成员允诺。这些准备包含了心态（进行面谈并乐意采取行动）、就绪，并理解承诺的内在含义以及它对当前工作量和资源的影响。这样做的结果就是，不到小组成员清楚承诺的内在含义，就不要作出承诺。相反，小组成员要提出一个更小的、他们能够理解的承诺，例如对这些承诺的内在含义进行研究，然后再迅速坚定地作出承诺。对较小承诺的成功交付将建立小组的信任。

清晰定义自己担负的承诺。这样可以避免一些可能会导致小组成员间信任危机的误会。

做出一切合理的努力来交付承诺的工作。如果一个小组有来自不同组织的成员，那么合理的期望也将因人而异。例如，某些小组成员可能认为在周末工作是合理的；而其他人则可能将他们视为例外或者可能在周末几乎不会去上班。

发现承诺陷入危机时进行真诚的沟通。有时将无法避免事情的变化，原因可能是某些任务的优先级调整、一个意外事件或仅仅是因为一项工作延期完成。及早的进行沟通将使与之相依赖的其他小组成员可以有机会制定相应的计划。也许他们还可以提出解决这些问题的途径。

这些行为应与企业文化是融合在一起的，队员们已经将它们视为一种文化，因此很少讨论它们。但是，团队有时需要与不同的组织一起工作，在这些组织中的相关的价值观念并没有被完全地了解和注重。这些组织常常呈现出一种高度推诿的文化，这种文化约束着应该开放的信息流。在这些情况下，团队领导应当根据这一点来清楚地陈述他们的期望并帮助新的小组成员适应这种工作方式。

共同的项目设想：

全力提倡采用一个共同的设想，以便把注意力放在小组的工作方法上，包括在一个操作环境里交付产品完整的解决方案及服务。

对项目和过程的目标有一个清晰的了解是很重要的。因为小组成员和客户都在猜测这项解决方案能为组织做些什么。一个共同的设想将使这些猜测明确化，并确保所有参与者都在为完成相同的目标而努力着。共同的设想是团队组织模型的基础之一。

当所有的参与者都了解了这一设想并朝着这一设想工作的时候，小组便能够根据成员使自己的决策与这一设想体现的更为广阔的小组意图相吻合，从而获得他们的权力。

没有共同的设想，小组成员可能出现与目标相抵触的观点，作为一个团体的交付将变得更加困难。并且即便小组完成交付，小组成员也很难确定自己的成功，因为这种成功依赖于他们评价成功的设想。

以客户为中心：

满足客户对任何优秀的团队来说都被看作是第一位的。在整个开发过程中，以客户为中心包含了小组对了解和解决客户业务问题的承诺。衡量以客户为中心的理念体系获得成功的方法之一是能否使设计中每一个特性都符合客户和用户需求。同样，实现客户满意度的一个关键方式是使用户积极地参与设计并在整个开发过程中提供反馈意见。这样，小组和客户都能的使期望和需求更加吻合。

零缺陷：

在一个成功的团队中，所有成员都感到要对产品的质量负责。产品质量责任不能由一个团队成员委托给另一个成员或部门。同样，每个成员都要作为客户的拥护者，在整个开发周期中考虑最终产品的可用性。

零缺陷理念是对质量的承诺。这意味着目标是尽可能最高效地执行工作，这样即使不得不在明天就交付产品，他们也可以交付出一些东西。这个想法是让每一天都有一个接近可交付的产品。这并不意味着交付不存在任何缺陷的代码；这意味这产品满足或超出了项目出资人的质量要求并在预想阶段被小组接受。

用自动机车装配线作类比最有力的描述了这一概念。传统上，工作人员将汽车由单独的部分组装起来并且为他们自身的质量负责。当汽车下线，一名检查员进行检查并判断该汽车的质量是否达到售卖的标准。然而在这个过程的后期，大量的时间将花费在查找所有的问题上，因为在此时进行纠错是极富价值的。同样，既然质量是不可预计的，在后期决定产品是否可售卖所需花费的时间也是不可预计的。

在当前的汽车制造业中，质量已经成为了“第一工作”。这意味着当工作正在进行时（例如正在装配一扇车门或是安装一部收音机），检查员同时审查该项工作以确保它符合为标准的汽车所定义的质量标准。只要在整个装配过程中保持该级别的质量，那么在后期为确保这辆汽车的质量可接受只需要花费更少的时间和资源。这使生产过程更可预测因为检测员只需要检查各个部分的整合处而不是所有个别的工作。

　　1、2006年6月9日-7月9日，你需要阅读报纸的体育版，这样你才知道世界杯都发生了什么事，才能跟我们说得上话。如果你没去看报纸，那么你的待遇就不怎么样了，或者说你整个儿将被忽略。

　　2、不要抱怨不受重视。

　　3、在世界杯期间，电视机是我的，从早到晚，没有任何理由。

　　4、如果你不得不从电视机前面经过，我也不介意，只要你匍匐前进不挡着我就行。如果你策划赤裸着站在电视前面，劝你还是赶紧把衣服穿上好了，因为你感冒了我还得花时间照顾你，送你去医院，这可是我的世界杯月！

　　5、看比赛的时候我会是瞎子，聋子和哑巴，除非我跟你说需要喝点或者吃点什么。所以如果你指望我听你说话，开门，接电话，或者说孩子从二楼楼梯上滚下来你让我去接……除非你昏了头，这些才可能发生。

　　6、对你还有个很好的建议：冰箱里常备两组6罐装的啤酒，还有随手拿了就能吃的食物。还有，在我的朋友们过来看球的时候，请不要对我的朋友扮鬼脸。作为回报，我会允许你在中午12点和早上6点的时候看一会儿电视，除非他们正在重播我漏看的比赛。

　　7、请你，请你，请你务必做到，如果我因为我的球队输了球而沮丧，千万不要说“算了，这只是一场比赛”，或者“别担心，他们下次会赢的”。如果你这么说话，只可能是让我更生气，我对你的爱都会因此减少。记住，你永远不可能像我一样了解足球，所以你所谓的“鼓励的话”只能导致我们分手，或者离婚。

　　8、欢迎你跟我坐在一起看一场比赛，你也可以在半场的时候跟我说话，但只可以是广告时间，前提还得是上半场的比分让我满意。另外，请注意我说的是“一场”，你可别把世界杯当成我们可以共同分享的什么美好时光。

　　9、进球的重播是非常重要的，我才不管之前看没看过，我就要再看一遍，一遍又一遍。

　　10、通知你的朋友，千万别在世界杯期间生孩子，或者为家里的孩子搞什么PAR鄄TY，再来邀请我们参加。因为我不会去，就不去，肯定不去。但如果我的一个朋友星期天邀请我们去他们家看比赛，我们要去的，立刻就去。

　　11、每天晚上电视里的世界杯进球集锦对我来说，和比赛本身一样重要。所以，别说“你不是都看过了吗？干嘛不换个台找点我们可以一起看的节目？”想都别去想，对你的回答将是———参见上面第二条。

　　12、最后，请你收起所谓“谢天谢地，世界杯四年才一次”的论调，这对我不起作用。因此世界杯之后，还有很多球赛,我还有冠军联赛，英超、意甲、西甲等等等等。

　　谢谢你的合作。此致全世界的男人