51Testing软件测试论坛

标题: 小公司应先进行项目计划还是先行开发赶进度？（2009-5-22 ）获奖名单已公布 [打印本页]

作者: 默默巫 时间: 2009-5-22 14:56
标题: 小公司应先进行项目计划还是先行开发赶进度？（2009-5-22 ）获奖名单已公布
背景描述：小公司开发设计全凭公司人员的想法和老总的想法为准，变动大且计划开发的周期时间短。
那么小公司应先进行项目计划还是先行开发赶进度？

奖项	获奖名单	奖励	答案连接
最佳话题PK手	蓝色水滴	当当购物卡50元+最佳PK手勋章	54#

本期问题由huihuike会员提供！
如果你也有矛盾的问题想提出来和大家一起讨论，请点击此处>>
说不定下期PK的话题就是由你提出的哦，请快快参与吧！

作者: 测试小女子 时间: 2009-5-25 15:17
标题: 计划是行动的妈妈
我认为计划是行动的妈妈，就像失败是成功子母一样

计划是我们在初期估计我们的进度，成本，规模
这些的正确估计，有助于我们合力分配时间和人力资源。
虽然是小项目，如果项目经理经验丰富，计划也是有必要的。。不然，我们在行动的过程中常常很盲目，更容易导致到期不能按质按量的完成。

作者: hellinangel 时间: 2009-5-25 15:20
标题: 小的概念是什么.
这个问题要看小的概念是什么,小到何种程度.

作者: wuchunying 时间: 2009-5-25 16:11
标题: 计划是一切的开始
其实文中的说的公司人员的想法和老总的想法，从一定程度上来说也是计划，只是没有书面化而已。没有笔头记下的东西不能保证以后没有遗漏，开发之间的任务和意思也有可能还留有一点没有相互理解。（我就遇到过赶项目的时间，2个开发做了同一个页面，漏了一个页面）后期在改也要花很多时间。还是一开始把计划写下来，当然进度很紧的话，不用写的那么充分，但是必要的流程，任务分工等还是要记录的，这要不了多少时间，还可以为以后维护留下资料，毕竟人脑不是电脑，不能记得做过的所有项目。

作者: ganhuiping 时间: 2009-5-27 15:09
小公司赶进度的后果是，后面花费的维护时间更长。这个时候就能看到实现计划的重要性了。亲身体验。

作者: davy_chen 时间: 2009-5-27 15:40
我本身是中立的，但是看到反方投票太少，所以给投了一个反方票，其实哪个好，实践是检验真理的唯一标准，两个没有做出来前，可以说无从对比。
其实我们不要追求形式上的，或者固定模式的哪种方法更好，只要本着得到最终好的结果（软件）即可。
变是绝对的，不变是相对的。

作者: kiyu 时间: 2009-5-31 15:21
本人觉得项目计划的制定非常重要，它对整个项目期间每个阶段需要多长时间进行大概估算，使整个项目组成员在这个阶段有个明确的目标，不会像无头苍蝇，保证了效率，也保证了产品的质量。没有项目计划，就没有一个指路明灯，一天干多少活算多少，最后可能会导致项目延期。

作者: hongyan 时间: 2009-5-31 17:19
不管是大公司还是小公司都应该有相应的项目计划，应先进行项目计划是肯定的，但就目前很多小公司来说却没有相应的项目计划，主要原因有两个：第一，公司不重视，只要出东西就行；第二，项目周期短，时间紧迫，开发人员急于赶进度。

作者: Gray 时间: 2009-6-1 15:44
如果这个问题问的是只分先后，而不是进行不进行的话。。。。。我觉得先进行项目计划还是先行开发赶进度,为什么不能同时并行呢？
计划是对整体的操作规划，对于小项目可先分析业务，确定在老板怎么拍脑袋都不会变的需求先由开发实现（这个过程应该不会花太多的时间吧？），那么我想计划的同时也可以开始开发，测试也可以同时开展
计划不如变化快，但我们应该保证计划要赶得上变化

作者: huihuike 时间: 2009-6-1 16:43

原帖由 Gray 于 2009-6-1 15:44 发表
如果这个问题问的是只分先后，而不是进行不进行的话。。。。。我觉得先进行项目计划还是先行开发赶进度,为什么不能同时并行呢？
计划是对整体的操作规划，对于小项目可先分析业务，确定在老板怎么拍脑袋都不会变的需 ...

公司的计划变化太快，而且没有书面的一个确定需求，都是领导说今天要加这个功能就加这个功能，明天说那个功能不要了，又做了白工。开发人员做的很辛苦，测试人员做的也很辛苦，关键就是没有一个定论。

作者: sunnycocol 时间: 2009-6-1 16:55
这个问题我也一直困扰哈！
小公司嘛，也不是很规范，按照一步一步规范流程来做，需要慢慢来。
什么也不明确，想到什么就做什么，想到什么就往里面加，原来所关联做的有些不合理又要删掉，真是浪费了不少劳动力，
开发人员和测试人员的劳动力，特别是测试人员，牵着鼻子走，本来测试人员就处于被动的状态，汗。。。。。。。。

