OOPAA

Focusing on OO, Patterns, Architecture, and Agile
posts - 29, comments - 75, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

2010年12月23日

     摘要: 作为技术人员,我们经常需要跟客户、业务分析人员等非技术人员沟通软件设计方面的问题。如何比较直观地向这些非技术人员解释设计、软件质量对项目的影响,解释糟糕设计、不干净代码给项目带来的风险,解释我们必须开始关注软家设计问题?这里有两个概念(metaphor)可以帮助我们达到这一点。  阅读全文

posted @ 2010-12-23 23:55 mingj 阅读(6236) | 评论 (2)编辑 收藏

2010年12月22日

posted @ 2010-12-22 22:55 mingj 阅读(6741) | 评论 (1)编辑 收藏

2010年9月24日

     摘要: 浮潜潜水员游弋于海水表层,看鱼戏浅滩,望影掠深海。水肺潜水员可以潜过海水表层的深度;他能潜到更深的地方,在一定的区域内研究那些影子以发现鱼类、沉船残骸以及珊瑚的细节。在相同的时间内,浮潜潜水员可以游历更宽阔的水域;而水肺潜水员则在潜游深度上占据优势。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用,在特定的时刻明智地选择合适的方法,从而有效地利用了时间。  阅读全文

posted @ 2010-09-24 21:05 mingj 阅读(3785) | 评论 (0)编辑 收藏

2010年9月14日

     摘要: 在一开始的时候,一切都显得那么美好。市场部有一个来自于客户的请求——添加额外的下拉菜单。然后,在产品中添加一个输出接口的需求来了,产品经理想要加上一份新的分析报表,DBA要求在数据库里增加一个新字段以改变背景的颜色。所有这些需求以及其他更多的需求,都交由开发人员负责加进到产品里面。随着需求的不断添加,产品的特性集不断增长,但过了一段时间之后,每个人——市场部、客户和开发团队——对如何将所有这些碎片整合在一起、这些碎片如何帮助实现业务目标,失去了理解。曾经带着明确目标出发的项目变成了难以下咽的、由各种无关特性炖成的一锅汤。  阅读全文

posted @ 2010-09-14 07:42 mingj 阅读(3780) | 评论 (2)编辑 收藏

2010年8月31日

     摘要: 在如今大部分的组织里面,是否给申请技术职位的人提供工作机会——这个最终决定权属于管理部门。经理们雇人,经理们裁人:一切都天经地义。然而在某些组织里面,这些技术人员能否得到工作机会却是取决于——至少部分取决于——他们将来的同事。这种同事预审的最终结果只有一种:当经理们让技术职员拥有发言权的时候,每一个人——申请人、职员和经理——都会和盘托出自己的想法。  阅读全文

posted @ 2010-08-31 21:19 mingj 阅读(3063) | 评论 (0)编辑 收藏

2010年8月4日

posted @ 2010-08-04 01:04 mingj 阅读(4112) | 评论 (1)编辑 收藏

2010年7月30日

     摘要: 组织相信忙乱的工作状态象征了健康的生产率。  阅读全文

posted @ 2010-07-30 22:44 mingj 阅读(2601) | 评论 (1)编辑 收藏

2010年7月26日

     摘要: 项目经理的很多技能都与传统的英式保姆有共同之处。  阅读全文

posted @ 2010-07-26 23:38 mingj 阅读(4228) | 评论 (2)编辑 收藏

2010年7月20日

     摘要: 高涨的士气永远象征着组织的健康。与之类似,低弱的士气则说明肯定有什么地方做错了。有一种管理理念就是奉这种关系如圭臬,试图从相反的方向来利用这种关系。逻辑是这样的:把士气鼓舞起来,其他美好的东西也就跟随而至。  阅读全文

posted @ 2010-07-20 21:54 mingj 阅读(3325) | 评论 (2)编辑 收藏

