关于架构设计和项目管理的讨论

原创 2005年02月28日 09:58:00
这是某日和朋友通过即时通信方式进行的关于项目管理的讨论。

我将该讨论重新看了一遍,发觉我说的比较多,听的比较少:)。一般我不是这样的。主要我对于朋友所在的公司(开发习惯,程序员的水平,deadline如何设定等等)比较熟悉,非常担心这个项目是否能够成功,所以就拼命地劝说朋友采用一些回避风险的办法。

由于在这个讨论中的目的是以说服为主,所以很多概念叙述的不一定精确完整。这个项目大概有4个人参加,用c++开发手机平台上的应用程序,估计大概需要半年时间,应该算是一个小项目。


以下是讨论全文:

我: 你的项目怎么样了?
友: 进行中
友: 下个星期详细设计开始
友: 还没有开始写代码
我: 你让他们加断言,他们加了吗?
我: 那么还没有开始编码罗
友: 当然要他们加的
我: 大家都同意了吗?
友: 我说了算阿
友: 我是头
我: 呵呵,要心服口服最好了
友: 嗯
友: 我会让他们明白的
友: 你怎么样,
我: 比较轻松,最近在写gui,用wxpyhon
友: 呵呵,高手就是高手
我: 一天写个10行左右吧
我: 靠,这还叫高手
友: 呵呵。。。。
友: 微软也不过每天10行
友: 这个就是微软的水平了
我: 得了吧,微软比我们厉害多了
我: 我们这叫低效率
友: 嗯
友: 我最近在看《设计模式》
我: 不错嘛
友: 学习学习阿
我: 你计划谁来把握程序的架构呢?
友: 现在要学习这方面的 
友: 我看下来我这里没有这个方面的人才
友: 现在只有靠我自己来架构了
我: 那么谁呢?
友: 没有
友: 我自己了
友: 项目的规模不是很大,我自己可以试试看
我: 没有人第一次架构都能做好的,你身兼项目管理和架构比较麻烦。
我: 架构在后期是被人埋怨的主要目标
友: 是啊,我现在是身兼数职。。。
友: 我现在就是我想了以后找下面的人商讨,看看这个构架是不是合理
友: 然后定下来。。。
我: 最好委派两个人做架构,你有最后否决权
我: 你来指导
友: 我现在手下没有特别突出的人
友: 只能是这样了
我: 名义上委派也可以,不要把责任都自己抗
我: 要用委员会的形式来设计架构
友: 嗯~~~
友: 明白了
友: 这个方面我会好好的分配一下
我: 架构这个东西就是很难做好,但是人人都想做的东西,我认为从主管的角度来说,可以把架构设计看作一种报酬,而不把它看成一种工作。
我: 从报酬的角度来讲,人人有份是最得人心得。又因为很难做好(因为风险太大),所以人人有份可以降低风险
友: 有道理
友: 再多说点这方面的知识
我: 不要划分模块,而要以讨论会得形式又大家来决定模块和接口。
友: 嗯
友: 我基本上是这么做的
我: 因为接口改变(或者说架构改变)是很累人得,也很得罪人。所以由大家决定,要怪也只能怪大家。
友: 只不过是我先提出来一个模块,在进行大家讨论
我: 还是由别人提出模块,你再修改比较好。
友: 问题是我这里没有其他的人可以做这个事情了
我: 最好让人接受了你得意见,还认为是自己得意见。
友: 嗯~~~~
友: 有道理
我: 形式是很重要得,否则别人难免会有想法。
我: 最好没有痕迹的让别人认为架构是自己做的。
友: 是啊。如果软件开发过程中,一些不必要的想法不存在会节省很多的人力
我: 必要的时候可以妥协,放弃自己好的设计,用别人差的设计。关键是要大家一致。
友: 嗯
我: 我的理解,从管理的角度,可以认为架构设计的过程的目的是搞定人心的,而不是技术上追求完美。
友: 帅哥,这个话太酷了
我: 我可是认真的啊
友: 昨天我刚看到这样一句话:
友: 构架就像政治一样,是处理各种不确定因素的艺术
友: 看到你说的话,我就想到了上面这句话
友: 我也是很认真的
我: 如果让大家自由讨论架构设计,一定会有不统一的意见。只要你善于搞平衡,多恭维大家,多妥协,多哲衷。最后就是大家很开心,也达到了一致。至于架构本身的质量也不会太差的。
友: 有道理~~~~
我: 哈,我和他的意思很接近嘛。我的意思是把架构设计变成搞政治
我: 关键是你自己要置身事外。
友: 你也是大师阿
友: 嗯
我: 肉麻
友: 8-)
我: 委派别人搞架构(或者说接口),人越多越好。就怕你图后来图省事,不能坚持委员会的形式。
友: 嗯
友: 有时候我觉得是为了统一,我会用我的权力来规定
我: 基本原则就是接口要简单和少。你可以让他们搞出接口来,你再砍掉一半的接口。
我: 你最好作为仲裁人体现权威。
友: 嗯
我: 就是大家争论不下了,你让大家各让一半,互相妥协。
友: 这样可能会使大家都伤士气的
我: 自己作为争论的一方搅进去会很累的
我: 表面上没有争论不一定就是没有士气啊
我: 实际上士气完全取决于大家对你的看法
我: 有不同当面说出来总比埋再心底好。
友: 有道理
我:  表面上没有争论不一定就是有士气啊
友: 嗯
友: 我完全赞同
我: 实际上做仲裁很简单的,连脑子都不用动,就是让大家各让一半
我: 互相妥协嘛
友: 我觉得管理者最重要的事情就是让大家有干劲
我: 对啊
友: 其次才是项目
我: 这样对项目也是最有利的
我: 因为项目是高风险,所以要使用讨论+妥协的办法。
友: 嗯
友: 项目的讨论是非常必要的
我: 不到万不得已,不要发表自己的意见
友: 嗯
我: 最好永远不发表
友: 这个不是这样的,你不发表,你就没有权威了
友: 我觉得妥协,就是发表。。。
我: 对,
我: 我的意思是有时候要放弃自己正确的意见
我: 就是为了妥协。
友: 妥协也是一种另类的一种表达你的能力,证明自己在项目当中的位置。
我: 我的意思是力排众议这种事情最好避免
友: 嗯。。。
我: 而应该反过来做。
友: 明白。。。
我: 你抓抓质量控制就可以了。
友: 嗯
我: 质量控制你可以看《测试驱动开发》
友: 好,一定看
我: 以测试来驱动开发的质量
我: 你只要抓住测试这个环节就可以了。
友: 嗯,这个我完全明白
我: 这本书讲了一个很重要的道理,就是测试是开发的命脉。
我: 重要到测试应该比开发还要优先。例如,先写测试代码,再写开发代码。
友: 测试是开发的命脉?可惜我现在对测试的了解太少了
友: 看样子我该马上看这本书了
我: 不是单元测试,是一种基于断言的自动测试(比断言要高级一点的技术)
友: 哦~~~~~~~~
友: 《测试驱动开发》是谁写的
我: 大家进行设计的时候你要把关,尽可能使用结构化的设计,不要使用面向对象的技术。kent beck
友: 嗯
我: 尽可能少地使用继承,多态
友: 这个我知道
友: 嗯
我: 访问数据要通过函数,不要直接访问,做到这样就可以了
我: 其余的自由发挥
友: 这些都是封装性不好的表现
我: 对
友: 我不过限制个性的发挥
友: 我希望他们在一定的基础上,自由的发挥
我: 嗯,主要是考虑到大家的c++水平,
我: 多态,继承用的不好很容易写出难改的代码的
我: 这是c++容易出错的地方。
友: C++水平是我最担心的一个问题
友: 我这里只有一个C++程序员
我: 没什么好担心的,把C++当成结构化的C,质量肯定是有保证的
友: 好
友: 我明白了。。。
我: 到编码开始的时候你应该把精力放到开发过程的自动化方面。
友: 这个是什么意思
友: 没有明白
我: 现在开发不是都有ide的嘛?
我: 这实际上不利于多人合作。
友: 是的
友: 嗯
我: 你可以通过脚本(dos下的bat文件可以),命令行编译器,makefile,将构建和部署的过程完全自动化。也就是说,只要点一次鼠标就可以把构建和部署完成。
我: 我的意思就是每日构建了。
友: 哦~~~~~
友: 有点高深
我: 这比写代码简单的多了。
友: 我在这个方面没有什么研究哎
我: 只要会写dos bat文件就行了。
友: 哦
我: 比如说,你的应用程序要使用两个dll,一个exe。
我: 现在有三个人开发
友: 嗯
我: 打开visual studio
我: 编辑,再按build按钮。
友: 对
我: 最后再把这些东西拷贝到一处,打包,对吗?
友: 嗯
我: 现在就是要求你完全不使用任何带gui界面的程序,写一个简单的脚本程序。双击这个脚本程序,就把所有的事情都做了(包括打包)
友: 明白了
我: 这是业界流行的管理技术,我们这都是这么做的。
友: 好技术阿
友: 明白了
友: 深受启发
我: 意思就是你不要陷到开发过程衷去,假设你是个编程白痴,连visual studio也不知道,该怎么管理呢
我: 点击鼠标一次总会吧
友: 呵呵
友: 会
我: 这个技术很有用的,不需要编程基础,实际上具体脚本编写也可以委托别人来做。你只要提要求就可以了。
友: 嗯
我: 关键就是你得站在管理者得角度
我: 假设自己什么都不懂,但是要有最简单轻松得办法进行质量控制。
友: 站在管理者的角度...
我: 所以你就要尽可能剔除过程中人得因素。
友: 俄
我: 我指的是人的负面因素,所以要自动化。每天得工作就是点且只点鼠标一次就可以了。
我: 你每天得工作就是点鼠标一次。
友: 嗯。。。。。。。
友: 要做到上面的过程,看上去很简单
友: 实现起来恐怕就很难了
我: 对啊,到后期你的管理工作就是点鼠标呗。
我: 怎么会难呢
我: 就是先做什么后做什么
我: 得一个单方向得脚本,连if得逻辑都用不到
我: 比vb都简单。
友: 这个是在前期的开发工作基础上实现的呀
友: 前期的开发工作的质量监控比较难
我: 所以从开发得第一天就开始集成啊
我: 这是自然而然结论啊
友: 这个就是每日构建阿
我: 根本没有系统集成这种大得阶段
我: 从第一天就开始系统集成了。
我: 呵呵
友: 有点懂了
我: 你要假设自己是编程白痴啊
我: 你会的唯一得管理工作就是点鼠标
友: 看样子在要好好的实践实践
我: 难道前期你能放弃管理吗?
友: 不能
友: 绝对不能
我: 所以从编码得第一天就开始系统集成。
友: 嗯~~~~~~
我: 如果办不到就让他们想办法啊。否则就是你放弃管理(因为你只会点鼠标)
友: 大受触动

