作者：LD系瑰精棂_142 | 来源：互联网 | 2023-05-18 04:55
在很多小系统的开发中，往往是三四个人直接面对客户，既作需求又作设计又编代码，这样开发出来的小系统一般都比较实用，但是可能不具备通用性，而且往往缺乏文档，一旦相关人员离开，留下的可能只有源代码，给后继的
在很多小系统的开发中，往往是三四个人直接面对客户，既作需求又作设计又编代码，这样开发出来的小系统一般都比较实用，但是可能不具备通用性，而且往往缺乏文档，一旦相关人员离开，留下的可能只有源代码，给后继的人造成很大的问题。
而为了改变这些情况，软件工程应运而生，将传统的工程的一些流程和思想贯彻到软件开发中。
但是由此也产生了很多问题，其中最主要的是由于程序开发本身所具有的一些特点，以及需求的不确定性（往往越是大项目需求越是容易频繁变更），造成无数软件无法按照预定计划完成，要么就是成本过高，要么就是半途中止。
个人觉得目前业界出现的XP、敏捷等方法则是把软件工程中一些不适合软件开发规律的去掉，但是这套方法也是在摸索中。
由此产生两种不同的对人员能力要求。
强设计＋弱开发 VS 强开发
根据个人的一些经验，我觉得即使对于大系统，也应该采取强开发人员的方式。
确切的说我比较赞成这样一种模式（和Xp很类似）：
这其中关键的人员是 用户代表、项目经理、需求分析人员、架构设计人员、详细设计与开发人员
第一阶段：需求调研阶段
1、主要参与人员：包括用户、需求分析人员、项目经理
2、项目经理拟定需求阶段计划
3、调研
4、给出业务需求文档，得到业务的详细描述和功能需求框架（可能只是部分）
同时必须给出质量属性（性能、安全性等非功能的要求）
第二阶段：架构设计阶段
主要参与人员：包括用户代表、项目经理、需求分析人员、架构设计人员
1、项目经理拟定架构设计计划
2、由架构设计人员根据本公司的技术体系架构及自身的开发经验，对应业务需求给定技术架构，并初步估计工作量。
3、如果有技术难点，应立刻列出，进行攻关，如果该难点对技术架构影响较大，则在未完成攻关之前不应进入下一阶段
4、此阶段结束后应把除功能以外的所有问题全部解决。
第三阶段：详细设计与开发阶段
主要参与人员：用户代表、项目经理、需求分析人员、架构设计人员、详细设计与开发人员
1、项目经理拟定开发阶段计划
2、开发队伍组建和培训
3、由开发人员进行详细设计，并直接面对用户（包括用户代表和最终用户）讨论，讨论时应有业务需求人员旁听，业务需求人员根据双方的讨论整理功能需求。需要时开发人员应准备各类Demo以说明自己的想法。
4、如果双方达成一致意见，则开发人员进入开发，并进行单元测试。
5、开发负责人应经常性的进行集成，并提交测试，以保持稳定版本。
如果人力较为充沛，则可以考虑采取pair programming的做法。
17 个解决方案
VS在哪里了？ 好像还有一半没有写完哦。呵呵，gz。
写得不错，不过真正的对比似乎是没有开始，鼓励你继续！
你的观点很像FFD 不过我建议在需求调研阶段就必须有技术人员的加入 它们可以在做需求的时候就大概的作出成本 技术基础等地评价 同时要注意需求分析人员往往只是对需求的合理性进行分析 而不是对需求的实现进行分析 这个问题大家都似乎不是很在意 但是这确实是2个不同的角色
同意楼上的。
而且，一个现实的问题是，需求调研阶段如果没有技术人员，做市场的人会把可能实现的东东全部答应下来，却不一定是必须的，然后就开始拼命对技术部门施压……
同意楼上两位：在需求调研阶段确实必须技术人员的参与。
另外，想听听您自己对二者VS的看法。
关注中。
无甚新意，感觉仍然没有解决目前软件开发项目中的诸多问题，比如说需求不确定性的问题也没有很好的解决方案，开发人员在详细设计阶段和用户讨论过程中来决定最后的需求，那么最后确定的一些需求可能会对整个系统的设计造成相当大的影响，系统概要设计需要重新调整，工作量也要重新估算，从而导致项目的进度要重新计划，这在目前国内的很多项目是无法做到的，国内的大部分项目是先签订合同，确定了交付日期后才开始开发的，上面的做法非常有可能在进度上延误。
包括现在很热门的XP我也认为没有很好地处理这个问题，XP适用于进度压力不大的项目，技术人员和用户可以反复地讨论需求，修改功能。
对于进度确定且时间紧迫的项目（国内项目大都如此），则有非常大的风险，即使客户对进度延期没有意见，开发公司也有非常大的可能成本超支。
接下来讲一讲重点，主要是第三阶段的人员要求。
这一部分的任务主要是详细设计、代码，而其中的详细设计还负担着细化需求的任务。
一种是强设计人员＋弱开发人员，就是开发人员完全跟着设计走，设计说作什么，开发人员就做什么，也就是所谓的“程序工人”；
一种是强开发人员，也就是开发人员兼做设计（也可以倒过来说成，设计人员兼做开发）。
第一种情况:
在需求明确的情况下比较合适
1、整体人力成本较为低廉，因为所需要的设计人员相对较少，开发人员相对较多
2、不会有太多的迭代和反复
3、比较容易控制进度
但在需求不明确的情况下这个就没什么合算的了，往往是看起来都做了，但是项目就是结不掉，计划一变再变。
而且这一种情况对于程序工人的要求是很奇怪的：熟悉编程语言，但是没有自己的想法。非常不符合我们国家目前的情况，老实说熟悉编程的程序员没多少会安于这种职位的。
这本来就不是技术性分析，只是另一种抄袭。这种研究方法，别人提出软件工程规则，你适合当反对派。
你说的两种方式没有太大的区别，无非是人员的分工不同罢了，要根据公司的人员配置状况来定，重要的是把详细设计和编码分成两个阶段来做，让开发人员兼做详细设计和编码是可以的，但不能不做详细设计，现在很多开发人员号称同时做详细设计和编码，但经常是只编码，然后不停地修改代码，最后草草补一个详细设计文档了事，放弃了详细设计工作，没有经过设计的代码一定是一塌糊涂，最后连自己都搞不清楚了，这种做法就很有问题。
把细化需求的工作交给开发人员来做也有类似的问题，开发人员经常是不研究需求，先花了很多时间写代码，然后给客户看，然后修改代码，最后草草补一个需求文档，没有丝毫用处，经过多次修补的代码结构混乱，会产生大量难以修补的BUG。这里关键也是要把需求分析与详细设计、编码分开成不同的事情来做，尽管也可以由一个人来做，但这是不同的事情，应该先做需求、再做设计、再编码，实现这一点的关键是建立一个好的流程。
谢谢各位的指正，continue:)
第二种情况：
我所指的强开发人员是可以和客户沟通，确认需求，并进行详细设计，然后再进行编码的程序员。
然而在目前的国内，这样的开发人员太少了，往往就当小组长用了。
而对于公司来说，如果底层的程序员都是这种级别的，那么人力成本就会很高。
但是，在我看来，这是程序员的一个重要发展途径。尤其是国内的现状来说，这样的程序员比纯技术的架构设计师更缺。
没有经验的开发人员确实是可能不重视文档，可是我认为目前国内的程序员在整体素质上是很高的一群人，只要加以适当的磨练，是很容易掌握这样一种操作方式的。
关键是公司或者项目负责人如何来打造这支团队？
clamp_chen(燕归来)
》没有经验的开发人员确实是可能不重视文档
看来你还要做大量的调查研究工作 至少你应该知道Kent Beck反对文档 而且xp阵营中很大的一股人都是这样 他们可能是你现在可以看到的最有经验的一群coder了 我现在仔细研究了你的发言 发现 w_rose(w_rose) 的话很中肯
虽然你试图用敏捷的方法来包装你的做法 但是我看你对敏捷的理解很不充分 至少在xp下 你应该明白所有的人都是做设计的 这是xp的一个本质特点 所以你所谓强开发人员根本就不是一个清晰的概念 而且在我看来 xp只不过是把角色做了新的分配 使人从事多个角色 就像重构中的帽子 还有你对pp的看法也是问题 pp虽然是xp中最有争议的问题 但是至少所有的经验已经表明pp是可以大大提高效率 但是如果项目中的人员太多 那么pp在实行中就应该有更多的管理的保证 就是隐含的提示你pp在人员众多的时候实施的困难要大
还有所谓的第三阶段的详细设计的问题 虽然我在详细设计文档的讨论中说过xp其实也有详细设计 但是你应该知道我说的详细设计和你说的不是一个概念 如果按照你的详细设计的方法 那么就更本不需要什么强开发人员了
还有你应该理解敏捷提出的小版本发放 为什么不是demo发放 敏捷下的小版本必须是可以工作的产品
国内的程序员专业素质很高 但是不能否认他们都还很年轻 而且很多人地综合素质还不是很平衡 这才是大家的问题 我再次说一句 如果大家多注意一些程序外的问题 这样进步才快
同时我感觉 你提出的模式还只是你的设想 如果你在没有实际实施 那么你就最好多做些准备
谢谢各位指正：）
re:ozzzzzz
我所提到的两种模式是我经历过的，目前正在实施后一种。
其实我提出这个问题，是因为目前我们公司有这样两种意见，涉及到公司人员的培养方向以及如何打造有效率的团队的问题。
换句话说：对于不同类型的项目，怎样以最小的人力成本来达到最大的效果。
在这里发文是想借鉴各位的智慧，顺带整理一下自己的思路。
人力成本事实上不单是开发人员的问题，还涉及到设计人员、需求人员、测试人员等多方面的情况，同时和市场上目前的人力资源行情也很有关系。
我的目的是试图在管理层和技术层之间找到一个平衡点。
XP模式是一个开发模式，但是它没有回答管理层比较关心的一些问题：
对于管理层来说，关心的是什么时候可以有整体的需求确认，什么时候可以把整个项目结掉，否则项目做的再好，拿不到钱也是枉然。
对于XP来说，需求确认阶段拖得太长，对于合同的签订是很不利的。
毕竟商业规则还是要考虑的，一般会将功能需求等作为附件，而这份功能需求到底包含多少内容是非常值得考虑的。
如果需求太粗，就可能造成较大的需求变更，但是如果需求太细，就需要在这之前花费大量的时间和人力，这在合同未签订之前是很不保险的。
clamp_chen(燕归来)
你的问题在于你没有对问题进行深入的研究 就xp来说它不去关心整体的需求确认，注意敏捷的系统都是这样的，所谓动态的需求，适配的开发。对你的问题我有如下看法，首先应该改变得不是软件工程模式的问题，而是你们销售的模式问题，我见过（自己也有过）这样的经验。而且需求的问题是一个老生常谈的问题，不客气的说现在这是衡量是程序员还是项目经理的一个最客观标准。在国外有专门的顾问作需求的咨询工作，你也可以找到很多这样的书籍。比如机工的《软件需求》 Karl E. Wiegers ￥19.00。但是这本书很很多的书一样，实用性我感到有问题。如果你有耐心可以等待一段时间，我会对需求做一个专门的介绍。但是你应该明白软件不是白菜，而且你们必须让你们的客户也理解这一点。做到这一点你就可以即使项目时间超过预估也无所谓。至少我有过这样的经验，最后客户主动的在原计划结束项目前追加了资金和时间。
如果你觉得在需求方面有问题，我大概可以给你帮助。
很可惜，在目前的国内这样好心的客户还比较少。
当然客户允许进度的拖延还是比较常见的，但是追加资金是很罕见的。
对于项目时间超出预估最在意的应该是开发方的管理层，因为这意味着成本的增加，如果没有追加资金，我觉得老板的脸色多半不会好看。
动态需求的模式就是要把东西做的最好，充分满足用户的需求。但是在同样的需求范围下，一个优秀的设计（充分考虑用户的工作量/人性化的界面/自动操作等等）和一个差的设计对于人力和时间的要求相差非常大。
换句话说， XP或者类似模式下出来的软件存在着“过度满足用户需求”的倾向。
对于一些想买便宜货的用户来说是不太适合的。
对于一些只接小单子的公司来说也是不太适合的。
clamp_chen(燕归来)
我很理解你的苦衷 这些烦恼在我没有作管理工作前都存在过 但是当我主抓一个项目之后 我发现我的问题是由于我过分的关注于程序本身的原故 在我看来一个项目的进行不是只做软件的开发 而是还包括很多别的内容 其中就应该包括客户对你的软件再发现的过程 所以在国外很多的项目都是时间很长的项目 而我们由于大家的年纪阅历等客观条件的限制 对技术以外的因素了解太少 而且作为老板和老总也没有一个正确的坐下来研究问题的态度 所以就是我们对问题的解决往往是抱着简单粗矿的办法 而不是仔细研究究竟项目会给客户造成什么影响 我们应该如何让客户的投资和自己的投资最大化 我们的客户可以说往往没有我们专业的素质 但是不要忘记他们有他们自己的专业素质 他们都是商人 如果你告诉他 给我￥2 我给你一个东西可以让你节省￥10 并且让他相信你说的 你看看他是不是会掏钱 关键是你作为项目经理 应该全面的考虑问题 而不是只从完成公司任务的角度考虑问题 一个项目发展的时间越长说明你的工作越出色（当然不是拖的越长） 这就要求你应该不时的扮演一个销售者的角色 其实只要客户会算帐 并且希望使自己的利益最大化 那么你就可以有办法来做工作
re:ozzzzzz兄
我现在的难题不是在于说服客户，而是如何在各个方面的人中间找到利益平衡点，还要被各方所接受。
很多项目可以简化成如下的模式
开发商 客户
——————————————————————————————————
管理层 管理层
项目经理 用户代表
开发团队 一般员工（最终用户）
我是希望考察一下哪种开发模式更能够兼顾这六方的利益。
比如客户的管理层决定投资一套系统，一方面提高员工效率，另一方面可以让自己更方便的监控。重点还是后者。
对于客户的一般员工来说，则是希望减轻自己的工作量，但是他们并不愿意把一切都暴露在老板的眼前。
对于用户代表来说，则介于两者之间，看他是哪里出身的了。
对于开发方来说，公司管理层希望以最少的时间和人力成本完成这一套系统，一方面满足客户需求，另一方面可以锻炼人，以及积累开发经验，为进一步的开发作准备。当然也希望接到下一个定单。
对于项目经理来说，则需要兼顾各方利益（包括自己的），不断的协商、妥协、调整计划等等
对于一般开发人员来说，则是完成自己所分派到的任务，也希望能够锻炼自己的才能。
呵呵 你还遗漏了一些人 还有别的方面 所以我现在相信你的需求系统有问题
：）
但是你应该已经看到事情背后的东西 其实我们就是在这场博弈中去寻求大家利益的结合点 这就要求你跳出原来技术人员思维的框框 从一个开放的角度思考问题 你已经做了 继续下去就可以 总之就是我用￥1做的东西 ￥2卖给你 可以给你解决￥10的问题 如果你希望是￥100 那么很好请再给我￥。。。。。。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有