2009年9月28日

     摘要: 前一阵子使用JSF开发web应用程序,碰到一个典型的页面转向需求。按照JSP的方案完成了需求,但却给系统引入了BUG。而且更糟的是,系统页面没有任何提示,后台日志没有任何异常信息。本文通过一个JSF的非典型性BUG,提出了软件调试的原则和指导,并就前述BUG进行了调试分析,找到问题的所在。最后,软件调试是一项很有意思的活动,常常给开发人员带来解谜般的快感,或者一团乱麻的纠结。导入代码、设置断点、逐步调试并不是最好的办法,清楚地划分问题域,找准确定点可能会事半功倍。当然,在找出水面下面的暗礁之后,别忘记给自己、给其他人mark上这块区域的暗礁位置,能极大减少以后触礁的痛苦。  阅读全文

posted @ 2009-09-28 02:01 mingj 阅读(3750) | 评论 (1)编辑 收藏

2009年7月11日

     摘要: 在日常生活中,有各种各样的法律规则和道德准则来约束、指导行为。比如在初次的商业合作中,双方都会选择制定一份详尽的合约来规约双方,包括双方拥有的具体权利、以及单方出错时对方享有的权利等。软件开发,在商业上面也必然会有详尽的合约,处理的是两个组织之间的利害关系。但是,软件开发同时作为紧密involve商业客户与开发团队的活动,正如Alistair Cockburn把它比喻称为game——由客户、管理层和开发人员共同play的game,其中也需要由参与play game的各方利害人来共同制定规则,让大家都能玩得开心、尽兴,甚至长久。这样,围绕着多赢长赢的出发点来play game,就同样需要这样一份“权利法案”,对开发过程中的三方利益利害人的权利做出基本的原则上的规定。在敏捷软件开发方法中,特别是极限编程中,就存在这样一份“权利法案”。  阅读全文

posted @ 2009-07-11 17:37 mingj 阅读(3611) | 评论 (0)编辑 收藏

2009年7月6日

     摘要: 由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商 ThoughtWorks共同主办的敏捷中国技术大会(Agile China 2009),将于9月11日~12日(周五、周六)在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管 理人员等参加。本次大会将特别邀请敏捷宣言缔造者、敏捷编程(XP)方法学创始人Kent Beck,敏捷开发权威人士、敏捷宣言的创始人之一,Dave Thomas,敏捷宣言签署人之一Steve Freeman等国际敏捷领域专家,以及在团队中成功应用敏捷的阿尔卡特、赛门铁克、诺基亚-西门子、华为、腾讯等公司的项目负责人参与此次大会并分享他 们的心得。  阅读全文

posted @ 2009-07-06 19:57 mingj 阅读(2712) | 评论 (0)编辑 收藏

2009年6月28日

     摘要: 上周末参加openparty,来自译言的几个朋友详细解释了他们预想的译言的收费模式。简单来说,译言会出面买下一些文章或书刊的版权,签约译者进行申领翻译。当译文通过审核,译言就把原文以及译文打包作为收费文章挂在译言收费频道上,按点击率来收费;或者转卖给其他网站,也可以按整文收费。最后,原文作者、译文作者和译言三方来分取利润。如果受好评足够高,译言还可能将译文提供出版,不再仅仅局限在网络上面,而是进入广大的书店。本文着重谈谈译言的出版计划,试图分析在这个时代,谁更有可能脱颖而出,引领行业浪潮?  阅读全文

posted @ 2009-06-28 11:12 mingj 阅读(3694) | 评论 (3)编辑 收藏

2009年6月18日

     摘要: 在很多人看来,实施了敏捷,似乎就等于纵容程序员,允许他们不把纪律放在眼里。事实是这样子么?本文发表于《程序员》杂志2009年6期,因篇幅较长,故分为两段,本篇为下篇。  阅读全文

posted @ 2009-06-18 09:42 mingj 阅读(3747) | 评论 (1)编辑 收藏

     摘要: 在很多人看来,实施了敏捷,似乎就等于纵容程序员,允许他们不把纪律放在眼里。事实是这样子么?本文发表于《程序员》杂志2009年6期,因篇幅较长,故分为两段,本篇为上篇。  阅读全文

posted @ 2009-06-18 09:40 mingj 阅读(3959) | 评论 (0)编辑 收藏

