向你的软件开发员传授什么内容？

向你的软件开发员传授什么内容？

来自：zdnet.com.cn

大多数机构都没有正式的软件开发员学徒计划。软件开发没有熟手之说。但是，今天，许多软件开发者通过与其他开发员交流所学到的知识，与他们通过正规教育获得的知识一样多。

　　如果你的开发者通过在你们机构所取得的经验学会如何做一名软件开发员，你将向他们传授什么内容呢？是时候评估一下软件开发员在你们机构所学习的内容了。

　　教育的需要

　　我们这个行业还在遭受项目失败，它的成本过高、顾客满意度低，总体上是萎靡不振。大家公布的软件开发项目失败率相差很大，最低只有5%，而最高则达到70%以上。尽管这两个数字都不是十分可信，但说明了一个事实：就是说问题依然存在。如果软件开发总是制作出高质量的软件，所有这些数字都会处于同一范围内。

　　然而，失败的事实并不能指明失败的原因所在。的确，造成项目失败的原因很多。而且，那些处在软件开发前沿的开发员对那些造成的原因都十分了解。

　　缺乏需求收集、项目管理不善、变更控制差、工具选择不正确等情况都是典型的软件开发问题。我们也知道这些问题会导致项目失败；然而，虽然我们意识到这一点，大家还是不断地犯同样的错误。

　　人们认为“技术熟练水平”与“行业发展水平”之间的差距是造成这一情况的原因。“技术熟练水平”是一种理想状况，这时每个人都了解与软件开发有关的一切知识。对于各种方法论、工具及技术来说，这无疑是一种理想的理解状态。另一方面，“行业发展水平”指的是软件开发从业人员拥有的平均知识。尽管没有一个平均的人，但你可以制造这样一个角色来识别传统的软件开发人员。

　　如今，典型的（一般的）开发者都有机会应用整合开发环境（IDE）与源版本控制。这两点很重要，因为它们是高效代码管理的基础。但是，传统的软件开发者最多只了解两种软件开发方法。因此他们无法确定某种软件开发方法的优点所在。

　　同样，传统的软件开发者也没有应用式样的经历。式样是描述普通问题常用解决方法的基本解决方案。尽管许多开发人员听说过式样（通常是工厂式样），但他们并不了解式样及其作用。

　　使用的测试方法也很随意。一些开发人员进行单元测试，其他开发人员则采取“踢足球”的方法，依靠别的开发人员、质检员及终端用户来找出漏洞。

　　出于用户的请求，或是自己的兴趣驱使，典型的软件开发员不断变更代码，却没有进行变更控制。变更控制的缺乏，结合其它一些改变，引起连锁反应，造成项目失败。这并不是他们有意造成的，主要是因为他们并不完全理解这些微小改变的影响。

　　如何学习

　　在动身去购买软件开发最新书籍与经典作品之前，请暂停一下。通过阅读使软件开发人员达到相对的“技术熟练水平”是不大现实的。在阅读之后不立即进行实践，很多人是无法完全掌握他们所学的内容的。

　　回想一下你所阅读的每一篇文章。你能够贯彻每篇文章中提出的建议或指导方针吗？当然不能！你无法消化你阅读的所有内容。我们没有那样的能力。我们每个人理解、结合阅读材料的能力都不一样，在这方面没有人是全能的。

　　实践学习是最佳的学习方式。也就是说，只有实践所学习的内容，才能达到最佳学习效果。阅读当然不错，但我们越专注，记忆的效果就越好。

　　我在上面提到“技术熟练水平”时称其为一种理想状态。由于人类是通过实践来学习的，所以这是一种没有人能够达到的状态。期望一个人拥有能够理解软件开发各方面最佳方法的经验，是不切实际的想法。例如，网络开发注重多重叠代与视觉外观；然而由于更新内嵌软件比较困难，内嵌软件开发看重质量与可靠性；这两者的最佳方法完全不同。

　　但是，我们并未失去一切。我们可以鼓励专注阅读、进行特定领域开发，并在团队的其它成员之间分享所获得的知识，从而使大家接近“技术熟练水平”。

　　允许队员个体在整个团队中集中并补充学习内容，这是体验教学积极的一面。正是这种方法帮助团队接近“技术熟练水平”。但是，许多机构却养成并强化了一些坏习惯，无意间让开发人员远离“技术熟练水平”。

　　双重恶果

　　在许多机构都有一些基本的进程。有一些需求收集进程。有一些代表性的设计阶段。一些人，特别是那些应用过通用进程（UP）、Rational统一进程（RUP）或其它灵巧的方法的人可能知道这些进程的别名，如启发与调查。尽管它们的持续时间较短，它们有助于了解问题，建立解决方案构架，达到了同样的根本目的。

　　许多机构都有某种形式的文本材料。可能是一个“项目章程”----例如执行赞助人的电子邮件、请求数据库或是一些其它形式的信息资料库。不管它有多大，它一定会存在。

　　问题在于，许多机构省略了进程中的这些步骤，跳过了文本材料，直接进入开发过程。凭直觉，这可不是个好主意。大量证据表明，“编码并修复”方法（如果可以这样叫的话）效果不大。但是，时间紧迫时，我们就省略了为启发与调查所保留的时间。

　　这对项目开发人员有什么启示呢？他们会认为这些做法对软件开发不重要（用Fred Brook的话说，无关紧要）。再也没有比这更为荒谬的了。但是，事实就是这样。很明显，即使时间紧迫，这些步骤与相关的文本材料也不能忽略。

　　忽略这些行为可能产生的后果，还会产生另一种恶果。开发人员开始认为：他们所做的一些工作（启发与调查）实际上只是组织为使他们忙碌而增加的工作负担，而不会把它看作是成功软件开发项目的一种技巧。

　　家里有一个四岁大的孩子，我痛苦地意识到为某件要重复的事，我必须做（或说）多少遍。这坚定了我的决心，即启发、调查或文本材料工作绝不能省略或缩减。我知道，这些行为即使忽略几次，就意味着以后必须进行长期的再培训。（如果你有孩子，想想他们在爷爷奶奶家呆上几天会是什么样子。）

　　这并不是说启发工作一定要进行三个月的繁重文本处理。但是，尽可能全面地理解当前叠代或阶段的所有需求还是实际可能的，也是必须要达成的目标。即使解决方案的主要部分已经完成，你也不应放松，对于运作与当前叠代，这都是必需的条件。在启发工作完成以后，前面的路并不明朗。

　　落伍

　　部分由于缺乏培训时间，需要更多的经验；更让人痛苦的是由于我们让开发人员误以为进程的一些阶段（不管你同意用什么方法）无关紧要，因而不会影响项目的成功，致使许多软件开发人员落后于“技术熟练水平”。保护进程执行的最低要求，对继续支持软件开发者的职业发展尤为重要。