摘要： 项目组的开发工作也进入到了季后赛门票挣夺的最后阶段。4月6日，甲方对目前的四个项目进行了第一次内部公示，结果项目组在毫无准备的情况下出现了致命的失误。这是我带领项目以来最糟糕的一次演示，虽然是在毫无准备的情况下进行的。但是通过这件事，发现了很多问题。 1、测试不足 2、细节处理不够 3、团队成员工作态度不认真 项目组... 阅读全文

摘要： 周五，但不是周末。 下周一要发布一个内部测试版，项目组几个月以来第一次在周末加班。在这一次版本里需要发布小层剩余油研究和油层组的一部分功能，总体上感觉不错，兄弟们都很“强壮”。 最近的兴致不高，76人三连败了，每次都是在比赛快结束的时候，被对手反超比分。几乎已经成为联盟中绝杀的最佳练习场了。今天是最郁闷的，在领先15分进入第四节的情况下，居然再一次被乱枪打死。I... 阅读全文

摘要： 12月25日，圣诞节。 在这个西方人的节日里，我们送走了构造阶段的第一次迭代。而任务列表也终于出现了久违的绿色。高兴之余，有些失落。这说明我在构造阶段的时候才真正寻找到团队的运行速度，依照项目前的设想整整推迟了尽一个月的时间。在那段时间里，大家一直生活在我的构想中。当这种构想回归到现实中时，就会突显出问题的本质。 为什么要制定项目计划？其实最根本的原因是为了克服恐惧... 阅读全文

摘要： 在大庆没有感冒，回北京却感冒了。由此推论，感冒会受到气温的影响而不决定于气温。项目组的运行也是如此，受限于人员而成败于团队。 从北京"渡假归来"重新回到剩余油的项目团队中，可以清楚地认识到团队存在的优势和不足，得以重新调配人员组合。如何将现有的人员有机的整合在一起，发挥出团队的力量，这就是项目管理的重要。事实上，用组织这个词组比管理更为贴切。 随着汇报日期的逼近，项目组细... 阅读全文

摘要： 12月5号，在原来的计划中应该是构造阶段的开始。 现在看来，细化阶段的完成必须被推迟了。虽然上午的时候，我们提到小层剩余油研究才是本项目的核心，宏观剩余油可以做为一个单独的子系统并入进来。但相较原计划来看，我们的进度有些慢了。正如我之前所说，推迟的原因主要在于对风险的准备不足。这种风险包括技术上的风险，比如DWG文件的读写、等值图的绘制。同时也包括诸如业务的不明确和组员对... 阅读全文

摘要： 进入第三次迭代中期，一些问题直接被暴露出来，项目的进度缓慢。问题原因在于前期对项目的非技术性风险准备不足，表现在： 1、项目组部分组员对.NET平台不了解，熟悉需要花费一些时间。项目组之前接受过.NET的培训，因为动手较少，所以培训效果并不理想。因此在项目进行过程中直接影响了项目的进展。对于这种情况项目组决定在下周专门提出一部分时间对项目的框架以及该项目用到的技术... 阅读全文

摘要： 根据团队特点改进后的迭代开发流程： 工具使用需求 用例模型(ROSE)、用例规约(Word)OOAD 白板、ROSE类图和子系统 ROSE、PowerDesigner自动生成 MyGeneration编码 VS2003、VS2005数据库 Oracle9i版本控制 VSS持续构建 CruiseControl.NET单元测试 ... 阅读全文

摘要： 项目在今天终于进入了正常的轨道，大家都很高兴。 有两个任务被完成了，一个是小层剩余油多层次模糊综合评判的代码实现，虽然还需要进行大量的重构，但大家忙了这么长时间(尤其是王元庆和王兴)，终于可以看到结果，是件很另人兴奋的事。我想明天应该辅助他们完成这个项目的重构，然后配置在代码管理器上，这样的代码才够健壮。关于健壮的问题，我和王兴刚刚还有一个争论。争论的源头在于单元... 阅读全文

摘要： 团队因为Oracle的问题，浪费了整整一天的时间。而这种浪费仍然在继续。 在项目开发的过程中，风险无处不在。开发没有十拿九稳的事，如果没有丰富的经验，千万不要因为事情简单而忽视它的存在，那是致命的。今天的工作有两个，一是搞定CastleAR与Oracle的结合问题，另外一个为小层剩余油的代码完成测试工作。这两个问题都有可能延续到明天。 今天周六，处在迭代尾声。回头来... 阅读全文

摘要： 迭代中期，我们发现迭代初期制定的任务并非预料那么简单。 这很正常，正如我之前所说，迭代计划一定是和实际情况有出入的，如果发现完全符合计划，那只能说明两个问题：第一，该计划是在任务完成之后做的，做该计划的原因是项目规定。第二，迭代的完成是因为时间到了，而并非实际任务的完成。但是，这种出入会随着项目的不断深入，越来越接近于零值。所以在项目初期制定迭代计划时，需要将用例根据业务价值排序... 阅读全文

