导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:966498
  •  

2007-7-17 13:19 | 现代软件管理原则

1.将过程建立在架构优先方法的基础上:这要求在交付资源进行全面开发前,就在需求,架构,生命周期计划上做好权衡。
 
2.建立一个能够尽早的应对风险的迭代式生命周期模型:对于今天高度复杂的软件系统,完全按照瀑布模型进行开发是不可能的,因此需要使用迭代过程,通过多次迭代来完善对问题的分析和理解,得出有效的解决方案和计划。
 
3.设计方法向强调基于构件的开发转变:从代码行至上转变为基于构件开发的思想,是减少人工生成代码行数和减少定制开发的必要过程。构件是一个已存在代码行的内聚集合。
 
4.建立一个变更管理环境:迭代式开发的动态特性,可观的需要控制的基线。
 
5.通过支持双向工程的工具增强变更的自由度。
 
6.用严格的,基于模型的符号标记设计工件。严格和符号和正规的语言为可视化建模提供了更客观的方法。
 
7.为过程配备工具进行客观的质量控制以及进度评估。必须在过程中集成工作产品的进度评估和所有中间产品的质量评估。
 
8.使用DEMO对中间产品进行评估
 
9.建立一个具有可伸缩性的配置管理过程。
编辑 | 阅读全文(843) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 传统软件工程原理

1.把质量放在第一位:必须对软件质量进行量化,并采取措施促进质量的保障
常用的量化指标有缺陷泄露率,缺陷密度,COPQ,COGQ和COQ
软件项目质量包含了可用性,可测试性,健壮性,性能,易用性和友好性,可维护性等多项内容应该制定不同的量化指标
 
2.高质量的软件是可能的
评审,原型,客户参与,测试,迭代开发,雇用优秀人员已经证明可以很好提高软件质量
 
3.尽早的向客户交付产品:无论在需求阶段理解客户的需求有多难,确定用户真正需求的最有效的方式就是尽可能早的交给他们一个产品让他们使用。
这个是现代过程框架的一个重要原则。原型法,增量迭代,客户参与验证等已经被认为是成功的方法
 
4.在编写需求前确定问题:当面对一个被认为是问题的问题时候,多数工程师都急于给出一个解决方案。当试图解决一个问题的时候,要保证已经试验过了其它的选择,不要被轻而易举的解决方案所迷惑。
解决方案在逐步细化的过程中,问题的参数也会变得越来越容易掌握。现代工程框架直到充分理解问题,足以提交整个产品时候,才会将问题和解决方案一起归档。
 
5.评价设计可选方案:当需求达成一致后,你必须验证多种架构和算法。你肯定不想在需求说明书中使用了一个"构架"就真的使用这个构架。
现在软件过程中设计可选方案的分析过程是和需求规格说明同时进行的,而且需求和架构的产出物是明确分开的。需求有专门的需求规格说明书,而架构有相关的4+1View的架构文档。
 
6.使用合适的过程模型:项目必须要根据自己的项目特征来选择项目的过程模型,这些特征包括项目规模,周期,人员情况,需求可变性,文化,风险,应用领域等。
 
7.在不同的阶段使用不同的语言:
 
8.尽可能缩小理解上的差距:尽可能缩小理解上的差距,软……
编辑 | 阅读全文(1244) | 回复(0),人月&神话 发表于 2007-7-17 13:19
首先我们看下过程和流程的区别,我的理解是流程更多的仅仅是告诉要要按照什么样的步骤和顺序做事情,流程不是以目标驱动的。而过程最主要是目标驱动的,我们为了实现某个目标,通过我们的经验总结处理来的做事情的方式和方法,这里不仅仅是顺序和步骤,更多的会包括推荐的方法,工具,技术等相关内容在里面。另外流程不可能进行自我发现和改进,而过程可以进行持续改进。
 
而过程是怎么形成的?我认为更多的就是总结我们的经验,教训,方法和工具,将我们的这些非量化的存在于我们头脑里面的信息固化出来,因为只有这样固化出来会进行量化的分析,才可能进行不断的改进,另外固化出来的好处还有更好的被他人学习和借鉴。
 