2009年6月14日

     摘要: 行业日新月异,敏捷、迭代式和迭代这些热门词已是“飞入寻常百姓家”,一个定义模糊的新角色——迭代经理,也浮出水面。这是新一代的项目经理么?抑或是美其名的团队带头人?又或者是管理上的一个新阶层?谁会被冠以这个“经理”头衔?本文将着重阐述迭代经理作为软件团队成员的工作内容和价值。我们将分析迭代经理的职责范围,同时讨论作为一个不可或缺的角色,迭代经理在面对组织和文化挑战的情况下,如何维持一个健康的工作环境。本文是全文的下部分。  阅读全文

posted @ 2009-06-14 15:45 mingj 阅读(3550) | 评论 (0)编辑 收藏

2009年6月13日

     摘要: 行业日新月异,敏捷、迭代式和迭代这些热门词已是“飞入寻常百姓家”,一个定义模糊的新角色——迭代经理,也浮出水面。这是新一代的项目经理么?抑或是美其名的团队带头人?又或者是管理上的一个新阶层?谁会被冠以这个“经理”头衔?本文将着重阐述迭代经理作为软件团队成员的工作内容和价值。我们将分析迭代经理的职责范围,同时讨论作为一个不可或缺的角色,迭代经理在面对组织和文化挑战的情况下,如何维持一个健康的工作环境。本文是全文的中部分。  阅读全文

posted @ 2009-06-13 16:31 mingj 阅读(3586) | 评论 (0)编辑 收藏

     摘要: 行业日新月异,敏捷、迭代式和迭代这些热门词已是“飞入寻常百姓家”,一个定义模糊的新角色——迭代经理,也浮出水面。这是新一代的项目经理么?抑或是美其名的团队带头人?又或者是管理上的一个新阶层?谁会被冠以这个“经理”头衔?本文将着重阐述迭代经理作为软件团队成员的工作内容和价值。我们将分析迭代经理的职责范围,同时讨论作为一个不可或缺的角色,迭代经理在面对组织和文化挑战的情况下,如何维持一个健康的工作环境。本文是全文的上部分。  阅读全文

posted @ 2009-06-13 12:21 mingj 阅读(3338) | 评论 (2)编辑 收藏

2009年5月22日

     摘要: 我们曾举办了一次为期三天的敏捷培训,学员主要是一些知名软件公司的项目经理和资深开发人员。培训期间,我们带领学员进行了丰富的游戏,通过寓教于乐的方式让他们体验了敏捷方法学的大部分知名实践,并讲解了敏捷方法学推崇的价值和原则。从学员的回顾以及意见表上可以看出培训效果是显著的,但是在培训过程中学员也提到一些问题,主要是对敏捷方法学的实践和价值比较疑惑。在回答问题的同时,我们能感觉到随着敏捷方法学在国内被引入、被宣传,很多软件组织或人员对敏捷方法学都已经有了基本的了解,但是对敏捷方法学向软件行业承诺的价值还存在不同程度的顾虑。  阅读全文

posted @ 2009-05-22 20:19 mingj 阅读(3933) | 评论 (2)编辑 收藏

2009年5月16日

     摘要: 对于软件开发,多少代工程师梦想能像堆积木一样堆出满足功能需求的软件。Brooks在No Silver Bullet一文中提到解决软件开发过程中复杂性的一种可能方案就是成熟的组件市场,人们可以购买需要的组件而不是再自行开发。但对于开发工作,有没有一种更高层面的模式,可以把原来混乱无序的开发过程分解成一段段明确定义的步骤?比如说,开发人员接到一个任务,他可以这样跟他的同伴解释他的计划:“我先要抽取类(extract class),然后移动方法(move method),就完成了。”这正是本文试图讨论的主题:通过一系列明确定义的重构步骤,以达到实现系统功能的目的。我们可以进一步假想,重构是否就是开发人员开发软件的领域专属语言呢(refactoring as DSLs to developers' development)  阅读全文

posted @ 2009-05-16 15:15 mingj 阅读(3685) | 评论 (3)编辑 收藏