摘要： ――和你面对五个人的防守时一样，软件开发也是一项集体游戏 当每个阶段的结束时 你需要好好的放松一下，那是对自己的一种奖励。这种权力没有任何一个人可以剥夺，哪怕是教练。因为你需要面对更多的挑战，第二节，第三节，还有第四节…当每次迭代结束时 不要放松，我们需要回头看看这次迭代的成果。进攻、防守。在下一次迭代中改进它…当每次迭代开始时 没有事情可以重来，... 阅读全文

摘要： 细化阶段第二天，发现需求应该扩充和整合的部分。 正如之前所说，开发者不可能一下子把用户的需求整理出来，随着项目的深入，尤其是原型的提供，会逐渐发现需求中的问题。比如，在初始阶段，我们注意到项目的业务需求是为了发现更多的剩余油，以便于生产的需要。于是将系统的需求分为宏观剩余油研究、小层剩余油研究、油层组剩余油以及四维剩余油研究四项，而小层剩余油研究的目标是根据基础生产数据计算出... 阅读全文

摘要： 终于拿到了VS2005的正版软件，然而随之问题即来。 先是发现Nant与MSBuild的编译问题，刚刚把Nant的源码改完，好不容易可以持续集成了，紧接着发现NUnit仅支持到2.0.40607版。然后是Nhibernate和Spring.net。没有时间把所有的开源项目都改成正式版本的，也不值得。 于是决定把所有的版本重新改回VS2003。直接浪费时间2.5天... 阅读全文

摘要： 今天是项目开始的第二天，随着对环境的熟悉，项目组也慢慢步入了正规。 因为前期对需求多少有些投入，所以整理起来并不是十分困难。但正如我之前所说，在真正的软件开发过程中，用户都不知道自己的需求。随着项目的深入，这个问题会逐渐报露出来。所以需要一套有效的方法对其加以重视。在整理需求规约的过程中，发现真实的需求和当初的设想有大量的差异。主要体现在两个方面。一方面是因为用户对项目的期望，往... 阅读全文

摘要： 昨天开了一天的启动会，对项目的大致背景作了一个介绍。其中涉及的内容还包括团队的组建、角色的划分、过程和工具的使用以及项目与迭代计划的安排。整个开发过程中，我们希望以RUP为指导作为过程结构的框架。如果软件是一个行业的话，那么其它行业也一定存在着同样的问题。从管理的角度来看，一个团队的成功更多的不是依靠工作规范或者条例。尤其软件行业从业者的教育素质相对较高。因此，团队成员之间的交流显... 阅读全文

摘要： 阅读全文

摘要： 最近很兴奋，这缘由大概是因为可以和一群优异的人在一起工作的原因。在项目中成功和失败过的人都会清楚的了解这一点，那就是优秀的团队可以给你带来什么。而这个简单的道理，我整整经历了两年的时间，才真真正正的体会出来。有时候就是这样，道理很简单，但只有真正经历了才可以明白。几日前和赵巍到盛世紫薇，偶然间发现他们的员工内训教材。其中提到一条就是习惯，原文想不起来了，大致的意思是“强制成习惯，... 阅读全文

摘要： [关于需求] 需求应该记录下来。但是很多需求在通过语言表达的过程中被发现并不复杂，于是很多程序员的选择是把它们存储在大脑芯片里。这样可能会节省很多时间。然后一旦出现人员流失或者需求变更的情况，那么它就会显得非常混乱。要知道用户可不想一次又一次的回答同样的问题。我曾经给众多的客户充当过开发顾问的角色。他们总是向我抱怨，项目团队的开发人员总是一次又一次的问他们同样的问题，而理由是... 阅读全文

摘要： [关于单元测试] 我曾经有试一些经历，越接近项目尾声的时候越感到焦虑不安。项目的结束更多时候是工期的结束，而产品则是一大坨代码的堆砌。我不清楚这样的代码是否可以经历起风雨，而当时最提心的事情莫过于客户提出的更改要求。因为那意味着动一而发全身的工程，调试的思路会非常混乱，你并不清楚哪些代码是可以信赖的。直到Kent Beck给我讲授的关于辘栌的故事。在小时候，我姥姥家的家村见过... 阅读全文

摘要： 道，可道，非常道 阅读全文

摘要： 随着对国内软件开发现状的逐渐深入了解，越来越有一种写些东西的感觉。我自己并不晓得这对于国内软件行业来说有怎么样的意义，或者根本不值一提，但我越来越坚定信念，要写下去的信念。我需要通过一个实际的例子从两个方面来写，一是从软件开发生命周期的角度来看问题，指明这个生命周期中的角色、活动、流程与工件的关系与取舍。另一方面从OOAD的方面，指明如何通过OOAD的方法解决实际工作中出现的问题。... 阅读全文

摘要： 一言以蔽之，建立在人和交流的基础上，做尽可能少的东西，越少越好。而一些项目经理失败的原因居然简单到连减掉一些工件的力气都不愿花费。 阅读全文