作者: hero001 时间: 2009-6-2 09:11
需要不需要计划还得依具体的情况而定，在人手紧、时间紧的情况下一些流程上的东西我觉得还是可以删减的，不用非得去按正常的流程走，当然制定些简单的计划什么的还是必要的，千万别为了走流程最后把项目人员弄的整天加班去赶进度，时间挤到最后压缩的还不是项目测试的时间，没有经过充分测试的软件质量也就可想而知了（亲身体会啊）。所以制定项目计划，按照正常的项目开发流程是在人力资源、时间等条件相对充裕的情况进行会比较好。

作者: 咚咚宝031102 时间: 2009-6-2 11:39
视情况而定

作者: imutou 时间: 2009-6-3 09:15
没有先后之分。。。两手抓两手都要硬。。。::zilian:::

作者: stella_luan 时间: 2009-6-3 15:38
标题: 没有好的计划就没哟好的实施
首先要明确一点是否真的很小，
如果半个月就可以搞定的事情，没有必要在搞一些噱头和一些没有必要的形式文档。

但是一个真正的项目，计划是最最重要的前期工作，需求如果不定好，没有办法定下来完成的时间，
需求的改变意味着无线的延期。
耽误时程。

作者: allen_lu 时间: 2009-6-4 17:51
标题: RUP
小公司项目小可以采用RUP进行软件的开发，应该会比较有质量保证，不会浪费很多时间。计划做的周全了，需求明确了，可以节省很多变更需求造成的时间浪费，也同样为日后的开发节省下了时间。也可以先进行项目开发得到一个初期的模型，然后再扩展，即可以降低风险，也可以增加进度。但不管计划先进行还是开发先进行，都必须明确需求。

作者: zr_may 时间: 2009-6-5 10:30
标题: 并不冲突
还是觉得这些都是要兼顾的。
项目计划是一个全局的东西，指导了整个的软件开发的过程。如果是紧急的项目，那就更加的应该有项目计划啊之类的了，因为，这样才可以更好对所要做的事情进行估计和计划，才能够避免盲目。假设一个紧急的项目没有项目计划等，恐怕开发进行到一半发现，哎呀，没有办法完成了，那才不得了。

作者: xuemeili1216 时间: 2009-6-8 11:34
标题: 计划是要做的
计划是肯定要做的　但是之所以叫做计划　就是说在实际执行过程中可以进行变动　计划是死的　人是活的　不管大小公司　项目开始前肯定要做计划（因为计划是根据项目性质来做的）

作者: dqar 时间: 2009-6-8 15:00
标题: 完整的计划小项目
完整的项目计划是个什么概念，对于一些项目时间特别紧急的项目可以之计划一些比较重大的里程碑，不用太细化，只要能充整体上把握项目进度就行，不必考虑1号设计几个功能点，2号测试几个功能点

项目小，小又是个什么概念呢？无论大小，计划都是应该走的，但是应该根据项目的实际情况，考虑计划的制定方式和表现形式。

作者: cctvnba 时间: 2009-6-10 17:14
标题: 小公司也要通过分析它的组成来决断
从目前中国国情来说，投了正方一票。
对于国内大多数小公司来说，人员少，具有丰富工作经验的高级人才也少，那么项目计划是必须制定好的。我们可以说计划是用来改的，但没有计划，我们连参考的标杆都没有，不光开发过程受影响，管理也混乱。
某些小公司，这种公司国外存在的情况较多，人员少而精，从上到下都是多年经验的牛人，而且共同共事多年，对于各种流程早已吃的透透的。我觉得这样的公司没有计划也可，难道你会认为他们会因此把项目搞砸？
多说一句，就像CMM的应用一样，国外一些公司已经觉得CMM流程制约项目开发，搞起了敏捷。国内目前还没有一家公司达到超越CMM的级别，自然还得老老实实按条条框框来的好。

作者: huijuan0501 时间: 2009-6-10 18:22
好的计划，对项目开发进度和测试进度都有绝大关系的，自身经历，公司小，人员短缺，多个项目临时调动人员，如在提前不制定一个合理项目计划，再以后项目启动后，时间及人力资源上上有很大的浪费，效率提不上去

作者: fyjfyjsmile 时间: 2009-6-12 17:39
标题: 没有项目计划后面的一切都是徒劳的
这和大小公司没关系，和工作任务紧不紧也没有关系，作什么事情都需要三思而后行，这个事情一定要做，只是结合每个公司的情况我们可以把项目计划的周期时间缩短，或者太多的形式化的东西去掉，做一切有利于我们工作的计划，然后再进行下面的工作，否则后续的工作中将会产生一系列的问题，否则项目负责人将对整个项目进度很难把握，工作质量也无法保障！

[ 本帖最后由 fyjfyjsmile 于 2009-6-12 17:42 编辑 ]