所以我们谈过程做好的最大体现就是项目不依赖于单纯的个人,而是依赖于整个过程或团队,相关的知识和经验都已经固化下来了,如果能够达到CMMI五级的话,我的理解是项目和团队完全是高度自适应和自我循环的。遇到问题不可怕,最重要的是在这种自适应的团队里面所有问题都可以快速的分析,解决和改进。而这些如果仅仅依靠我们单个人的经验是很难做的到的。
 
让我们分析下软件项目中经验和过程的两个例子
 
1.风险
在没有风险管理过程时候,个人能力突出项目经理可以很好保证项目成功,而能力一般项目经理可能会导致项目的延期。突出项目经理时刻都在考虑我项目可能存在哪些问题,我开发人员水平怎样,需要不需要培训。我如何保证我的需求不做大的变动而影响到我后续设计开发;我可能需要定期和项目成员沟通和交流,让团队成员有成就感和责任心;而这些恰恰都是我们风险管理的内容,能力突出项目经理把这些内容都装在自己脑子里面,所以更多仅仅是依赖个人经验和思维。而当我们把这些东西提升到风险管理过程的高度的时候,这些都浮出水面,过程会指导你拟制项目计划的时候要考虑项目的风险,对关键的风险……
编辑 | 阅读全文(1285) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 看球有感


1.团队不能搞个人英雄主义,团队需要核心但不能个个都是核心,核心最好是一两个重要的成员,其它成员围绕核心开展工作;个个能力都强的人组建的团队绝对不是最强的团队。像巴西败给法国,既有其偶然性也有其必然性,巴西核心和英雄太多反而是没有核心;而法国对齐达内是觉得的核心,大家围绕着核心而凝聚为一个高战斗力的团队。
 
2.始终记住目标是第一追求的东西,所有的活动都是为了实现目标而进行。而对于软件项目最大的一个目标就是客户满意,东软2000年就提出了软件创造客户价值的核心价值观,充分体现了这点。所以及时你过程,规范遵守的再好,再完美,如果不能实现这个目标那就只能说本末倒置。像捷克队,虽然给大家贡献了赏心悦目的比赛,毫无功利足球的影子,观众得到了欣赏的满足但捷克人却早早的打道回府。
 
3.时刻认清楚自己的位置来制定战术和策略,像加纳队一上来就和巴西打对攻,还搞造越位战术,结果早早的丢球,而让巴西打起防守反击来,基本就没有任何胜算了。
 
4.个人属于团队,团队的目标也是个人的终极目标,这两者应该是高度一致的。因此个人绝对不可以由于自我的一时之块而损坏了团队的利益,如年少的鲁尼被罚下就是个很好的例子,这样破坏了整个团队的利益,同时也破坏了自我的个人利益。
 
5.高手对决比的不是谁进攻多,而是谁犯的错误少,因为你致命的一个错误可能就会导致整个局势的变化,将主动权拱手让给对方,最终输掉整个比赛。
编辑 | 阅读全文(1066) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 关于软件架构

今天借了《构件中国》这本书,是普元的几个牛人写的,看了一点还是有点启发。现在我们一直在谈软件工厂,而基于构件开发正式迈向软件工厂最重要的一步。工厂的两个重要特征一个是配置,一个就是组装。根据用户的不同需求组装出不同的产品,而其中最重要的就是构件。
 
构件是绝对高内聚的,通过接口提供服务。构件开发的一个重点就是软件的架构设计,不管我们是谈RUP还是MDA,都强调架构设计在软件开发中的重要性。因此摘录一些该书关于软件架构的一些陈述。
 
Ivar Jacobson 在 AOSD一书中的描述
 
架构无疑是非常重要的,什么是架构?如果问五个不同的人可能会得到五个不同的答案。架构和许多词汇一样是无法正式触及的东西,其感觉就像过程,项目,用例,构件一样。当谈及架构时候,我们将讨论如何理解架构描述。因此架构是架构描述的语义,它包含了关于系统的主要决策,例如:系统元素是如何组织的?系统如何实现所需要的功能?系统如何满足预期的性能,可靠性和其他的质量属性?系统需要什么技术?系统内部的组织结构能否弹性的相应功能,技术,平台的变化?是否有标准能够保证系统开发始终一致?例如使用了什么设计模式?使用了什么异常处理原则。
 
Martin Flower在《企业应用架构模式》一书中的描述
 
