软件项目开发没规划好就注定会失败

软件项目开发没规划好就注定会失败

软件项目开发与管理的一些原则

软件项目的开发与管理是一门复杂的学问,不是简单地需求来了就动手编码,编码完了就算项目完工那么简单。一个项目如果没有好好规划,那么就很容易会失败。同样,我们在做一个软件项目的时候,需要注意的东西很多,下面总结一下一些容易视而不见但又非常重要的软件开发指导原则。

对外部环境的认识

1、必要性原则:用户(客户)需要应用软件来帮助他们处理信息。

2、“脱机”原则1:用户(客户)通常不会一直坐在电脑面前,他们都有自己的工作要做,而那些工作才是他们真正要做的事情。如果你是秘书,那么,电 脑不会帮你做会议纪要,也不会给你安排老板喜欢的度假酒店。极端一点,假设你是清洁工人,一台多点触摸的 surface 即使再逼真的让你看到街角的一小块垃圾,你最后也还是得用扫帚去清除。

3、“脱机”原则2:不要把用户(客户)想象成电脑专家。下班后他们会回家吃饭、看电视、逛街、看电影。很多搞手机应用的人注定失败,原因就在于他们想象用户会从起床开始到睡觉都一直盯着手机看,实际情况是:没有人会这样。

4、需求原则1:“要求”不等于“需求”。如果有人要求你给他(她)做一个能看电影的收音机,那么,你应当告诉他(她):“你需要的是一台带收音机的MP4播放器。”而不是立即开始开发“电影收音机”。

5、需求原则2:需求是会发生变化的。所以,你要做的,就是尽早发现这种变化并尽可能提高自己应对变化的能力。

6、很多人还没有意识到“信息”以及处理信息的软件对改善他们工作的重要性。但这不是他们的“错”。

开发的原则

1、技术非常的关键!“技术上没有问题,问题在于…”说这样的话只能证明这人在技术上的确存在问题。

2、但,技术需要用户(客户)的需求来引导。永远按照需求来选择(甚至学习)技术,而不是相反。

3、限制性原则:技术不可能什么都能实现!参见“‘脱机’原则1”

4、适用性原则:只要分析到位,用户(客户)的需求,技术一定能够实现。参见“必要性原则”

5、“速度”原则:除非编码(Coding)在软件的整个生产过程中占到 50% 甚至更高,否则,任何希望提高编码速度来换取更快进度的努力都会以失败告终。但是,有编码在整个软件生产过程中占到甚至超过 50% 的项目吗?没有。所以,任何希望通过提高编码速度来换取更快进度的努力最后都会以失败告终。

为什么?参考“需求原则1” 和 “需求原则2” ,以及下面的“管理的原则”。

管理的原则

1、技术相关原则:技术决定工艺流程和工种,由此,决定了团队的构成和所有管理的基础(基础技术假设)。

Web 应用程序是通过在服务器获取数据并组合成网页展示给用户来工作的,所以,你的团队里面要有会制作网页和会写代码从数据库取数据的成员,并且,在进度上,网页要早于代码完成以便集成。

2、因为需求会(而且可能很快)变化,所以,为减少对管理带来的冲击,应当在一开始就选用适应力最强的技术。

3、“最少”原则:任何管理和技术上的努力与技巧,都比不过一开始就明确只做最少的内容。如果这一点做不到,那么,也许应该试试:

4、“设计优先”原则:尽可能给设计多点时间,这是我们思考的过程。如果这一点也做不到,那么,也许应该试试:

5、“死亡冲刺”:先做出来再说,有问题以后再改。不过,请做好足够的心理准备,你要应对的不仅仅是总体成本和维护工作量的上升,更严重的是团队成员的质疑、无休止的加班和逐渐低落的士气。

6、“最小管理”原则:如果你真的是没有办法了,但是还是希望能够对软件的生产过程进行控制,那么,就做好配置管理吧。

只要你每次在任意一台服务器上从配置库获取最新代码都能够在10分钟内完成部署,并且,在生产环境中部署的软件也是这个版本,那就应该差不多了。

7、“国情”原则:适合你的管理方法一定是你从你自己的实践和需要出发摸索出来的,其它的各种理论、方法、实践都只能作为参考。

时间: 2024-10-17 10:09:11

软件项目开发没规划好就注定会失败的相关文章

软件项目开发总结,假如历史可以重来

TD学生助手--release版发布 1.设想和目标  1.我们的软件要解决的问题 TD学生助手的主要核心思想就是帮助学生安排他们忙碌的学校生活.主要是通过以下几个方面 1.通过学生的需要进行分类(考试,实验,发博客等等),添加日程,保存日程到数据库中,将日程模块化管理: 2.用月视图和周视图,日视图三个视图来管理添加进去的日程,让日程管理起来更加直观,方便,增强用户体验. 2.是否有充足的时间来做计划 我们做计划主要是在Sprint计划刚开始的时候进行计划,并在以后实施计划时进行调整,但是由于

软件项目开发流程