作者: test_fairy 时间: 2009-6-15 15:12
标题: 其实我对这个命题感觉是二者都不全赞同,也不全反对
原因:对应一个小公司来说,的确存在上面所提到的问题,变化短,变动周期大,这样一来就给测试人员造成了非常大的麻烦,要想进行好的测试时间上不允许,而且没有计划就不能好好的进行测试.
但是,我想这样的问题在一些大的公司也有可能存在,(由于开发条件比如时间的限制等)所以,不能马上确定是先进行项目计划还是先开发赶进度.而是应根据具体情况进行具体分析,如果时间上允许就先进行项目计划.反之,先开发赶进度也无可厚非,毕竟现在是经济时代,皮之不存,毛之焉附.
另外,正如楼上的人员所讲的,如果你的人员对某一类系统非常有经验的话,先计划也不一定是必须的,一类系统有一个比较完整的计划就可以.现在相似的系统难道还小吗?

作者: qzyyh5505 时间: 2009-6-16 09:42
标题: 支持反方
首先要解决温饱问题，然后才是吃好

作者: xmflansitu 时间: 2009-6-16 14:15
标题: 计划是不可缺少的
我所在的公司算是一个小公司吧，可是也会有一个计划，没有计划，就像无头苍蝇一样乱撞。即使开发出来了也是不成熟的版本。与其到时意识到问题存在后不停的弥补缺陷甚至推翻重来，还不如刚开始的时候就计划周全一点，这样才是一种节省成本的方式。
首先，计划应该尽可能的考虑的周全一点，把能想到的问题全部考虑进去，不仅如此，也要考虑一下以后的发展趋势，这样就可以把以后可能需要往这方面发展的一些东西也考虑进去，这是我们项目经理经常跟我们说的。
但是在实施的时候可以从大处着眼，可能把项目的主干提取出来，当主干搭好以后，其它一些也就可以做一些功能使项目变得饱满，这样也可以不用担心不能迟迟上线的问题了。
当然在开发过程中不免会有一些改变，当然这些变动不会动及主干，所以在开发过程中可以开个小会讨论一下，并且可以时时跟踪改进的情况，避免功能全部做好以后才发现那不是想要的效果，这样也可以省很多不必要的成本。
计划----改进-----确认-----实施,我认为这几个步骤是非常关键的。
这只是鄙人的想法，如果有说的不对的地方欢迎指出。

作者: 忍忍忍 时间: 2009-6-17 15:57
标题: 你是老总么？
各位一定要明白，老总成立公司的目的是什么？赚钱！所以为什么很多小公司不走项目计划流程而直接进行开发，因为项目没有计划部分的资金，一般都是客户扔个项目过来，只说给多少钱，什么时间完成，而且对项目的质量要求不高。
如果正方觉得凡是项目都应该进行项目计划，是否可以极致地说凡是项目，都应该按照cmmi5级标准进行？如果真是这样，我相信现在市面上的绝大部分公司都会倒闭了（吃皇粮的不算）。
一个软件的开发生命周期现在都研究得很透彻了，说得土一点，只要有足够的时间和资源，一定可以做出质量很高的软件；而问题就在于任何一家公司都不可能用有限的资源投入到无限的提高质量的过程中去，即项目周期中的任何一个环节都有可能会被裁剪。
回到话题，是先计划还是先赶开发进度不是我们说得算，而是根据项目具体情况而定，一般小公司做法就是先赶进度，后期补计划。
----
题外话：这种做法对不对呢？理论上讲是不对的，但是很无奈，正如各位人手一张身份证一样，习惯就好了。

作者: lrdavid 时间: 2009-6-17 16:28
标题: 项目不预则废
再小的公司在做项目之前也是需要项目计划的。
1. 把握需求，项目启动之前一定是会有需求的。做计划可以肢解需求，让项目组的成员对需求有更深刻的了解，本来小公司人就很少，如果大家对需求把握不了就麻烦了。
2. 做好计划有利于明确各自的职责。
3. 提高员工的效率减少项目的无故拖延。在实际情况中，如果项目组的紧迫感不强的话会造成员工效率的底下，如果在做计划时能按照时间来要求进度，做好里程碑点的控制的话会很大程度提高项目的效率。

作者: lennie-zhao 时间: 2009-6-17 16:30
标题: 小公司的项目不一定小
就拿我的公司来说，公司的确很小，但做的是产品，项目历时1年了（还在进行中），过去的一年只是完成了整个大项目的一部分，这一小部分就计划。项目无论大小都是一个个小部分组成的，每一个小部分就是计划

作者: lyj672 时间: 2009-6-17 17:29
敏捷开发,敏捷测试

作者: zhjd4839 时间: 2009-6-17 19:54
标题: 计划是一切的开始
没有计划，后面的好多工作可能就白做了，可能这对于小公司来说是浪费时间的事情，但是，如果没有计划是很危险的

