- 浏览: 1152561 次
- 性别:
- 来自: 火星郊区
博客专栏
-
OSGi
浏览量:0
文章分类
- 全部博客 (695)
- 项目管理 (48)
- OSGi (122)
- java (79)
- Vaadin (5)
- RAP (47)
- mysql (40)
- Maven (22)
- SVN (8)
- 孔雀鱼 (10)
- hibernate (9)
- spring (10)
- css (3)
- 年审 (6)
- ant (1)
- jdbc (3)
- FusionCharts (2)
- struts (4)
- 决策分析 (2)
- 生活 (10)
- 架构设计 (5)
- 破解 (2)
- 狼文化 (4)
- JVM (14)
- J2EE (1)
- 应用服务器 (1)
- 我的链接 (5)
- 数学 (2)
- 报表 (1)
- 百科 (6)
- Flex (7)
- log4j (2)
- PHP (1)
- 系统 (2)
- Web前端 (7)
- linux (6)
- Office (1)
- 安全管理 (5)
- python (2)
- dom4j (1)
- 工作流 (3)
- 养生保健 (4)
- Eclipse (8)
- 监控开发 (1)
- 设计 (3)
- CAS (1)
- ZK (41)
- BluePrint (3)
- 工具 (1)
- SWT (7)
- google (2)
- NIO (1)
- 企业文化 (2)
- Windoes (0)
- RCP (7)
- JavaScript (10)
- UML (1)
- 产品经理 (2)
- Velocity (10)
- C (1)
- 单元测试 (1)
- 设计模式 (2)
- 系统分析师 (2)
- 架构 (4)
- 面试 (2)
- 代码走查 (1)
- MongoDB (1)
- 企业流程优化 (1)
- 模式 (1)
- EJB (1)
- Jetty (1)
- Git (13)
- IPV6 (1)
- JQuery (8)
- SSH (1)
- mybatis (10)
- SiteMesh (2)
- JSTL (1)
- veloctiy (1)
- Spring MVC (1)
- struts2 (3)
- Servlet (1)
- 权限管理 (1)
- Java Mina (1)
- java 系统信息 (6)
- OSGi 基础 (3)
- html (1)
- spring--security (6)
- HTML5 (1)
- java爬虫搜索 (1)
- mvc (3)
最新评论
-
Tom.X:
http://osgia.com/
将web容器置于OSGi框架下进行web应用的开发 -
chenyuguxing:
你好, 为什么我的bundle export到felix工程中 ...
在Apache Felix中运行bundle -
string2020:
<niceManifest>true</ni ...
Bundle Plugin for Maven -
jsonmong:
OSGI,是未来的主流,目前已相当成熟。应用OSGI比较好的, ...
基于OSGi的声明式服务 -
zyhui98:
貌似是翻译过来的,有很少人在linux上做开发吧
如何成为“10倍效率”开发者
trong> 英文原文:Technical Debt a Perspective for Managers
作者:Mark Levison 译者:赖勤毅 发布于 2010年11月5日
现在已经到第十次迭代开发周期了,你的项目开发速度开始变慢。在之前的几个迭代周期中,团队没有像以前那样完成很多的“故事场景”(stories)。此 外,最近在新的故事场景和回溯中却发现更多缺陷(bug)。项目经理知道,团队成员没有变,他们也花同样的时间工作。但是,客户会发问:“发生什么事情 了?这个团队还在努力工作吗?”
很多敏捷团队的产品改进率为150-500%,可是你们的项目看起来却貌似只有20-40%左右的改进率。这到底是怎么回事呢?在此我们找不到什么大问 题;相反,只是有无数的小问题。有时,这些只是一些为了方便而使用的捷径(开发人员没有时间去清理这些修改),有时开发人员仅仅是不熟悉这中语言。还有一 些问题就是,代码跟灌木丛一样凌乱,需要大幅度的修整。所有这些都属于“技术债务”。
什么是“技术债务”?
它就是“那些内在的事物,现在你不去解决,遗留下来(不干完),它就会阻碍未来开发”[Ward Cunningham ]。 表面上,应用程序看起来质量很高且状况良好,但是这些问题却隐藏在下面。 QA(质量保证部门)甚至可能告诉你说,这个应用程序真是不错,几乎找不到缺陷,但是其中仍然存在“技术债务”,如果我们没有很好地管理并设法降低这些 “技术债务”,那么,程序编写和维护的代价最终将会超过它对客户的价值。
技术债务就像信用卡一样,会有很高的利息率,就如同给团队留下了大量的帐务开销。这种情况下,开销将会体现在时间花费和解决问题所需的努力上面。开发团队拖延债务的时间越长,所积累的利息就越多(会额外增加很多工作),付出的成本也就越高。
另外,这还增加了实际的财务支出:开发团队处理技术债务所花费的时间,可以用在对团队有价值的其它工作上。同时,这些难读的代码引起的技术债务也让我们难以找到软件的缺陷。再且,理解代码所损失的时间还可以用来做其它更有价值的事情呢。
我们为何要累积技术债务呢?
项目编码初期,不整理代码,不写单元测试,也不做测试驱动开发,整个团队粗制滥造出更多的“故事场景”。 这些问题通常都不会马上暴露出来,而循规蹈矩地编写代码往往需要更多的时间,特别是在早期阶段。
技术债务来自哪里?
- 没有经验的开发人员 —— 有些项目里面,编写Java/C#/Ruby的开发人员没有接受过培训,或者没有面向对象的观念。结果呢,他们会一直编写适用于他们曾经习惯的编程语言——像Visual Basic等——的代码。
- 项目工期的压力 —— 那些来自于经理或客户的显性压力和其它一些潜在的压力。“我们承诺在以后迭代(发布)的故事场景中做到这些”。开发团队会发现他们不会交付这些承诺的发行 版本(迭代版本),而是采取便捷的手段。“我们不得不把事情做完;我们无法承担修整代码所耗费的时间。如果这不是新特性/缺陷,那么就不用去做”。 不幸的是,这些观点还会得到管理人员的支持,特别是在管理层没有意识到这些成本的时候。
- 凌乱而难读的代码。当一个方法或类中存在一些难读的代码,下一个开发人员继续这些工作的时候,就觉得他也没有必要迫使自己编写清晰的代码。所以,每次有人接手这些代码的时候,一小段脏乱的代码将会变成一大堆乱七八糟的代码。
- 专业领域的代码 —— 往往有这样的观念:这些代码看起来就是很差劲,但是这不属于我的领域,所以我不能或不会改变它们。另外,对于修改专业领域的代码,开发人员也会觉得力不从心。
- 过度复杂 —— 开发人员经常趋向于在需求之前设计解决方案。而且,很多情况下他们的代码没有找到正确的方向,还会写一些没有用处的代码。或者,这些代码没有真正地符合需 求,因为代码在问题还没有完全明白的时候就已经写完了。还有另外一种情况,过度设计花费了额外的时间,产生的代码不是不能使用就是不符合项目的需求。
- 糟糕的设计 —— 有些解决方案只是设计不佳。但在设计不好的代码上面继续扩展,而不去解决这个问题,会使问题更加恶化。
解决问题
这个问题的并不是一下子可以解决的,解决方案需要通过几个迭代周期。并且,你需要耐心,并要从多个角度寻找解决途径。
解决方案中的要点
- 让开发人员接受语言方面的基本培训并教授他们面向对象的原理,从而把他们的理解力提升至入门阶段。要想既成功又有效的话,这需要花几个礼拜的时间培训,还需要有精通这方面的人员来跟进和支持这一系列培训。
- 告诉开发人员和管理人员,当前的这些问题都是需要花费企业资金的。这点尤其重要,因为它会使解决这些问题的意义更加明确。你要清楚地告诉他 们,管理人员会重视这些问题,并且已经开始着手偿还这些技术债务了。不断支持这些工作使之成为常规的原则之一,这样整个团队就会信任这个准则。
- 提供一些培训,包括代码的坏味道,重构,单元测试和测试驱动开发等。还可以结合课堂会议,基于网络的材料和书籍来进行培训。
- 在工作的时候,给他们一些空余时间去研究和练习他们的技能(一个礼拜两个小时应该是达成这个目标的最小的时间量)。练习的代码应该被丢弃,这 样,他们就能无拘无束地尝试和试验一些事情,不管怎么样,他们不用在基础代码库上面进行练习。花点时间练习和研究应该是最有用的建议了。假如没有为他们提 供空闲的时间,就压根不会发现真正合理的敏捷开发方式。这种组织方式也被称为“道场”-Dojo(更加详细的资料可以参考 TDD Randori Session 和 TDD Randori Workshop )。
- 使用工具(静态分析,单元测试,持续集成,自动化可接受性测试)来帮助团队发现、减少和衡量他们的技术债务量。应该在团队层面利用这些度量数 据,而不能分享给管理人员。团队成员需要知道,他们并不会因为对这些技术债务的度量而接受奖励或者遭受惩罚。如果我们把这些度量数据报告给管理层,并由管 理层来追踪的话,开发人员很快会找到一些窍门来规避它们,这样就失去了本来应有的价值了。
- 当人们完成了他们的培训或者在技术上取得了少许提升时,应该得到奖励。奖励可以是给予一次认可的表彰或者是一些小小的礼物,但不要直接给予现金奖励。
- 每两个礼拜进行一次午餐聚会和一些关于技术方面的学习型会议。利用这些会议来促进开发成员之间的讨论。提供午餐可以提高参会人数。另外比较重要的是需要管理人员每次都来出席,这样就很清楚的表明他们也一直支持大家提高技术。
- 维护关于技术债务的备忘录 – 任何时候,如果开发人员发现一些无法立即应付的技术债务时,就需要填写一份技术债务登记卡。开发人员应该优先考虑这些技术债务,并花费10-15%的精力来偿还这些技术债务。大多数项目中,任何的一些小事都会使问题变得更加严重。
基于这样的立场,你会发现问题,也会拥有机会。你的问题是:项目的基础代码一直在积累技术债务,但是这些债务已经开始下降了。然而,现在跟客户申请用于处 理这些问题的资金会跟处理这些问题一样困难。你的机遇是:提高了开发人员的技能;清楚地表达了管理层对这项工作的支持,还有,软件的代码质量会不断改善, 软件缺陷的数目也会不断减少。同时这也会很好的提高团队的整体开发能力。
发表评论
-
原来公司需要这样的你
2012-10-18 14:22 1029转自:http://512zw.iteye.com/blo ... -
如何做一个优秀的领导者
2012-07-14 19:21 929TeamLeader是比较尴尬的角 ... -
软件开发过程文档如何写作?——“文档==鸡肋”?
2012-03-29 08:42 969“鸡肋——食之无味, ... -
软件工程过程名称
2012-03-28 14:06 1169AN...需求分析 英文(_A ... -
如何编写优质的需求文档
2012-03-28 08:20 867研发计划。对于最终的产品,需求文档扮演着开发者行为和消费者行为 ... -
项目管理
2012-03-20 16:50 1026部门有位同事(姑且称为小A),工作时间内积极性相对还是蛮高 ... -
【开源项目】
2012-03-08 14:15 1809metamorphosis 简称Meta,一个高性能、高可 ... -
软件项目经理新手上路5 - 头痛医头,脚痛医脚
2012-01-16 08:27 1171项目总有各种各样的 ... -
软件项目经理新手上路4 - 老好人
2012-01-16 08:23 1108老好人式的项目经理并不少见。他们人很好,希望让每一方满意。 ... -
软件项目经理新手上路3 - 这不是份简单的工作
2012-01-16 08:19 1105绝大多数开发人员的职业目标都是成为项目经理。项目经理的工作看 ... -
软件项目经理新手上路2 - 力量从哪里来?
2012-01-13 08:10 1010技术冲突是技术出身的项目经理经常碰到的事情。一开始只是技术讨论 ... -
软件项目经理新手上路1 - 序
2012-01-13 08:09 1168软件项目经理,这是广大开发人员向往的职位。随便抓个开发人 ... -
解读敏捷3 - 解读敏捷实践之结对Review
2012-01-13 08:06 1032程序员A碰到了程序员B。“Scrum糟透了”程序员A说。 ... -
从电影《三傻大闹宝莱坞》看IT新手应如何学习?
2011-12-31 08:45 1046《三傻大闹宝莱坞》电视上又在放,又看了一遍,觉得很赞。很喜 ... -
技术人的最终出路
2011-12-27 08:46 1129虽然是希望这个论坛成为一个纯技术性论坛,但作为一名 ... -
如何成为“10倍效率”开发者
2011-12-26 08:22 1388Brad Feld的一篇文章The Rise of Devel ... -
项目-团队-技术-个人(提拔篇)
2011-12-23 08:54 959是团队,就需要领导。领导从哪里来呢?途径可以有多种: 1 ... -
项目-团队-技术-个人(专业篇)
2011-12-23 08:50 9791引言 今天,我的话题是“专业”。 这里的“专业”,指的不 ... -
从技术员到项目管理转型的体会
2011-12-19 11:23 1061一、与领导有效 ... -
技术人员出差携带物品自检表
2011-12-15 12:53 1182出差,又是出差。 做技术工作,出 ...
相关推荐
这三篇日记,从不同的角度和阶段,展现了研发经理在技术与管理之间寻求平衡的智慧和努力。通过这些日记的分享,我们不仅能够体会到一个研发经理在职业生涯中所面临的各种挑战,而且也能学习到如何在复杂多变的工作...
3. **财务可行性**:从投资者角度计算投资回报,评估财务盈利能力和债务偿还能力。 4. **组织可行性**:规划项目进度,设立组织结构,选派经验丰富的团队,确保项目顺利执行。 5. **经济可行性**:评估项目对资源...
盲目追求新技术,不考虑实际应用场景和长远影响,往往会带来技术债务,导致后期维护困难和资源浪费。因此,需要在深入研究的基础上,理性选择技术路线,确保技术的稳定性和可扩展性。 个人职业发展同样需要稳中求胜...
通过这一环节,审计组能够从员工的角度,了解经理在日常管理中的表现和影响。 财产清查和物资盈亏情况的审计,旨在确保企业资产的准确性和完整性。这包括固定资产、存货以及其他形式的资产。审计过程中,将对这些...
3. **用户故事与计划游戏**:用户故事是从客户角度描述功能需求的简短叙述。计划游戏是一种交互式规划方法,团队通过估算用户故事的工作量来确定迭代的工作内容。书中详述了如何编写和管理用户故事,以及如何有效地...
这表明从债权人的角度看,债务的保障水平下降,企业的短期偿债能力减弱,可能面临更高的财务风险。 报告的分析表明,尽管青岛海尔的营运资金表现较好,但流动比率的下降意味着其短期偿债能力可能在减弱。在评估企业...
9. **技术债务**:因快速开发而产生的未来需要付出额外努力的问题,如何管理和减少技术债务也是敏捷实践中的一项挑战。 10. **团队协作**:强调团队成员间的信任、共享责任和互相尊重,以促进高效协作。 通过阅读...
17. 收益质量分析:从现金流量表的角度,收益质量分析关注会计收益与现金净流量的关系,营运指数是重要的财务比率。 18. 中国特色的关联交易:资产重组中的关联交易在中国具有较高的实践频率,涉及关联方之间的资产...
从财务杠杆的角度来看,增加债务(债券)会提高财务杠杆,可能导致更高的财务风险,但如果预期的回报率超过债务成本,这可能是可行的。而发行股票(无论是普通股还是优先股),虽然不会立即增加财务风险,但可能增加...
8. **技术债务**:书中可能会讨论技术债务的概念,即为了短期利益而采取的捷径,长期来看会增加额外的工作负担。理解并管理技术债务是维持项目健康的关键。 9. **用户故事**:作为敏捷开发的需求表达方式,用户故事...
首先,从公司会计机构设置的角度看: 1. 公司治理结构中,董事长直接领导财会部经理可能违背了权力分离的原则,可能导致财务决策过于集中,不利于内部控制的实施。正确的流程应是董事会总经理通过总经济师(或总...
本文将从贷款及负债率的巧妙运作角度出发,深入探讨其对企业经营的影响,并结合具体案例进行分析。 #### 二、贷款的作用与意义 1. **缓解资金压力**:对于初创企业或处于发展阶段的企业来说,资金往往是最大的瓶颈...
- **挑战概述**:本书首先探讨了软件开发中面临的各种挑战,如代码质量、维护成本、技术债务等。 - **解决方案**:通过引入现代开发实践和技术来应对这些挑战,如持续集成、测试驱动开发(TDD)等。 ##### 2.2 深度...
首先,从权益管理的角度看,企业存在着委托代理问题,即管理层可能追求个人利益,如额外福利或工作懈怠。为解决这一问题,企业可以采取分红、股票回购、强化监控(如审计师与管理层的合作)以及激励性薪酬等方式。...
9. **技术债务**:敏捷开发强调避免技术债务,即为了短期速度牺牲长期维护性和质量。团队应定期清理代码,以保持代码库的健康状态。 10. **自组织团队**:敏捷团队鼓励自主决策和自我管理,团队成员共同负责项目的...
从股权结构来看,截至2008年6月30日,华能国际的总股本为123,834,400股,其中资股占比74.66%,外资股占比25.34%。中国华能集团通过其子公司持有部分股权,而华能国际电力开发公司和华能集团分别持有42.03%和8.75%的...