软件业的人乐于做这样一些事情-找一些词汇,并把他们引申到大量微妙而又互相矛盾的含义。一个最大的受害者就是架构这个词。我个人对架构的感觉是它是一个另人印象深刻的词,主要用来表述一些重要的东西,很多人试图给架构下定义,而这些定义本身却很难统一。能够统一的内容有两点:一点是最高层次的系统分解;另一点是系统中不易改变的决定。Ralph Johnson认为架构是一种主观的东西,是专家级项目开发人员对系统设计的一些共享的理解。
&……
编辑 | 阅读全文(1146) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 与熊共舞读书笔记(2)

1.风险的不确定性要进行量化,可以通过风险图来直观的进行量化。风险图可以清楚的看出不确定性的范围。如果不确定性的范围比较小的化,大家都容易接受;不确定性的范围太大会使你焦虑不安。这里一般需要将项目进度的不确定性范围控制在总体项目周期的10-15%以内。
 
2.当项目出现偏离的时候很少是因为计划内的工作耗费了比预期长的时间,更多的原因是不在计划中的工作使项目陷入了泥潭。在估计必须完成的任务时候,大多数项目经理做了足够的工作,但是在估计可能必须完成的任务时候,他们付出的努力少得可怜。请牢记住:昨天得问题就是今天得风险,今天得风险不识别出来就是明天问题。
 
3.风险值等于风险得概率乘以风险得后果。对风险暴露度得估计并不是一门精确得科学。对发生概率最好得估计来源于业界历史得数据,从前得问题清单,风险库或干脆就是凭空猜想。风险储备是预留出来得缓解风险得时间和金钱,风险储备值应该以风险暴露度为依据。保守得策略是分配超过风险保留得风险储备,而带进攻性得策略是分配略少于总暴露值得储备。
 
4.蒙特卡洛是风险定量分析得很好得方法,通过该方法还可以对组合风险进行模拟。见IT项目组合风险分析:http://blog.sina.com.cn/u/493a8455010004kj
 
5.软件项目共通得五大风险
  进度安排的先天错误 (必须要重视估算和提高估算准确性)
  需求蔓延或需求变更过多 (定义可以承受的需求范围偏离)
  人员流失
  规约崩溃
  低生产率
 
6.克服风险发现的障碍,由于一些不成文的规定,大多数人对项目风险三缄其口。这些规定是(问题在于不能很好区别敢于承担责任的人和只会发牢骚的人)
  不要成……
编辑 | 阅读全文(1280) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 永远的回忆

编辑 | 阅读全文(907) | 回复(0),人月&神话 发表于 2007-7-17 13:19
软件的智能和记忆功能
1.用户登录界面最好有用户名和ID的记忆,焦点直接定位到密码输入框
2.单据录入界面最好有保存和载入默认值的功能
3.单据搜索界面可以保存用户自定义的各种搜索条件组合
4.用户调整过的GRID的列宽,窗口的位置可以自动记忆
5.系统可以根据用户的使用频度对相关功能进行自动的优先级排序
6.系统能够记忆不同用户的使用偏好,使用系统的固有模式和常用的自定义设置
 
减少不必要的重复交互
1.减少不必要的各种操作,能够点一次鼠标或敲一次键盘完成的绝不作出两次或多次。
2.提示信息要适度,太多不好,太少也不好。
3.数据项完整性校验问题要注意光标焦点自动定位到错误处
4.完整业务功能不要让用户在多个窗口切换多次才能够完成。尽量减少这种切换。
5.为了方便用户切换窗口,相关的表单最好都作为非模式的形式。
6.相同的信息不要让用户在系统中多处或多次录入,保证入口的唯一性
7.系统要尽可能根据用户已经录入信息自动获取其它附属信息,而不需要用户重复的选择或录入。
 
导航和界面跳转
1.表单新弹出对话框,对话框再弹出对话框的这种层次要控制在3层以内。
2.所有的非模式活动窗口最好有类似桌面任务栏一样的停靠方式,方便切换窗口
3.系统可以支持用户自己定义常用功能和菜单
4.对于常用功能应该提供便捷的快捷键和工具栏按钮
5.对于系统中提供的各种业务和表单功能能够让用户便捷挑转到帮助信息上
6.对表单和界面联动和交互的时候要注意相关界面数据的自动刷新
7.一个窗口中最多不要出现超过三个的GRID控件
8.BS方式不要左右滚屏。CS模式既要避免左右滚屏也要避免上下滚屏
9.需要根据业务查看需求和数据的展现需求来选择合适的界面控件
 