作者: 阿七 时间: 2009-6-18 13:00
磨刀不负砍柴功

作者: sidneylover 时间: 2009-6-19 11:10
标题: 项目结束时拿不出成果，一切都是扯谈
正方大多都是想当然了，老板的目的都是追求利益最大化，不管长期还是短期。
如果人力、物力资源足够，制定详细的项目计划，包括开发计划、测试计划，合理的安排资源、有效的风险控制等可能都会起到事半功倍的效果。作为公司方，肯定希望项目有足够的时间去完成，项目周期越长，项目经费也越多，公司利益也就越大，在项目确定时，公司与客户应该就项目没有足够的时间所造成的后果进行交流。如果没有客户催促，项目启动会安排充分的时间。
我认为在项目周期时间短的时候应该先赶进度开发，项目结束时拿不出成果一切都是扯谈，客户不会因为你由于制定详细的项目计划导致项目延迟而支付你全部的项目经费。

作者: love_yebin 时间: 2009-6-19 13:33
标题: 测试根据需求来，开发根据计划来

老大，发布的话题，涵盖的不深
首先，根据不同公司的运作方式，采用的软件开发模型都不一样，按您说的，貌似和V模型很像，
实际中，我知道的公司，基本都还在螺旋，迭代模型，如果说小点的公司，我认为更是如此

测试的标准来自需求，这个在我的经验中，不属于项目计划的份额，客户需求出来后，我们的做法一般都是
确定一个demo,然后客户确认，OK 了，项目就可以开始了，
测试根据需求完成测试计划及部分测试用例，开发根据计划完成开发进度

迭代过程，会产生很多不成熟的版本，有质量控制，一般都是 MD5值
提交送测
产生下次迭代，直到项目结束

里面老总肯定是有想法或者人员变更的，但是在迭代中，这个又不影响

我认为，这才是比较适合小公司的运作

[ 本帖最后由 love_yebin 于 2009-6-19 13:41 编辑 ]

作者: hellinangel 时间: 2009-6-19 14:38
怎么感觉这个命题有点问题呢，小公司不代表流程不完善，也不能说明所承接项目就一定都是小项目，见过N多小公司承接大的项目了。

作者: chengxq 时间: 2009-6-19 14:52
这个其实就是质量进度成本三角关系中的质量和进度的关系，没有太多问题，只是一个权衡而已

作者: puchonghui 时间: 2009-6-20 20:54
这跟公司大小有啥关系
发觉最近这边的话题越来越扯了。。。

作者: woza 时间: 2009-6-21 12:07
标题: 可以用敏捷的方法来解决
平均一个月的开发周期，3天做计划足够了。如果超过3天，那就说明计划的东西太多了，十有八九在开发周期里面完不成。仔细看看你的计划，起码里面有一半的东西都是可做可不做的。毫不犹豫砍掉吧。我这里说的一个月时间，实际是22个工作日，每天写代码时间不超过6小时。
测试的问题很容易解决，只要测试人员和开发人员坐在一起工作。以团队的形式来约束。比如说一个测试人员配两到三个开发人员作为一个团队。任务分配以团队为单位。团队中不管是开发还是测试的任务，都可以大家一起做。
需求的问题么，必须让需求人员和开发测试人员一起工作。只要开发人员能够根据需求做出东西，那测试肯定能感觉需求测试。有问题直接问定需求的人。文档不是很重要。
需求变更没问题，只要定需求的人知道，加一个新需求，就意味着多半要砍掉一个计划内的需求。让他自己去衡量利弊。

作者: 佐伊 时间: 2009-6-23 13:42
看看大家的见解

作者: tensy125 时间: 2009-6-23 18:32
只要项目成功了，还在乎那么多？？

不管是为了写计划，还是为了赶进度，都是为了项目成功，最后Give me money，完事。

作者: jhhaitun 时间: 2009-6-24 12:52
要不要做计划，答案是肯定的。理由上面已经讲得比较全面了
难的是，项目很紧张的时候，没有时间去做计划。或是经验不够丰富的时候，计划做的没有水准，没能体现计划的优点来。
那么，如果是上面的情况怎么办呢?
时间紧张：
先跟着有经验的同志领导下工作先展开来。期间的变化，或者小的计划，负责人要及时沟通记录好。等到中间有空闲的时候，计划再慢慢跟上。
经验不丰富：
请个高手（基本不太现实）
一边集体商榷，一遍摸索，一边执行，一边及时总结。
本次经验累计下来，下次同样的问题，不可以这么杂乱无章了

作者: woza 时间: 2009-6-24 19:43
一个项目不可能没有时间做计划。传统开始模式下，如果感觉做计划的时间不够，那其实是因为计划的范围太大了。还有一个问题是，做计划的人太少了。

如果一个PM管20个工程师。他要替20个人安排工作，估计时间，当然需要花很多时间。但是其他人又不能替他做决定，他当然要很多时间做计划。

