Quora阅读

1.软件开发周期总是预估的2~3倍

其中存在很多不可抗的因素，有人力，技术，万恶甲方因素等等，诸多因素导致软件开发的周期总是比预估多出很多。

软件开发周期预估：

软件开发周期预估就是根据软件的开发内容、开发工具、开发人员等因素对需求调研、程序设计、编码、测试等整个开发过程所花费的时间做的预测。

软件开发周期预估在软件开发中也是较为困难的工序之一，因为软件开发所涉及的因素不仅多而且异常复杂。软件开发是一项非常复杂的工程，不仅包含需求分析、设计、编码、测试、实施、维护等不同的过程，还涉及到开发工具、开发人员、项目管理、风险等众多因素，不同因素会对周期预估产生不同的影响。

当低估项目周期时，会造成人力低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量。而项目周期估计过长，也会带来成本估计过高，人力资源利用不充分效率低下的后果。所以，过长过短的预估周期都是不好的，周期预估就是后续开发工作的基础，它完成质量的好坏所带来的影响会贯穿整个项目，由此可见开发周期正确估算的重要性。

周期延迟的因素

1.构造软件框架时做的东西没有也无法全量覆盖 业务需求、技术难点 等，导致与实际落地产品 差距甚大。

2.需求理解有差异，用户表达的是这样的，而程序员的理解是这样的，且客户需求不定，增加需求，组织协调不畅。

3.项目经理没有处理好任务的时间分配。有的任务分配时间过长，浪费了时间，有的任务分配时间过短，没时间去完成。

4. 某些独立的任务一致性要求高，无法增添人员并行加速，因为有些任务对于思考的连贯性很强，如果强行加派人手，只会 频繁中断。

5. 开发人员对实现目标的可能出现的问题，估计不足，往往会低估问题的复杂程度。风险意识不足，没有意识到风险或者意识到风险响应错误不及时

6. 项目技术难度很大，花费的时间超过原先的估计。

7. 程序员大多是乐观的，乐观表现于假定一切运作是良好的，而事实经常相反。

8. 人力资源也会对估算影响，表现在技术水平、理解能力、沟通能力等几个方面，编程水平的高低、速度的快慢、能否适应团队、能否与各成员保持良好的沟通都会对开发进度产生影响， 软件开发周期估算前，应对开发人员的技术水平进行定级，然后依据项目组实际人员的水平做修正，这样可以减少对后期开发预估的误差。评价程序员的技术水平可以从编程熟练程度、编程速度、解决技术问题的能力几个因素考虑。

另外还有其他因素：

1、项目范围边界未确定好

在对项目尚不了解的情况下，如何估算项目工期？很难找出一位客户可以准确地说出他们的系统应该如何运行。

例：开发人员参与的每一个大型项目几乎无一例外都要求系统具有“灵活性”，换句话说就是，客户希望系统能处理将来需要处理的一切，但他们也说不清究竟需要什么功能，因此，“灵活性”本质上不是系统需求，因为它是一个模糊的概念。

2、开发时间由非程序员估算

如果你不是程序员，不要私自猜测开发需要的时间，如果项目经理象写小说那样虚构估算，项目注定会失去控制，开发时间的估算应该听取程序员的意见。

3、开发人员的估算太过乐观

开发人员估算时间一般都只考虑了编码需要的时间，另外，每个人的开发速度和效率都不一样，许多开发人员在估算开发时间时都过于乐观，他们往往会忽略掉诸如项目管理，需求整理，讨论，缺勤，电脑问题等因素。

4、没有充分解剖项目

对于一个独立的功能，如果估算的开发时间超过了一周就要小心了，象这样的功能应该进一步细分，这样开发人员可以更详细地分析更复杂的问题。

5、估算多少时间就使用多少时间

给一个程序员5天时间让他完成一个任务，他就一定会用5天时间，软件开发是可以无级变速的，任何代码都可以进行改善，如果开发人员只花了3天就完成了任务，他们会用剩下的时间来调整代码或干脆做其它事情。

遗憾的是，这将会导致估算时间成为开发所需的最小时间，实际交付时间只能被进一步推迟。

6、开发人员多!=开发速度快

一个需要耗时100天的项目不可能用100个开发人员1天就完成了，开发人员越多只会导致项目复杂性呈指数级增长。

7、项目范围变更

这可能是每个开发人员感觉最头疼的问题，有时是应客户的要求对功能进行修改或添加，有时会是CEO一时兴起，觉得某个功能很酷就要求加上或修改。

8、估算被固定

估算应是一个持续的过程，应随系统的开发进度不断更新，程序员往往会认为他们能够弥补逝去的时间，但却很少有人真正做到。

9、遗忘了测试时间

要让开发人员自己测试自己的代码是不现实的，他们知道代码是如何工作的，因此会潜意识地使用一个特殊的测试方法，通常，测试和调试时间需要占到开发时间的50%。

10、估算得太死

非程序员很少能体会到软件开发的复杂性，因此很少有项目计划不被迫延后，影响项目进展的因素很多，估算时如果不预留部分机动时间，最终只会是一个失败的估算。

开发延迟会导致代价高昂的连锁反应，遗憾的是，出了问题大家都喜欢将责任归咎于底层的程序员，这样下去对以后的项目也会不利，因为程序员会吃一盏长一智，下一次他们要么拒绝提供估算时间，要么会夸大开发时间。

软件项目常常会出现各种各样的变更，最好的办法只能是面对变化，在每次变化后对项目进行重新估算并进行相应的工作调整。根据变化及时更改预估值，也不失是接近精确值的方法之一。

2.软件开发方论让你觉得糟糕

软件工程方法论令我们着觉得很糟糕，因为我们在真正的进行软件开发之前，并没有办法预测我该项目适用于哪种开发方法，如果一味的只知道死套前人的方法，束缚了思想，那肯定得不到预期想要的结果。用代码的行数取衡量一个开发人员的优劣，同样是不正确的。项目成功的唯一正确度量是最终的结果在生命周期里是否达到了预期目标。对项目获得的反馈少等因素IT专业人士很难获得成功产品和服务所需的技能。

3.从瀑布到敏捷——漫画解读软件开发模式变迁史》

瀑布模型有很多优点：1.有明确的交接点

2.责任明确

3.发生问题能准确溯源

4.流程划分清晰

缺点：1.反馈结果单一

2.客户不参与开发过程

3.新需求的增加会打乱整个发布节奏

4.造成人力资源浪费

敏捷开发成功地弥补了瀑布式开发的不足，有很大的优势：

1.

强调“响应变化”

2.使资源利用最大化

3.反馈及时

4.短周期

缺点：1.忽视文档的重要性

2.开发成本高

3.需求分析失误有偏差

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！