下面小编给大家整理的软件项目成功之道(共含5篇），欢迎阅读!同时，但愿您也能像本文投稿人“迷人小狗”一样，积极向本站投稿分享好文章。
作者以精炼、风趣的语言揭开了项目管理过程的神秘面纱。所涵盖的内容涉及工具、使用项目技术、曳光弹开发以及常见问题的解决办法，并提供大量实用建议，且总结出方方面面的“技巧”，帮助读者在阅读过程中快速消化所看内容。
《软件项目成功之道》适合软件研发专业人士阅读，对软件项目管理感兴趣的社会各界人士也能从中获益。
Jared R. Richardson是一名开发人员、演说家、作家和独立顾问，是由开发人员逐步成长为研发经理的。他有着十多年丰富的工作经验，擅长使用非定制技术来解 决疑难问题。他领导着SAS软件研究所的一个开发和测试团队，负责带领整个公司提高了测试自动化的使用。
William A. Gwaltney Jr.有着二十多年软件开发经验，在网络、通信、知识表达及基于网络的计划调度方面都很有造诣。他在SAS软件研究所从事测试自动化方面的工作。
如果我们坚持不懈，那么，优秀就不再是一种行为，而成为一个习惯。
亚里士多德
绪 论
如今，很多软件开发人员都很困惑。他们夜以继日、废寝忘食地工作，可是他们的团队还是无法顺利地完成项目。不是他们的努力不够，也不是愿望不强烈：团队里的每一个人都希望能干净利落地把项目搞定，不过大家都不知道如何共同努力完成工作。你很难有时间坐下来静心读点东西，做些试验，得出哪些做法可行以及如何在你的工作室合理运用。大多数人都太忙于手头的工作，而无暇顾及这种研究。
本书就这样应运而生。这本书汇集了大量基本而实用的建议，这些建议已经在这个领域的多个项目以及大小公司中得到充分证明。我们的亲眼所见和亲身经历可以证明这些方法确实可行。我们不同于那些只在公司出出进进几个星期就离开的顾问，而是天天都在这些公司全力工作。我们并不只是提出一些听起来不错的想法，就匆匆转向下一个预约项目。如果这些想法没有效果，我们还会留在公司查看为什么会失败，哪里出了问题。另一方面，我们必须等到情况好转，工作能够顺利进行下去。
我们介绍的想法有些是从一些众所周知的软件方法中得来的，我们会尽量指明它们的出处。另外一些想法则是我们用热血、汗水和泪水“凝结”而成的。我们尝试过很多工具、技术和最佳实践，如果可行就会将其保留;如果失败，就会断然地放弃。在这里你几乎看不到我们通过盲目摸索得来的一手经验(尽管这是好东西)。相反，我们会“站在巨人的肩上”，精选出这个行业最睿智的思想，把它们转化为你将看到的文字。
如今，50%~70%的软件开发团队并没有使用那些基本的、众所周知的软件实践([Cus03])。很多情况下，这并不是因为他们不知道要做什么，而是因为他们不清楚该如何立即开始运用这些实践。我们会告诉你如何向管理层推销这些想法，给出能够让你迅速上手的明确的实用步骤，然后指出要注意哪些警告信号以免脱离正轨。
本书由“一线”开发人员倾力编写。这本书凝聚了我们在不同公司的实践中得出的经验(从初创的小型公司，到全世界最大的私营软件公司)，而不是刻板的理论。这是一个不依赖具体方法论的指南，更注重如何让项目顺利完成。
我们努力使这本书沿袭PragmaticBookshelf图书一贯秉承的风格：实用、简洁，轻松阅读。希望能将这一风格发扬光大。
不论是对你自己还是对你的职业发展，最明智的一项投资就是让你身边有一些“合适”的人——他们会成为你能找到的最好的资源。这些人可能已经做过你打算做或者想学着做的事情。如果你想做一些事情，最好找到那些做过这些工作的人，或者至少找到一些真正睿智的人，能够告诉你该怎样完成这些工作。尽可能和他们多待些时间，通过相互帮助来向他们学习。与这些高水平的人相处，会让你学到很多东西，不论你的工作是什么，这都会让你表现得更出色。
这是一个很好的想法，但是要想与那些顶尖人物接触可能很困难。像Martin Fowler、Kent Beck和Pragmatic Programmers的作者等大师级人物，并不是我们大多数人有机会见到的，不过我们可以看到他们的书、文章和演示文稿。所以要开始读书。一个月读一本书应该不会太费劲。但是不要就此止步，接下来可以学习一种新的编程语言，或者研究一个不同的开发过程。在学习和读书时，要想办法把这些新思想应用到当前的工作中。这样一来，你不仅能帮助你的公司提升，更重要的是，还可以让你自己得到提高。
要让自己开放地接受新思想。不要闭塞，应当想办法把这些新思想应用到你现在的工作中。也许你会放弃，并声称某种新思想不适用，这样做当然更轻松，不过我们的目标是学习采用另外一种不同的方式考虑问题。要打破条条框框(或者至少建一个更大的框框)。多学习掌握一些看似不太相关的概念和思想。
通过对环境和过程进行分析和评判，你可以找出弱点。也许这会帮助你对这个项目或者下一个项目做出改进。但同时你也练习了一种新的思维方式，不论在哪里工作这对你都会有好处。大多数人从来不曾了解这个概念，擅长的人更是少之又少。
所以，读完这本书的每个实践后，请停下来，花5分钟时间试着想想有没有办法在你今天做的工作中具体运用各个概念。你可能不假思索地回答：无法做到。这种回答当然最不费劲，不过要记住，不能这么懈怠，你应当更加努力!如果你自己找不出一种方法来应用这个概念，可以找一位同事来帮忙。如果仅凭自己的双眼看不到，可以借助别人的视角来了解。不论在什么领域，知道如何利用同事的经验，绝对是高手特有的标志。
希望你掌握从本书(和整个Pragmatic Starter Kit系列)读到的内容，想办法在工作中应用每一个概念。你会看到读这本书给你带来的直接好处，其中最大的好处就是你会学习如何真正加以应用。
希望你喜欢!
致谢
首先要感谢Andy和Dave让我们为Pragmatic Bookshelf写一本书。能为你们写一本书真是荣幸。Andy，你做的已经远远超出了你的份内职责，甚至花好几个小时与我们一同修改手稿，给我们上了一堂写作速成课，尽管有时对我们的写作天份……有些发愁(我们确信你肯定失望过)。Dave，我们曾经问过很多关于图书生成系统和标记语言细节的问题，感谢你花那么多时间回答这些邮件。非常感谢你们二位!
我们有很多非常棒的审校人员，另外还有很多人做出了贡献，他们详细而且有建设性的反馈确实意义重大。没有你们投入的时间，没有你们丰富的经验，这本书不可能出版。Susan Henshaw和Jim Weiss花了大量时间审校我们粗糙的文字，而且读过不止一遍。谢谢你们。
还要感谢Mike Clark、David Bock、Ken Pugh、Dominique Plante、Justin McCarthy、Al Chou、Bryan Ewbanks、Graham Brooks、Grant Bremer、Guerry Semones、Joe Fair、Mark Donoghue、Roberto Gianassi、Rob Sartin、Shae Erisson、Stefan Schmiedl和Andy Lester。你们当中很多人曾忍受过这本书很早的版本，最近我们重新读了你们原先读过的版本，对你们曾经遭受的“折磨”我们深表歉意。说真的，所有反馈都很棒，正是有了这些反馈，这本书才得到了如此显著的改进。
在我们的职业生涯中，曾经与很多人共事过，其中有些人对我们的工作以及这本书产生了直接的影响。我们要特别感谢Jim Weiss、Randy Humes、Graham Wright、Flint O’Brien、Toby Segaran和John Wilbanks。还要感谢我们现在的经理Oita Coleman对我们的鼓励和支持。我们很幸运，能够在SAS这样的世界级公司工作。
如果没有敏捷开发社区的智慧，没有大家出色的作品，这本书绝无可能问世。我们读过XP、Scrum、Crystal以及很多其他软件领域专家的书和文章。没有你们辛苦而忘我的工作，软件行业可能还在黑暗岁月中挣扎。也许我们还没有完全走出黑暗，不过起码正朝着正确的方向前进。你们孜孜不倦的工作让大家受益匪浅。
开源社区共同为全世界提供了这么多非凡的工具和想法，同样要向你们表示感谢。正是因为全世界开发人员的无私奉献，我们这里讨论的大多数工具才可以免费使用。在此要特别提到SourceForge团队和Apache 软件基金会。你们提供的服务和工具不仅让我们提高了生产效率，还改变了整个世界。
最后，也是最重要的，要感谢我们的主，耶稣基督，愿主永得荣耀!
Jared Richardson和William Gwaltney
我的妻子Debra为这本书投入了大量的时间和精力。甚至有好几个星期Debra花在这本书上的时间比Will和我还要多。其余的时间她既做母亲又做父亲，才让我得以安心地完成这本书。我发自内心地相信，如果没有她的帮助和支持，我绝对不可能完成这个工作。谢谢你!
我的孩子们，Hannah和Elisabeth，很多个夜晚和周末爸爸都把自己锁在办公室里一心扑在这本书上，感谢你们忍受了这一切。谢谢你们的理解和爱!
王总经营一家小型的软件公司，为某行业做管理信息系统。早几年，工作非常顺利，哥儿们几个干的得心应手。用户关系王总一人全部搞定。
可是，公司发展大了，项目却越来越难做了。倒不是因为用户关系方面，而是项目时间越来越长、迟迟不能结束。在王总看来，手下的几个高手，现在是越来越搞不定了。技术没有什么变化，用户还是老用户，是他们的能力下降了，还是他们不想干了。好象都不是。
哪是为什么?
王总一筹莫展，退的心思都有了。
我认为主要是因为没有建立有效的项目管理体系。创业之初，大家都有工作热情，而且都是团结一致、一门心思想取得好成绩，所以在大家的共同努力下，工作就会非常顺利。然而几年后，情况就变了。一方面是因为公司规模的扩大，各部门的组织与协调的不善，就会导致项目完成的困难;另一方面是因为员工的倦怠心理，以及人际关系的微妙变化。所以就要求企业要建立健全项目管理体系。
项目管理是通过项目各方干系人的合作，把各种资源应用于项目，以实现项目的目标，使项目干系人的需求得到不同程度的满足。软件项目的成功来之不易，成功的几率很小。成功的软件项目依赖成功的项目管理，而项目管理是企业软件项目成功的保证。
失败的项目原因很多，在这个案例中我认为主要是因为：人员士气下降。但很多项目经理以及高层领导都没能意识到在项目进展过程中人的真正作用和重要性。项目管理中人的管理对项目的顺利结束起着举足重轻的作用，沟通、协调好项咳嗽惫叵凳浅晒Φ墓丶
分析这个案例，我觉得有几方面需要注意：
首先，项目经理要有项目计划意识。因为制定计划的过程就是一个对项目逐渐了解掌握的过程，通过认真地制定计划，项目经理可以知道哪些要素是明确的，哪些要素是要逐渐明确的，通过渐近明细不断完善项目计划。阶段计划中包含的工作汇报和下一阶段工作安排是掌握项目进度的依据，从阶段计划对照总体计划，才能一目了然地看出工作的进展情况。制定计划的过程，也是在进度、资源、范围之间寻求一种平衡的过程。制定计划的精髓不在于写出一份好看的文档，而在于运用智慧去应对各种问题和面临风险并尽可能做出前瞻性的思考。一旦计划被负责任地完成，就可以给自己一个和客户交流与协商的基础，帮助防范项目过程中各种问题的出现，以及保证项目按时完成。在高技术行业，日新月异是主要特点，因此计划的制定就需要不断地完善。反之，如果项目经理对总体计划、阶段计划的作用认识不足，做计划是走过场，比较随意，不少事情没有仔细考虑，就会导致阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。 因此就要求提高项目经理的计划意识，采用项目计划制定相关各种知识、技术、工具，加强对开发计划、阶段计划的有效性进行事前事后的评估。
其次，项目团队要有集体意识。因为项目团队内部有时由于角色之间的责任分工不够清晰而造成工作互相推诿、责任互相推卸的现象;或是各项目成员只顾完成自己那部分任务、不愿意与他人协作。这些现象或多或少地造成了项目团队内部资源的损耗，从而影响了项目的进展。而出现这种情况主要是项目经理的责任，项目经理应当尽快地将工作范围进行分解，并将分解的工作责任分配给团队成员，这样就可以按任务分清每个人的责任。特别是从事高科技的开发项目，更应使人员根据需要相互协作，相互配合，共同完成项目任务。所以，项目团队内分工协作问题十分重要。项目经理应当对项目成员的责任进行合理的分配并清楚地说明，同时应强调不同分工、不同环节的成员应当相互协作，共同完善。
最后，还要注意管理工作中人员的沟通。沟通的目的是为了两个人之间的交流，对于交换信息、拓宽思路和统一认识，沟通的作用巨大，而且很多时候是必不可少的。要了解和关心每一个项目组成员，这种关心不是表面工作，不是说两句冠冕堂皇的官话，而是将关心落实到实处，了解每个成员的长处和不足，安排工作时尽量发挥他的长处，多交流，一旦有人攻克了一个技术难题，取得了大的进展一定要当众给予表扬。另外若有成员在工作以外的方面遇到问题，也应该力所能及的给与帮助。总之，要将心比心、设身处地为下属着想。项目经理在工作中要以身作则，勇于承担责任和压力，实行恩威并重的管理策略。管理要讲艺术性，在一个项目组内有的人工作积极，而有些可能很懒散，得过且过，对于工作态度不积极的成员要分析原因采取相应措施，进行监督和控制，必要时候可以采取一定的惩罚手段。
如果我是王总，面对这种困惑我不会放弃，因为这不仅仅是一个人的成就，这是好朋友们同甘共苦拼搏出来的，怎么能遇到困难就畏惧不前呢!我觉得应该和项目人员们推心置腹地好好谈谈，既然不是他们不想干了，那就一定有别的原因，只有找出原因才能对症下药。另外，更重要的一点就是严格项目管理机制，创造和保持一种使项目顺利进行的环境，使各项工作有条不紊的进行。虽然这个案例在项目的进度上出现问题，但这绝不是单纯的一方面，它反映了整个项目管理机制亟待改进提高。
通过这个案例，我认识到一个项目经理并不好当，不仅要制订周密的计划，还要及时管理变化。尤其是在当今社会中，一切都是项目，一切也将成为项目。项目管理是一门学科，也是一个专业，更是一种职业。只有努力学习项目管理相关知识、技能，在实践中锻炼提高，解决各种各样的问题，才能使项目管理工作越做越好。
★ 小企业成功之道
★ 经商成功之道
★ 五粮液成功之道
★ 软件项目年终总结
★ 软件项目计划书
★ 软件项目策划书
★ 软件项目策划书
★ 软件项目总结
★ 李嘉诚的成功之道
★ 海底捞成功之道