在敏捷模式中，只要product owner告诉团队需求，工程师们会自己估计时间，分配任务。这样一来大家一起做计划，只需要很短的时间就可以完成。所以不会有计划和进度之间的矛盾。

作者: Airoo 时间: 2009-6-26 14:24
磨刀不误砍柴工，一开始可能会比较困难，几个项目下来就看到进行项目计划好处了

作者: yuhong01 时间: 2009-6-26 15:17
需要计划，否则天天变化开发测试都受不了。

[ 本帖最后由 yuhong01 于 2009-6-26 15:20 编辑 ]

作者: mengpeng 时间: 2009-6-28 00:25
标题: 无计划无进度
我认为一个好的计划就是事情成功了一半，没有计划就无从下手。虽然是小公司，也应该有完整的计划，这样每个人才知道什么时间做什么事。做起事来有条有理，不至于盲目，更能事半功倍。试想在一个脏乱的仓库和一个整齐的仓库，那个仓库找东西更快？效率更高？小公司，时间紧.......这些只是借口罢了。

作者: 劳拉 时间: 2009-7-1 12:39
标题: 看项目情况和团队人员组成情况
如果不是新项目,而是作了好几年的项目增加功能,又是老手或高手,做后期版本的话,如果项目要求尽快完成,则可以做个简洁计划或省略计划;
如果是新项目,难度大,并且人手也是新的,或超过1/4是新人,项目交付时间要求再紧也要作好计划,并且越详细越好,否则将一团乱.

如果这个小公司的业务方向比较单一,集中,可以根据CMM流程相对裁减一些,制定符合自己公司业务的一套实用的流程,没必要一定要符合什么什么规范.目的是用最低的成本,在要求的时间内,最大化的保证项目质量.

作者: huchao 时间: 2009-7-3 10:18
标题: 我支持一下反方，
背景描述：小公司开发设计全凭公司人员的想法和老总的想法为准，变动大且计划开发的周期时间短。
背景说的好，第一这个是个小公司，人员配备应该不是和全面的，所以所必要的人员和专业的技能应该没有的，
第二，背景里描述了这个公司的开发设计全是凭老板和开发的想法为准的，
第三，开发周期比较的短那么就没有充足的时间按留给作计划的人员了，那么没有时间做计划那做出来的计划就不是完整的计划了，那一个不是完整的计划的话那么就没有指导软件制作的全过程了，所以说在这样的一个小公司的这样的一个情况下我认为没有必要做计划了

作者: movestar 时间: 2009-7-6 15:37
我个人认为有计划比较好。虽然公司小，但是没有计划，后期改动量有可能会很大，而且开发人员没有充分的依据来证明他们的开发是按照上司原来的计划来实现的，所以有了计划就相当于有了一份可以思考、参考、证明的依据。
前期花一部分时间去计划项目，会给后期带来很大的方便，有不明白的地方就已计划书为依据。
易于软件的开发与测试。
没有计划的开发返工的几率是十分大的，对于开发、测试、公司来说，都是浪费。
因此我坚持，开发前一定要做好计划。

作者: sundongzhi 时间: 2009-7-6 18:02
标题: 测试用例是一定要写的···
在很多时候都会出现这样的情况，周期短没有时间写测试用例，这样可以写测试大纲！测试用例还是必须的！

作者: DreamLink 时间: 2009-7-6 21:33
1、從測試角度,我支持正方的觀點:没有完整的计划项目无法测试充分，出现问题大。
因為有詳細的說明、明確的目標，才會會好的測試案例，才能有全面、多方位的測試。才能保証軟件產品的質量。如果內有這些做保証、產品需求會因時間、人事不斷變更。最終只有當是人才知道最終、真正的需求。
2、從開發及公司管理的角度來看，我支持反方觀點。
需求需要占用大量人力、物力。如果在資源短缺、項目期短情況下，也只能暫時先舍棄一些。不然需求出來了，項目期已經到了，其它的都是無用功了。

項目要看大小，流程要考慮環境。

作者: xiaonanzeng 时间: 2009-7-7 11:20
我做的都是正规的项目，但我还是支持反方。
1、小公司是做不到量化这一步的，人员、技能、流程、制度都达不到标准。根本做不出一份可行的计划，如果要做，他们只会COPY
2、敏捷的思想是以人为本，不在乎其它
3、一个企业的发展历程：最初是创业文化，第二阶段是目标导向的文化，第三阶段是规则导向的文化，第四阶段是团队亲情文化。小公司只处在一二阶段

作者: 本来就很乖 时间: 2009-7-7 16:20
当然是先项目计划了，要是开发一半才发现人员短缺，或其他问题，那么问题就大了

作者: 梧桐落叶 时间: 2009-7-7 19:57
计划是要做的，只是不要搞的太过规范，制订有指导意义的计划，要切实可行的。
因为考虑到变动大的因素，可以测重在需求变动这里进行规范，不然做计划也是白做，
所以要慢慢规范起来，而不是直接就开发赶进度。
什么都是慢慢来的嘛