软件开发流程(Software development process) 首先 看一下基本软件项目开发流程图 其中 1.需求分析: 通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书. 2.总体设计: 通过分析需求信息,对系统的外部条件及内部业务需求进行抽象建模,最终形成概要设计说明文档. 3.详细设计: 此部分在对需求和概要设计的基础上进行系统的详细设计(也包含部分代码说明). 4.开发编程: 对系统进行代码编写. 5.测试分析与系统整合: 对所有功能模块进行模

软件项目开发团队组员跨项目组兼职案例分析

按照现代项目管理的观点,项目团队是指"项目的中心管理小组,由一群人集合而成并被看作是一个组,他们共同承担项目目标的责任,兼职或者全职地向项目经理进行汇报". 项目团队的特征有: (1)项目团队具有一定的目的 项目团队的使命就是完成某项特定的任务,实现项目的既定目标,满足客户的需求.此外项目利益相关者的需求具有多样性的特征,因此项目团队的目标也具有多元性. (2)项目团队是临时组织 项目团队有明确的生命周期,随着项目的产生而产生,项目任务的完成而结束,即可解散.它是一种临时性的组织. (

中小型软件项目开发一般流程建议

一:编写目的 本文档的编写旨在探寻规范的软件开发流程.加快软件开发速度.提高软件开发质量.降低项目综合成本. IT界有一句格言:"You can do it right; you can do it fast; you can do it cheap. Pick two." 而我们要做的就是:提供优质服务.项目周期短.成本低廉 二:总体说明 项目从用户需求说明书的提出,到系统的第一个完整版本的交付使用经历了若干或复杂或简单的过程,但不管项目大小如何一般需要经历以下几个步骤: 1.  

小型软件项目开发流程探讨

一.导言 国内很多项目都是小型项目, 参与人员少(两到五个人), 要快速交付(一两个月) . 要成功完成这种项目, 除了使用成熟且被团队成员熟练使用的技术之外, 有一个良好的开发流程, 也是很必要的. 二.小型软件项目开发流程 下图是我对小型软件项目开发流程的一个设想: 需求分析的重要性想必大家都应该清楚, 对于项目来说, 满足用户的需求是第一位的. 因为时间紧, 系统设计经常被忽略. 这会留下很大的隐患, 国内很多项目的需求通常是很简略的, 还需要在系统设计阶段把一些需求进一步的明确. 不然会

软件项目开发环境构建之一:整体流程

通常情况下,一个大的项目,很难一个人完成,需要一个团队共同协作,大家彼此分工,共同完成不同或相同的模块,这时要求所使用的工具软件要具有分布式协同功能.处理冲突及持续交付功能,一般软件项目的整体流程如下: 一个软件项目的实施,要经过概念阶段.计划阶段.创建阶段.发布阶段及追踪阶段,Atlassion的软件族都有各阶段的对应软件. 一般,概念阶段,可以使用Confluence 进行需求管理,从最初的想法到最终的需求,能够通过Confluence强大的协同功能,高效的完成需求收集.整理.分类等工作(M

用互联网思维来开发客户端软件——项目开发小结

随着智能手机.平板电脑的快速发展,台式电脑在个人用户那里已经没落了,但是台式电脑仍然是企业用户工作中的主要工具,且具有不可替代的作用.客户端软件在企业级用户那里有着不可替代的作用,结合时代发展,我们应以互联网思维来做好企业级应用客户端软件?研发快速迭代.快速试错,把大功能拆分成小功能,分阶段实现,追求微创新. 通常企业级应用的客户端,就是企业管理应用系统,一般分为BS与CS两种架构,CS架构要求在用户的电脑上装上客户端与数据库,或者数据库安装在数据库服务器上.这种方式我们经常会碰到一些问题,比如

资深架构师的经验分享——软件项目开发和决策

这篇文章是关于什么的 参与项目决策的人必须意识到他们的决定对项目的成功和成本以及时间和金钱的影响. 对于我20多年的软件开发经验和10多年的咨询工作,我作为架构师或开发人员参与了许多项目 - 其中大多数成功,有些失败,但每个项目(无论成功与否)都涉及好的和不好的决策由各种人制作. 本文的目的是通过提倡根据我的经验做出的决定以及避免错误的决策来为项目成功奠定基础. 总的来说,我拥有C ++,Java,C#和JavaScript的经验,但在过去的10年中,我一直主要致力于C#桌面应用程序.尽管如此,

软件项目开发中需求分析与设计时间和开发时间的比例分配的问题

从毕业到现在做开发已经有近7年了,大大小小的项目也经历了几十个了.在项目开发的过程中很少有项目在设计阶段投入很多时间的, 有很多情况下,甚至都没有怎么做设计就直接开始编码了,处于一种边开发边设计到状态,还有些时候,设计就是完成一些文档来应付下,很 少有认认真真做设计,然后就直接开始编码,如果遇到需求上问题,再确认.还有些时候,是一边确认需求,一边开始做原型,然后再进入开 发,这种方式倒是比较好,至少可以在前期发现很多问题,避免后续的重大问题出现的几率. 其实从我个人的角度来观察,很多时候我们重开