前言
第一次写论文，随便啦。 反正也不是什么很重要的，就放这里咯。笑死，学习通查重率40%多。 跟预料差不多。
正文
在上大学之前，对于软件工程虽然有一定的了解，但是对于企业团队的开发的项目管理并非清楚。只了解企业之间的团队协作不是简简单单的上对下的关系。而我自己一直想做一个软件开发的精英，那么自然需要了解软件开发团队如何进行项目管理。通过听了软件专业导论课以后对于软件开发团队项目管理有了一个新的和更深的认识，也对自己未来的四年学习方向重新进行了思考。
现在我对于软件开发项目管理的认识是：
- 软件开发项目管理大致可以分为两类：
- 软件创新
- 软件项目感力
- 项目是定义明确的任务，这是为了实现某个目的（例如：软件开发、交付和管理）进行的一系列操作的整合。一个项目可以表征为：
- 每个项目都可以有一个独特而鲜活的目标
- 项目不是日常活动或日常运营。
- 项目带有开始时间和结束时间。
- 项目在其目标实现时结束，因为它是组织生命周期中的一个临时阶段。
- 项目需要充足的时间、人力、财力、物力和知识库资源。
以上是对软件开发团队项目管理的基础总结，之所以能有上述的来源。都是历史中开发者经历了若干个大型软件工程项目的失败后，人们逐渐意识到软件项目管理的重要性和特殊性。
对于软件开发失败，事实上不一定是由从事软件开发工作的软件工程师无能，正相反，在软件行业中，绝大多数都是当时杰出的技术专家，对于软件开发有着深刻的认识和独特的见解。而出现软件开发的失败主要是因为管理不善。
所谓管理，就是通过在一个组织内进行计划、组织和控制等一系列活动，合理分配和调动资源，使得组织内可以动态调整，达到既定目标的过程。
那么，为什么软件开发项目管理很有必要？软件被认为是一种无形的产品。软件开发是世界商业中的一种全新流程，在构建软件产品方面的经验不多。大多数软件产品都是根据客户的要求量身定制的。最重要的是底层技术的变化和进步如此频繁和迅速，以至于一种产品的经验可能无法应用于另一种产品。所有这些业务和环境限制都会给软件开发带来风险甚至失败，因此有效管理软件项目至关重要。
综上所述，需要一个很好的项目管理是很有必要的。因此对于开发准备阶段，要进行估算软件规模和工作量估算。确认此次软件项目大致情况以便大致判断工作量。对此引入一个技术“代码行技术”。 代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。对于代码行技术，需要开发者拥有较多的开发经验和开发历史数据。也就是说，如果想要使用代码行技术，你是一位经验较多的开发者或者更进一步说是资深的开发者。但是代码行技术也有一定的缺陷：源程序仅仅是软件配置的一个成分，用它的规模代表整个软件所需要的代码行数并不太合理；因为运用不同开发语言所输出的代码行数并不相同。例如：对于C语言和C# 开发语言输出“HelloWorld”。当然也有相对应的优点，代码是所有项目都有的“产品”，而且容易计算代码行数。如此估算，可以很快定下项目所需要的开发人数，如何管理，生命周期等等。
虽然代码行技术有优点，但是缺点所造成的损失也会有。为了减少在估算软件规模和工作量的偏差程度，进一步引入了“功能点技术”。 所谓功能点，就是根据一个项目所拥有的功能进行判断软件规模。依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP） 为单位度量软件规模。例如：利用PHP实现博客程序 。对于初学者或者经验不足的软件工程师，很可能不适用代码行技术，如果强行使用代码行技术进行代码估算，那么很有可能估算的结果远超于实际。如果使用功能点技术，就拿博客举例，其功能点主要有：前台和后台（这类说法相对不准确），前台是用户访问，可以让用户看到自己编写的博文、分类和写下评论。后台可以让博主写博文、修改博文、删除博文、分类管理、评论管理等内容。依据功能点进行整理，即可以清楚自己的开发架构和逻辑也可以估算项目规模。
以上既是对软件的工程量进行大致分析的方法，对于一个软件的开发，我们需要定义一个生命周期，而不能漫无目的的，没有时间规划进行开发。这样也会造成开发的失败，因此估算开发时间也是非常重要的。估算软件规模可能根据 KLOC（Kilo Line Of Code） 或通过计算软件中的功能点数量进行估算，而工作量的单位通常是人月（pm） 。代码行数取决于编码实践，功能点根据用户或软件的要求而变化。对于大多数估算模型的经验数据，都是从有限个项目的样本中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。因此，我们需要合理估算开发时间。 估算完成给定项目所需的总工作量后，接下来的问题就是：我们需要多长时间才可以完成整个项目的开发工作？假设一下，一个项目估计工作量为100人月。我们可以设想出以下几种进度表：
- 1个人用100个月完成项目。
- 10个人用10个月完成项目。
- 100个人用1个月完成项目。
我们引用上面开发博客程序的例子，博客能够正常运行，需要前台与后台的配合运行，而其允许与之进行配合运行需要后端支持，例如需要后台编写博文后发送给后端API输入进数据库，前台访问从后端API从数据库调取指定数据后显示。则后端就是整个博客程序的核心。如果后端没有开发完成，那么前台和后台就不能够根据后端进行开发，没有开发方向，从而无法下手。因此，上述举例进度表并不现实，实际上软件开发时间与从事开发工作的人数时间并不是简单的反比关系。
软件开发团队为了能够快速解决上述内容，就需要进行进度计划安排。无论从事哪种技术性项目，实际情况都是在实现一个大目标之前往往必须完成数以百计的小任务（也称之为作业）。其中有一些任务称为“关键任务”有一些任务称为“非关键任务”，就如上述博客程序所说，后端属于关键任务，后端的开发进度拖延一定会造成整个程序开发的延期。所以管理人员英高高度关注关键任务的进展情况。 项目管理者的目标是定义全部项目任务，合理分配，识别出关键任务，跟踪任务的进展情况，以确保可以跟踪项目进度情况。为了达到上述目标，管理者必须制定一个足够详细的进度表，以便监督整个项目的进度情况。
对此，我们可以借助可用的工具进行有效的项目管理： 甘特图：甘特图是由亨利·甘特（Henry Gantt,1917） 设计的。它代表与事件段相关的项目进度表，其中的条形表示为项目安排的活动和事件。 虽然甘特图可以很形象描绘任务的分解情况，以及每个子任务（作业）的开始时间和结束时间，但是甘特图不能够显示地描绘各项作业彼此之间的依赖关系；进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；计划中潜力部分不明确，往往会造成资源浪费。故在此之后，引入一个新的概念“工程网络”。工程网络可以解决上述大部分问题，并且可以很明确分出主从关系以及依赖关系。 对于软件项目成功的关键是具有高素质的软件开发人员。然而大多数软件规模都很大，单个软件开发人员无法在给定的期限内完成开发工作。因此，必须把多名开发人员组织起来，合理调度、分配，使之有效地共同完成开发工作。
现有的如那件项目组的组织方式有很多，通常，组织开发人员的方法，取决于所承担的项目特点、以往的组织经验以及管理者的看法和喜好而分出以下三种典型组织方式：
- 民主制程序员组
民主制程序员组的一个重要特点是，小组内成员完全平等，享有充分的民主，通过协商做出技术决策。但是这种类型的程序员组人数不能太多，否则组员之间彼此通信的时间将多余程序设计的时间，也很有可能将使开发失败。因为小组成员之间的通信是平行的，假设小组内有n名成员，那么通信方式y一共有
y=(n(n-1))/2民主制程序员组也有很多优点，例如组员享有充分的民主，小组内具有高度凝聚力，组内学术气氛浓厚，更利于开发者的协调工作、协同攻克难关等。但是民主制程序员组也有很致命的缺点，民主制程序员组内成员是完全平等，是通过协商做出技术决策。因此，往往需要组内成员多数为经验丰富技术熟练的开发者，这样的非正式组织方式可能会非常成功。但是，如果组内多数成员技术水平不高，或者缺乏经验的成员，由于没有明确权威的指导者，组内成员缺乏必要的协调工作，最终可能导致程序的失败。 适合规模：较小 - 主程序员组
主程序员组用经验多、技术好、能力强的程序员作为主程序员，也泛指软件行业中主要的技术开发程序员，此类程序员开发能力强，思维逻辑强等，是项目，公司不可或缺的重要组成人员。采用该组织方式主要出于以下几点进行考虑：
- 软件开发人员多数比较缺乏经验，需要经验丰富具有权威性引导开发。
- 程序设计中有许多事务性的工作，例如大量信息的存储与更新迭代。
- 多渠道通信浪费时间，会降低程序员的生产效率。
而主程序员组中应当具有两个重要特性：专业化、层次性。该组中，需要有主程序员、后被程序员、编程秘书以及1~3名程序员组成。对于其他必要时候，需要其他领域专家协助。例如气象相关软件开发，还需要有气象相关专业人士引导操作。 但是，主程序员组中的成员机制不现实，编程秘书事务繁多且层次较低工资水平也相对较低，而且对于计算机基础以及先对应的开发技术要求较高，所以，这类发现错误修改积极性不高，双重核心容易出错。 适合规模：中等
- 现代程序员组 为了解决著程序员可行性差，不适合大型项目，组员主动性不高。对于大型项目来说，为了能够高效可以很好的利用成员和资源，采用分小组、多层次方式。 解决上述问题的方式是，取消主程序员大部分的行政管理工作。前面已经指出，很难找到既是高度熟练的程序员又是成功的管理员，取消了主程序员的行政管理工作，不仅解决了小组成员不愿发现程序错误的心理问题，也使得寻找主程序员的人选不再是那么困难。那么实际上“主程序员”应当由两个人共同担任：一个技术负责人，一个行政负责人。
但是，这又会引发出一个新的问题。由于“主程序员”是由两个人同时担任的，分别为技术负责人和行政负责人。技术负责人不需要完全明白行政负责人，行政负责人也不需要明白技术，只需要做好自己分内的事情。就是因为这种，会导致对于职责不清楚的矛盾。例如，核心程序员休假问题，行政负责人批准了该程序员的休假，但是由于他是核心程序员，由于他的请假会导致整个项目的延期甚至出现不可预料问题，而技术负责人很可能不批准该程序员的休假，导致的管理权限职责不清晰。而解决这类问题的办法就是求助于更高层次的管理人员，对行政组长和技术组长都认为是属于自己职责的范围内的事务，制定一个处理方案。
由于一个程序员组成员不宜过多，当软件项目规格较大时，可以分为若干小组，采用如下图所示（图中以上述博客程序进行举例，其中黑色线条为相联系部分）的组织架构。由图中可以看出，产品开发作为一个整体是在项目经理的指导下进行的，程序员向他们的组长汇报工作情况。当产品规模增大时，可以适当增加中间管理层次。 但是根据上图不难发现出，组长与组长之间没有沟通，组长下属程序员之间也没有沟通，会导致程序开发效率极低。那么另外一种做法就是在原有的基础上和主程序员组的优点结合起来的另一种方法，是在合适的时候采用分散做决定的方法。如下图所示（黑色线条表示通信渠道）。这样做有利于形成通畅的通信渠道，以便充分发挥每个程序员的积极性与主动性，共同攻克难关。但是上下级之间（管理关系）依旧是向下的，也就是说集中指导下后发挥民主制。我们假设，加入程序员可以指挥项目经理，则只会引起混乱，各级之间的调度失效。
如此，各部门之间都能够有效交流，既避免了程序员数量过多导致民主制成为弊端，又可以促进开发进度和调动程序员开发积极性与主动性。 适合规模：中大型
当人员分配完毕后，进行正式开发过程中，我们不仅需要保证开发能够如期完成，也需要保证软件的质量。概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，一个软件的开发，不仅需要满足用户所诉说的的功能，还应当包括一些隐藏的特征。 什么是隐藏的特征？我们假设用户需求博客程序，诉说了需要的功能外，还应当提供其他必须包含的隐含特征。例如：博文基本交互，支持Markdown 语言书写或者BBcode 书写博文，以及方便后期出现问题可以容易维护。如果不支持，那么就会给用户实际体验造成影响。
对于软件质量定义强调了下述3个要点：
- 软件需求是度量软件质量的基础，与需求不一致的就是质量不高。
- 指定的开发标准定义了一组知道软件开发的准则，如果没有遵守这些准则，很有可能会导致软件质量不高。
- 同上，有一组没有显示描述的隐含需求（例如，软件应该是容易维护的）。如果软件满足明确的描述需求，但是不满足隐含的需求，那么软件的质量任然是值得怀疑的。
为了保证软件质量得以保证，就要实施软件质量保证措施。现在，软件质量保证的措施主要有：基于非执行的测试（也称为复审或评审）；基于执行的测试（即软件测试）和程序正确性证明。对此，软件开发团队中还需要软件质量保证工作的人员。
软件开发团队为什么需要复审？正式技术复审的显著优点是能够较早发现软件的错误，从而可防止从无被传播到软件过程中的后续阶段。统计数字表明，在大型软件产品中检测出的错误，60%~70%属于规格说明错误或设计错误，而正式技术复审在发现规格说明错误和设计错误方面的有效性高达75%。由于能够检测出并排除掉绝大部分这类错误，复审可大大降低后续开发和维护阶段的成本。
复审是软件质量保证措施的其中一种，包括走查 和审查 。走查一般由4~6名成员组成。以走查规格说明小组为例：成员至少包括一名负责起草规格说明的人，一名负责该规格说明的管理员，一位客户代表，以及下阶段开发组的SQA小组 的一名代表。
- 走查主要有下述两种方式：
- 参与者驱动法。参与者按照事先准备的列表进行，对走查小组解释说明他们不理解的术语与不正确的属于。对于上述问题，要么承认有错误要么对此做出解释。
- 文档驱动法。文档编写者向走查小组详细解析文档内容。走查小组在此期间针对各个可能出现的问题提出质疑。
- 而审查的范围比走查广泛得多，通常，审查包括下述5个基本步骤：
- 综述。由负责编写文档的一名成员向审查组说明该文档内容。
- 准备。审查组仔细阅读文档，并发现其中的错误类型，并按照发生的频率进行错误的分级，辅助审查工作。
- 审查。评审组仔细走查整个文档，在这个步骤中也是发现文档中的错误（不修正）。
- 返工。文档负责人负责解决在审查报告中列出错误及问题。
- 跟踪。组长必须确保所提出的每个问题都得到了圆满的解决（例如：修正了文档；澄清了误认为错误的条目）。
审查过程不仅步数比走查多，而且每个步骤都是正规的。审查的正规性体现在： 仔细划分错误类型，并把这些信息运用在后续阶段的文档审查中以及未来产品的审查中。 综上所述，完成整个项目的开发需要经过：工程规模估算、估算开发生命周期、进度计划、人员组织、质量保证、软件配置管理等。
对于一个项目的开发，首先确定好工程规模，只有确定好了工程规模的大小才可进行工作量估算和估算开发生命周期，只有确定好工程规模，确认好所需功能点，合理安排、分配开发者进行人员组织，通过工程量分为小型、中型、大型开发从而根据开发需求以及公司需要合理安排最佳程序员组。其中较为难地方为各组人员之间的通信交流，对于小型项目开发而言不算什么复杂的事情，对于大型项目开发，各组之间的交流，各个不同开发类型的开发者之间的交流如何安排才能够最佳发挥程序员的积极性与主动性。以及在各个程序员开发的过程中避免因为持续开发造成开发中心、开发点偏移。需要由各审查小组在开发的过程中不断指正，修正开发内容以及错误的开发方向。最终，通过质量保证和软件管理配置后交付产品给用户。
对此，各成员之间，各种方式的交流工具必不可少。例如进度计划的甘特图，在各个小组内开发指定任务所分配任务以及规定生命周期的看板。在程序开发中较不可缺少的git （如上图），在发现错误及团队协作中有较大帮助，也可以帮助各程序员之间进行有效的通信交流，避免代码无效冗余，重复执行无意义的工作。 通过软件工程专业导学，深知自己有广阔的发展前景，也让我们知道我们未来面向的企业是如何运转的。对于我们这些软件学习者来说想要成功，不仅要在软件开发层面下功夫，还要再方方面面清楚软件工程相关内容，才能更好地提升自我，才能让我们有更优越的机会。