作者: leafgemini 时间: 2009-7-15 10:39
如果没有一个好的计划，测试工作很难充分展开！反而会影响到产品后期维护。

作者: jsj1jsj 时间: 2009-7-16 14:51
看项目小到什么程度了，很小的话没有必要做计划脑子就可以有个大致轮廓的当然可以忽略计划稍大点就要有计划防止前功尽弃

作者: 蓝色水滴 时间: 2009-7-17 10:44
其实两者完全不冲突的啊，难道说写计划会延误项目的进度？不见得。再紧也不差个一天半会儿的吧，不是说所有的计划都得写在纸上，写得清清楚楚，谁做什么，在哪天前必须完成什么功能，还有意外延期处理等等。尤其是小公司，就3-5个开放人员，他们制度的灵活性非常高，用流行的话来说，就是完全具备敏捷的研发条件（但前提要开发人员的个人素质和开发技术要突出）。他们的计划在研发的过程中可以快速的更改，而不需要复杂的流程。一句话再小的公司也有计划，也许没有那么详细，也许没有纸质化。

作者: cnmpdhy2009 时间: 2009-7-20 12:05
计划是很重要，可是目前大部分中小公司都很难做到按计划来

作者: buutterfly 时间: 2009-7-21 22:53
小公司相当于激流中的独木船，在激流徘徊中依然前行，即使一路有着很多的风险，但在激流中依然沉稳，且不失为一种很好的解决办法。
大公司相当于茫茫大海中的一艘豪华游轮，稳重，即使有着较大的风浪，其自身的防备措施依然可以保证它成功起航，成功到达目的地。
如果将“独木桥”放于大海，就相当于将小公司至于大公司竞争的行列；
如果将“豪华游轮”放于小溪中，就有些发展环境过于狭小。

小公司应该找到适合自身发展的方式，因为其受到自己公司规模，项目大小等多因素的限制，机动灵活是其最大的特点，也是其最大的优点。太多的规划，因为其根本不具备这样的资源，或许会限制自身的发展。

大公司恰恰相反，在资源都相比更为充足的情况下，一个切实的详细的项目开发计划是必须的，否则如此之大的一个团队没有目录，会如何呢?不敢想！

基于以上观点，所以我反对！

作者: 流浪貓_遇上測試 时间: 2009-7-22 15:10
标题: 計劃趕不上變化快
雖然計劃是很重要的.但是就背景所說的"开发设计全凭公司人员的想法和老总的想法为准" 那就相當於計劃趕不上變化快了.
說變就變, 再好的計劃也會被一改再改, 不但在進度上減慢了,人力上也浪費了資源.

作者: 流浪貓_遇上測試 时间: 2009-7-22 15:47
标题: 計劃趕不上變化快
計劃,一般是就著公司現有的資源進行合理分配,進行統籌兼顧,儘量用最短的時間,最少的人力把project做好.
1.小公司不比大公司, 哪來那麼多的人力?物力資源?一但遇上突發事件(接到新的項目必須進行的), 就能將一開始的完美計劃給打亂.
2.對於一個說變就變的project, 在你更改新的計劃後的下一秒可能又會再次發生變化,那一個計劃要寫到什麼時候?此項目要何時才能開始?工作要到什麼時候才能交到客戶手上?
3.初建的小公司,在還沒有得到一定的信任時, 一般接到的project都不會很大, project不大,員工們幹起來也不會有太大的問題,
4.小的project一般分派的人手不會多,1-2個, 從了解需求到開發測試(簡單的檢查)提交,實施....,如遇上更改的,自己了解開發的過程, 更改起來也很簡單, 根本就談不上計劃, 更不需要了.
簡單的說: 種一棵薰衣草和種一片薰衣草, 兩者都需要計劃的嗎?
種一片:你要找一個大的地點, 而且還要有陽光的,再者在種的時候你還需要知道每一棵薰衣草之間的間隔...... .. . ..這些都要心裏有數,有計劃.
而種一棵,也許你在家的陽臺找個花盤就能種下了.

作者: ningxin 时间: 2009-7-22 18:06
标题: 有计划有准备才能成功
小公司也要先计划好，只是赶进度的去做，很盲目。而且会导致后期的维护量很大，项目缺乏灵活下，难扩展。计划好了，开发起来也很快的，关键是后期维护量小，相应的耗费的人力成本等都会减少。

作者: b45993e 时间: 2009-7-23 16:12
......................................

作者: 爱喝可乐的猫 时间: 2009-7-30 16:55
标题: 小公司的测试很难做
目前，由于小公司的开发流程就存在很大程度上的问题，没有需求说明，没有开发文档，等等一切的需求都是没有标准的，一天可能变换n遍，另外开发人员之间可能没有工作的具体化，一个地方改动，甚至牵扯到了大局，给测试带来了很大的麻烦，没有需求，开发人员乱搞，需求随时变换，都在很大程度上造成了项目的进度，只赶进度，产品根本无法正常使用，稍微有点问题，可能整崩整个系统。