系统性能和健壮性方面的
1.……
编辑 | 阅读全文(931) | 回复(1),人月&神话 发表于 2007-7-17 13:19
同行评审是CMMI的VER过程域的一种重要手段,同行评审提倡事前发现问题并解决问题,防治缺陷的泄露。当企业在实施同行评审的过程中往往并不能达到很好的效果。出现COPQ值偏高,而COGQ值偏低的不合理情况。
 
毫无疑问,同行评审做好了肯定可以起到很好的作用,而如果没有起到很好作用说明同行评审没有真正做好。而无法真正做好同行评审也有很多实际原因在里面。
 
1.计划的安排上,项目经理往往对评审的工作量估算不足,评审包含了工件的预审,评审,异常录入,意见修改等多个步骤,一个有效的预审至少需要投入1天的工作量。以需求工件为例,有效的评审效率一般为3-5页/小时。只有在这个效率下才可能真正的发现工件中的重大问题,如性能瓶颈,控制逻辑错误,架构弱点和可靠性等问题。
 
2.通过挤压评审时间到设计开发中是一种不自信的表现,项目经理或成员任务提前一周拿出一个BUG特多的运行版本也不愿意延迟一周拿出一个高质量的版本。而提前一周的代价往往需要返工三周或更长时间,而延迟一周拿出的产品往往仅仅需要返工一周,这就是我们说的COPQ和COGQ出现比例错位的问题。
 
3.参加同行评审人员,特别是涉及到新开发系统的总体业务模型和架构方面的评审时候,评审成员必须是这方面的专家,因为只有专家才可能从自己多年历史经验总结中造成工件的潜在严重质量问题。所以一般评审人员发现的10个缺陷往往比不上专家发现的一个缺陷,一般人员发现的10个缺陷后期返工修复时间远小于专家发现的缺陷的后期返工修复时间。如果仅仅把评审停留在表面的检查上,那效果显然是有限的。
 
4.实践是检验真理的唯一标准,没有通过实践仅仅凭经验,即使是专家也很难给出是否正确的结论。因此很多深层次的工件或系统的问题完全靠同行评审是无法解决的,只有通过原型,试验,……
编辑 | 阅读全文(1633) | 回复(0),人月&神话 发表于 2007-7-17 13:19
熟练人员经过多年的积累加上自己的CodeSnip的总结,基本不用额外再查找资料。而一般的开发人员在开发过程中会花掉10-20%时间去查找资料。
 
熟练人员注意代码复用,并且时刻注意重构和抽取公用代码。一般开发人员是代码拷来拷去完成功能。
 
熟练人员非常注意查找,定位,标签等各种快捷键的使用,定位查找方便快捷,IDE环境也根据习惯定义到最方便状态。
 
熟练人员编码前先思考清楚整个流程,在头脑或纸张上规划好整个实现方式和方法函数的划分。一般人员想到哪里写到哪里。
 
熟练人员写了50行以上或更多代码才Debug一两次,一般人员写了几行代码就要Debug多次,完全通过Debug来验证代码正确性。
 
熟练人员注重代码的质量,单元测试和可维护性,注重各种业务逻辑的验证和边界条件的校验。一般人员只注重简单功能的简单完成。
 
熟练人员提交测试的代码BUG很少,返工工作量很小。一般开发人员由于自测不完善BUG较多,造成大量的返工工作量。
 
熟练人员合理分配自己的时间,规划好每天工作任务,开发过程各位专注。一般开发人员一心多用,边开发边聊Q。
 
熟练人员善于知识的总结和积累,形成自我的知识库和经验库。
 
熟练人员善于发现问题,分析不足而自我持续改进。一般人员在外力干预侠被动改进。
 
熟练开发人员开发重点已经专业到对业务的深刻理解,一般开发人员考虑的是开发上编程的语言和工具。
 
熟练人员善于从各种影响自己开发效率的因素中挤时间,善于使用各种辅助开发工具。而一般人员则不善于这种总结。
 
