软件工程学习笔记6——项目规划篇2

一、项目管理工具

一切管理问题，都应思考能否通过工具解决

1、项目管理工具软件发展史

（1）最初的项目管理软件：项目计划工具

像微软的 MS Project 这样的项目计划工具软件普及，才让制订计划变成了一个相对容易的事情，可以方便的对分解好的任务排出计划。

MS Projec 虽然解决了计划制订的问题，但还是有些不足之处。例如不方便跟踪任务进度，进度不直观等。

再加上后来敏捷开发开始兴起，很多项目都开始采用 Scrum 的方式来进行项目管理，开发变成了迭代的方式，以前单纯的项目计划工具，就不能很好的满足项目管理需要了。

（2）基于 Ticket 的任务跟踪系统

最早在软件项目中，应用 Ticket （标签）跟踪系统的领域是测试领域，用来追踪 Bug，后来逐步衍生到整个项目管理领域，不仅跟踪 Bug，还用来跟踪需求、开发任务等。

也有很多系统用 Issue 来表示 Ticket 的概念，无论 Ticket 还是 Issue，表示的都是一个工作任务，可以包括软件的 Bug、功能需求、某个模块的开发、系统的重构任务等。

一个 Ticket，应该包含：

标题：摘要性的描述 Ticket 内容；
类型：属于什么类型的 Ticket：Bug、需求、任务；
内容：Ticket 的详细内容，例如，如果是 Bug 的话，除了要写清楚 Bug 内容，还需要重现步骤。如果是需求的话，要有需求的描述，可能还需要额外的文档链接辅助说明；
创建人：谁创建的这条 Ticket；
优先级：这个 Ticket 的优先级高还是低；
状态：Ticket 的状态，例如：未开始、处理中、已解决、重新打开、关闭等；
指派给谁：这个 Ticket 被指派给谁了，谁来负责；
历史记录：整个 Ticket 改变的历史信息，用以跟踪；
还有一些其他信息，例如创建时间、附件、标签、版本等。

基于 Ticket 的任务跟踪系统，很好的弥补了项目计划工具的不足，让项目中大大小小的各种开发任务都可以方便的记录跟踪起来。

但仍然存在一些缺点，就是整体的 Ticket 状态还不是很直观，例如不能清楚的看到哪些任务在进行中，哪些任务待领取。缺乏结构化，各任务之间的关系不明确，容易只见树木不见森林，因此不适合做项目规划和任务分解。

（3）基于看板的可视化任务管理

现在的 Ticket 任务跟踪系统几乎都会有看板视图，通过看板可以很直观的看到当前任务进展情况。

整个过程完全不需要项目经理从中协调太多，尤其是结合每日站立会议，可以让项目成员自发有序地按照看板开展日常工作。

2、有哪些项目管理软件可以选择的？

如果单纯是项目计划工具，功能最好、最全的应该是微软的MS Project，但遗憾的是只能运行在 Window 上，不支持 Mac 平台。

如果要在 Mac 上使用项目计划工具，可选的有OmniPlan和Merlin Project。

而且这些项目计划工具，现在也都支持了看板视图。不过如果只是单机支持的话，意义并没有那么大，需要在线版的 Ticket 跟踪结合看板视图，才能让整个团队可以一起浏览操作，发挥其最大效用。

基于 Ticket 的任务跟踪系统，最有名的应该是Atlassian公司出品的Jira软件，功能全面，体验很好。Jira 主要是在海外比较流行，因为访问速度和使用习惯等原因，国内用户要相对少一些。

同类产品也很多，微软的Azure DevOps （以前叫 TFS, Team Foundation Server），和微软系的产品如 Visual Studio、Azure 可以很好的整合。

代码托管平台GitHub本身也集成了一套 Issue 跟踪管理系统，虽然没有 Jira 那么强大，但是对于普通项目来说，足够用了。尤其是对于开源项目，完全可以基于 GitHub 的 Issue 进行日常的项目管理。