作者: helina168 时间: 2009-7-30 19:56
没有计划的话后期工作很难维护，就好比你先不想好盖什么样的房，直接盖，那么可能你盖到中途发现这房再盖下去会塌，那么这样不是做无用功吗。一个项目是需要计划的，每个阶段都应该有计划

作者: hero001 时间: 2009-7-31 09:24
要知道小公司的存在条件是什么，为什么是小公司呢，也就是说人力资源是相对短缺的，那么在有限的人力情况下还去写计划，走正规的流程，我个人认为是很不恰当的，等到计划什么的指定完毕了，估计项目周期也剩不下多少时间了，接下来怎么才能按时交付产品呢，只能是没命的加班去赶进度，小公司接项目也不容易，能不能按时叫产品对公司的影响是很大的，所以先保证按时完成产品对小公司是最重要的

作者: 箭在行动 时间: 2009-7-31 17:36
标题: 没有计划的软件必定是有缺陷
我严重抗议没有计划的软件项目。我今年刚毕业，在公司的一个部门里面做测试。项目没有专门的测试人员，我来了以后没有需求，没有计划，什么资料都没有提供给我。我只好找开发人员具体的每个功能。项目没有明确的计划，需求因为部分人员的一两句话一改再改，后期陷入了混乱。测试后，软件漏洞百出，我在一个星期内找到了40多个Bug，有些足以致命。这让大家都很郁闷。
我在做测试的开始就是一个纯粹的功能体验者，处处被动。
我绝对反对没有计划的项目，这样定然会走许多弯路。

作者: helina168 时间: 2009-8-3 19:38
没有计划的软件项目是很难管理和维护的，如果说有计划却不按计划执行，那是更不能接受的，我感觉我们公司的就是这样？文档都有了，可是真正用上的没几个，测试全是人工控制，就像楼上说的，时时处于被动状态，什么时候需要你测试的来测了，就叫上，测好了也就没事了；那些计划都是给上面领导看的。。。。。
没有计划感觉没头没尾，不知道什么时候开始测也不知道什么时候结束，工作日程更加不好安排，测试人员只能跟着开发的走。。。。

作者: drwei123 时间: 2009-8-5 18:30
首先要保证在投标规定的时间内把项目做完，没有做完的话，什么都是白搭。
质量的问题解决是能可以先给出第一个主要功能完善的版本，其他小的功能到下个甚至下几个版本再修复或添加。。。

作者: snoopy1234 时间: 2009-9-29 18:08
首先我认为应该是针对项目而言，小公司可以有几年的大项目的，所以跟公司规模无关，跟项目规模有关。

第二计划肯定是需要的。预则立，不预则废。
但是在计划的时候，可以根据项目的规模，属性等作出裁剪，然后做够项目用的计划。
但是不管怎么样，里程碑还是要有的，成本计划还是要有的，范围，质量，人员体制等总归还是要有的，这样在项目监控中也有据可依，要不变更怎么控制，进度怎么算延迟，人员一直变动怎么办呢
至于计划文档的形式可以从简，只要大家能看明白、没有歧义即可。

作者: bichenlu 时间: 2009-10-10 16:09
标题: 计划赶不上变化
计划赶不上变化

作者: livehome2008 时间: 2009-10-14 10:34
标题: 我觉得这两个观点的出发点不同，说不到一块儿！
正方是理想主义者，优点是以保证软件质量为目的，走正规流程直至软件开发完毕，这样的好处是测试有根据，跟踪缺陷时能比较容易找出问题所在，从而定位究竟是程序本身编写的问题，还是原先设计的问题，可使测试人员头脑清醒地做测试，心里也有底；缺点是往往这样走流程需要开发团队有相当高的管理意识和执行能力，对于小公司的来说是个巨大挑战，特别是在项目时间紧迫时，给人的第一错觉就是，走流程耗时太久，从而打击了工作积极性，其实这个也是不对的，但这是当今许多公司的现象，如果想解决这个问题，我觉得目前在当今急功近利，盲目冒进的社会现实中是不可能的。
反方是现实主义，优点也是缺点，就是看上去好像是为了赶开发进度，但其实是在扰乱项目进程，并且极有可能会得不尝试，给测试人员造成了非常大的测试障碍，就是无根据，无基准，只得走一步、看一步、测一步，毫无整体思想，这样的测试注定只能找到些边角料，对于软件的关键核心功能，无法进行详细测试（因为不知道那玩意儿该是怎样的嘛），并且在这种情况下，开发人员也会心里憔悴，无暇顾及需求，只是冒进地写代码，希望最后验收的时候能碰巧对上用户的心理，其实这个和买彩票的心态差不多！但做软件能和买彩票一样吗？这样的做法，一定会引起用户的不满，拿出来的东西牛头不对马嘴，然后再花大量的成本去修改，要是能来得及改，并且改成了也就算了，问题是很多时候，改不成，来不及改，弄得开发人员精疲力竭，测试人员一头雾水，可能还要蒙受不白之冤，甚至这趟生意就也就这样丢了，这个时候再来考虑原因，是不是太迟了？
所以按我说，这不是正方反方谁有理的问题，这是业务关注点和与社会现状的一次剧烈碰撞，所谓人在江湖，身不由己，在竞争日益激烈的现今，赶进度，抢占市场，先发制人，固然是经营法则，可也拿好东西去抢占啊，否则一堆白眼狼在后边正等着看你出丑，把位置让出来。
社会的发展，可以说就是取代与被取代的游戏，但谁又能立足于江湖而不倒呢？想想两房，想想雷曼兄弟，还不就这样倒了，再想想花旗、汇丰，尽然被工商、建设所取代，怎么让人不叹息，三十年河东，三十年河西，出来混总要还的，即使你这辈子不还，你的儿孙们也会有该他们还得时候。
小公司的生存当然重要，无论他们的意图是要自己越做越大，还是打算被大公司兼并，能生存下来都是关键，赶进度无可厚非，都是为了生存；按流程走，也很重要，毕竟保证质量，事关重大，但这是两件事，说不到一块儿，并且完全可以在保证质量的同时，赶上开发进度，这些从领导到员工，从项目经理到程序员、测试员，都要明确的，想走捷径，我建议还是买彩票吧！