Unity项目架构设计与开发管理

1.EmptyGO 2.Simple GameManager 3.Manager of Managers 4.MVCS(StrageloC) 5.MVVM(uFrame) ………. 1.E...

Unity项目架构设计与开发管理观看总结

Architectures(主流架构) EmptyGO Simple GameManager Manager of Managers MVCS(StrageloC) MVVM(uFrame) ...

Samurai-Native架构设计与项目构建

  • 2017年12月01日 09:21
  • 2.98MB
  • 下载

项目架构设计

  • 2008年04月16日 21:03
  • 827KB
  • 下载

项目管理师-系统分析师-系统架构师的区别

本人原先对这两个概念也不怎么清楚,后来到网上专门收集了一下 整理如下,方便各位考友! 当软件规模比较小时,系统分析师所完成的工作是把真正的业务需求(这个需求不是指客户简单所说的哪一个功能,而是需要去挖...

企业网络架构设计实训项目

  • 2009年09月10日 04:38
  • 2.89MB
  • 下载

敏捷项目管理(摘录)——敏捷流程架构

楚凡科技(www.trufun.net)   10年间致力于做中国最专业的软件工程解决方案提供商   规范软件开发过程  优化软件开发流程 保证软件开发质量  提高软件开发效率 ...

程序大会-架构设计与存储管理

  • 2013年12月06日 23:57
  • 7.42MB
  • 下载

项目管理师-系统分析师-系统架构师的区别

本人原先对这两个概念也不怎么清楚,后来到网上专门收集了一下 整理如下,方便各位考友! 当软件规模比较小时,系统分析师所完成的工作是把真正的业务需求(这个需求不是指客户简单所说的哪一个功能,而是需要去挖...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:关于架构设计和项目管理的讨论
举报原因:
原因补充:

(最多只允许输入30个字)