编辑 | 阅读全文(1046) | 回复(0),人月&神话 发表于 2007-7-17 13:19
IT项目的度量,跟踪控制都是很重要的,但更重要的是对收集的数据进行有效的分析,然后及时的采取纠正偏离的行动。而我们的行动和应对措施必须是针对问题根源的,必须要分析到问题的本质和内因。所有数据分析一般需要通过多个指标来共同分析,充分考虑到数据的相关性,同时在分析的过程中不断的对得到的结论进行验证,保证分析到了问题的根源。然后再根据问题的根源来采取纠正行动和应对措施。
 
现在仅仅对系统测试比预计的测试时间长导致整个项目进度延后进行分析(这里假设需求和实现阶段的进度都和预计一致)
 
这里用思维导图进行分析如下:
 
 
分析完成后你可能发现引起测试进度延迟的真正原因在项目经理自己,可能由于你压缩了需求和设计的工期,而导致了后期大量返工,导致了评审没有有效进行而缺陷大量泄漏。导致开发为了在规定实际完成任务根本不可能仔细做自测和单元测试。进度本身不合理性到测试阶段才发现出来的话,项目经理已经回天乏术了。
 
其它还有很多可能和问题根源,或许为了避免下个版本的测试进度延迟,你仅仅是和你的一个需求人员一起吃了顿饭,沟通了感情而解决问题。
编辑 | 阅读全文(1878) | 回复(0),人月&神话 发表于 2007-7-17 13:19
软件的质量属性
鲁棒 - Solid and Robust Code
简洁 - Maintainable and Simple Code
高效 - Fast Code
简短 - Small Code
共享 - Re-usable Code
可测试 - Testable Code
可移植 - Portable Code
 
集百家之长, 归我所用 - Follow Basic Coding Style
1.代码能够清晰的表达你的思路
2.代码应该具备自解释能力,注释代码别是单纯解释语句,这种注释毫无意义
3.编码的缩进和排版规范
4.所有的函数和变量应有他人容易理解的名字
5.将Tab键改用为4个空格字符
6.减少单个函数的长度,控制在50-100行以内
7.避免幻数,多使用枚举和常量的定义
 
取个好名字 - Use Naming Conventions
1.采用匈牙利命名法对变量进行命名
2.名字要清晰表达含义,不要怕长
 
凌波微步, 未必摔跤 - Evil goto’s? Maybe Not…
1.goto的使用应该遵循原则,而不是全盘否定
2.不用写高深晦涩的语句,不要一味追求性能忽视代码可读性
3.模式并不是一味正确,特定问题更需要考虑反模式
 
先发制人, 后发制于人- Practice Defensive Coding
1.尽量保持代码的简洁和简单
2.调用其它接口和函数时候首先对返回值进行检查
3.避免有符号/无符号,32位/16位,被零除等误算情况
 
见招拆招, 滴水不漏 - Handle The Error Cases: They Will Occur!
1.通过异常处理机制来保证程序代码的健壮性
2.异常处理中一定要注意……
编辑 | 阅读全文(955) | 回复(0),人月&神话 发表于 2007-7-17 13:19
在雁群的飞行过程中,会发现每只大雁在拍动翅膀的同时会本能的成人字形队列;同时位于队形后方的大雁会不断发出鸣叫声;如果发现受伤的同伴队群会自发的出现两只大雁脱离队形,靠近这只遇到困难的同伴,协助它降落在地面上,直至它能够重回群体,或是不幸死亡;领雁并非一只贯穿飞行始终,当领雁疲倦时,便会自动退到队伍之中,另一只大雁马上替补领头的位置。
 
从上述大雁飞行过程中所遵循的原则中,不难看出团队建设中的几点要素,这也恰是一些企业团队建设中所缺少的核心精神。
 
一、 共同目标
目标的一致性,是团队建设的基石。一个企业只有在其所有成员对所要达到的整体目标一致的肯定和充分的认同,才能为之付出努力、最终共同实现目标。而我们的企业尤其是小型企业,奋斗目标的不确定性往往是导致最终失败的主要原因之一。目标的不确定、方向感的缺失使企业高层与中层之间,中层与基层之间出现了严重的信息、沟通的断裂并由于引发了价值观的分歧,失败的计划、目标、团队建设由此而生。事实上每个人都必须忠诚于自己的团队,忠诚于自己的事业,做好自己的本职工作,为共同的目标不懈努力。如果你不拍翅膀,他不拍翅膀,这个团体还会存在吗?又如果大家都朝着不同的方向拍翅膀这个团体还会称之为团体吗?而个体间的生存空间和高度还会有多少?
 
