软件工程之项目规划
从公众号转载，关注微信公众号掌握更多技术动态
---------------------------------------------------------------
一、可行性研究
可行性研究讲的是如何科学地论证项目的可行性，以及项目是不是值得做。如何科学论证是方式方法，是否值得做则是对投入回报比进行评估。
-
经济可行性：从成本和收益角度分析，看投入产出比。不仅分析短期利益，还要分析长期利益。
-
技术可行性：技术上是否可以实现，不能解决的问题能否规避。
-
社会可行性：法律、道德、社会影响等因素的考量。
1.经济可行性
从投入产出比的计算，来分别统计成本和收益。考虑收益的时候要对短期和长期都进行 分析。
2.技术可行性
技术是否可行，关键还是在人。技术本身需要考虑两个方面：成熟度和覆盖面，对于不能解决的问题能够规避。
3.社会可行性
从三个方面考虑：
-
是否存在不良道德行为
-
是否存在负面社会影响
-
是否违反相关法律法规
二、项目计划
1.如何制定计划
(1)任务分解
WBS（Work Breakdown Structure）：把要做的事情，按照一个树形结构去组织，逐级分解，分割成小而具体的可交付结果，直到不能再拆分为止。
在制定计划的时候，除了要拆解任务，还要反复思考各种存在的问题。对技术细节不清楚的地方，要寻求技术人员的帮助。
(2)估算时间
主要是靠经验，要想估算准确，需要从两个方面入手：
-
任务拆解越细致，想的越清楚，就能估算的越准确。
-
要让负责这个任务的人员参与估算
PERT预估
O乐观预估：如果一切顺利，可以在这个时间内完成，为了保证乐观预估有意义，应当控制概率在10%以下
N标称预估：概率最大的数字，按照正常速度进行的预估
P悲观预估：考虑到可能发生的各种意外
实际时间= O+4N+P/P-O
(3)排路径
根据任务之间的关系，资源占用情况，排出合适的顺序。
2.设置里程碑
里程碑是承诺，不能轻易改变。
Deadline是第一生产力。
里程碑完成后，获得正面激励。
3.计划的跟踪调整
两种方式跟踪进度：
-
项目经理定期收集跟踪
-
项目成员主动汇报
好的实践：
-
每日站立会议
-
看板
4.制定流程和规范
好的项目管理，不需要直接管人管事，，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。
(1)为什么要有流程规范：
-
提升团队效率：
-
将好的实践标准化流程化，让大家可以共享经验
-
借助流程规范，让项目管理从人治到“法治”
(2)如何制定好流程规范
可以通过四个步骤来开展：
-
明确要解决的问题
-
提出解决方案：可以参考软件工程中，大家公认的好的实践。
-
达成共识、推广执行：要得到大家的人可，还需要配合奖惩措施来保障执行。
-
持续优化，不断改进
三、风险管理
风险包含两个方面的内容：
-
发生后，会造成什么损失
-
发生的概率有多大
1.风险识别
识别风险，经验很重要，因为大部分风险其实都是类似的。一个识别风险的方法叫检查表法，类似这样的：
软件项目的风险主要分成以下几类：
-
项目风险：项目预算、进度、用户和需求等方面
-
人员风险：人员离职、人手不足等问题
-
技术风险：采用的技术可能带来的风险
-
商业风险：与市场、产品策略等有关的商业风险。
建议：定期针对风险问题开一些头脑风暴会议，一起发现可能的风险。让项目成员有合适的渠道来反馈可能发生风险的问题。
2.风险量化
风险识别出来之后，需要从两个方面去评估：
-
发生的概率
-
后果的严重程度
划分优先级来制定策略。
3.应对计划
回避风险：对可能发生的风险，放弃或修改导致风险的方案，从源头消除。
转移风险：将损失转嫁出去，比如对自己不在行的服务，购买专业的服务产品。
缓解风险：在风险发生前采取措施，降低风险发生的概率。比如涨工资来留住核心成员
接受风险：在一些风险本身很难避免，或者应对风险的成本超过风险发生后造成的损失，那就勇敢一点吧！
4.风险监控
要做好监控，需要做好三个方面：
-
能对监控的内容量化
-
设置阈值
-
要有后续的报警和处理机制
四、项目管理工具
1.项目计划工具
MS Project在分解任务和排计划方面十分方便直观。
2.基于Ticket的任务跟踪系统
Ticket跟踪最早源于客服的工单系统，每次客服接到一个问题，就创建一个工单，后续和客户的每一次交流和处理，都要更新工单内容和状态，直到结束。
一个Ticket应该包含的信息如下：
-
标题：摘要性地描述Ticket内容
-
类型：属于什么类型的Ticket：Bug、需求、任务
-
内容：Ticket的详细内容。如，bug的话，包含bug内容和重现步骤
-
创建人
-
优先级
-
状态：未开始、处理中、已解决、重新打开、关闭等
-
指派给谁
-
历史记录
利用燃尽图可以直观的预测工作将在何时全部完成。
缺点：整体Ticket状态不是很直观，不能清楚看到哪些任务在进行中
3.基于看板的可视化任务管理
通过看板可以很直观地看到当前任务进展情况。
普通项目成员使用看板的流程：
4.工具的选择
项目计划工具：MS Project（windows）、OmniPlan和Merlin Project（Mac）
基于Ticket的任务跟踪系统：Jira、Azure DevOps、Github的issue
国内同类产品：
5.维护一个项目概念列表
每个项目都有自己的词汇表：对团队有特殊意义的术语。“Order”对于开发在线商店的团队来说是一回事，而对于记录宗教团体的世系的应用程序来说，意味着完全不同的另一件事。重要的是，团队中的每个人都知道这些词的意思，并始终如一地使用它们。一种方法是鼓励大量的交流。如果每个人都参与结对编程，并且频繁地交换结对，那么术语就会渗透性地传播开来。另一种方法是使用项目术语表，列出对团队有特殊意义的术语。这是一个非正式的文档，可以在 wiki 上创建并维护，也可以将索引卡片挂在墙上。过一段时间，项目术语将会有自己的生命。随着每个人都熟悉了这些词汇，就能够把这些术语用作简称，准确而简洁地表达许多意思。（这正是模式语言所指。）
维护一个概念列表，可以保证团队交流的准确性，避免你说的是A，我理解成B的情况。一个项目中有不同的角色，业务方、产品、前端、后端、算法、数据，对于一起开会时经常提起的概念，大家的理解并不一定一致。举个简单的例子，比如业务方有个二分类的需求，要从一些商户中找到其中不合规的商户，模型预测结果如下图所示，但是一个人以为的准确率是(a + d) / (a + b + c + d)，另一个人以为的是d / (b + d)。如果没有在项目之初明确下来大家关注指标的具体含义，那可能出现各说各的的情形。技术按照一个计算逻辑承诺并达成了准确率指标，业务方按照另一个逻辑计算后发现准确率远远没达到，这会给团队合作带来障碍。