无我

让内心永远燃烧着伟大的光明的精神之火!
灵活的思考,严谨的实现
豪迈的气魄、顽强的意志和周全的思考

从编程到工程——系统地分析软件工程

       《大道至简》的第六章“从编程到工程”,我认为是全书的精髓!作者以自己深厚的积累、丰富的经验,用精炼的文笔深刻阐明了“软件工程”的内涵和外延,讲清楚了代码、方法、过程、工程与组织的关系! 非常值得我们深入学习和研究!

         本章所有内容都是围绕作者给出的一张图——EHM模型图,完全可以说,这张图充分显示了作者深厚的功底:
         
         既可以说这幅图展示了软件工程内涵的各个层面,也可以说这其实就是软件工程的发展史:从最早只追求程序实现到后来有完善的组织和管理。

         在本章的后面若干节内容中,作者分开描述EHM各个组成部分。我想下面这一段“方法”可能比较对技术人员的口味:
原文      推动这种逻辑向前发展的,是“方法”和“方法论”的出现。长期的编程实践,自然的归演与总结,必须沉淀为某种( 软件开发) 方法,于是“过程”出现了,于是“对象”出现了,于是相关的方法论也就出现了。 
      这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落,实践积累达到一定的程度,微软不提出某个方法,IBM 也会提出这个方法。即便他们都不提出,可能你自己已经在使用这个方法了。 
      方法并不神秘,因为它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法,而模式就是你昨天书写代码的那个行为。只不过,GoF 归纳、抽取、提升了这些行为的内在规律。 
      你看不到你做事的行为,也就不能理解“模式”作为一种方法的价值。所以大师们众口一词:模式需要一定的编程经验才能理解。 
      同理,理解过程也需要编程经验,理解对象也需要编程经验,理解MDA与SOA还是需要编程经验。 
      ——这可能就发生在你去回顾你上一行代码编写的经过,或者上一个项目失败的经历的那一瞬息。经验来源于回顾、理解与分析,而不是你将要写的下一行代码。 
 
      有人在寺院扫了一辈子的落叶而得道,也有人因为一句话而得道。 
      GoF 因为无数次的代码回顾而得道。 

         而这一段“组织”可能让项目经理比较感兴趣:
原文       工程理论其实是包含组织学的。然而我在上面的那张图中,将组织与工程分离开来,并在二者之间画下了一道纵向的线。 
               

      如果说工程关心的是“需求”、“配置”和“文档”等等这样一些要素,那么这样的工程还是停留在技术层面的:关注的还是工程的实现细节,而非目标。从角色的角度来看,这是项目经理和技术经理所共同关注的那一部分。 
      然而项目经理还必须关注于人力资源、项目资金以及多个项目之间的协调等等。这些与工程本身并没有直接关系,而是“组织”方面的内容。 
所以在工程环节中“文档管理”和“配置管理”等等中的那个词汇“管理”,是管理的具体技术和方法;而在“组织”这个环节中的这个“管理”,才是真正的管理学上的用词。 
      我在这张图上,试图从这个角度上来说明:作为项目经理,你必须有一部分的工作是非技术性的。甚至,你可能绝大部分的工作是非技术性的。——因为与技术相关的管理技能( 需求、配置、过程管理等) 可以由开发经理来做,或者公司对于这一方面有较统一且成熟的规范,因而无需投入过多的精力。 
      你必须更关注于对这个( 或这些) 工程的组织与计划。站在“组织者”这个角色上,你现在要考虑的内容可能会是: 
  1. 为项目的各个阶段建立计划,并逐渐地细化计划的内容,以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度; 
  2. 确立项目或者产品阶段目标,成果的准确描述、定位,以及整个项目的质量目标及其评核办法; 
  3. 对团队中的不同角色展开培训,以指导并协调角色间的工作,从而消除因为工作习惯的差异带来的影响; 
  4. 为每一个人准备他所需要的资源,这不单单是把一套shareware 变成正式版或者把512M 内存变成2G,还包括准确地评估他的工作量,以及决定是否为他增加一个( 能协同工作的) 副手; 
  5. 决定在哪些环节上反复审核和回顾,而在哪些环节上采用较为宽松的方式以加快进度; 
  6. 习惯于开会、组织更短而有效的会议以及建立激励机制,当然也不要忘记让每一个成员意识到这一项目的风险; 
  7. 不要乐观。 
      即使你做好这一切,可能项目的结果仍然不够理想。但是你应该知道,好的项目经理并不是不犯错误的人,而是以尽可能少的失败来获得成功的那个人。 
      无论是你的团队成员,还是你的老板,对重复的错误以及可预料的错误都是不会宽容的。——在一个团队中,失去了组员的信任比失去老板的信任更为可怕。 
      所以回顾每一个项目,或者项目中的每一个阶段,以及与每一个团队成员交流的细节,是你的日常工作。
      
         当然,了解一下BOSS的定位和主要职责也是很有帮助的:
原文      很多人以为BOSS 是给自己发钱的那个人,这其实是错误的。发钱的决策通常是由三个角色来做出的: 
  1. 部门/团队经理。你的直接上司,他是雇佣你的人,是他用薪金的多少来衡量你的价值,或者反之。 
  2. 纪效经理。如果你的公司有这个角色的话,那么他总是盯着你的错误以决定从你的薪水里的扣除比例。 
  3. 财务经理。有钱?没钱?没钱?有钱?…… 
      BOSS 并不决定你的薪水。 
 
      BOSS 在公司中解决的是“经营”问题。这其实是在比“组织”更靠外侧的一层。——在前面的图例中并没有给出,这也意味着“经营者”与“工程”基本没有关系。 
      在一个更大规模的组织机构里,你可以会更直接地观察到“经营者”与“组织者”之间的差异。例如公司的大小股东是“经营者”,董事会通常是解决经营问题的地方;而总经理、执行经理以及各个部门经理则是各级的“组织者”,经理办公会则是解决组织问题的地方。 
      你应该清楚,真正的BOSS是经营者。 
      这有助于你明确你被雇来的原因,你的工作是面向哪一个层面的,以及你或者你的上司有没有权限来决定是一个项目是否应该立项,或中止。 
      BOSS(经营者) 决定了一个方向,组织者保证决策与这个方向是同步的,而工程是在这样的一个方向、决策的构架下的一个具体行为。 
      工程中没有BOSS。

         从编程到工程,本文系统地分析了软件工程的方方面面。EHM给出的是完整的软件工程架构,不是一个小程序,也不是单独的过程。这是一套体系,在这套体系中,软件工程的所有参与人基本都能找到自己的位置,包括那个只是偶尔出现来指手画脚的BOSS。

         作为软件工程体系中的一个角色,找对自己的定位,明确自己的职责,对以后的工作无疑会有巨大的帮助。经常读读本文吧~

posted on 2013-07-16 17:01 Tim 阅读(264) 评论(0)  编辑 收藏 引用 所属分类: 品读《大道至简》


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


<2012年5月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

公告

本博客原创文章,欢迎转载和交流。不过请注明以下信息:
作者:TimWu
邮箱:timfly@yeah.net
来源:www.cppblog.com/Tim
感谢您对我的支持!

留言簿(9)

随笔分类(173)

IT

Life

搜索

积分与排名

最新随笔

最新评论

阅读排行榜