国内同类的软件有：

• 禅道：为数不多提供开源版本可以自己搭建的；
• Worktile：集成了即时消息软件；
• TAPD：腾讯出品，可以和腾讯的服务很好整合，例如企业微信和腾讯云；
• 云效：阿里巴巴出品，可以和阿里的服务很好整合，例如阿里云和钉钉；
• DevCloud：华为出品，和华为云有很好的整合。

还有一些其他很多产品，就不一一列举。

二、风险管理

培养风险意识
对软件项目风险的管理，才是体现项目管理水平的地方。项目中的任务，不能盲目乐观，都思考一下它最坏的结果是什么，如果最坏的结果不能接受，就说明要有个 B 计划，考虑风险管理了。

1、如何对风险进行管理？

软件项目风险管理，通常分四步来做。

（1）风险识别，识别可能的风险

识别风险这种事，经验很重要，因为大部分风险其实都是相似的。

一个识别风险的方法叫检查表法，就是可以把类似于上面这些常见风险收集整理起来，分类列成清单，按照清单去检查对照。

软件项目的风险主要分成以下几类：

• 项目风险：项目预算、进度、用户和需求等方面的问题；
• 人员风险：人员离职、人手不足等问题；
• 技术风险：采用的技术所可能带来的风险；
• 商业风险：与市场、产品策略等有关的商业风险。

也可以按照上面的分类整理出自己的风险检查表。

（2）风险量化，对风险进行评估量化

在风险识别出来以后，需要从两个方面去评估：

• 发生的概率多大？
• 发生后，后果多严重？

设置不同的优先级去考虑

（3）应对计划，对风险制定应对策略

针对风险，主要分成以下几个策略。

• 回避风险——更改导致风险的方案
• 转移风险——将损失转嫁出去
• 缓解风险——降低风险发生概率或减少可能造成的损失
• 接受风险——明知山有虎偏向虎山行

（4）风险监控，对风险进行监控预警

要做好监控，第一要能对监控的内容量化，第二要设置阈值，第三就是要有后续的报警和处理机制。

三、项目文档

写文档，其实对个人、对项目、对团队，都是非常重要的事情。

• 帮助写文档的人理清楚思路。
  先写文档，就会抛开代码细节，去站在全局思考。写的时候，各个模块之间的依赖关系、各种可能的安全隐患、各种可能需要其他人配合的地方，就都冒出来了，必须要去查资料，去找人讨论，反复缜密的思考后最终写出来。
  思路没理清，在心中只有一些未成型的混乱的想法和概念，必须要努力把这些模糊的想法确定化和具体化，才能写出来。
• 便于未来的维护和交接
• 团队更好的协作沟通

写文档的时候，主要有几种图比较常用：线框图、流程图、时序图、各种格式的截图。

线框图
线框图是最常用也最实用的一种图形，用简单的方框代替功能、模块、服务等，再用箭头表示关系或者数据流向，非常简单直接。

要画好线框图并不难，主要是要理清楚有哪些模块，以及模块之间的关系是什么。用方框配上文字表示模块，方框之间的连线和箭头表示关系。
如：

流程图
流程图是软件项目文档中一种常用图形，可以方便的表示各种不同条件下的逻辑路径。要画好流程图不难，重点是要理清楚逻辑关系，各个关键节点在不同条件下的走向
如：

时序图
时序图也是软件项目所特有的一种图形，可以表示不同对象之间发送消息的时间顺序，尤其在涉及网络通信的文档中特别常用。

画好时序图，关键是要列清楚所有涉及的对象或者服务，以及消息发送的先后顺序。

如：

各种格式截图
截图也是个非常简单直接的方式，把软件的 UI、交互设计的效果、数据趋势图、数据统计图等直接截图，必要的话配上一些箭头、文字，也可以很好的说明清楚问题。尤其是产品设计文档，经常用到。