最近我遇到一个问题!软件开发思想是什么?很迷茫、不懂!需要大家帮我解惑一下

解决方案 »

  1.   

    转:
    对我过去感兴趣的朋友们,请看十年总结系列文章 
    --- 
    正式回到原来公司就职后,开发这边的管理团队形成了一个三足鼎立的局面, 
    田田,十几年工作经验,不怎么懂具体技术,负责纯管理,以及协调开发与市场, 
    乐乐,8-10年工作经验,03下半年,他牵头做了一个2.0版本的框架,java c/s架构,年底要移民澳洲, 
    我和乐乐各带了几个开发人员一起主持开发工作。 虽然多头领导并不是一件好事儿,但对我来讲并不是一件坏事儿, 
    因为来北京这几年,开发方面都是以我为主,很多时候我也不知道自己的决定是不是对, 
    我相信大家都有这种感受,自己做出的决策,虽然内心相信是正确的,但还是希望通过其它途径得到证实, 
    这就是常说的“他山之石,可以攻玉”,“外来的和尚会念经”。 
    我现在觉得,需要别人来证明自己的时候,正是自己还不成熟的时候,不过从青涩变得成熟,不都要经历这个阶段嘛! 04年,我的课程学分拿的差不多了,因为专业是软件工程,所以课程包括:过程改进、软件度量、算法设计、面向对象设计等等, 
    我当时的感觉就像一个熟读了武功秘籍的人,迫切的希望通过修炼来印证功法所说的种种妙用, 
    田田和乐乐都比我有经验,我自然乐得好好学习。 我有几年的软件开发经验,也切身体会到不少的问题,我也经常思考如何更合理的组织开发, 
    我的目标有些理想化,在我看来: 
    1、管理应该实现“无为而治”,也就是说管理者的精力应该不在管,而在于看,看结果,看未来 
    2、软件开发过程应该是可视、可控的。 
    3、软件开发的结果是可预期的。 我所学的各种管理课程都信誓旦旦的保证,规范的流程可以满足我的要求(除了第一条), 
    所以当乐乐提出开发团队要采用RUP的时候,我积极响应,表示大力支持。 
    于是,我们剪裁文档、安装Rational Rose、招聘测试人员和配置管理人员,制定版本管理规范等等。 
    我也在这一时期,阅读了《人月神话》、《IT项目管理》、《UML》等很多相关书籍。 然而,问题很快就出现了。 在小公司,我们虽然是产品研发团队,但我们无法做到和项目的完全隔离,我们发布出去的版本还不能稳定的像Window,office一样out of the box, 
    在流程的作用下,实施人员开始抱怨对问题的响应太慢(因为大家都习惯了有问题直接找开发,而现在我们要评审、修改文档然后改代码发布), 
    用户的“紧急”需求被我们安排到下一版本,但市场通过老板来改变我们的版本发布计划,插入更加急迫的需求。 由于规范的实施,导致开发与实施+市场产生了一定的对立(我不清楚这是我们公司的特例还是普遍情况), 
    因为中国公司的客户总是很急,市场压力很大,于是每隔一段时间,当矛盾激化的时候,田田就召集我们和负责市场和实施的人开会, 
    讨论的结果往往是如下几种: 
    1、这个问题,需进一步“优化流程”,还是寄希望流程解决问题。 
    2、我们开发力量不够,需要继续加人(但公司的实力是有限的啊) 
    3、实施方面保证目前面临的是一个特殊情况,开发方面暂时妥协,尽快解决问题(一个项目总有足够多的“特殊”理由) 
    3、要么没有结论,保持问题依旧(实际上是实施方面妥协) 在一次次的摩擦中,虽然乐乐一直坚定不移的倡导他的“RUP”,并将很多问题归结为“流程不够优化”和“人员不足”时, 
    我却在疑惑和反思。 
    在一家小公司,什么样的开发过程才是合理的? 
    产品化之路在小公司行的通吗? 
    RUP实施的越彻底,所带来的管理消耗越大,到底有多少小公司可以承受? 正当我为此郁闷不已的时候,听到了“XP”一词。 
    那是04年第一学期结束的时候,回学校给导师汇报毕业论文的计划, 
    她提到最近参加一次国际会议,会上有人讲解国外方兴未艾的软件开发思路:极限编程(eXtreme Programming,简称XP)。 
    老师描绘的由XP带来的快速交付能力和代码质量的巨大提升,让我觉得心动不已,但又将信将疑。 回家后,我立刻上网搜索相关信息,阅读XP的最佳实践, 
    从XP又找到了敏捷建模、敏捷思想,并熟知了一些大师们的名字。 
    这些先进的思想,当时给我的感觉就是“天上掉下个林妹妹,似一朵轻云刚出岫”,让人眼前一亮, 
    我隐约觉得我所追寻的东西,就蕴含在这些大师们的思想之中。 经过初步分析,我觉得XP对开发团队来讲过于激进,而“敏捷”这个宗旨是比较有现实价值的, 
    于是毫不犹豫的买下了大师们写的几本书,包括: 
    《敏捷建模》,《测试驱动开发》等。 以最快的速度看完这些书后(要知道,解决问题式的学习和无目标的纯学习那是太不一样了), 
    我在一次团队会议上提出尝试让开发团队变得“敏捷一点”的想法。 
    在我介绍了XP以及敏捷的核心思路后,乐乐表示不相信这样做会有效,而田田则不置可否,认为需要证实, 
    于是,我建议讲相关资料分发给大家去学习,然后再开会讨论此事。 大家经过学习后(我其实很怀疑有些开发人员是不是真的在意过这些事情),只有军军这个小伙子表现出跟我一样的兴趣, 
    在后来安排的会议上,我就像诸葛亮舌战群儒一样,跟大家辩论敏捷和RUP哪个更适合我们。 
    经过辛苦的辩论(这可比我论文答辩辛苦多了),我们终于达成一致,在开发团队试行“敏捷”的开发方式。 真正实施起来,敏捷建模或者XP编程远没有想象的那么简单,以我的经验来看,敏捷的成败取决于如下几点: 
    1、成员对这种思想的认知和认同 
    2、对参与者的水平普遍要求较高 
    3、要防止XP演变成自由主义 我们团队中试行的“敏捷”虽然没有达到老外们“宣称”的效果,但在改善代码质量,提升团队的响应速度方面,有比较明显的作用, 
    因此,在以后的日子里,RUP也慢慢不再被人提及。 
    以后几年里,我经历了几家有CMM资质的公司,但发现一个现象,那就是“资质是公司的,而不是团队的”, 
    也就是说,虽然公司过了认证,但团队在做开发的时候,风格更多的取决于团队的领导。 
    我在实际的软件项目管理过程中逐渐形成了如下信念: 
    1、无法执行的规定还不如没有规定。 
    2、代码质量应该在一切可能的情况下成为开发人员的第一目标。 而我从关注方法过渡到关注结果(代码质量),是04年下半年的事情。 --- 我并不否认RUP的伟大意义,但以我目前的经验来看,不是每家公司都适合,至少以项目为本的公司,不适合。 
    然而敏捷或者XP也有较高的实施门槛,所以,实施起来也并不容易。 
    但对于个人来讲,提升自己提交物(无论是代码还是文档)的质量,是经营个人品牌的重要举措。 以前也讨论过读不读研的问题。学校的课程不是没有价值,但如果不考虑学历文凭,我们不上学一样可以学到, 
    但有一点,学校是一个思想交汇的地方,借助你的导师和同学,能够发现一些有价值的知识或者机会,这一点自己不容易成就。 
    就像我接触到XP一样。 在工作中,不要让流程或者制度成为推卸责任的借口。 我觉得刚开始接触XP的时候,其思想比现在要极端的多(也许是我当年的感觉比较极端),而今天我看到RUP for XP之类的字眼,实在感觉有些哭笑不得, 以RUP为代表的“工程化”软件开发管理思想,很重要的一个思路就是拿软件开发和建筑开发做比较,希望能够像盖房子一样来做软件。 
    但盖房子和做软件最大的差异在于,软件质量的度量比建筑质量的度量要复杂太多。 
    传统软件工程思想是希望稳定需求,通过关注过程而保证结果, 
    而以XP为代表的敏捷阵营,关注的是参与开发的人,以及提交物的质量,强调沟通、协作,主张拥抱变化。 
    我个人觉得,这两者真的蛮难融合的。 
    很多人说我写的慢,每篇写的太少。 
    呵呵,没办法啊,我有我的家庭,我有我的工作, 
    写点东西,都是在业余时间中抽时间,我的每一篇文章,通常都要花2-3个晚上,大家没法发现我经常凌晨发贴子吗? 
    我要回忆,我要有取舍,我还要注意行文的流畅,最重要的,我还要从中思考与总结。 
    我也不可能把所有的精力都来写这一个系列,我还得随时捕捉思想中的灵感,因为我目前的人生课题是“思考”。 这不是在写小说,各位担待啊。 
      

  2.   

    推荐一本书  <think in java>
      

  3.   

    [Quote=引用 14 楼 yefengmeander 的回复:]
    引用 1 楼 xyz20003 的回复:软件开发思想就是:“用最小的代价,开发出最好的产品,卖最多的钱。”支持
      

  4.   

    这种问题属于laymen问题,不是科学问题
      

  5.   

    这个分很多种!搞FLASH游戏的人家也叫软件开发,搞单片机的也叫软件开发,有点乱!
      

  6.   

    http://topic.csdn.net/u/20100322/16/56f713c2-806d-4e8c-a597-f0ea05c773b7.html