软件开发流程疑问？

chengxq

我们公司是从事软件外包的，现在一项目正在设计开发阶段，项目经理的意思是，由于现在对产品不明确
一边编码一边写详细式样书，或者先编码在写详细式样书，因为这是从进度方面考虑的，我也知道这样做法在后期对应维护等存在很多的风险和问题，但是我却不知道如何说服项目经理，请各位大虾给出自己的看法！
谢谢！

tofy

原帖由 luoyear 于 2008-5-10 08:03 发表
这是一个软件外包行业很经典的问题。很多问题也许是合同签署的时候就埋下了隐患，所以此时的焦点不是讨论先编码还是先写设计文档的事情，因为这压根就不是问题的根源。
问题的根源在于我们对这种渐进明晰的项目，在 ...

赞同，对于这种项目还是采用原型法合适！

迷雾精灵

原帖由 luoyear 于 2008-5-10 08:03 发表
这是一个软件外包行业很经典的问题。很多问题也许是合同签署的时候就埋下了隐患，所以此时的焦点不是讨论先编码还是先写设计文档的事情，因为这压根就不是问题的根源。
问题的根源在于我们对这种渐进明晰的项目，在 ...

说得真中要害！

zhongmg108

那这个详细说明书除了花费更多时间,还有什么正面作用呢? 仅仅是为了应付客户吗?
如果项目规模比较小的话,可以采用直接编码的快捷开发模式,但要与客户达成一致.
其实详细设计对客户来说并没有多大意义,他只是通过阶段产品来监控项目质量,以提前发现问题,降低风险!
如果项目组连详细设计都不知如何写的话,这样的项目确实风险很大.

gracedl

觉得最好还是在需求调研阶段就采有原型法。也就是设计阶段与需求阶段同时进入。这样一来可以保证需求的正确性，避免模糊需求，如果在懒的也可以把两个文档在一起写包含功能性需求与非功能性需求，加上原型贴图，那后期就是编码了。前提还是采用正确的原型工具及方法，应该说比较适合周期短的项目，外包情况下不知道如何。

chengxq

原帖由 Yarlun 于 2008-5-13 10:44 发表
是不是文档不能解释清楚，通过编码和文档展示给客户，说明自己观点啊？
还有“项目经理打算一边写详细设计书，一边编码”，觉得在这种情况下，你们应该主动向项目经理了解项目（是要做什么，需要怎么做，我们得做什 ...

主要是由于项目组成员都是新员工，没有写详细设计书的经验，项目经理打算一边编码，一边写详细设计书，这样互相补充。
我的考虑是：由于项目的实际情况，如果真的必须要把详细设计书写详细，精确到某个函数，某个class，估计也不能够作到，因为大家都没经验
我想可以一边编码，一边设计，主要是对过程的控制，如增加检查的频率，任务的细化，多review，同时项目经理要及时确认来进行控制！
不知道这样做，是否可行？望指教！
谢谢！

Yarlun

是不是文档不能解释清楚，通过编码和文档展示给客户，说明自己观点啊？
还有“项目经理打算一边写详细设计书，一边编码”，觉得在这种情况下，你们应该主动向项目经理了解项目（是要做什么，需要怎么做，我们得做什么），这样才能让项目正常化进行

chengxq

原帖由 luoyear 于 2008-5-10 08:03 发表
这是一个软件外包行业很经典的问题。很多问题也许是合同签署的时候就埋下了隐患，所以此时的焦点不是讨论先编码还是先写设计文档的事情，因为这压根就不是问题的根源。
问题的根源在于我们对这种渐进明晰的项目，在 ...

谢谢！感觉你说的我明白，可是我仔细想了想，我还是不明白，因为项目一要赶进度，二由于项目组年轻成员过多没有这方面的经验，综合二个因素项目经理打算一边写详细设计书，一边编码！您的解决方案，和项目选择生命周期我不太清楚有何关系，还请赐教！
谢谢！

luoyear

这是一个软件外包行业很经典的问题。很多问题也许是合同签署的时候就埋下了隐患，所以此时的焦点不是讨论先编码还是先写设计文档的事情，因为这压根就不是问题的根源。
问题的根源在于我们对这种渐进明晰的项目，在给与客户Proposal的时候，就缺乏一个明确的建议，比方采用原型法，或者多轮跌代，但每轮跌代是有明确的进入准则和退出准则的。在这种开发模式下，再来谈怎么样的一个文档体系，才是解决问题的王道。