作者: hongyuyimeng 时间: 2009-11-11 11:49
首先项目计划是必不可缺的，无论一个人的项目还是几个人的项目。我们在做任何事情之前都应该有自己的plan，没有plan就无法control。那么一个leader如果你都没办法control project了那么这个项目的人为因素就很高了，也就是没有文档计划可以跟踪，什么事情都要依靠个人的决断。这样我们的风险就暴露出来了。如果这个人离职或者生病。。。，那么如果让其他人接受这个项目呢？
对于小项目，在项目计划上我们要明确自己的里程碑，清楚在什么时间我们需要做什么，在什么时间我们需要deliver什么，这样才能让你的项目按照制定好的轨迹走。而不是给它很高的随机因素。为什么现在要走ISO，走CMM,CMMI，就是因为我们要让我们的质量有个标准，而不是时好时坏。所以如果一个小公司想发展成大公司，想拥有质量的竞争力，那么项目计划是必不可少的，不仅仅是项目计划，很多流程和文档也是比不可少的。

作者: 绯苍信 时间: 2009-11-12 13:50
标题: 有计划才有依据，避免无用功
有了整体的计划开发和测试才有依据进行工作，如果直接开始赶进度，中间出现需求偏差，还得返工，耗时耗力，而且也达不到最初赶进度的目标，反而使项目延期。::ybaojc:::

作者: dreams 时间: 2009-11-13 14:31
楼上的分析很有道理

作者: 小册子 时间: 2009-11-18 17:31

原帖由 箭在行动 于 2009-7-31 17:36 发表
我严重抗议没有计划的软件项目。我今年刚毕业，在公司的一个部门里面做测试。项目没有专门的测试人员，我来了以后没有需求，没有计划，什么资料都没有提供给我。我只好找开发人员具体的每个功能。项目没有明确的计划 ...

这位同仁说出了我的心声，我也是刚毕业的，在公司的开发部做测试。公司也是什么文档都没有，我建议他们一些细节的修改，他们觉得这个不影响功能，现在就不改。以后有时间再说。。。。。我也不好说什么。。。。

作者: caoyuanxuelang 时间: 2009-11-25 13:36
想是做的开始，计划是行动的开始。
对于小公司来说，指定计划也是必须的。相信大家都学过磨刀不误砍柴工，计划就是磨刀了，计划做好了，下面的工作就不会出现一些事倍功半的问题了。
人力资源和设备资源的使用以及时间的安排都是非常重要的，麻雀虽小，五脏俱全，五脏都要来协调身体运动的，公司虽然小，没有一个整体的计划，各个部门之间配合出现问题，那么就不能支撑公司的正常运作了。
所以不管公司是大是小，都是要制定计划的。

作者: Michael0112 时间: 2011-3-13 10:57
计划

作者: 春天梅花 时间: 2011-5-5 13:42

作者: 祝兄jz 时间: 2012-1-30 14:48
不错的~~! 感谢您提供

蛇胆疮带状孢疹蛇胆疮后遗症蛇胆疮怎么治疗 www.shedanchuang.cn

作者: weiweixiaocao 时间: 2012-5-30 20:20
支持一下！！呵呵

作者: changpei12315 时间: 2014-7-8 23:28
现在很多企业，喜欢采用敏捷开发方式，这样不仅能够保证按时完成项目，而且对于维护也很方便。但是对于一个成熟的软件公司来说，在开发之前，做好需求分析及测试，对整个项目的后期维护等有很大的好处，据不准确性统计，软件的后期维护费用将会级数增长，所以，前期做好相关分析及测试后再出产品，会节约很大成本。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)