二、 团队协作
协作的优劣,是团队建设的关键所在。在一个企业里,会以企业为单位、部门为单位、小组为单位,分别存在不同的大小团队。企业为这三个团队中的核心团队,而企业的整体利益必然也必须成为任何一个小团队的利益中心,所有的行动的指南。在现在的企业团队中以销售团队最为代表性,为了个人、小集体、区域、部门的部分私利而置整体大局而不顾,大到业界之间、企业之间,小到部门之间、同事之间相互倾覆、抢单、抢户、杀价,使整体销售业绩急剧下滑、产品含金量大打折扣、利润空……
编辑 | 阅读全文(3192) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 方法论的切入点

方法论是可以解决特定场景下的问题的一系列方法,过程,工具,技术的集合。而学习方法论往往更应该从小问题出发,学习相关步骤和其系统思维的方式。然而对于小问题我们往往一眼就看到了答案,而忽略按部就班的去使用方法论,去积极的锻炼自己的思维过程,或者是先想到了答案再根据结果再反推着具体的步骤和方法。这样导致我们遇到复杂的问题时候往往感到无从下手,因为这个时候缺乏的已经不是步骤的问题,更多的是缺乏系统的思维模式和实践。
 
当爬一个小山坡的时候,还没有爬可能就看到了顶点,看到了中间的亭子等重要里程碑,所以爬的时候也不会去考虑什么方法,也不用去思考也能够正确的爬到顶点。而当你爬一座高山的时候,顶点要不可及,或者连中途的里程碑点都无法看到,所以这个时候你爬的时候心里面没有底,也不知道自己是否偏离路线,也不知道按现在方式能否成功爬到山顶。可能到这个时候你才会真正意识到了在爬小山坡的时候没有注重这些步骤和技术的练习,所以你始终处于爬山的初级阶段。
 
当平时遇到简单问题解决起来得心应手,而一遇到复杂问题就感到无所适从的时候是否该反省和总结下相关的方法论。
 
当对于简单的系统或功能设计和开发起来游刃有余,而遇到复杂的系统却无法进行分析和设计的时候,是否该考虑下系统化进行分析和设计的思维方式和逻辑。
当遇到小问题的时候,如果能够考虑按照方法论或过程定义我应该如何解决,方法论为何推荐我们这样去思考的时候,或许这才是我们最需要的思维锻炼过程。
 

 
编辑 | 阅读全文(1461) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 读微软研发制胜策略(3)

 
学无止境
如果程序设计师只是完成份内的程序设计工作,那还不够好,一位讲求效率的管理者应该不断提高对属下的要求标准,就像花样滑冰选手的教练一样,当您提高了对组员程序设计功力的要求,也会带动整个公司的程序设计功力水平向上提升。
 
不要让程序设计师的学习停滞不前,要让程序设计师有机会磨练不同领域的技术,培养十八般武艺样样精通的组员。持续性的训练、培养是必要的投资,以后会带来不可限量的回馈。
训练新进程序设计师时,先培养他对整个公司所有项目都有价值的技术,然后才培养本项目独有的技术。
 
不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学,为了公司和他个人的前途,您应该把他推荐到别的项目,让他的成长永不间断。
 
确定每位组员、每两个月都有一项技术上进步。空闲时候阅读相关的技术书籍是巩固和完善自己知识体系的重要手段。学习的结果最好是一个可以量化和评估的目标,这样才能够更好的检验学习的效果。
 
绝对不要让组员一直做同样的工作,这样是限制了他的学习,使他停滞在原来的领域。一旦程序设计师精通了某一个领域,就让他换别的领域做做看,永远让他们学习新的技术。
 
态度问题
是的,撰写“零错误”程序的确需要下功夫,而程序设计师大都不愿下这些功夫,除非程序设计师有正确的态度:没有任何理由,有错虫就是不行。
 
纠正程序设计师以为增加异常处理和错误提示花太多时间的观念,应该训练程序设计师第一个反应是考虑加上这些是否有道理,第二是考虑加异常处理是否符合项目的目标与工作的优先级。
 
项目主管应该乐于……
编辑 | 阅读全文(1081) | 回复(0),人月&神话 发表于 2007-7-17 13:19
(共 973 条) 1 2 ... 21 22 23 24 25 ... 64 65 翻页至

仅列出标题